Стоит ли время разработки выводить допустимый HTML?
Разработка веб-сайтов требует много времени. Чтобы повысить производительность, я бы закодировал прототип, чтобы показать нашим клиентам. Я не беспокоюсь о том, чтобы прототип соответствовал стандарту. Большую часть времени наши клиенты одобряли прототип и давали необоснованный срок. Обычно я использую прототип в производстве (эй, прототип работает. Нет необходимости делать мою работу более трудной.)
Я мог бы реорганизовать код для вывода допустимого HTML. Но стоит ли выставлять правильный HTML?
Ответы
Ответ 1
Это только стоит усилий, если это дает вам практическую пользу. Придерживание стандартов может упростить создание веб-сайта, который работает в большинстве браузеров. Опять же, если вы довольны тем, как веб-сайт отображается в браузерах, о которых вы заботитесь (возможно, один, может быть, все), то через обручи, чтобы пройти проверку, это пустая трата времени.
Кроме того, разница в SEO между веб-сайтом all-valid html и веб-сайтом с большей достоверностью html незначительна.
Так что всегда ищите практическую пользу, в некоторых ситуациях есть некоторые, но не делайте этого только ради этого.
Ответ 2
Да. Это достаточно сложно, пытаясь разобраться, как разные браузеры будут отображать правильный HTML, не говоря уже о том, чтобы попытаться предсказать, что они сделают с неправильным кодом. То же самое касается поисковых систем - достаточно проблем в HTML может привести к тому, что сайт не будет проиндексирован правильно или вообще.
Я предполагаю, что реальный ответ: "это зависит от того, что недействительно в отношении HTML". Если недопустимые части относятся к проблемам доступности, вы даже можете обнаружить, что у вашего клиента есть юридические проблемы, если они используют сайт на коммерческой основе.
Ответ 3
Возможно, нет, если у вас есть несовместимый сайт, чтобы начать с него и не хватает времени.
Однако, и вы не поверите мне, потому что я не верил другим, но с самого начала проще сделать сайт совместимым - это избавляет вас от головных болей с точки зрения совместимости браузера, поведения CSS и даже Поведение JavaScript и, как правило, меньше разметки для поддержки.
Соответствие сайта (по крайней мере, переходному) довольно просто.
Ответ 4
Выполнение совместимого HTML похоже на то, что во время компиляции у вас нет предупреждений - предупреждения существуют по какой-то причине, вы можете не понимать, в чем причина, но игнорировать предупреждения и, прежде чем вы знаете, где вы находитесь, как и многие, вы не можете определить тот, который относится к проблеме, которую вы пытаетесь исправить.
Если вы используете Firefox для просмотра своих веб-страниц, вы получите полезный зеленый тик или красный крест в нижнем правом углу, быстро продемонстрируете, были ли вы выполнены или нет. Щелчок по красному кресту покажет вам все места, где вы столкнулись.
Некоторые из предупреждений/ошибок могут показаться немного педантичными, но исправить их, и вы выиграете во многих отношениях.
- На вашей странице гораздо больше возможностей работать с более широким диапазоном браузеров.
- Соответствие доступности будет проще (например, у вас будут атрибуты "alt" на ваших изображениях).
- Если вы выбрали XHTML в качестве стандарта, ваша разметка будет более полезна в среде AJAX.
Неспособность сделать это приводит к непредсказуемости.
Одна из самых больших проблем с веб-браузерами заключается в том, что они увековечили вредные привычки (и по-прежнему делают это в некоторых случаях), тихо исправляя определенные проблемы разметки, такие как неспособность закрыть ячейки таблицы и/или строки. Этот единственный факт привел к тому, что тысячи веб-страниц несовместимы, но "работают", убаюкивая своих разработчиков ложным чувством безопасности.
Когда вы рассматриваете, сколько вещей есть, что может пойти не так с веб-сайтом, будучи ленивым, когда дело доходит до соблюдения, просто добавляет больше проблем к вашей рабочей нагрузке.
EDIT: снова прочитав свой оригинальный пост, я замечаю, что вы говорите, что не работаете с соблюдением при работе над прототипом, тогда вы говорите, что обычно используете прототип в производстве - это означает, что он не строго прототипом, но кандидатом.
Нормальная ситуация в таких обстоятельствах заключается в том, что, как только клиент принимает кандидата, не время выделяется для исправления ошибок или уборки, тем самым усиливая аргумент в пользу того, чтобы в первую очередь обеспечить совместимость с метками.
Если вам не будет предоставлено время позже, сделайте это сейчас.
Если вам дано время позже, у вас есть время, чтобы сделать это в любом случае.
Ответ 5
Если вы хотите, чтобы ваше зрение было доступно людям с ограниченными возможностями и без них, а также внешним системам, то да, вы должны обязательно убедиться, что вы выдаете правильный HTML.
Легко протестировать ваш HTML с помощью автоматических валидаторов.
Я добавлю к тому, что сказал Майк Эдвардс о правовых последствиях, и напоминаю вам, что у вас тоже есть моральное обязательство:)
Ответ 6
Почему бы не написать прототип в действительном (X) HTML в первую очередь? Я никогда обнаружил, что это больше усилий, чем использование недопустимого HTML. Создание действительного XHTML должно быть тривиальной задачей. (С другой стороны, создание семантически значимого XHTML может быть более подверженным налогообложению.)
Короче говоря, я не вижу никакого преимущества в использовании недопустимого HTML для прототипов.
Ответ 7
Честно говоря, я не знаю, почему это требует дополнительных усилий для создания стандартов на основе HTML. Это не так, как если бы это было трудно, и вы должны делать это как вопрос профессионализма.
Если вы заплатили кому-то, чтобы построить вам дом, и он вырезал углы из лени, которые вы не заметили в то время, но через 10 лет в ваших стенах появились трещины, вы были бы счастливы?
Ответ 8
Совершенно верно. Неверный код может вызывать все виды странных поведений и ошибки, которые не скрывают тех, которые делают, когда вы получаете отчет о проверке.
Пример:
Желтый фон выходил из списка сообщений и над заголовком для следующего списка сообщений, но только в Internet Explorer.
Почему? Фон был применен к элементу списка, но человек, который написал страницу, написал его как единый список с заголовком в середине. Заголовки не допускаются между элементами списка, и разные браузеры пытались восстановить их по-разному. Internet Explorer закончил элемент списка (с цветом фона), когда увидел начало следующего элемента (после заголовка), в то время как другие браузеры закончили его, когда увидели конечный тег для первого элемента списка.
Это была единственная ошибка достоверности на странице, поэтому потребовалось всего пару минут, чтобы отследить проблему и исправить ее.
Ответ 9
Допустимый HTML, чтобы иметь значок на вашем сайте - нет.
Имея "действительный HTML" в смысле "HTML, который работает на каждом главном браузере или в браузере" - да.
Ответ 10
Потому что, если вы придерживаетесь стандартов, ваша работа будет совместима в будущем. Пользовательские агенты будут стремиться к стандартному соблюдению, и режим их несоблюдения всегда будет изменяться. Так должно быть.
Если вы не входите во все эти IE8, которые они хотят включить по умолчанию. - это еще один аргумент.
Webkit, Gecko, Presto? (это опера-движок?), а остальные всегда будут более совместимы с каждым выпуском.
Если ваша работа html не находится в IE с встроенным браузером, тогда нет причин выводить действительный html до тех пор, пока он отображает.
Ответ 11
По моему мнению, ключевым критерием является "подходящий для цели". Если ваши клиенты хотят что-то для малого/внутреннего рынка (и не волнует, что это отчуждает потенциальных клиентов, которые имеют инвалидность или используют менее распространенные браузеры), тогда их выбор.
В то же время я считаю, что наша (как разработчики) ответственность за то, чтобы они знали о последствиях своих решений. Некоторые организации будут связаны законодательными требованиями, что веб-сайты могут использоваться читателями экрана, что обычно означает совместимый со стандартами HTML.
Ответ 12
Я считаю, что создание допустимых выходных данных html не повредит вашему времени разработки, если бы вы научились правильно кодировать действительный html с самого начала.
для одного, его не трудно понять, какие теги не разрешены внутри элемента и требуемые атрибуты в теге, иногда те, которые вам действительно нужны в любом случае - я считаю, что это основные ошибки, которые делают ваш html недействительным, так почему бы не просто изучить их уже сейчас, если вы планируете долгое время оставаться в Интернете? "плюс вывод правильного html может помочь повысить рейтинг сайтов
Ответ 13
Существует два правила написания веб-сайтов:
- Сайт должен работать для ваших пользователей.
- Сайт должен работать для ваших пользователей.
Чтобы соответствовать первому правилу, вы должны закодировать таким образом, чтобы ваш сайт правильно отображался при использовании Internet Explorer. Если у вас нет права изменять дизайн вашего сайта, чтобы использовать только те функции, которые IE отображает правильно, это означает запись недопустимого HTML.
Чтобы соответствовать второму правилу, вы должны закодировать такой код, чтобы ваш сайт правильно отображался при использовании экранных считывателей и экранов Брайля. Хотя некоторые более свежие программы для чтения с экрана могут работать с сайтами, ориентированными на IE, в общем случае это означает, что нужно писать правильный HTML.
Если вы работаете над небольшим проектом, или вы являетесь частью большой команды, вы можете закодировать сайт, который выводит IE-ориентированный HTML для IE, а также действительный HTML в противном случае. Но если вы сами выполняете проект средней и большой, вы должны решить, какое правило вы будете следовать, а какой из них вы проигнорируете.
UPDATE:
Это получает проголосовать от пользователей, которые думают, что вы всегда можете избежать действительного HTML в IE. Это может быть правдой, если у вас есть гибкость в изменении дизайна, чтобы обойти IE недостатки, но если клиент дал вам дизайн, и вы должны заставить его работать, вам, возможно, придется обратиться к недействительным HTML. Это печально, но это правда, что бы они ни думали.