Я работаю в веб-студии, постоянно пользующейся услугами верстальщиков-фрилансеров. И если несколько лет назад верстальщики частенько присылали код, пестревший ошибками разметки, то сейчас это уже большая редкость. К сожалению совсем другая картина с логикой разметки, автоматического валидатора которой, насколько мне известно, пока нет. В надежде, привлечь внимание верстальщиков к этой стороне их работы, хочу рассказать о недавнем случае, показывающем, что логичность разметки не менее важна чем её валидность.
А дело было так. Заказчик захотел чтобы на сайте были «красивые» поля ввода в формах. Верстальщик применил для этого скрипт custom-form-elements.js. Однако, когда вёрстку установили на CMS, выяснилось, что в некоторых браузерах, к примеру в FireFox, для изменения состояния чек-боксов требуется двойной клик, а не одинарный, как обычно. Программист, занимавшийся сайтом, первым делом заподозрил custom-form-elements.js. Другой скрипт аналогичного назначения проблему с чек-боксами решил, но не подошёл по другим соображениям. Программист занялся отладкой первого скрипта. Когда это ничего не дало, он обратился ко мне. Я тоже начал с отладки скрипта и обнаружил, что обработчик «onclick» мистическим образом вызывается дважды. Тогда я решил взглянуть на разметку, и вот что увидел:
Обратите внимание на выделенный label. Скрипт custom-form-elements.js скрывает input с классом «styled» и ставит перед ним span «изображающий» из себя чек-бокс. При клике по span custom-form-elements.js изменяет состояние скрытого input. Но помимо span событие, порождённое этим же кликом, передаётся и обрамляющему span элементу label. Который транслирует это событие первому вложенному в него input-у. Таким образом состояние чек-бокса меняется дважды — один раз JS, второй — браузером, что и приводит к описанной проблеме. При всём при этом, label здесь совершенно не нужен, т. к. собственно метки (подписи) он и не содержит. Подпись размещается совсем в другом теге label.
Если бы верстальщик следовал логике, он бы не обернул этот input в label, скрипт custom-form-elements.js отработал бы правильно и ни программист, ни сам верстальщик не тратили бы лишнее время на устранение проблемы с чек-боксами.
А дело было так. Заказчик захотел чтобы на сайте были «красивые» поля ввода в формах. Верстальщик применил для этого скрипт custom-form-elements.js. Однако, когда вёрстку установили на CMS, выяснилось, что в некоторых браузерах, к примеру в FireFox, для изменения состояния чек-боксов требуется двойной клик, а не одинарный, как обычно. Программист, занимавшийся сайтом, первым делом заподозрил custom-form-elements.js. Другой скрипт аналогичного назначения проблему с чек-боксами решил, но не подошёл по другим соображениям. Программист занялся отладкой первого скрипта. Когда это ничего не дало, он обратился ко мне. Я тоже начал с отладки скрипта и обнаружил, что обработчик «onclick» мистическим образом вызывается дважды. Тогда я решил взглянуть на разметку, и вот что увидел:
<tr>
<td><label>Машина в кредит:</label></td>
<td><label><input type="checkbox" class="styled" name="credit" value="yes"></label></td>
</tr>
Обратите внимание на выделенный label. Скрипт custom-form-elements.js скрывает input с классом «styled» и ставит перед ним span «изображающий» из себя чек-бокс. При клике по span custom-form-elements.js изменяет состояние скрытого input. Но помимо span событие, порождённое этим же кликом, передаётся и обрамляющему span элементу label. Который транслирует это событие первому вложенному в него input-у. Таким образом состояние чек-бокса меняется дважды — один раз JS, второй — браузером, что и приводит к описанной проблеме. При всём при этом, label здесь совершенно не нужен, т. к. собственно метки (подписи) он и не содержит. Подпись размещается совсем в другом теге label.
Если бы верстальщик следовал логике, он бы не обернул этот input в label, скрипт custom-form-elements.js отработал бы правильно и ни программист, ни сам верстальщик не тратили бы лишнее время на устранение проблемы с чек-боксами.
