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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Что касается браузеров, соблюдение 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>.

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

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

Just because you can validate your code doesn’t mean you are better than anybody else. Heck, it doesn’t even necessarily mean you write better code than anybody else. Someone who can write a banking application entirely in Flash is a better coder than you. Someone who can integrate third-party code into a complicated publishing environment is a better coder than you. Think of validation as using picture perfect grammar; it helps you get your ideas across and is a sign of a good education, but it isn’t nearly as important as the ideas and concepts you think of and subsequently communicate. The most charismatic and possibly smartest person I’ve ever worked for was from the South and used the word “ain’t” quite regularly. It didn’t make him any less smart, and, in fact, it made him more memorable. So all I’m saying is there are plenty of things to judge someone on… validation is one of them, but certainly not the most important.

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

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