10 популярных мифов о валидности и валидации
Миф 1. Валидность — некая единая, универсальная характеристика для любого кода
Примеры употребления: «Поменяй доктайп с X на Y, а то невалидно».
Реальность: валидность — понятие конкретное и относительное. Валидность документа на языке разметки означает соответствие определенной схеме. Указанной (напр. DTD в доктайпе) или подразумеваемой (в HTML5). Схемы бывают разные, и требования у них тоже (аналог из жизни: к строительству жилых домов и атомных электростанций применяются разные СНиПы), поэтому документ, валидный по одной схеме, наверняка будет невалидным по другой (хороша была бы АЭС, построенная по нормативам жилого дома!).
Доктайп как правило указывает на схему, по которой планируется валидация. Но не факт. Доктайп может быть выбран из прагматических соображений для выбора оптимального режима браузеров, например. XHTML5 может вообще не иметь доктайпа, но быть валидным.
Миф 2. Валидность — это соответствие стандарту
Пример употребления: так и употребляется
Реальность: валидность — результат механической проверки на отсутствие формальных грамматических ошибок заявленного в схеме языка. О логике, тем более о смысле документа валидация не знает и не задумывается. Например, по формальным правилам русского языка знаменитая фраза «волны… падали стремительным домкратом» абсолютно «валидна», любой «валидатор» (напр., проверка орфографии в Ворде) найдет в ней ровно ноль ошибок. Но грамотна ли эта фраза? Конечно, нет — ведь слова в ней использованы не по назначению! (Не подумайте, что я считаю валидацию или проверку орфографии ненужной — напротив, это нужные и очень полезные инструменты! Но, увы, не всесильные.)
Точно так же формально валидный веб-документ может быть абсолютно неграмотным с точки зрения стандарта, бессмысленным, нелогичным и непонятным для браузеров и поисковиков. Потому что стандарт определяет и грамматику языка, и его логику (семантику), а валидатор в принципе способен проверить лишь первое. Так что валидность — лишь часть соответствия стандарту, условие необходимое, но не достаточное.
В аналогии со строительством дома, валидатор укажет на неоштукатуренную вовремя стену или косо вставленное окно без шпингалетов (и будет прав, такое нужно исправлять!), но вполне может пропустить, например, то, что туалет оказался замурован наглухо (без единого дверного проема), а на кухню можно попасть только через балкон соседней квартиры (ведь валидатор не телепатор, замысел архитектора ему неизвестен — вдруг так и задумано? А монтаж перекрытий вполне соответствует ГОСТам и СНиПам…).
Миф 3. Валидность — это гарантия кроссбраузерности
Пример употребления: «— Почему у меня в IE8 (IE7, Fx2…) не так отображается меню, валидатор ведь ошибок не показывает?»
Реальность: валидность — это соответствие схеме. Ни больше ни меньше. Так что если какой-то браузер какую-то схему просто не знает — ждать от него правильного отображения в соответствии с этой схемой как минимум наивно. Кроме того, отображение сейчас главным образом зависит от поддержки браузерами CSS, а не разметки. И вообще браузеры умеют лишь то, что умеют. А еще у всех браузеров есть баги разной степени неочевидности.
Так что если страница валидна — далеко не факт, что она будет везде отображаться как задумано. Но, справедливости ради, вероятность кривого отображения и степень его кривизны для валидной страницы почти всегда меньше, чем для невалидной.
Миф 4. Лучший валидатор — это браузер
Пример употребления: «Главное, чтобы страница везде одинаково отображалась, а валидностью пусть заморачиваются фанатики»
Реальность: браузер — не валидатор, никогда не был валидатором и не претендовал на то, чтобы быть валидатором. И не замена валидатору. У них разные задачи. У валидатора — тупо проверить страницу на соответствие заявленной схеме (и указать на все найденные несоответствия). У браузера — отобразить страницу хоть как-то, несмотря на эти несоответствия (и более того — даже на саму схему, иногда, особенно если она указана явно «от балды» и не имеет связи с реальностью).
Так что если страница отображается — далеко не факт, что ее поймут правильно поисковики, устройства вывода для людей с ограниченными возможностями и т.п.
Миф 5. Фраза «браузер — лучший валидатор» устарела, это пережиток эпохи IE6
Пример употребления: «Лебедев (или еще кто-то) сказал эту фразу в 90-е, а сейчас нет браузера с долей > 80%»
Реальность: хотя разоблачение мифа 4 по-прежнему в силе, именно сейчас в этой фразе больше правды, чем было когда-либо в прошлом!
Причиной этого оказался главный секрет HTML5. Вкратце — впервые за историю веба браузеры и валидатор нашли общий язык. По крайней мере, стали понимать страничку по одним и тем же правилам. Более того — такие браузеры, как Fx4+ и Хром 7+, подстроили свои стили по умолчанию под эти правила (например, размер заголовка в них по умолчанию зависит не от его «номера», а от уровня вложенности в структуре плана документа). Так что если структура заголовков вашей страницы в этих браузерах при отключенных стилях выглядит логично — скорее всего, вы использовали элементы более-менее по назначению. А если при этом еще и таблицы не рвутся, подписи полей форм не улетают прочь от самих полей и т.п. — скорее всего, и грубых ошибок в синтаксисе у вас нет.
Миф 6. XHTML валиднее, чем HTML
Пример употребления: «Все одиночные теги по стандарту должны быть закрыты — <br />, <img /> и т.п., иначе невалидно»
Реальность: во-первых, см. п. 1. Даже код а-ля <FONT COLOR=RED>UNDER<BR>CONSTRUCTION</FONT> может быть валидным — если в доктайпе заявлена схема HTML 3.2:). Потому что валидность — это соответствие схеме, ни больше ни меньше!
Во-вторых, в XML (а следовательно, в XHTML, потому что он — его подмножество) есть дополнительное (помимо валидности!) ограничение синтаксиса — веллформность («правильная сформированность», синтаксическая корректность). Именно она требует обязательного закрытия всех тегов (в т.ч. «самозакрытия» одиночных), «закавыченности» всех атрибутов, непременного экранирования амперсанда в виде & и т.п. Эти требования общие для всех языков на базе XML (будь то SVG, MathML и т.п.). Может показаться, что у XHTML валидация «двойная» (соответствие DTD плюс XML-веллформность), а у HTML — «одинарная» (только DTD), но на деле валидность и там, и там определяется именно схемой. По определению. А XML-веллформность — это требование базового синтаксиса. Вроде того, как HTML требует, чтобы теги начинались и заканчивались угловыми скобками.
Есть более мягкий вариант этого мифа — «XHTML проще поддерживать валидным». Дескать, обязательность явного закрытия всех тегов и прочие XML-ные строгости «приучают к порядку». Доля правды в этом есть, но небольшая. Да, XML-ная строгость отчасти страхует от некоторых механических ошибок (скорее даже опечаток). Но это обманчивая страховка. Она заостряет внимание на синтаксисе и отвлекает его от логики кода, что увеличивает риск куда более значимых (для отображения и работы страницы) ошибок — например, случайно вложить элемент (напр. список) в неподобающий ему контейнер (напр. абзац). Иногда привычка слепо полагаться на закрывающий тег может сослужить дурную службу.
Запомнить все правила HTML (напр., в каких случаях, кроме явного закрывающего тега, автоматически заканчивается элемент P) сложнее, чем правила XML. Но это не делает разметку, соответствующую этим правилам, менее валидной. А ведь кое-кто до сих пор уверяет, что правила HTML проще:)
Ну а если кто-то скажет вам, что «тег <br> невалиден в HTML, потому что не закрыт слешем» (увы, даже сейчас, в 2012-м, можно услышать подобное!) — отправляйте его в школу, учиться читать. Потому что, умея читать, вычитать такую чушь ни в одной спецификации нельзя:)
Миф 7. Вреда от XHTML-валидности уж точно не бывает
Пример употребления: так и употребляется.
Реальность: XHTML и HTML — разные языки. XHTML пишется и валидируется по правилам XML А вот читается, т.е. парсится браузерами, чаще всего как HTML(5).
HTML- и XML-парсеры работают по разному алгоритму. То, что XML-парсер в общем случае не поймет HTML-разметку, всем понятно. Но почему-то большинство авторов, ставящих на страницу XHTML-доктайп, считают это само собой разумеющимся, что для HTML-парсера она проблемы не составит. Хотя на самом деле это далеко не очевидно! Разметка, одинаково понятная для разных парсеров, по-научному называется «разметкой-полиглотом» и для нее был и есть отдельный стандарт, со своими особыми правилами. Или, как минимум, приложение C спецификации XHTML 1.0.
Валидатор же об этом «не задумывается» и проверяет только… правильно, соответствие схеме! А той всё равно, <div></div> или <div/>. Последний вариант иногда случайно копируется из окошка «показать код выделенного фрагмента» некоторых браузеров. И HTML-парсер, привыкший игнорировать концевые слеши, воспримет его как незакрытый тег!
Мораль: всегда валидируйте разметку по той схеме, по которой ее будут разбирать браузеры. И не злоупотребляйте доктайпами, которые могут сбить валидатор с толку. Чем плох лаконичный, ясный и однозначный <!DOCTYPE html>?:)
Миф 8. Валидация CSS3 — не фикция
Пример употребления: «Как сделать CSS3 валидным, если я использую filter и zoom?»
Реальность: валидность — это соответствие схеме. Есть ли схема у CSS? У CSS даже версий-то нет!
Формальное определение «валидного CSS» вроде бы есть. Всё та же спецификация CSS 2.1 говорит:
Валидность таблицы стилей зависит от уровня CSS, использованного для таблицы стилей. Все валидные таблицы стилей CSS1 являются валидными таблицами стилей CSS 2.1, но некоторые изменения по сравнению с CSS1 означают, что некоторые таблицы стилей CSS1 будут иметь слегка другой смысл в CSS 2.1. Некоторые «фичи» CSS2 не входят в CSS 2.1, поэтому не все таблицы стилей CSS2 являются валидными таблицами стилей CSS 2.1.
Валидная таблица стилей CSS 2.1 должна быть написана в соответствии с грамматикой CSS 2.1. Более того, она должна содержать исключительно @-правила, имена свойств и их значения, определенные в этой спецификации. Запрещенное (невалидное) @-правило, имя или значение свойства — то, которое не является валидным. (К последней фразе так и напрашивается подпись «К. О.» — прим. перев.:)
Ну а как быть с валидностью CSS3 (которого нет, как известно:)? По логике определения выше, «валидный CSS3» должен содержать свойства и значения, описанные в модулях 3-го уровня. Но ведь эти модули постоянно меняют синтаксис, то и дело признаются устаревшими и переписываются практически заново, а за некоторые модули (напр. таблицы 3-го уровня) вообще еще даже не брались?
В описании к сервису проверки CSS есть пояснение на эту тему (правда, в русской версии описания именно этот пункт почему-то потерялся!):
CSS — развивающийся язык, и многие считают, что «CSS» — это единая грамматика (определенная в последней спецификации) с набором свойств и допустимых значений, определенных в различных профилях. В будущих версиях этого валидатора дефолтным поведением может стать проверка стилей по новейшей «грамматике CSS» и облаку всех стандартизированных свойств и значений.
Но легко сказать «последняя спецификация», а каково на практике? Ладно, список свойств и значений можно взять, например, здесь. Или собрать по модулям статуса LC и выше (обычно в них есть специальный раздел со списком добавленных свойств, как здесь). А как быть с грамматикой? Бывает же и такое:
Этот модуль заменяет и расширяет правило ‘
@media’, определенное в разделе 7.2.1 [CSS21], и включает изменения, ранее сделанные неофициальными в разделе 1 [MEDIAQ] (в частности, правила ‘@media’ могут быть вложенными, что не допускалось предыдущими редакциями — прим. перев.).Его текущее определение зависит от @-правил, определенных в [CSS3-FONTS] и [CSS3-ANIMATIONS], но эта зависимость — только в допущении, что те модули будут обновляться раньше, чем этот. Если этот модуль будет развиваться быстрее, зависимость станет обратной.
Ну как, уже достаточно запутались или добавить шокирующих подробностей?
Неудивительно, что с определением «валидности CSS3» не всегда могут договориться сами авторы спецификаций. А тем более разработчики CSS-валидатора, которым один модуль твердит одно, а другой — противоположное. Поэтому они включили в описание сервиса следующий пункт:
Это официальная проверка на корректность CSS?
Нет. Это надежная и полезная утилита, но это всего лишь программа, и, как у любого программного обеспечения, у нее есть ошибки и проблемы. Актуальный справочник по таблицам каскадных стилей есть в их спецификации.
Так что, увидев сообщение об ошибке валидации CSS3 — не впадайте в панику и не бегите на форумы с вопросом Чернышевского, а спокойно прочитайте, в чем именно эти ошибки состоят. Если, например, в пропущенной точке с запятой между свойствами (отчего свойство не распознается) — такое надо исправлять. А если валидатор просто не знает парочки свойств (особенно в стилях, предназначенных только для старых IE) — смело считайте это проблемой валидатора. Ведь понятие «валидности CSS» такое расплывчатое! Хотя это не означает, что экспериментальными (с префиксами) и нестандартными браузерными «довесками» к CSS стоит злоупотреблять;)
Миф 9. Все валидаторы одинаково полезны
Пример употребления: «В пустые span-ы нужно вставлять хотя бы , иначе будет невалидно»
Реальность: не всё валидатор, что валидирует:). Например, популярный некогда аддон для Firefox с говорящим, казалось бы, названием «HTML validator» по умолчанию проверял совсем не тем алгоритмом, что официальный валидатор W3C. И считал многие вещи, вполне разрешенные стандартом (напр. те же пустые span-ы) ошибками! Хорошего в пустых span-ах, конечно, мало, но это не повод обвинять в несуществующих грехах сам стандарт. Поэтому, если пользуетесь «валидатором», отличным от официального валидатора W3C, обязательно поинтересуйтесь, что и как он проверяет на самом деле. Остерегайтесь подделок!
Миф 10. Все валидаторы, кроме официального валидатора W3C — ничто
Употребляется не так часто, но разоблачение предыдущего мифа иногда приводит к противоположной крайности
Реальность: во-первых, валидатор W3C проверяет только те стандарты, которые разработаны самим W3C. Так что сторонние валидаторы для сторонних стандартов — это логично. Например, валидаторы микроразметки Яндекса, Гугла и т.д. — вполне правильная и полезная вещь. Во-вторых, валидаторы (даже официальные!) — программы, гм… туповатые. Они проверяют «сферический код в вакууме» (например, для многострадального XHTML валидатор предполагает, что разбираться он будет XML-парсером, а скрипты в HTML-комментариях действительно закомментарены, т.е. «временно убраны», а не всего-навсего скрыты таким способом от архаичных браузеров).
В этом плане html5.validator.nu («живой» валидатор, в каком-то смысле «официальный» валидатор WHATWG), хоть и не является официальным валидатором W3C, но во многом даже лучше его. Потому что анализирует страницу так же, как это делают браузеры (более того — в его основе такой же самый стандартный HTML5-парсер, что и в Gecko!). См. тж. разоблачение мифа 5 выше.
P.S. Это тоже может быть интересно:
Это … любопытно.
Экзотика, конечно. Но бывает :)
Как приятно натыкаться на такие вот неожиданности, однако :D
Да, и при этом предъявлять нам притензии, не разобравшись изначально ;)
Если видишь опечатку, то лучше указать на нее и если это не опечатка получить ссылки на материалы не прилагая к этому труда, чем потратить минимум полчаса своей жизни скурпулезно проверяя — а вдруг не опечатка? со значительной вероятностью потратить это время впустую.
Я лично не вижу повода стыдится того, что не знаю чего то в своей области. Было бы стыдно если бы не хотел знать.
Хо-хо! Это не опечатка! http://dev.w3.org/html5/spec/single-page.html#html-vs-xhtml
В первый раз встретил этот термин. Чудесно.
Валидность документа относительно выбранного страндарта позволяет значительно уменьшить вероятность различий представления в разных браузерах. Механизм обработки ошибок в разных движках закономерно разный и он может преподносить неприятные сюрпризы. Валидность не гарантия кроссбраузерности. Не «достаточное», даже не «необходимое». Но она реально помогает избежать проблем. Так что я бы пожалуй не стал записывать это в «мифы».
Он не «валиднее», он строже. По моему мнению сейчас имеет смысл использовать только один доктайп и стандат — html5. Но при этом многие особенности xhtml перенесенные в html 5, не обязательные, но допусимые с точки зрения этого стандарта, могут помочь избежать головной боли и сюрпризов.
Ох…
Я настаиваю на том, что избежать проблем помогает понимание того, что делаешь. Слепая погоня за валидностью, особенно выкрутасы типа замены
target="_blank"наonclick="return !window.open(this.href)", пониманию не помогает, а наоборот, отвлекает от него. Поэтому всё-таки миф, притом (это уже сугубо имхо) вредный.Он не строже, он просто другой по синтаксису (про «строже» — это еще один миф, строже — это Strict vs. Transitional, но эту тему я трогать не стал, т.к. считаю Transitional напрочь утратившим актуальность). Полезные практики (напр. закавычивание всех значений атрибутов), разумеется, полезны и в HTML5. Но опять же — лучше разобраться и понять, почему это лучше, а не тупо задолбить в голову, что "так надо, ибо воистину".
Про «валидатор не телепатор» — типа шутка юмора. Что, совсем неудачная?
SelenIT понимание того, что ты делаешь необходимо, но оно не спасет от банальной опечатки. Да и от глупочти часто застрахует. Нужно понимать, что валидация — инструмент, а не самоценность и соответствие стандарту (не только формальное соответствие dtd) это не самоцель.
За
я лично бил бы по рукам гораздо больше, чем за
Но когда человек начинает изучать html/css он будет постоянно допускать глупые ошибки. Это нормально. И валидатор поможет ему отлавливать эти ошибки пока в конечном итоге человек на автомате не начнет проверять себя и отлавливать эти мелочи без валидатора. Я уверен в том, что с ним лучше, чем без него.
Ну конечно другой … синтаксис СТРОЖЕ :D
Сравни html5 и xhtml 1.0 strict
кавычки в атрибутах, закрытие тегов много всего.
xhtml 1.1 по идее вообще не должен отображаться, если не well-formed так как xml документ. Если это не «строже», то я не знаю как это назвать.
Мне совсем не понравилась :(
Показалась вульгарной в плохом смысле этого слова.
Хм, в общем-то эту мысль я и пытался донести… Да, сейчас, пересмотрев текст, вижу, что настолько заакцентировался на отрицательных моментах, что можно подумать, что я против валидации в принципе (именно потому, что мне казалось, что нужность валидации — вещь настолько самоочевидная, что обсуждать можно только ее технические нюансы). Постараюсь подправить.
Есть мнение, что чем раньше человек начнет понимать смысл кода — тем быстрее он избавится в т.ч. от глупых ошибок. А против механических опечаток валидатор, безусловно, полезен — и я нигде с этим не спорю.
У него просто разные правила. И <BR>, и <br/> — две примерно равноправные сокращенные формы записи пустого тега в SGML (допустимые при опред. оговорках). В HTML используется одна, в XML — другая. Без соотв. оговорок обе будут восприняты как незакрытый тег. Ну да, в XML правила закрытия тегов проще (об этом сказано в статье) и не требуют сверки с DTD. Но зато в HTML между TABLE и TR гарантированно будет TBODY (даже без соотв. тегов!), а в XHTML — может быть, а может и нет. Не великовата ли цена за «строгость синтаксиса»?
Хм… то ли я слишком неиспорчен, то ли слишком наоборот :). Имел в виду исключительно производное от слова «телепатия» + суффикс для рифмы…
я думаю — нет
Наверное все же наоборот. Понятия не имею о чем ты там сейчас подумал…
А я думаю, что предсказуемость структуры DOM для страницы, особенно в наше динамическое время, всё-таки важнее простоты парсинга (особенно с учетом мощности процессоров современных мобильников и микроволновок, ради которых 12 лет назад этот более простой парсинг придумывали).
Впрочем, я даже не против XHTML как такового. Более того, валидный XHTML1.x Strict вполне может быть валидным HTML5 даже без смены доктайпа. Я лишь призываю смотреть на вещи реально.
Я завис в рекурсии, т.к. понятия не имею, о чем можно подумать при слове, пардон, «телепатор», кроме как о телепатии :). Правда, в детстве слышал разговорное словечко «телепаться» в значении «копошиться»… но даже в этом случае не вижу, причем тут «вульгарность в плохом смысле».
а с какого перепугу DOM'у стать непредсказуемым, если значения атрибутов будут в двойных кавычках, теги будут закрыты, и вложенность элементов будет четко задана? Наоборот, он будет намного более предсказуем.
Я ж привел пример. TBODY в TABLE, обязательный независимо от наличия тега <tbody> в HTML DOM, но зависящий от его наличия в XHTML DOM. Отчего ячейка в HTML с гарантией будет 4-м потомком таблицы, а в XHTML может быть и 4-м, и 3-м.
А еще в XHTML можно нечаянно поставить закрывающий </p> не там и получить-таки список в абзаце. Правда, как раз от этого страхует валидация. Но в HTML от этого страхует сам алгоритм парсинга…
Полагаться на генерацию разметки агентом — последнее дело, по моему.
Касательно «нечаянно поставить тег не там» — вот от этого как раз спасает валидация. Очень неплохо, кстати, спасает.
А что касается алгоритма парсинга — угу. У нас сколько движков? В скольки из них он одинаков? Правильно. У каждого свой. Ты в такой ситации им доверять собрался? Давай ка лучше закрывать теги. Руками. Там где надо. И верить только тем тегам, которые поставили сами.
Верить закрывающим тегам, которые «мы ставим руками, там где надо», в общем случае как раз не получится — потому что именно их как минимум один движок (IE7-) тупо игнорирует.
А алгоритм парсинга одинаков у всех новых. В не такой уж далекой перспективе — у всех вообще. Потому что описан в стандарте для браузеров. А списан, в свою очередь, с поведения старых движков.
http://jsfiddle.net/zrdEL
Это может быть валидным html.
Но я бы такой код не принял.
И ты хочешь сказать что dom в этом случае будет БОЛЕЕ предсказуем, чем если закрыть теги и обернуть атрибут в кавычками?
Смотря где закрыть теги. В общем случае (с учетом старых IE) — как ни удивительно, да :)
У закавычивания атрибутов есть наглядная практическая польза — интуитивность результата и минимальная страховка от «наивного XSS» (для value элементов форм). А вот результат машинального закрытия тегов при HTML-парсинге как раз может удивить. Хотя валидация и здесь приходит на помощь :)
При случае напомни мне не доверять тебе верстку :D
И если ты про текстовые ноды, то незакрытые теги могут вылится в намного большие неприятности.
Можно пример таких неприятностей? Для валидной страницы ;)
И кстати: напоминаю, что гуглу доверять верстку тоже не стоит :)
Валидным? Ха-ха. Не будь наивным.
Привычка не закрывать теги очень быстро приводят к тому что страница очень незаметно перестает быть валидной и появляются перлы вроде такого http://jsfiddle.net/sFjLm/
И это не с потолка взято. Я правил достаточное количество примеров с порванными инлайн элементами и вложенными ссылками. А всего то — не закрыли тег.
А где грань — не закрыть li или b или a? Особенно если ты не бог спецификаций или просвещенный дзен буддист познавший все тонкости работы движков…
Кстати да. Верстка у проектов гугл часто столько же плоха, как его интерфейсы. Не стоит доверять верстку гуглу.
Ты бы еще Microsoft в качестве примера привел … а что? Делают свой браузер со значительным процентом на рынке, активно учавствуют в работе w3c. Но это не мешает волосам на моей спине шевелится, когда я вижу некоторые участки их кода и браузерам, включая ie, показывать этот код некорректно.
Точно так же привычка закрывать теги бездумно приводит к непоняткам типа раз, два, три. И где грань, объясняющая, что </div> можно ставить после почти чего угодно, </p> — только перед структурными/группирующими (в девичестве «блочными»), а </img> — вообще нигде и никогда? А порванных абзацев, предполагавших что-то блочное внутри, я тоже правил немало.
Валидатор, конечно, старается помочь, чем может (как помогал бы и в твоем примере!) — но без догадки, что теги вообще-то бывают разные и могут иметь разную Content model, принять эту помощь тоже не так-то просто. Так что учить базовые вещи из спецификации приходится не только богам!
В твоих примерах проблемы не в закрытых или не закрытых тегах. Они в попытке недопустимой вложенности элементов.
Есть нюанс ;) В моем примере проблема в невнимательности. В твоем — в незнании основ.
Скажи, что проще контролировать: код, в котором любой тег обязательно должен быть закрыт или код в котором часть тегов закрывается, часть нет и то, какие и почему можно не закрывать, а какие — надо обязательно потому что … пространно объясняется в н местах в немаленькой спецификации?
А еще скажи какой код банально легче читать, как только случаи хоть немного отходят от тривиальных? И как редакторы работают с кодом, в котором теги не закрыты?
Есть два нюанса :). В моих примерах люди, «плавая» в основах, тем не менее были твердо уверены в «закрывающих тегах, которые они поставили сами, руками».
Результат обеих ошибок — и от невнимательности, и от неправильной вложенности — как правило, хорошо виден невооруженным глазом и легко локализуется всё тем же валидатором. Но человек, понимающий различия Content model-ей и правильной вложенности от неправильной, первую ошибку исправит мгновенно, а вторую просто не допустит. Тогда как не понимающий этого отличия, но слепо верящий во всесилие закрывающих тегов, будет долго мучиться с отладкой, обвиняя в своих бедах баги браузера и валидатора, фазы луны и т.д…
Разумеется, первое — в идеальном мире. Но мы живем в реальном, в котором у нас просто нет выбора (по крайней мере, пока жив IE8, не позволяющий использовать XHTML по-настоящему). В котором просто «закрыть» теги мало — надо закрыть их там, где это допустимо. Что по факту эквивалентно необходимости помнить, что можно закрывать, а что нельзя. И n=1 :)
Вот это часто реальная проблема. Поэтому злоупотреблять советом Гугла действительно не стоит :)
Я не очень понимаю почему ты вообще противопоставляешь понимание и валидацию.
И то и другое необходимо.
Валидатор — инструмент, который позволит проверить на наличие очевидных ошибок.
Лучше следить за тем, что бы документ был валиден, насколько это вообще возможно.
Почему? Так как среди 20 не особо важных сообщений о пропущенном alt у тега img может затеряться одно, из за которого где то может развалиться лаяут. Да и будет откровенны … теги alt у img тоже важны.
Я противопоставляю не это. Я противопоставляю слепое поклонение зеленой галочке (с принесением ей
человеческихжертв труда и времени, бессмысленных и беспощадных) — рациональному изучению и осознанному применению по назначению стандартных инструментов, с результатом в виде надежно работающего и стандартного (а значит — валидного по построению) кода :)И да, я, например, понятия не имею что такое «СНиПы». Лучше использовать более приближенные к веб-разработке примеры ;)
Санитарные нормы и правила=)
т.е строительные. это я из прошлого медицины взял..
Ну вот, теперь я знаю на одну безполезную для меня вещь больше =)
Не быть мне Шерлоком Хоумсом.
И все же — спасибо за ликбез.
Добавил abbr с расшифровкой в title :)
Примеры не из веб-разработки выбраны специально, чтобы были не чем-то формальным и умозрительным, а наглядным и легко представимым.
часто сижу на форумах по веб разработке и вопросы на подобее:
"как сделать код который для старых ие валидным ?"
или мой любимый
"заказчик проверил мой код валидатором и он оказался не валидным, что делать?".
Поэтому спасибо за статью может люди начнут понимать что такое валидация и с чем ее кушать=)
П.с и все такие меня не покидает увереность что в W3С курят травку ;)
Мы попали в прошлое ? Советую найти презентацию 10 года. «doctype точка » . С конференци web standarts days.
А можно чуть поподробнее, как пересекается тема той презентации с темой этой статьи? Или вы увидели какое-то противоречие между ними? Или в чем суть претензии?
Очередная отличная статья. Уже полдня сижу на сайте и читаю, читаю. Типа, выходной у меня :)
Лучше возьмите сразу отпуск :)
бред сивой кобылы. практически со всем не согласен. автор сам не разбирается в том, что он пишет.
Так просветите же его, дурака:). Хотя бы по паре-тройке пунктов.
При словах «мифы о разработке» и прочих сразу вспоминается статья http://ida-web.ru/article/neskolko-mifov-o-razrabotke.html там так же представлены наиболее распространенные мифы с их истоками. Весьма полезное чтиво.