Насколько важна проверка W3C XHTML / CSS при завершении работы?

Несмотря на то, что в наши дни я всегда стремлюсь к полной проверке, я часто задаюсь вопросом, не пустая ли это трата времени. Если код запускается и выглядит одинаково во всех браузерах (я использую browsershots.org для проверки), нужно ли мне продвигать его дальше, или я просто слишком анален?

На каком уровне вы держите свой код, когда создаете его для:

а) себя б) ваших клиентов

PS Джефф и компания, почему не проверяется переполнение стека? :)

РЕДАКТИРОВАТЬ: Некоторые хорошие идеи, я думаю, что, поскольку я так долго был одержим действительностью, я программирую, зная, что вызовет проблемы, а что нет, поэтому я в лучшем положении, чем люди, которые сначала создают сайт, а затем "вернуться и исправить проблемы проверки"

Думаю, я могу задать еще один вопрос о переполнении стека; «Вы подтверждаете по ходу дела или вы заканчиваете, а затем возвращаетесь и подтверждаете?» так как кажется, что это то, к чему идет этот вопрос

Ответов (9)

Решение

а) Должен выглядеть одинаково

б) Соответствует стандартам, насколько это возможно, но не настолько анально, чтобы блокировать отделочные работы.

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

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

Мой подход, как правило, заключается в том, чтобы гарантировать, что я могу полностью проверить на всех страницах, однако я все равно отправляю страницу как text / html вместо application / xhtml + xml, поэтому в случае, если я что-то пропустил, не будет уродливых ошибок XML.

За исключением того, что сами валидаторы настолько аналитичны, когда отмечают ошибку или предупреждение всякий раз, когда используется -moz-, -webkit или -o-, т.е. квалификационный термин, специфичный для браузера. также они хотят, чтобы вы указали 0 пикселей, а не 0, или другие единицы измерения. Ноль - это ноль, независимо от единиц, с которыми валидатор хочет проверить это!

просто попробуйте проверить WordPress twentyeleven style.css, он выдает 140 нечетных ошибок, которые имеют всю природу выше, или валидатор восстанавливается после ошибок синтаксического анализа

Валидаторы бесполезны, если вы не можете отсортировать пшеницу от плевел !!!

Нам нужны валидаторы, которые распознают квалификационные условия браузера!

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

HTML-код, который вы передаете браузеру, интерпретируется браузером после DOM, интерфейса прикладного программирования, который отображает всю страницу в виде иерархии узлов. Каждая часть этого дерева представляет собой тип узла, содержащий различные типы данных. DOM (объектная модель документа) была необходима из-за разнообразия HTML-страниц, реализованных в ранних веб-браузерах (Netscape, IE ...), позволяющих изменять внешний вид и содержимое веб-страницы без ее перезагрузки. Чтобы сохранить кроссплатформенный характер Интернета, W3C хотел исправить различные реализации этих браузеров, предлагая DOM.

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

DOM - это самый простой шаг, с которого запускается веб-браузер. Его основной поток:

  1. анализ HTML для построения дерева DOM
  2. построение дерева рендеринга
  3. макет дерева рендеринга
  4. рисование дерева рендеринга

Шаг 1 дает дерево содержимого с тегами, обращенными к узлам DOM. Шаг 2 дает дерево рендеринга , содержащее информацию о стилях.

Итак, почему проверка имеет значение: потому что дерево содержания и визуализации дерево является основой , из которой веб - браузер начнет свою работу. Чем лучше они определены, тем лучше для веб-браузера.

В конечном итоге DOM также является основой для ваших событий JavaScript. Таким образом, его проверка помогает и на уровне взаимодействия.

Я думаю, что только "технические" ребята действительно заботятся о "100% соответствии стандартам". Мои обычные потребители страниц (= пользователи) не заботятся о том, нет ли атрибута alt для «элемента изображения границы меню».

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

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

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

Я думаю, что это та область, в которой вы должны стремиться использовать принцип устойчивости, насколько это возможно (что является хорошим советом для любой области программирования). То, что что-то работает сегодня, не означает, что оно будет работать завтра: если вы полагаетесь на конкретный взлом HTML / CSS или даже если вы просто немного не торопились генерировать строго действительный код, следующая итерация браузеров вполне может перерыв. Одноразовое выполнение правильного действия сводит к минимуму эту проблему (хотя и не устраняет ее полностью).

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

Что касается меня, я чувствую, что хорошо поработал, если мой код проходит валидацию. Вид зеленого флажка на страницах w3c вызывает у меня легкое головокружение. Что касается группы b, они обычно заботятся только о том, чтобы она выглядела и работала одинаково во всех браузерах. Они единственное место, где я обнаружил, что это неправда, - это государственный сектор. Они требуют полной проверки не только с помощью w3c, но и прохождения тестов ADA (в основном, как это звучит с помощью программы чтения с экрана).

ps, когда я говорю «государственный сектор», я имею в виду конкретно штат Калифорния и несколько округов внутри него. У меня не было другого опыта работы с другими правительственными группами, кроме них.