Пользователь
0,0
рейтинг
16 января 2013 в 12:45

Разработка → Вышел JQuery 1.9 recovery mode

image

Сегодня наконец был выпущен новый релиз JQuery версии 1.9. Давайте глянем какие нововведения и изменения мы тут увидим.



Jquery 1.9 и находящийся в бете Jquery 2.0 имеют схожий API.
Удалены некоторые устаревшие функции, такие как $.browser.

JQuery 1,9 пока еще работает на устаревших версиях Internet Explorer 6, 7 и 8. Но в версии JQuery 2.0 поддержка будет прекращена. Благодаря этому работать он будет быстрее и весить, соответственно, меньше.

Версия 1.9 уже доступна на CDN jquery и в ближайшем времени будет доступна на CDN Google и Microsoft





Для тех кто хочет проверить свои скрипты на JQuery 2.0 Beta 1 можно использовать JQuery CDN:





Для проверки вы можете подключить плагин jquery-migrate. Чтобы увидеть какие изменения могут вызвать проблемы с вашим кодом. Независимо от того какую версию Jquery вы используете, не забудьте открыть консоль, чтобы увидеть предупреждения или ошибки которые генерирует jquery-migrate. Предупреждения начинаются со слова «JQMIGRATE» и перечислены в документации плагина. Это поможет вам понять, что сломалось и как это можно исправить.

ЧТО НОВОГО В 1.9

Упрощенный API: многие устаревшие и сомнительные функции были удалены, как описано в обновлении руководства.

Обновлена функция .css(): Теперь Вы можете получить все значения css, запросив массив с ключами:
var dims = $("#box").css([ "width", "height", "backgroundColor" ]);
// { width: "10px", height: "20px", backgroundColor: "#D00DAD" }


Расширениная кросс-браузерная поддержка CSS3: JQuery 1,9 теперь поддерживает следующие CSS3 селекторы во всех браузерах: :nth-last-child, :nth-of-type, :nth-last-of-type, :first-of-type, :last-of-type, :only-of-type, :target, :root, и :lang.

Новый метод .finish: Этот метод может быть использован, чтобы немедленно завершить все анимации в очереди на элемент.

Другие исправления

AJAX
# 12004: Добавлен метод ajax.method как псевдоним для ajax.type
# 12550: Исправлен JQuery Ajax cache=false не всегда работал

ATTRIBUTES
# 9905:. RemoveAttr («ID») теперь не даёт сбои в IE7
# 12048: [IE6/7/8] XML набор атрибутов
# 12584: JQuery неправильно сериализует с одной сломанной # 12600: jQuery(‘select’).is(‘[value=«value»]‘) работает непоследовательно в зависимости от числа возвращаемых элементов.
# 12945: Attr бросает исключение в IE9 на Flash object
# 13011: Установка атрибута type на входе не работает как положено

BUILD
# 12254: Reflected XSS
# 12725: Не локализованные UTF-8 символы в intro.js
# 12741: несовместимый конц строки в официальном JQuery-1.8.2.js

CORE
# 11737: Удалён jQuery.sub
# 12134. Реализации HTML5 compilant data form в $ fn.serialzeArray
# 12519: Public методы API не должны иметь privat аргументы
# 12840: Удалён (privat) параметр «pass» в jQuery.attr и jQuery.access
# 13021: each() не может хорошо работать с большими объектами
# 13075. Оптимизация производительности $.type
# 13076: Оптимизация производительности (10-30%) для $(“some-selector”)

CSS

# 11938: jQuery.css должны принять массив, чтобы получить несколько свойств
# 12990: «px» автоматически добавляется в колонке количество в CSS
# 13088. Под IE8, $(selector).attr(‘style’) всегда возвращает строку

Ссылки

Официальный сайт
Весь список изменений
Руководство по миграции
Канев Виталий @xamelion
карма
2,0
рейтинг 0,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Спецпроект

Самое читаемое Разработка

Комментарии (71)

  • –1
    Может быть, вышел?

    > Вышла jQuera.
    • +6
      С другой стороны, «библиотека jQuery». Или даже «библиотека Джквери». :)
      • –2
        C третьей фреймворк — он.
        • +1
          фремйворк — это чуть чуть другое ru.wikipedia.org/wiki/Фреймворк
          это скорее библиотека, т.к используются просто функции, а не строится целая система
          • 0
            В следующем подобном топике (вот будет 1.9.1 через несколько дней...) хорошо бы сделать опрос: «Вы считаете правильным называть jQuery
            1) библиотекой?
            2) фреймворком?
            3) всё равно как?
            Считаю, что правильно первое, так как фреймворк, как определяется по ссылке, предполагает жёсткую структуру разработанного кода, а библиотека — нет. А jQuery — сама гибкость в разработке.
            • +1
              jQuery Это библиотека. Ибо на главной странице так и написано: jQuery is a fast and concise JavaScript Library. Да и потом, это компонент который можно заменить любым другим.
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Большинство старых скриптов нормально работающих в версии 1.8.3 c криками открываются в 1.9. Ну чтож, молоток и jquery-migration в руки и пошёл допиливать!)
      • 0
        свой код допиливать это ладно, но падают некоторые плагины, вернулся пока на 1.8.3
        • 0
          Падают даже при подключенном migrate плагине?
  • –3
    Ссылки бы не помешали. Что-то мне подсказывает, что в оффрелизе больше информации.
    • +2
      В релизе не больше, а вот в руководстве по апгрейду всё подробно написано.
      jquery.com/upgrade-guide/1.9/

  • +12
    Молодцы! Наконец хоть кто-то начал принимать жесткие меры, чтобы убить ненужные версии IE! Я про версию 2.0
    • +3
      Вы о чем? С выходом Windows 8 большинство крупных компаний (в том числе и гугл) отказался от поддержки IE8 (оно и понятно, в большинстве своем идет поддержка только двух последних версий браузера). Только вот для разработчиков это погоды не делает. Большая часть моих проектов идет под корпоративные нужды, и там поддержка IE7 нужна довольно часто.
      • 0
        +1, в моей конторе IE8 поддерживают.
        • 0
          У нас только если есть в спецификации. Беда в том что в одном из 3-х проектов попадается IE7+. Хотя все же уже реже чем год назад.
      • –3
        Не понимаю зачем нужна поддержка IE7, особенно под корпоративные нужды. IE8 — понимаю, IE7 — не понимаю.

        • 0
          В одном из мною поддерживаемых проектов 5% пользователей сидят на ИЕ6. И их игнорировать ни в коем случае нельзя! Это посетители из очень мелких городов и деревень. Они не виноваты в том, что родились в глубинке и зп 3-5 руб. тыс/мес и низкая компьютерная грамотность это норма и об обновлении компьютерного парка не может быть речи.
          • +1
            где родились — не виноваты. А вот в уровне грамотности только они сами и виноваты, никто другой.
            Но если они целевая аудитория проекта, то конечно же, нужно поддерживать IE6.
          • +1
            Я говорю про IE7, а не IE6. В пользу поддержки IE6 говорит то, что это дефолтный браузер в XP. В пользу IE8 — что это максимум для XP и дефолт для 7. IE7 не примечателен ни чем подобным (дефолтность его в Vista по-моему нельзя ставить в тот же ряд по значимости). Согласно приведённым в Wikipedia данным Net Applications доля IE7 сейчас еще меньше, чем IE6, что вполне логично.

            А ещё была упомянута корпоративная среда, где используемое ПО обычно более-менее контролируется.
            • +1
              не поверите, IE8 сейчас стоит на большинстве машин с Win XP. А там где стоит IE7 — видать обновляли когда IE8 еще небыл доступен в автообновлении. Тут все зависит от инфраструктуры. И иногда кроме как смириться и делать под IE ничего не остается.
              • 0
                не поверите, IE8 сейчас стоит на большинстве машин с Win XP

                Это почему же не поверю? :-) Совершенно логично. А IE7 — таки на меньшинстве.
        • 0
          Помниться мне пытались мы на одном довольно крупном проекте попросить заказчика обновить версию браузера. У него приблизительно 100К сотрудников, и приблизительно 10-15% на IE7. Все пользователи сидят через тонкие клиенты, ну и подсчитав предположительные затраты на обновление (ресурсы тех поддержки, администраторов и т.д.) вышло это дело существенно дороже чем просто дать нам еще 100 часов на внедрение поддержки этого браузера.

          Банальная математика. На мелкий фирмах эти вопросы решаются проще, только вот корпоративный сегмент не только из таких состоит.
          • 0
            У него приблизительно 100К сотрудников, и приблизительно 10-15% на IE7. Все пользователи сидят через тонкие клиенты, ну и подсчитав предположительные затраты на обновление (ресурсы тех поддержки, администраторов и т.д.) вышло это дело существенно дороже

            Что-то я не понял, тонкие клиенты же тем и красны, что весь софт в одном месте на сервере и обновляется централизованно с пол тычка (особенно в случае обновления IE7 на IE8, которые с точки зрения системы, на сколько я понимаю, практически идентичны (т.е. структурных изменений и сюрпризов вроде можно не ждать — фиганул апдэйт и всё)).

            И вообще я думал, что в о всех более-менее крупных (>10 машин) компаниях обновления выкатываются на весь домен (или по кусочкам для надёжности) через Active Directory и пользователь, если он не слишком «продвинутый», часто даже не в курсе.
        • 0
          Проще сбросить IE8 в режим IE7 и поддерживать таким образом вместо двух браузеров один, пусть и более старый.
      • 0
        Мне кажется это правильное решение для таких случаев:

        <!--[if lt IE 9]>
            <script src="jquery-1.9.0.js"></script>
        <![endif]-->
        <!--[if gte IE 9]><!-->
            <script src="jquery-2.0.0.js"></script>
        <!--[endif]-->
        

        И осёл будет работать, и не-ослы получат более лёгкий и быстрый вариант
    • +1
      Это только замедлит переход на версию 2
      • 0
        Значит никогда так и не отсекать? Уже сколько лет все ноют, что старые версии IE пора убить, так убивайте сами: хватит верстать с хаками и другими плюшками!

        Выходит новая технология и всегда один и тот же каверзный вопрос: «а как же ie6?».

        Да, вечный аргумент будет, что заказчик так просит. Так заказчика надо убедить в том, что это не надо, а не соглашаться сразу же с ним.
        • +1
          Поддерживаю. Принципиально не соглашаюсь делать верстку под версии ниже IE9.
          • 0
            А что делать если в хрюшке нет новых версий IE.
            • 0
              Ещё можно спросить, а как же lynx
              • 0
                Не все ломятся апргейдить железо после выхода новой версии windows. Им хватает то что есть: работает, пусть работает. Это касается и корпоративного сектора
            • 0
              В среднем 13-15% пользователей используют IE согласно webrowser.ru/rynok/statistika-ispolzovaniya-brauzerov-za-iyul-2012-goda.html. По больше части это домохозяйки, которым в принципе все равно, какой они браузер используют. Если Ваш продукт не ориентирован на домохозяек — Вы потеряете 0-5% потенциальных посетителей. Учтите, сколько времени и хаков необходимо, чтобы добиться в старых версиях IE адекватного отображения современных эффектов. Я считаю, что игра не стоит свеч.

              Ну, и всегда можно проверить User Agent и дать посетителю ссылку на browsehappy.com/.
              • 0
                По большей части старые версии IE используют не домохозяйки а корпоративный сегмент. Поэтому, если вы делаете сайт для компании B2B, и игнорируете старые версии IE, то вы обрекаете их на потерю существенной доли корпоративных посетителей.
          • +1
            Поддерживаю. Принципиально не соглашаюсь делать верстку под версии ниже IE9.

            Идеологически, конечно, похвально, но слишком радикально с прагматической точки зрения. Всё-таки самая распространённая версия IE — 8, с 9 они уже почти поравнялись, но до ухода доли IE8 в достаточно малые для пренебрежения величины ещё, увы, далековато.
  • +25
    Не забудьте презерватив перед тем, как пробовать JQuery на␣конец.
    • –19
      Я до сих пор не пойму что ты за безграмотную ерунду написал. Пишется правильно «Наконец» в данном контексте!
      • +3
        То есть пост Вы не читали?
  • +2
    А чем не угодила функция $.browser? Или есть новая реализация?
    • +1
      Разработчики советуют использовать библиотеки типа modernizr.
      Кстати, от $.browser зависит много плагинов. Например в Yii Framework используется jquery.ba-bbq.js. jQuery 1.9 ломает этот плагин.
      Но есть временное спасение — github.com/jquery/jquery-migrate/
      • 0
        Спасибо за разъяснения, я думаю пока функцию можно было и оставить, хотя бы до версии 2.0, видимо не «помещались» по размерам
        • +2
          jQuery.browser
          version added: 1.0
          version deprecated: 1.3 removed: 1.9

          Куда ещё тянуть? Да и сам смысл релиза был — выкатить все обновления и исправления, но оставить поддержку старых IE.
    • +1
      Ибо $.browser это моветон. Если уж так нужна эта функция, ее можно спокойно слепить самостоятельно.
    • +2
      Вместо нее рекомендуют использовать $.support
      • 0
        Определять браузер тоже нужно: чтобы показать пользователю определенные инструкции (установка закладки и т.д.)
  • +2
    Вы бы писали, что это перевод статьи в официальном блоге. (Не весь, конечно, но своих фраз в этой статье нету)
    • +4
      Недоперевод.

      # 12584: JQuery неправильно сериализует с одной сломанной
      • 0
        compilant --> compliant
  • 0
    На github.com/jquery/jquery-migrate/ написано так.

    <script src="http://code.jquery.com/jquery-1.8.3.js"></script>
    <script src="http://code.jquery.com/jquery-migrate-1.0.0.js"></script>

    Судя по исходному коду, так и должно быть. Надо подключать старую версию и находить фрагменты, которые не будут работать в новой. В блоге и в статье ошибка.
    • 0
      Зачем, в этом нет никакого смысла, точнее практического.
      «migrate» нужен для того, чтобы узнать какие функции могут вызвать проблемы с 1.9
      Там же (github/jquery-mirgrate) написано, что подключать её можно с 1.6.4+, чтобы узнать о потенциальных ошибках, но акутально это только для 1.9 соответственно.

      Я думаю если используется куча плагинов, то если острой необходимости нету в нем, лучше оставить как есть.
      А так для новых проектов использовать, постепенно с разработкой подключая нужные плагины и проверять на работоспособность, или искать/делать альтернативу устаревшему коду.
      • 0
        Прошу прощения, не сразу понял, что в jquery-migrate восстановлен весь удалённый функционал, а не только предупреждения проставлены.
  • +1
    Вот в упор не понимаю, зачем убирать $.browser.
    То есть, объяснения авторов библиотеки на этот счёти знаю, но как-то очень неубедительно.
    Не всегда можно обойтись тем, что браузер что-то умеет или не умеет.
    Вот реальный пример: если в IE8 на windows xp менять opacity, а иногда даже и размеры, у картинки png24 с полупрозрачностью, то на месте полупрозрачности появляются некрасивые чёрные артефакты. Вот как отлавливать и обрабатывать эту ситуацию? Сейчас делаю так:
    if($.browser.msie && parseInt($.browser.version)
    • 0
      > Вот реальный пример: если в IE8 на windows xp менять opacity

      В IE8 нет opacity.

      > Вот как отлавливать и обрабатывать эту ситуацию?

      Отлавливать её следует через Modernizr.opacity
      • 0
        не надо придираться :)
        $(«img»).css({opacity:0.5}) отработает. Фильтрами, но отработает. Имелось в виду именно это.
        Кстати, видимо хабр обрезал мой предыдущий пост на половине кода. Ну да и ладно. Всё равно там ничего особо ценного не было, а мысль донести вроде удалось.
        Modernizr не входит в состав jQuery, не так ли? ;)
        То есть, получилось, что для уменьшения веса и быстродействия нужно подключать ещё одну библиотеку. Как-то я тут логики не улавливаю.
        • +1
          Никто не запрещает вам самому теперь парсить user-agent или написать собственный микротест для opacity.
          Только вот парсить user-agent — плохая практика. Да и сам jQuery не предназначен для этого.
          Правильно — проверять доступность. Modernizr сделан специально для этого.

          Modernizr не входит в состав jQuery, но и ваши скрипты тоже. Проблемы совместимости — ваши проблемы.

          cssuseragent.org/ — вот ещё один инструмент. Предназначен именно для анализа user-agent.
          • 0
            да ну…
            всё это костыли.
            А вообще сейчас самое время переосмысливать полностью подход к веб-разработке и кроссбраузерности.
            jQuery такими решениями даже помогает в этом.
      • 0
        Прошу пардону, jQuery.support.opacity позволяет проверять поддержку того самого opacity.
        • 0
          К сожалению, оно не позволяет проверить корректность этой самой поддержки.
    • 0
      Реальный пример: отличить мобильный браузер от десктопного для дебага, тк. у них разные процессы авторизации на фейсбуке.
    • 0
      в крайнем случае проверять браузер на php
      • 0
        Зачем? Вот ейбогу не пойму.
  • 0
    Дайте-ка попиарить Зепто: zeptojs.com/
    • 0
      www.jqmobi.com/ — оставлю это вам.

      Для справки Zepto хоть и весит меньше, работает медленнее jQuery. Что на мобильных девайсах особенно критично.
      • 0
        Можно пруф?
        • +1
          jsperf.com/jqm3/79 — тут притянуто за уши, ибо так делать не стоит. Но все же.
          jsperf.com/jqm3/85 — выборка по селекторам.
          • 0
            Мда, спасибо.
  • +1
    Еще бы указали, что в версии 1.9 появилась поддержка Source Map
    Подробнее по ссылке www.elijahmanor.com/2013/01/the-magic-of-jquery-source-map.html
  • 0
    После перехода отловил лишь одну ошибку — некорректный .ajaxComplete для связи с php-обработчиком.
    Изучил документацию и сразу исправил. Благо есть Migrate для отладки.
    Другое дело сложно тем, кто с множеством плагинов связан.
  • 0
    live убрали
    • 0
      Этот метод давно числится как устаревший и давно не рекомендован к использованию.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.