Приемлемо ли это для недопустимого XHTML?
https://stackoverflow.com/questions/3448
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Я заметил, что многие сайты, включенные в SO, используют XHTML в качестве языка разметки, а затем не соответствуют спецификации.Просто просматриваю исходный код на предмет отсутствия закрывающих тегов для абзацев, недопустимых элементов и т.д.
Итак, должны ли инструменты (и разработчики) использовать XHTML doctype, если они собираются создавать недопустимую разметку?И должны ли браузеры быть более твердыми в своем принятии плохой наценки?
И прежде чем кто-нибудь закричит "лицемер", в моем блоге есть одна недопустимая разметка, связанная с captha (или она была, когда я проверял в последний раз), которая включает в себя стилизацию тега noscript.
Решение
Есть такие много причин использовать допустимую разметку.Мне больше всего нравится то, что это позволяет вам использовать валидацию как форму регрессионного тестирования, предотвращая то, что эквивалент разметки "дельта-гнили" приведет к реальным проблемам рендеринга, как только ошибки достигнут некоторой критической массы.И действительно, это просто небрежно - допускать накопление "ленивых" ошибок, таких как опечатки и неправильно вложенные / незакрытые теги.Допустимая разметка - это один из способов идентификации увлеченные программисты.
Существует также проблема отладки:правильная разметка также дает вам стабильную базовую линию, исходя из которой можно работать над неизбежными проблемами кроссбраузерной совместимости.Ни один веб-разработчик, который ценит свое время, не должен приступать к отладке проблем совместимости браузера, предварительно не убедившись, что разметка по крайней мере синтаксически допустимая - и любая другая недопустимая разметка должна иметь вескую причину для ее наличия.
(Кстати, stackoverflow.com не удается выполнить оба этих теста и предложения по устранению проблем были отклонено.)
Учитывая все вышесказанное, чтобы ответить на ваш конкретный вопрос, вероятно, не стоит использовать один из типов документов XHTML, если вы не планируете создавать valid (или по крайней мере наименьший хорошо сформированная) разметка.Основные преимущества XHTML вытекают из того факта, что XHTML - это XML, что позволяет обрабатывать и преобразовывать его с помощью инструментов и технологий, работающих с XML.Если вы не планируете делать свой XHTML корректно оформленным XML, то нет особого смысла выбирать этот doctype.Последняя спецификация HTML 4, вероятно, сделает все, что вам нужно, и она гораздо более щадящая.
Другие советы
Мы всегда должны стараться, чтобы он подтверждался в соответствии со стандартами.Мы будем уверены, что веб-сайт будет отображаться и нормально работать в текущих и будущих браузерах.
Я не думаю, что, если вы укажете doctype, есть какие-либо причины не придерживаться этого doctype.
Использование XHTML упрощает автоматическое обнаружение ошибок, каждое изменение может быть автоматически проверено на наличие недопустимой разметки.Это предотвращает ошибки, особенно при использовании автоматически сгенерированного контента.Веб-разработчику, использующему механизм создания шаблонов (JSP, ASP.NET StringTemplate и т.д.), Действительно легко скопировать / вставить слишком маленький или слишком большой закрывающий тег.Если это ваша единственная ошибка, ее можно немедленно обнаружить и исправить.Однажды я работал на сайте, на странице которого было 165 ошибок проверки, из которых 2 или 3 были реальными ошибками.Их было трудно найти в нагромождении других ошибок.Автоматическая проверка предотвратила бы эти ошибки в источнике.
Излишне говорить, что выбор стандарта и его соблюдение никогда не улучшат совместимость с другими системами (скребками экрана, программами чтения с экрана, поисковыми системами), и я никогда не сталкивался с ситуацией, когда действительное семантическое решение XHTML с CSS было невозможно для всех основных браузеров.
Очевидно, что при работе со сложными системами не всегда возможно придерживаться вашего doctype, но в основном это результат неправильного взаимодействия между разными командами, разрабатывающими разные части этих систем, или, скорее всего, устаревших систем.В последнем случае, вероятно, лучше изолировать эти случаи и соответствующим образом изменить ваш doctype.
Хорошо быть прагматичным и не придерживаться XHTML только потому, что кто-то так сказал, независимо от затрат, но с текущими знаниями о CSS и браузерах, инструментах тестирования и валидации в большинстве случаев выгоды намного превышают затраты.
Вы можете сказать, что у меня есть OCD на валидность XHTML.Я нахожу, что большинство проблем, связанных с некорректностью кода, возникают из-за того, что программисты не знают разницы между HTML и XHTML.Я уже некоторое время пишу 100% корректные XHTML и CSS, и у меня никогда не было серьезных проблем с рендерингом в других браузерах.Если вы сохраните все в силе и не будете пробовать ничего слишком экзотического с точки зрения css, вы сэкономите массу времени на исправлениях.
Я бы вообще не стал использовать XHTML, просто чтобы избавить себя от философского напряжения.В любом случае, не похоже, чтобы какие-либо браузеры обрабатывали его как XHTML.
Браузеры отклонят плохую разметку, если страница отправляется как application / xhtml + xml, но это редко бывает так.Это прекрасно.
Меня бы больше беспокоили такие вещи, как встроенное использование CSS и JavaScript с переполнением стека, просто потому, что они усложняют обслуживание.
Хотя я верю в стремление к корректному XHTML и CSS, часто это трудно сделать по ряду причин.
- Во-первых, часть контента может быть загружена через AJAX.Иногда фрагменты неправильно вставляются в существующий DOM.
- Возможно, не все HTML-файлы, которые вы просматриваете, были созданы в одном документе.Например, страница может быть составлена из компонентов или шаблонов, а затем объединена непосредственно перед тем, как браузер отобразит ее.Это не оправдание, но вы не можете предполагать, что HTML, который вы видите, был сразу закодирован вручную.
- Что делать, если часть кода, сгенерированного Markdown, недействительна?Вы не можете обвинять Stack Overflow в том, что он не создает корректный код.
- Наконец, цель DOCTYPE - это не просто сказать "Эй, я использую допустимый код", но также предупредить браузер о том, что вы пытаетесь сделать, чтобы он мог хотя бы приблизиться к правильному анализу этой информации.
Я не думаю, что большинство разработчиков указывают DOCTYPE, а затем явно не придерживаются его.
хотя я согласен с утверждением "если он отрисовывается нормально, то не беспокойтесь об этом", однако это полезно для следования стандарту, даже если он может быть не полностью поддержан прямо сейчас.вы все еще можете использовать таблицу для верстки, но это нехорошо по какой-то причине.
Нет, вам не следует использовать XHTML, если вы не можете гарантировать правильность оформления, и на практике вы не можете гарантировать этого, если не используете XML serializer для генерации разметки.Читать о создании XML.
Правильная форма - это тот самый то, что отличает XHTML от HTML.XHTML с "всего одной" ошибкой разметки перестает быть XHTML. Каждый раз все должно быть идеально.
Если кажется, что сайт "XHTML" работает с некоторыми ошибками, это потому, что браузеры игнорируют DOCTYPE и интерпретировать страницу как HTML.
Видишь Прокси -сервер XHTML это вынуждает интерпретировать страницы как XHTML.Большую часть времени они с треском проваливаются.Это одна из причин, по которой будущее XHTML неопределенно и почему разработка HTML была возобновлена.
Это зависит от обстоятельств.У меня это было проблема с моим блогом где видео с YouTube вызвало недопустимый XHTML, но оно отрисовалось нормально.С другой стороны, у меня есть ссылка "Valid XHTML", и комбинация утверждения "Valid XHTML" и invalid XHTML не является профессиональной.
Поскольку SO не претендует на валидность, я думаю, что это приемлемо, но лично я на месте Джеффа был бы обеспокоен и попытался бы исправить это, даже если это хорошо выглядит в современных браузерах, но некоторые люди предпочитают просто двигаться дальше и действительно доводить дело до конца, вместо того чтобы исправлять несуществующие ошибки.
Пока это работает в IE, FF, Safari (вставьте здесь другой браузер), у вас все должно быть в порядке.Проверка не так важна, как корректное отображение в нескольких браузерах.Просто потому, что он действителен, это не значит, что он будет работать должным образом, например, в IE.
Запустите Google Analytics или что-то подобное на своем сайте и посмотрите, какие браузеры используют ваши пользователи, а затем определите, какие браузеры вам нужно поддерживать больше всего, и позаботьтесь о менее важных из них, когда у вас будет для этого свободное время.
Я говорю, что если он отрисовывается нормально, то не имеет значения, идеален ли он в пикселях.
Требуется некоторое время, чтобы настроить сайт и запустить его так, как вы этого хотите, возвращение назад и внесение изменений немного изменят способ отображения страницы, затем вам нужно исправить эти проблемы.
Я не говорю, что вы должны создавать неаккуратные веб-страницы, но я не вижу причин чинить то, что не сломалось.Браузеры не собираются отказываться от поддержки исправления ошибок в ближайшем будущем.
Я не понимаю, почему все увлекаются попытками привести свои веб-сайты в соответствие со стандартом, когда у некоторых браузеров могут возникнуть проблемы с корректным отображением стандартного кода.Я занимаюсь веб-дизайном где-то около 10 лет и перестал заниматься двойным кодированием (читать:взлом css) и изменение глупых вещей только для того, чтобы я мог разместить кнопку на своем сайте.
Я считаю, что использование < div> в любом случае сделает вас недействительным, и без него будет немного сложнее выполнять любые основные JavaScript / AJAX.
Существует так много стандартов, и они так плохо "соблюдаются" или поддерживаются, что я не думаю, что это имеет значение.Не поймите меня неправильно, я думаю, что должны быть стандарты, но поскольку они не соблюдаются, никто им не следует, и это огромная нисходящая спираль.
Для 99,999% существующих сайтов это действительно не будет иметь значения.Единственный раз, когда у меня это имело значение, я запустил ввод HTML через HTMLTidy в XHTML-ize, а затем запустил свою обработку.
В значительной степени это аксиома старого программиста:не доверяйте никаким вводным данным.
