Разве соответствие XHTML бессмысленно?

Мне еще не приходилось сталкиваться с случаем, когда добавление нестандартного атрибута вызывало проблемы с рендерингом в любом браузере.

Не пытайтесь обойти эти нестандартные атрибуты. Валидаторы удобны в качестве инструментов для двойной проверки вашего кода на предмет непреднамеренных ошибок, но, как мы все знаем, даже полностью действительный xhtml не всегда будет отображаться одинаково в разных браузерах. Часто дизайнерские решения требуют от нас использования специфичных для браузера (и нестандартных) хаков для достижения эффекта. Такова жизнь веб-разработчика, о чем свидетельствует количество сайтов, управляющих технологиями (google, yahoo и т. Д.), Которые не проходят валидацию.

Проверка полезна, чтобы определить, когда что-то не соответствует стандартам, с которыми вы предположительно согласны. Если вы целенаправленно используете инструмент, который специально добавляет что-то, чего нет в стандартах валидации, очевидно, что это не нарушает ваше личное соглашение о стандартах.

Это обсуждение становится намного сложнее, если у вас есть начальник или клиент, который считает, что все должно дать зеленый свет, поскольку вам придется объяснить им сказанное выше и убедить их, что вы не просто ленитесь.

Тем не менее, убедитесь, что вы не просто ленивы. Хотя валидаторы могут раздражающе постоянно вызывать каждый экземпляр стороннего атрибута, это не отменяет (ха) других ошибок валидации, о которых они упоминают. Часто стоит просканировать, чтобы перепроверить свою работу.

Соответствие стандартам означает увеличение шансов, что ваша страница будет работать в браузерах, против которых вы не тестируете. Это включает в себя программы чтения с экрана и следующее обновление браузеров, с которыми вы проводите тестирование, и браузеры, с которыми вы проводите тестирование, но которые были настроены пользователем неожиданным образом.

Проверка не гарантирует вам ничего, поскольку ваша страница может быть проверена, но все же будет достаточно неоднозначной, чтобы когда-нибудь в каком-нибудь браузере она не будет вести себя так, как вы хотите.

Однако, если ваша страница действительно проходит проверку, у вас, по крайней мере, есть сила спецификации XHTML, говорящая, как она должна себя вести. Если это не подтверждается, все, что у вас есть, - это набор неформальных соглашений между разработчиками браузеров.

Вероятно, лучше написать действительный HTML 3, чем недопустимый XHTML, если есть что-то, что вы хотите сделать, что разрешено в одном, но не разрешено в другом.

Если вы планируете воспользоваться преимуществами XHTML как XML, то стоит сделать ваши страницы действительными и правильно сформированными. В противном случае вам, вероятно, понадобится старый простой семантический HTML. В любом случае потребности вашей аудитории перевешивают потребности валидатора.

Просто имейте в виду, что тег XHTML в большинстве браузеров отображается иначе, чем при его отсутствии. Атрибут DOCTYPE определяет, в каком режиме работает браузер, и определяет, что разрешено, а что нет. Если вы отклоняетесь от XHTML-соответствия, просто не забудьте провести повторное тестирование во всех браузерах.

Лично я придерживаюсь последних стандартов, когда это возможно, но вы наверняка должны взвесить время / деньги против их соответствия, и для большинства это сводится к личным предпочтениям.

Что касается браузеров, соответствие XHTML бессмысленно:

1. В браузерах нет парсеров XHTML. У них есть не зависящие от версии, веб-совместимые анализаторы HTML, которые строят DOM вокруг http://www.w3.org/1999/xhtml.

2. Некоторые браузеры, у которых есть анализаторы XML, могут обрабатывать разметку XHTML, обслуживаемую как application / xhtml + xml, как XML. Это примет XML и задаст стиль и поведение HTML по умолчанию для элементов в http://www.w3.org/1999/xhtml. Но, что касается синтаксического анализа, он не имеет ничего общего с XHTML. Соблюдаются правила синтаксического анализа XML, а не некоторые правила XHTML DTD.

Итак, когда вы используете разметку XHTML, вы даете браузерам нечто чуждое и смотрите, получится ли это так, как вы задумали. Дело в том, что это можно сделать с любой разметкой. Если он отрисовывается так, как задумано, и создает правильный DOM, у вас все хорошо. Вам просто нужно помнить о переключении DOCTYPE и убедиться, что вы не полагаетесь на ошибку браузера (чтобы все не развалилось в браузерах, в которых эта ошибка отсутствует).

Совместимость XHTML хороша для проверки синтаксиса (путем проверки), чтобы увидеть, правильно ли сформирована разметка. Это помогает избежать ошибок парсинга. Конечно, это можно сделать и с HTML, поэтому в XHTML в данном случае нет ничего особенного. В любом случае вам все равно придется тестировать в браузерах и надеяться, что поставщики браузеров создадут отличные парсеры HTML, которые могут принимать все виды дерьма.

Что не бессмысленно, так это попытки соответствовать ожиданиям браузеров. HTML5 помогает в этом большом деле. И, говоря о HTML5, вы можете определять собственные атрибуты, сколько захотите. Просто добавьте к ним префикс data-, как в ‹p data-order =" Это допустимый настраиваемый атрибут ".› Test ‹/p›.

Статус HTML Valid обычно помогает как вам, так и движку рендеринга браузера. Чем меньше причуд приходится решать браузерам, тем больше они могут сосредоточиться на добавлении новых функций. Чем строже вы будете, тем меньше времени вы потратите на размышления, почему этот проприетарный тег f @ # cking не работает в других браузерах.

С другой стороны, XHTML, IMHO, более бессмысленный, за исключением случаев, когда вы планируете интегрировать его в какой-либо XML-документ. Поскольку IE до сих пор не распознает его, придерживаться его бесполезно.

Я считаю, что написание «правильного кода» важно просто потому, что вы показываете пример, следуя правилам. Если бы каждый разработчик написал код для Fx, Safari и Opera, я думаю, IE пришлось бы «начать следовать правилам» раньше, чем с версией 8.

Я стараюсь писать совместимый код большую часть времени, сравнивая время / стоимость с потребностями аудитории во всех случаях, кроме одного. Если ваш код должен соответствовать стандарту 503, то в ваших интересах и интересах вашей аудитории писать соответствующий код. Я встречал кучу программ чтения с экрана, которые взрываются даже при небольшом сбое кода.

Как сказано в большинстве плакатов, на самом деле все зависит от того, что нужно вашей аудитории.

Это ни в коем случае не бессмысленно, но есть много оправданий для его нарушения. На начальных этапах разработки CSS это очень полезно для диагностики проблем браузера, если ваша разметка действительна. Кроме того, если вы хотите что-то сделать и считаете, что наиболее подходящий метод - прервать проверку, обычно это нормально.

Альтернативой использованию настраиваемых атрибутов является использование атрибута rel, например см. Litebox (и его родственники).

Конечно, вы всегда можете просто написать это так, как хотите, убедившись, что как минимум он работает. Конечно, мы уже страдали от этого менталитета и стали свидетелями его выхода - Internet Explorer 6.

Я большой поклонник подхода Майка Дэвидсона к разработке, ориентированной на стандарты.

То, что вы можете проверить свой код, не означает, что вы лучше, чем кто-либо другой. Черт возьми, это даже не обязательно означает, что вы пишете код лучше, чем кто-либо другой. Тот, кто может написать банковское приложение полностью на Flash, станет лучшим программистом, чем вы. Тот, кто может интегрировать сторонний код в сложную издательскую среду, является лучшим кодером, чем вы. Думайте о валидации как об использовании идеальной грамматики; это помогает вам донести свои идеи до людей и является признаком хорошего образования, но не так важно, как идеи и концепции, которые вы придумываете и впоследствии передаете. Самый харизматичный и, возможно, самый умный человек, на которого я когда-либо работал, был с Юга и довольно часто использовал слово «нет». Это не сделало его менее умным и, по сути, сделало его более запоминающимся. Так что все, что я говорю, это то, что есть по чему судить кого-то… проверка - одна из них, но, конечно, не самая важная.

Многие люди неправильно понимают этот пост, так как он означает, что мы не должны кодировать в соответствии со стандартами. Мы должны, очевидно, должны, но это не то, о чем действительно стоит даже думать. армия валидации всегда будет осуждать тех, которые не прошли валидацию, но валидация означает гораздо больше, чем валидный код.

Так что не теряйте своих принципов, но помните, что если вы будете следовать стандартам, вероятность того, что в будущем вы попадете в глубину проблем, значительно снизится. Контент, который вы пытаетесь предоставить, гораздо важнее, чем то, как он отображается.