rash

Возможно. Но я, можно сказать, получаю удовольствие, не указывая опциональные закрывающие теги в HTML, например. Хотя чаще всего HTML у меня получается не менее строгим, чем требует XHTML: всё закрыто явно, все атрибуты закавычены и т. д. Да и при наполнении контентом часто нет возможности следить за кодом, а при использовании HTML вероятность возникновения ошибок несколько меньше.

Ну как вам сказать. Я не испытываю ненависти к таблицам для нетабличных данных. По возможности стараюсь обходиться без них, потому что код получается чище и нагляднее, но в сложных случаях использую. Как-то даже пришлось полностью переверстать сайт на таблицах, когда уже была запущена версия, сверстанная на блоках. Но он постоянно дорабатывался, изменялся и развивался, и блочная верстка этого не выдержала. Она постоянно «обрастала» новыми элементами, правилами и классами, которые не предполагались изначально, и в один момент она просто стала слишком сложной для поддержки. В общем, как раз после этого случая мое восприятие таблиц «переломилось». Теперь я уверен, что важна не только чистота кода, но и его надежность и приспособленность к дальнейшей поддержке и доработке. Ждем css layout model, инструмент, предназначенный для раскладок изначально. Я надеюсь, что он с этой задачей будет справляться лучше тех средств, которые есть сейчас.

Вы не меняли структуру кода, а только перевели его в XHTML? :-)

Хочется понять, почему XHTML не сменил HTML. Первый как бы продуманнее, удобнее и т.д. В каких же аспектах он удобнее? Как раз наоборот. Он изначально создавался как более удобный для парсера, а не для человека. То есть его удобнее читать, а не писать. У них это получилось, только это никому не нужно. Нужен язык, который удобно писать, который устойчив к ошибкам. HTML именно такой.

Вот пока они нас не покинут, и будут нужны хаки и таблицы. Мир неидеален, ага... А верстка полностью без таблиц подразумевает слишком много условий, чтобы ее можно было считать надежной и универсальной.

На валидность XML-документы проверять не требуется, хотя и не запрещается. Такая поддержка нужна, потому что в теории XML-совместимые страницы удобнее обрабатывать на мобильных устройствах и прочих с ограниченными ресурсами. А на практике действительно идея себя не оправдала, поэтому смело пишите документы в HTML 4.01

К нему должны применяться правила разбора такие же, как для xml-документов, то есть если нарушается well-formed'ность, разбор должен останавливаться. Это значит, что большинство страниц, которые сейчас объявлены как XHTML, при правильном разборе отображены не будут.

Как XML.

Потому что он обрабатывается как HTML.

С таким доктайпом будет стандартный режим. Не вижу оснований для такого утверждения.

Вот еще как вариант: a { text-decoration: none; border-bottom: 1px solid #ccc; } a:before { content: "«"; border-bottom: 1px solid #fff; } a:after { content: "»"; border-bottom: 1px solid #fff; } Но мне этот способ нравится меньше, чем использование нормального подчеркивания для текста.

Используйте способ Бирмана. Он хороший. Сначала мне тоже не понравился, но потом я понял, что он обеспечивает наименьшее количество костылей. А подчеркивание ссылки у вас просто наследуется генерируемым контентом, ничего с этим не поделать. Нужно задавать подчеркивание для элемента, вложенного в a, а кавычки генерировать для самого элемента a. Что, собственно, у Бирмана и сделано.

А зачем валидность стилей нужна, если правила обработки ошибок описаны в спецификации?

Так паддинг "оттолкнет" бордер. Разве это то, что нужно? Разница только в том, где будет находиться однопиксельная граница, тут уже зависит от того, что нужно получить.

Когда отображается однопиксельная рамка, задавайте margin: 2px, когда трехпиксельная - убирайте отступ совсем.

Опера позволяет это делать только в quirks-режиме.

a:hover { border-bottom: 1px dashed; } Что-то вроде этого

Я с валидатором совершенно согласен. Не хватает одного обязательного элемента.

А если завернуть все это в блок, который тянется в нужных пределах, а внутри него text-align: justify и какой-нибудь невидимый элемент, перенесенный на вторую строку, чтобы заставить тянуться первую? Разделители ведь можно сделать текстовыми элементами.

font-size: 0; Он считает, что в этом блоке должен быть текст, и растягивает его на высоту строки (height = min-height)

Не видя макета можно посоветовать взять таблицы.

label'ы использовать хорошо и правильно, странно, почему о них так часто забывают. А вкладывать input в label можно, только приведенный код без атрибута for не сработает в IE6.

Им в общем и целом все равно, лишь бы хорошо работало и не разваливалось.

Сложно переделывать форму, если многое в ней надо изменить. Больше недостатков пока не заметил.

Можно сказать, что я это взял за правило.