Насколько важна проверка W3C XHTML/CSS при завершении работы? [закрытый]
хотя я всегда стремлюсь к полной проверке в эти дни, я часто задаюсь вопросом, не является ли это пустой тратой времени. Если код работает, и он выглядит одинаково во всех браузерах (я использую browsershots.org чтобы проверить), тогда мне нужно идти дальше или я просто слишком анальный?
на каком уровне вы держите свой код, когда создаете его для:
a) себя б) ваши клиенты
С. П. Джефф и компания, почему переполнение стека проверить? :)
EDIT: некоторые хорошие идеи, я думаю, что, поскольку я так долго был одержим валидностью, я программирую, зная, что вызовет проблемы, а что нет, поэтому я в лучшем положении, чем люди, которые сначала создают сайт, а затем "возвращаются и исправляют проблемы проверки"
Я думаю, что могу опубликовать еще один вопрос о переполнении стека; " вы проверяете, как вы идете, или вы заканчиваете, а затем возвращаетесь и проверяете?"как похоже, там этот вопрос идем!--10-->
9 ответов
a) должно выглядеть одинаково
b) как можно более соответствует стандартам, но не настолько анальный, что он блокирует отделочные работы
в ситуации, когда у вас есть постоянный доступ к коду, я не думаю, что стандарты-это все, что важно, поскольку вы всегда можете внести изменения в код, если что-то сломается. Если у вас нет постоянного доступа (т. е. вы подписываете код, и он становится чьей-то ответственностью), вероятно, лучше всего соответствовать стандартам, как возможно уменьшить головные боли обслуживания позже... даже если вам больше не придется иметь дело с кодом, ваша репутация сохраняется и может быть передана другим потенциальным клиентам, и многие команды любят обвинять предыдущего разработчика(разработчиков) в возникающих проблемах.
Я думаю, что это область, в которой вы должны стремиться использовать принцип робастности насколько это практично (что является хорошим советом для любой области кодирования). Просто потому, что что-то работает сегодня, не означает, что это будет работать завтра: если вы полагаетесь на конкретный взлом HTML/CSS или даже если вы просто немного расслабились в излучении строго действительного кода, следующая итерация браузеров вполне может сломаться. Делать это один раз правильно минимизирует эту проблему (хотя и не полностью смягчить).
однако здесь есть определенный элемент прагматизма. Я бы, конечно, сделал все возможное, чтобы сайт клиента был действительным, но я был бы готов пойти на больший риск в своем собственном пространстве.
Я думаю, что это только "технические" ребята, которые действительно заботятся о "100% стандартном соответствии". Мои обычные потребители страниц (=пользователи) не заботятся, если нет Alt-атрибута для "элемента изображения границы меню".
обычно я просто убеждаюсь, что не вижу никаких очевидных ошибок (все теги закрыты, все строчные буквы, атрибуты в кавычках,...), но если это выглядит хорошо на IE и FF, это все, что мне нужно. Мне все равно, использую ли я нестандартный атрибут в любом HTML-теге, чтобы страница не проверка на DTD-до тех пор, пока я получаю визуальные результаты, которые я намеревался получить.
для понимания почему проверка имеет значение, необходимо понять как браузер работает в его различных слоев, а также немного об истории интернета, с точки зрения веб-браузеров.
HTML, который вы даете браузеру, интерпретируется браузером после DOM, интерфейса прикладного программирования, который отображает всю страницу как иерархию узлов. Каждая часть этого дерево тип узла, содержащего различные виды данных. DOM (document Object Model) был необходим из-за разнообразия HTML-страниц, которые ранние веб-браузеры (Netscape, IE...) реализовано для изменения внешнего вида и содержимого веб-страницы без ее перезагрузки. Для сохранения кросс-платформенной природы интернета W3C хотел исправить различную реализацию этих браузеров, предложив DOM.
поддержка DOM стала огромным приоритетом для большинства поставщиков веб-браузеров, и усилия по улучшению поддержка на каждом выпуске. Так, он работал.
DOM - это самый простой шаг, с которого запускается веб-браузер. Его основной поток:
- разбор HTML для построения дерева DOM
- оказываем строительные дерево
- макет дерева визуализации
- покраска дерева рендеринга
Шаг 1 дает дерева, с тегами, обращенными к узлам DOM. Шаг 2 дает рендер дерево, содержит информацию о стилизации.
и почему проверка имеет значение: потому что дерева и рендер дерево являются основой, с которой веб-браузер начинает свою работу. Чем больше они хорошо определены, тем лучше для веб-браузера.
в конечном счете, DOM также является основой для ваших событий JavaScript. Таким образом, его проверка также помогает уровню взаимодействия.
Я знаю, что это не ответ на весь ваш вопрос, но стоит учитывать, что, используя полностью действительный html, вы можете быть уверены, что ваш сайт должен работать правильно в будущее веб-браузеров, которые еще не были выпущены.
мой подход имеет тенденцию гарантировать, что я могу полностью проверить на всех страницах, однако я все еще отправляю страницу как text/html вместо application/xhtml+xml, поэтому нет уродливых ошибок XML в случае, если я что-то пропустил.
для меня, я чувствую, что я сделал хорошую работу, если мой код был валидным. Вид зеленого флажка на страницах w3c просто заставляет меня немного головокружительно. Что касается группы b, они обычно заботятся только о том, что она выглядит и работает одинаково в браузерах. Единственное место, где я обнаружил, что это не так, это правительственный сектор. Они требуют полной проверки не только с w3c, но и прохождения тестов ADA (в основном, как это звучит с помощью считывателя экрана).
p.s. когда я говорю о государственном секторе, Я имею в виду конкретно штат Калифорния и несколько округов внутри него. У меня нет опыта общения с другими правительственными группами, кроме них.
Я думаю, что проверка-хорошая лакмусовая бумажка о том, правильно ли вы все сделали, поэтому, если есть только несколько незначительных проблем, почему бы не исправить их и не убедиться, что ваш сайт, по крайней мере, будет правильно понят браузерами в будущем (даже если они делают рендеринг по-другому по другим причинам)?
OTOH, для большинства проектов проверка кажется огромной головной болью, и если вы можете заставить вещи работать через браузеры, не стоит тратить дополнительный день / неделю+ только утверждение.
за исключением того, что сами валидаторы настолько положительно анальный, когда они помечают ошибку или предупреждение, когда используется a - moz-или-webkit или - o-т. е. конкретный квалификационный термин браузера. также они хотят, чтобы вы указали 0px, а не 0 или другие единицы Ноль-это ноль любых единиц, которые валидатор хочет проверить!
просто попробуйте проверить стиль WordPress twentyeleven.css он выбрасывает 140 нечетных ошибок, которые все природы выше или валидатор восстанавливается от разбор ошибок
валидаторы бесполезны, если вы не можете отделить зерна от плевел!!!
нам нужны валидаторы, которые признают конкретные условия квалификации браузера!