к счастью. Давно прошла. Cкорее не угадал. Хотя с другой стороны какая разница, если хорошо провел время, м? :) Кроме того, разве это так важно, что модно? А вдруг твой фреймворк опередил время и станет популярным через пару сотен лет? ;)

Нет, намного раньше :)
По крайней мере я всё для этого сделаю.

А вот это давай обсудим :)
Что мешает в XHTML?

для начала немного ссылок
Postel's law
The history of draconian error handling in XML
XHTML—What’s the Point? (Draft, incomplete)
Sending XHTML as text/html Considered Harmful
Everything you know about XHTML is wrong

мешает, конечно, его строгость. Она может быть полезна для разработки, но не нужна на production'е (зачем не отображать документ, если его можно отобразить? Малейшие ошибки приводят к полному отказу) Она повышает требования к людям и инструментам разработки и следовательно тормозит развитие. Пользователь может поломать сайт вставив невалидный контент. Ну или пускай не пользователь, пусть модератор/контент-менеджер/администратор (нужное подчеркнуть). XHTML - это скорее вопрос религии, чем практической необходимости. Либо кому-то просто наболело. И, собственно тот, кто это все придумал, признает, что это было по-крайней мере спорно:
http://diveintomark.org/archives/200...6/draconianism

и как мы все убедились, это было слишком категорично, по-крайней мере в таких масштабах. Нипалучилось :)

итого, я практически не вижу плюсов, зато вижу один большой минус

справедливости ради приведу ссылку с альтернативным мнением, правда 2004 года выпуска

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

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

Это да.

Вообще, я говорил не о формате, а о DTD. Т.е. если мы используем документ в формате XHTML (расширение xhtml, content-type: application/xml+xhtml), то это уже указание на формат, а не какое-то там DTD, поэтому и парсится соответственно.
DTD XHTML прижился и используется. Формат XHTML не используется. Потому что ишак клал на него.
Давайте далее, говоря о XHTML, подразумевать соответствие документа с DTD XHTML в формате HTML.

x-yuri, ограничения, о которых ты говорил, накладываются форматом. А что мешает соответствовать DTD?

tenshi, почитай ссылки, там все есть:
это уже поинтереснее. Но 1) это проблема решаемая, 2) почему из-за тех, для кого это важно должны страдать все? 3) для тех, для кого это важно - это не проблема, у них есть опытные специалисты и достаточно денег, 4) вместо xss получаем проблему с чисткой контента, создаваемого пользователями

dtd ничего не мешает соответствовать. Вопрос в том, что это даст. Что там в этом dtd такого есть? Я наверное не особо в курсе. На модули разбили? Четче описали правила? Да и вообще, расскажи что ты видишь положительного в XHTML

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

На самом деле, программируя интерфейс, вы все уже давно работаете с модулями. Всё что вы пишите по сути своей расширяет уже что-то готовое, встроенное, либо это самостоятельный модуль.

Приведу примеры. Вы все писали расширения к модулям XHTML:
placeholders, валидация, ajax загрузка файлов - это примеры расширений модуля Forms, описанного в спецификации XHTML. Действительно, в валидаторе вам нужны только теги из этого модуля (т.е. форма и её элементы).
Сортировка - расширение модуля Tables.
Дерево - расширение модуля List.

В HTML нельзя создать собственный модуль на уровне данных. Формат этого не предусматривает. Конечно, логику написать можно и всё будет работать, но данные (теги), которые он использует, будут принадлежать другим модулям (стандартным). Отсюда все болезни: верстак изменил html-код - упали скрипты (знакомая ситуация?). Фикс такого бага в большинстве случаев сводится к правке селектора или ещё какой-нибудь мелочи, но сам факт фикса присутствует!

XHTML дает такую возможность посредством пространств имен. Модальное окно - пример самостоятельного модуля. Основные узлы (заголовок, контент и т.д.) должны принадлежать ему (иметь собственное пространство имен). SVG - самостоятельный модуль. Работает только в XHTML, потому что в HTML его просто невозможно вставить (см. предыдущий абзац).
По сути - кастомный модуль почти ничем не отличается от того же SVG. Отличие одно - SVG написан на другом языке программирования и встроен в браузер, а кастомный на javascript.

Я смотрю на веб-приложение с этой позиции. Предлагаю взглянуть и вам :)

http://www.alistapart.com/articles/u...rounds-part-i/
как на практике дело обстоит - не знаю

т.е. ты предлагаешь создавать свои модули (в терминологии XHTML, на равне с его собственными), писать для них свой dtd? Это скорее для каких-то достаточно больших проектов. Как-то слишком сложно и непонятно, что это дает. Я не понимаю как модули могут предотвратить необходимость изменения скриптов при изменении разметки. Привязываться только к своим тегам? С тем же успехом можно добавлять к классам префикс, получаем некоторое подобие пространства имен. Но если ты изменишь разметку своих тегов, из своего модуля скрипты все равно упадут. Кстати, БЭМ, по идее, близок к твоей задумке, только без XHTML-модулей. А почему, собственно, для этого нужны XHTML-модули? С ними разве что красивее получится, но ничего не мешает это реализовать без них

Ну я про это и говорю. В HTML5 тоже есть пространства имен, как и в XHTML, что позволяет вставлять SVG.

DTD можно и не писать. Тем более что все кладут на валидатор W3C. А если писать, то уж лучше XML-схему. Вообще, при таком раскладе валидация становится средством тестирования страниц. Другие тесты можно даже и не писать. Таким образом твой вопрос должен был звучать так: "Писать для них свои тесты?".

Собственно:
... и атрибутам.

Постараюсь объяснить что же это нам даст.

Что нужно верстаку? Править html-код. Что конкретно в коде ему нужно править? По пунктам:

1. Добавлять/удалять узлы.
2. Править атрибуты.
3. Править стили (как CSS, так и классы).
4. Изменять структуру дерева.

Это что касается поддержки и развития. Когда html только создается - проблем нет.

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

<div ns:parent="name">
  <p>Paragraph</p>
  <ns:item class="item-1">text</ns:item>
  <ns:item class="item-2">text</ns:item>
  <div class="nbsp">&nbsp;</div>
</div>

Верстак может без проблем поменять имя корневого тега, так как оно не относится к пространству имен. Атрибут ns: parent его вообще не должен интересовать. Точно так же он может менять атрибуты class не задумываясь о том, к чему принадлежат эти классы. Можно добавить любые теги или убрать те, которые не принадлежат к пространству имен. Другими словами: он видит с чем ему можно работать, а с чем нет. Так мы полностью отделили верстальщика от JS-ника.

Что касается четвертого пункта. Структура данных - по природе своей древовидная и от этого никуда не деться. Мы должны учитывать это. Если структура изменяется, изменяется и логическое значение узлов. Так же и тут: если вынести ns:item за ns: parent, то он уже не будет ребёнком parent-а. Но скрипт и не упадет от этого. Он просто не обработает его.

БЭМ вообще придуман для CSS (хотя и файловую структуру это коснулось тоже). Стиль наименования классов + логическое разделение, я бы сказал. К XHTML отношения вообще не имеет.

Собственно, чем сейчас все и занимаются. Архитектура сегодняшнего веб-приложения:
данные - куча говна
логика - стая мух, облепивших говно со всех сторон
представление - где-то между говном и мухами

А потом задумываемся - почему серверных разработчиков ставят на уровень выше клиентских? И правильно делают.

хм, я тебя по-другому понял. Но возникает другой вопрос: если пространства имен поддерживаются html5, то чего тебе не хватает? Тебе не нравится, что все про них забыли?

да, это и имел в виду

а какие другие тесты и почему их можно не писать? Ведь ты только структуру с помощью xml-схемы проверишь

ну вот альтернативная реализация твоего примера

<div ns-parent="name">
  <p>Paragraph</p>
  <div class="ns-item item-1">text</div>
  <div class="ns-item item-2">text</div>
  <div class="nbsp">&nbsp;</div>
</div>

в чем разница?

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

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

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