Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 71
Может быть, вышел?
> Вышла jQuera.
> Вышла jQuera.
С другой стороны, «библиотека jQuery». Или даже «библиотека Джквери». :)
C третьей фреймворк — он.
фремйворк — это чуть чуть другое ru.wikipedia.org/wiki/Фреймворк
это скорее библиотека, т.к используются просто функции, а не строится целая система
это скорее библиотека, т.к используются просто функции, а не строится целая система
В следующем подобном топике (вот будет 1.9.1 через несколько дней...) хорошо бы сделать опрос: «Вы считаете правильным называть jQuery
1) библиотекой?
2) фреймворком?
3) всё равно как?
Считаю, что правильно первое, так как фреймворк, как определяется по ссылке, предполагает жёсткую структуру разработанного кода, а библиотека — нет. А jQuery — сама гибкость в разработке.
1) библиотекой?
2) фреймворком?
3) всё равно как?
Считаю, что правильно первое, так как фреймворк, как определяется по ссылке, предполагает жёсткую структуру разработанного кода, а библиотека — нет. А jQuery — сама гибкость в разработке.
Ссылки бы не помешали. Что-то мне подсказывает, что в оффрелизе больше информации.
Молодцы! Наконец хоть кто-то начал принимать жесткие меры, чтобы убить ненужные версии IE! Я про версию 2.0
Вы о чем? С выходом Windows 8 большинство крупных компаний (в том числе и гугл) отказался от поддержки IE8 (оно и понятно, в большинстве своем идет поддержка только двух последних версий браузера). Только вот для разработчиков это погоды не делает. Большая часть моих проектов идет под корпоративные нужды, и там поддержка IE7 нужна довольно часто.
+1, в моей конторе IE8 поддерживают.
Не понимаю зачем нужна поддержка IE7, особенно под корпоративные нужды. IE8 — понимаю, IE7 — не понимаю.
В одном из мною поддерживаемых проектов 5% пользователей сидят на ИЕ6. И их игнорировать ни в коем случае нельзя! Это посетители из очень мелких городов и деревень. Они не виноваты в том, что родились в глубинке и зп 3-5 руб. тыс/мес и низкая компьютерная грамотность это норма и об обновлении компьютерного парка не может быть речи.
где родились — не виноваты. А вот в уровне грамотности только они сами и виноваты, никто другой.
Но если они целевая аудитория проекта, то конечно же, нужно поддерживать IE6.
Но если они целевая аудитория проекта, то конечно же, нужно поддерживать IE6.
Я говорю про IE7, а не IE6. В пользу поддержки IE6 говорит то, что это дефолтный браузер в XP. В пользу IE8 — что это максимум для XP и дефолт для 7. IE7 не примечателен ни чем подобным (дефолтность его в Vista по-моему нельзя ставить в тот же ряд по значимости). Согласно приведённым в Wikipedia данным Net Applications доля IE7 сейчас еще меньше, чем IE6, что вполне логично.
А ещё была упомянута корпоративная среда, где используемое ПО обычно более-менее контролируется.
А ещё была упомянута корпоративная среда, где используемое ПО обычно более-менее контролируется.
Помниться мне пытались мы на одном довольно крупном проекте попросить заказчика обновить версию браузера. У него приблизительно 100К сотрудников, и приблизительно 10-15% на IE7. Все пользователи сидят через тонкие клиенты, ну и подсчитав предположительные затраты на обновление (ресурсы тех поддержки, администраторов и т.д.) вышло это дело существенно дороже чем просто дать нам еще 100 часов на внедрение поддержки этого браузера.
Банальная математика. На мелкий фирмах эти вопросы решаются проще, только вот корпоративный сегмент не только из таких состоит.
Банальная математика. На мелкий фирмах эти вопросы решаются проще, только вот корпоративный сегмент не только из таких состоит.
У него приблизительно 100К сотрудников, и приблизительно 10-15% на IE7. Все пользователи сидят через тонкие клиенты, ну и подсчитав предположительные затраты на обновление (ресурсы тех поддержки, администраторов и т.д.) вышло это дело существенно дороже
Что-то я не понял, тонкие клиенты же тем и красны, что весь софт в одном месте на сервере и обновляется централизованно с пол тычка (особенно в случае обновления IE7 на IE8, которые с точки зрения системы, на сколько я понимаю, практически идентичны (т.е. структурных изменений и сюрпризов вроде можно не ждать — фиганул апдэйт и всё)).
И вообще я думал, что в о всех более-менее крупных (>10 машин) компаниях обновления выкатываются на весь домен (или по кусочкам для надёжности) через Active Directory и пользователь, если он не слишком «продвинутый», часто даже не в курсе.
Проще сбросить IE8 в режим IE7 и поддерживать таким образом вместо двух браузеров один, пусть и более старый.
Мне кажется это правильное решение для таких случаев:
И осёл будет работать, и не-ослы получат более лёгкий и быстрый вариант
<!--[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]-->
И осёл будет работать, и не-ослы получат более лёгкий и быстрый вариант
Это только замедлит переход на версию 2
Значит никогда так и не отсекать? Уже сколько лет все ноют, что старые версии IE пора убить, так убивайте сами: хватит верстать с хаками и другими плюшками!
Выходит новая технология и всегда один и тот же каверзный вопрос: «а как же ie6?».
Да, вечный аргумент будет, что заказчик так просит. Так заказчика надо убедить в том, что это не надо, а не соглашаться сразу же с ним.
Выходит новая технология и всегда один и тот же каверзный вопрос: «а как же ie6?».
Да, вечный аргумент будет, что заказчик так просит. Так заказчика надо убедить в том, что это не надо, а не соглашаться сразу же с ним.
Поддерживаю. Принципиально не соглашаюсь делать верстку под версии ниже IE9.
А что делать если в хрюшке нет новых версий IE.
Ещё можно спросить, а как же lynx
В среднем 13-15% пользователей используют IE согласно webrowser.ru/rynok/statistika-ispolzovaniya-brauzerov-za-iyul-2012-goda.html. По больше части это домохозяйки, которым в принципе все равно, какой они браузер используют. Если Ваш продукт не ориентирован на домохозяек — Вы потеряете 0-5% потенциальных посетителей. Учтите, сколько времени и хаков необходимо, чтобы добиться в старых версиях IE адекватного отображения современных эффектов. Я считаю, что игра не стоит свеч.
Ну, и всегда можно проверить User Agent и дать посетителю ссылку на browsehappy.com/.
Ну, и всегда можно проверить User Agent и дать посетителю ссылку на browsehappy.com/.
Поддерживаю. Принципиально не соглашаюсь делать верстку под версии ниже IE9.
Идеологически, конечно, похвально, но слишком радикально с прагматической точки зрения. Всё-таки самая распространённая версия IE — 8, с 9 они уже почти поравнялись, но до ухода доли IE8 в достаточно малые для пренебрежения величины ещё, увы, далековато.
А чем не угодила функция $.browser? Или есть новая реализация?
Разработчики советуют использовать библиотеки типа modernizr.
Кстати, от $.browser зависит много плагинов. Например в Yii Framework используется jquery.ba-bbq.js. jQuery 1.9 ломает этот плагин.
Но есть временное спасение — github.com/jquery/jquery-migrate/
Кстати, от $.browser зависит много плагинов. Например в Yii Framework используется jquery.ba-bbq.js. jQuery 1.9 ломает этот плагин.
Но есть временное спасение — github.com/jquery/jquery-migrate/
Ибо $.browser это моветон. Если уж так нужна эта функция, ее можно спокойно слепить самостоятельно.
Вместо нее рекомендуют использовать
$.support
Вы бы писали, что это перевод статьи в официальном блоге. (Не весь, конечно, но своих фраз в этой статье нету)
Зачем, в этом нет никакого смысла, точнее практического.
«migrate» нужен для того, чтобы узнать какие функции могут вызвать проблемы с 1.9
Там же (github/jquery-mirgrate) написано, что подключать её можно с 1.6.4+, чтобы узнать о потенциальных ошибках, но акутально это только для 1.9 соответственно.
Я думаю если используется куча плагинов, то если острой необходимости нету в нем, лучше оставить как есть.
А так для новых проектов использовать, постепенно с разработкой подключая нужные плагины и проверять на работоспособность, или искать/делать альтернативу устаревшему коду.
«migrate» нужен для того, чтобы узнать какие функции могут вызвать проблемы с 1.9
Там же (github/jquery-mirgrate) написано, что подключать её можно с 1.6.4+, чтобы узнать о потенциальных ошибках, но акутально это только для 1.9 соответственно.
Я думаю если используется куча плагинов, то если острой необходимости нету в нем, лучше оставить как есть.
А так для новых проектов использовать, постепенно с разработкой подключая нужные плагины и проверять на работоспособность, или искать/делать альтернативу устаревшему коду.
Вот в упор не понимаю, зачем убирать $.browser.
То есть, объяснения авторов библиотеки на этот счёти знаю, но как-то очень неубедительно.
Не всегда можно обойтись тем, что браузер что-то умеет или не умеет.
Вот реальный пример: если в IE8 на windows xp менять opacity, а иногда даже и размеры, у картинки png24 с полупрозрачностью, то на месте полупрозрачности появляются некрасивые чёрные артефакты. Вот как отлавливать и обрабатывать эту ситуацию? Сейчас делаю так:
if($.browser.msie && parseInt($.browser.version)
То есть, объяснения авторов библиотеки на этот счёти знаю, но как-то очень неубедительно.
Не всегда можно обойтись тем, что браузер что-то умеет или не умеет.
Вот реальный пример: если в IE8 на windows xp менять opacity, а иногда даже и размеры, у картинки png24 с полупрозрачностью, то на месте полупрозрачности появляются некрасивые чёрные артефакты. Вот как отлавливать и обрабатывать эту ситуацию? Сейчас делаю так:
if($.browser.msie && parseInt($.browser.version)
не надо придираться :)
$(«img»).css({opacity:0.5}) отработает. Фильтрами, но отработает. Имелось в виду именно это.
Кстати, видимо хабр обрезал мой предыдущий пост на половине кода. Ну да и ладно. Всё равно там ничего особо ценного не было, а мысль донести вроде удалось.
Modernizr не входит в состав jQuery, не так ли? ;)
То есть, получилось, что для уменьшения веса и быстродействия нужно подключать ещё одну библиотеку. Как-то я тут логики не улавливаю.
$(«img»).css({opacity:0.5}) отработает. Фильтрами, но отработает. Имелось в виду именно это.
Кстати, видимо хабр обрезал мой предыдущий пост на половине кода. Ну да и ладно. Всё равно там ничего особо ценного не было, а мысль донести вроде удалось.
Modernizr не входит в состав jQuery, не так ли? ;)
То есть, получилось, что для уменьшения веса и быстродействия нужно подключать ещё одну библиотеку. Как-то я тут логики не улавливаю.
Реальный пример: отличить мобильный браузер от десктопного для дебага, тк. у них разные процессы авторизации на фейсбуке.
Дайте-ка попиарить Зепто: zeptojs.com/
www.jqmobi.com/ — оставлю это вам.
Для справки Zepto хоть и весит меньше, работает медленнее jQuery. Что на мобильных девайсах особенно критично.
Для справки Zepto хоть и весит меньше, работает медленнее jQuery. Что на мобильных девайсах особенно критично.
Можно пруф?
jsperf.com/jqm3/79 — тут притянуто за уши, ибо так делать не стоит. Но все же.
jsperf.com/jqm3/85 — выборка по селекторам.
jsperf.com/jqm3/85 — выборка по селекторам.
Еще бы указали, что в версии 1.9 появилась поддержка Source Map
Подробнее по ссылке www.elijahmanor.com/2013/01/the-magic-of-jquery-source-map.html
Подробнее по ссылке www.elijahmanor.com/2013/01/the-magic-of-jquery-source-map.html
live убрали
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Вышел JQuery 1.9