s0rr0w

А в чем сложность написать его самому?

Та легкотня. Чо там учить? 12 типов нод, 109 тегов, 112 атрибутов, и все.

Вообще миграции в промышленной разработке - зло. Нужно очень хорошо подумать, прежде чем переходить на новые версии. Лично для меня вынужденная миграция осуществяется только если 1. Повышается безопасность 2. Повышается надежность 3. Повышается быстродействие, которое может принести осязаемую прибыль, а не ожидание прибыли. Во всех остальных случаях этого не стоит делать. Баги имеют свойство накапливаться.

Только не в разгаре разработки. Можно возразить, что пока будут исправляться ошибки, люди научатся новым трюкам, и потом будут писать быстрее, но это не так. Новые "баги" быстро сожрут время, при этом результат будет нулевым. Ни одного, ни второго не успеете. То, что раньше работало, может перестать. Переход страшен не переписыванием кода, а перетестированием всего и вся. Три раза в рамках одного проекта. Первый раз был самым тяжелым, так как кардинально менялся синтаксис. Второй раз был легче, так как менялась версия библиотеки вместе с дизайном. Третий раз был проще всего - это была косметика, которая укладывалась в рамки автозамены В случае с jQuery - не актуален. Во второй версии не появилось ничего такого, что могло бы существенно повлиять на 1. Скорость разработки 2. Скорость поддержки 3. Методику разработки Это всего лишь мелкие твики, улучшайзеры. Единственный пункт, который меня беспокоит, это http://bugs.jquery.com/ticket/12254

Правильно. И каждый браузер пытается смотреть не к вам на комп, а на свой.

Протокол file:// указывает на локальные файлы компьютера. Даже если заменить на http://, то все равно работать не будет из-за указания домена localhost и абсолютного пути к файлу Почитайте в гугле про абсолютные и относительные пути

Гугл закрыли?

А если перефразировать в "Сделай селект-затравку, подменяй им пустышки" - то не воспринимается вообще никак. Лучше перебдеть, чем недобдеть, и выдать почти готовый алгоритм (не хватает инициализации при ховере)

Обратиться к атрибуту with, сравнить его с нужным числом

Я все слышу...

Делается "тупо" до безобразия Сначала создаем один селект где-то в скрытой области кода (display:none). Пусть это у нас будет #parking Потом делаем на месте каждого селекта выбора профессии пустой селект-затравку, у которого нет ни одного <option> Навешиваем на select'ы hover, по которому селект-затравку прячем, а перед ним вставляем запаркованый селект (insertBefore) Кликать человек будет по наполненному опциями селекту. По blur'у чистим селект-затравку, удаляя все option внутри, и добавляем тот option, который только что выбрал пользователь, паркуем полный селект снова в #parking (appendChild), показываем селект-затравку (он будет содержать как раз выбранный опшин) Вуаля!

Каждый делает отладку ровно так, как привык делать, и как позволяет делать архитектура приложения. Мне позволяет делать в пару кликов, или вообще без кликов.

http://jsfiddle.net/htRSQ/ Это банальная декларация функции внутри блока. Обратить внимание, что "a inside b" показывается 2 раза, вместо ожидаемого "a" По спеке сначала ищутся все декларации функции внутри scope, потом определяются, потом уже выполняется общий поток

Ничего не понял

HTML5 != HTML Для HTML5 это действительно уже не так, и разрыв наступил в момент, когда появились собственные parsing rules. Голова дырявая становится, сам же читал про это недавно...

Не надо по файлам, надо по исходному коду

На самом деле идея родилась где-то в районе 2005-го года. По-моему, даже раньше jQuery. В более-менее современном виде - с 2008-го года Ну да, кому он нужен... HTML не противоречит SGML, поэтому является подмножеством. SVG, VML, MathML, VRML, OTD... Да, пожалуй никому SGML не нужен. В HTML5 нет прямого запрета на использование любых атрибутов или тегов. Если валидатор этого не понимает, то это проблемы валидатора. data-* удобен тем, что имеет в JS интерфейс dataset, минуя getAttribute, его можно итерировать как обычный массив. Но никто не запрещает сделать аналогичную обертку, используя прямой доступ к атрибутам.

Если вы всегда решаете задачу только в лоб, то конечно же, ваше решение вполне подойдет. Можно, правда, выкинуть лишний кусок со сплитом, потому что потом все равно используются регулярные выражения, так почему бы сразу не искать нужные цифры? if (str.match(/[?|&]id=(\d+)&*$/)) alert(RegExp.$1); При такой регулярке уже все равно, где именно будет этот параметр, хоть в середине строки, хоть в конце. Да, и проверять на цифры не обязательно регулярным выражением, можно пользоваться некошерным хаком. Так как название явно указывает на целочисленку, причем положительную, то можно использовать var st = "12"; if( 0|st ) alert('int');

Конечно же проекция, как же иначе. Аргументы закончились уже? Так быстро? Окей, давай вернемся к тому-же Яндексу, и его развитием БЭМ, но уже в рамках JS. Открываем ссылку http://ru.bem.info/articles/bem-js-main-terms/ и читаем Фу, ересь какая! Такие "модные" разработчики в Яндексе сидят, и используют приемчики из 90-х... Надо им написать, чтобы не позорились, и почитали наконец javascript.ru...

/?pid=7&id=9 Все, приехали.

Одна из тактик отрицания факта - преуменьшение его влияния или важности. Неважно какое количество, важно что приемчики из 90х живы и процветают. Наверное это что-то значит... Скорее всего в Google и Yandex работает низкооплачиваемые кодеры, которые не до конца прониклись практикой ненавязчивого JS. Другого пояснения у меня нет... Вы часто видели страницы на чистом HTML, для рендеринга которых требуется ОДНА СЕКУНДА? Лично я видел, но это очень большие документы. Конечно прозрел, вместо десятков милисекунд для рендеринга обычного HTML браузер целую секунду что-то считает далеко не на самом медленном компе. Это и есть накладные расходы, про которые я говорил. Как раз из-за желания гуглом сократить работу своих серверов, переходе не ненавязчивый JS. Я ничего вам не доказываю. Это не тот случай, когда что-то надо доказывать. Я смотрю, про DocumentFragment мало написано в вашем любимом javascript.ru? Не все браузеры одинаково показывают содержимое функций, в отличие от единого формата alert'a

Все мы когда-то не понимали, что такое Javascript...

Какая избирательная логика... Открываю ютюб, ищу //*[@onclick] Результатов масса. Менюшка гугла с их сервисами. Сплошь и рядом onclick (а она была переделана совершенно недавно), G+ тоже есть. Да вперемешку там все. Заходим на сайт yandex.ru, ищем то же самое. 96 matching nodes. И это на обновленном совсем недавно ресурсе! Используются приемы из 90х!!! Накладные расходы не содержат только килобайты передаваемой информации. Сюда включаем и скорость рендеринга страницы на стороне клиента. Вы никогда не задумывались, а что же означает вот тот прогресс-бар, который показывает gmail при загрузке? Лично у меня интерфейс почтовика рендерится примерно секунду. Это и есть те накладные расходы, про которые я говорил. О, начались фантазии... Да вы что, правда что-ли? А я то горемычный думал, что это одно и то же... Я дал ссылки и примеры из ваших людимых гуглей да яндыксей. Даже они используют аттрибуты, и не стесняются. Потому что фанатизм и максимализм хорошо, а стоимость поддержки и архитектура требуют совершенно непопулярных у таких людей как вы решений. Живите и дальше в своем розовом идеалистическом мире Слишком долго, слишком сложно. Тыцнуть в тег, скопировать название функции и сделать alert(functionName) и я уже читаю код обработчика.

Я тоже умею умные ссылки постить http://stackoverflow.com/questions/7810534/have-any-browsers-implemented-the-dom3-eventlistenerlist Почитай, почему этот метод так и не был реализован в браузерах Теперь давай просто разберемся, что же нам предлагает тот же хром для дебаггинга. Ага, пару списков в абсолютно неудобоваримом виде. Вроде и информация есть, а быстро найти нужное - не сильно то и просто. Читабельность того же onclick в разы выше. Потому что определить поведение элемента можно заглянув в исходный код, в простое дерево в инструментах разработчика. Открыл google.com. Набрал слово javascript. Посмотрел код первой попавшейся ссылки. <a onmousedown="return rwt(this,'','','','1','AFQjCNGf8B1MwS6OVNL15BpCO4mTO-e8NQ','','0CC8QFjAA','','',event)" href="http://uk.wikipedia.org/wiki/Javascript"><em>Javascript</em> — Вікіпедія</a> Еще вопросы есть? Фанатизм - страшная штука... Вы не думали о том, что накладные расходы на формирование ненавязчивого JS могут быть на десятки килобайт больше даже 1000 ячеек? Мало того, если вам реально необходимо выводить таблицы с 1000 ячеек, то мне жаль ваших пользователей. И еще, я могу сделать ряд твиков, сократив количество обработчиков до одного. addEventListener для тысячи обработчиков будет жрать ресурс, итерируя DOM, onclick="" парсится в разы быстрее. Сравните как нибудь скорость innerHTML и appendChild, особенно на большом количестве элементов. Почитайте ваших любимых Yandex, или документацию по оптимизации jQuery, там советуют или innerHTML, или DocumentFragment.

Это, наверное, не просто так было сделано... Вы не задумывались над тем, что любой ненавязчивый JS существенно замедляет отладку и тестирование? А причина простая - нет официально задокументированных методов, которые бы рассказали, какие именно обработчики сейчас навешены через addEventListener. Лично мне это кажется гирей, которую люди вешают себе на ногу, чтобы потом придумать множество способов, как облегчить от нее страдания. А вы не задумывались никогда, что кроме ООП есть еще другие паттерны реализации приложений? Например, структурный, когда логика переносится по максимуму на структуры HTML. И плевать на то, что кому-то это кажется ужасным, это гораздо удобнее, практичнее, надежнее, проще тестируется. Меня не нужно пугать такими вещами. Вы про html-темплейтирование что-то слышали? Это методика построения приложения, когда HTML-код содержит в себе все, что необходимо для его функционирования, и клонируя HTML-структуры вы получаете сразу полнофункциональный компонент или его элемент. При этом абсолютно ничего в JS менять или переопределять не нужно. Этим достигается отличная слабосвязанность компонентов. Если у вас jQuery головного мозга, то это вам будет очень тяжело понять. По его мнению, jQuery позволило бы write less, do more. На практике же это далеко не всегда так.