Семён Андропов: Чтобы было понятно сразу — тонны говнокода говорят о том, что автор не умеет самостоятельно искать проблему.
Суть поиска источника проблемы всегда кроется в анализе различных факторов. Чтобы ускорить нахождение проблемы и не столкнуться с несколькими одновременно, нужно уменьшать код до минимально возможного.
Зачастую, в процессе такого уменьшения ответ на вопрос уже найден. Это откладывается в голове. Вываливание тонны ерунды, в которой кроется 2 и более потенциальных проблем, кроме как скуки ничего не вызывает. Автор может рассчитывать максимум на комментарии типа «консоль смотрели? Да? Ну ладно...».
Сергей: Если webkit не умеет работать с градацией насыщенности и корёжит в 2 состояния многоступенчатую систему (100 => 400 => 700 => 900), это не есть аргумент. Если вдруг webkit Научится работать со всеми ступенями, то normilize это перекроет. А пока он не умеет, то в чём значение этих правил normilize?
За некоторые вещи в normalize.css нужно оторвать одно место, а некоторые предполагают обязательных дополнительных правил, но 90% тех, кто используют normalize.css, про это либо не знают, либо забывают.
Nikolay Talanov: А зачем вообще его не юзать? Чем же плох id?
Вы же именно про поиск написали, я и не понимаю — зачем искать по id более медленным способом, чем getElementById?
И кстати, getElementsByTagName тоже хотите забыть? Ну раз querySelectorAll есть.
Александр Аксентьев: Для предотвращения действия по умолчанию в инлайн-обработчике обязательно нужно писатьreturn somefunc();. Если функция вернёт false, то действия не произойдёт. А если что угодно, кроме false, то выполнится.
Однако, решение вполне себе нормальное. Вечно ориентироваться на старых ослов не будем.