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

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

На каком уровне вы держите свой код при создании:

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

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

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

Я думаю, что я могу опубликовать другой вопрос о переполнении стека; «Подтверждаешь ли ты, когда идешь, или заканчиваешь, а потом возвращаешься и подтверждаешь?» как это, кажется, где этот вопрос идет

11.08.2008 16:46:28
9 ОТВЕТОВ
РЕШЕНИЕ

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

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

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

11
11.08.2008 16:50:32

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

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

0
11.08.2008 16:52:01

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

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

4
11.08.2008 16:52:57

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

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

3
11.08.2008 17:01:39

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

1
11.08.2008 16:55:52

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

1
12.08.2008 20:08:39

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

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

1
12.08.2008 20:49:23

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

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

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

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

0
11.03.2012 07:37:22

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

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

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

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

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

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

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

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

2
5.02.2013 11:28:13