у тебя получатся абсолютно различные реализации для ие и всех остальных и ты запаришься добиваться единообразного поведения.

Можно сказать уже добился... Конкретной реализации пока не могу привести.
С (x)html разве не так же? По-сути вся реализация сводится к обучению ишака и создания красивого фантика для всего этого, как в том же jQuery (не будем обращать внимание на небольшие различия нормальных браузеров).

нет, xml узлы из не знакомых браузеру пространств имён много чего не умеют..

Это и правильно. На то это и xml. В любом случае всегда можно создать xhtml-узел. Разница подхода из статьи (твоя?) и моего, по сути только в том, что там глобальное пространство имен принадлежит xhtml, а не xml. В моём случае этого добиться очень легко. Но! Это и не нужно! Я сознательно хочу создать такую среду, где разметка описывала бы только структуру данных. Ты когда-нибудь участвовал в разработке ну очень динамического интерфейса? Если да, то наверняка должен знать, что обычных классов и id никогда не хватает. Приходится навешивать невалидные атрибуты с JSON-ом в качестве значения и т.д. Когда на одном элементе 5 классов и ни один не задаёт визуальное оформление это нормально по-твоему? А прикручивать к href строку с параметрами как в thickbox? Для всего этого в xhtml уже просто не хватает места... Уже незнаешь что куда прикрутить, чтобы всё проинициализировалось при ready. Или ты думаешь я от делать нех. этим занимаюсь?

вот давай это обсудим ;) Видимо я не учавствовал в разработке _очень динамических интерфейсов_. Почему там не хватает id и классов? Зачем навешивать невалидные атрибуты с JSON в качестве значения? Что за строка с параметрами в thickbox?

Разберём на примере thickbox-a. Есть на странице куча не связанных с собой элементов, при клике на которые должно подниматься модальное окно (thickbox). При ready скрипт должен сам найти и проинициализировать (добавить обработчики в нашем случае).
Для этой задачи id вообще не подходят: количество элементов не извесно, а генерить id по маске по меньшей мере глупо. Можно на все элементы добавить класс thickbox (как раз что и делает этот плагин), но они ведь придуманы совсем для другого. Но и этого не достаточно.
Ещё необходимы параметры. Thickbox это делает так:

<a href="#?TB_iframe=true&height=400&width=600" class="thickbox">link</a>

Но такой вариант подходит только для ссылок и не всегда бывает удобно их использовать.
Не так давно я написал своё окно, которое указывается так:

<div modal="type:'info', width:'auto', height:'200', id:'id'">text</div>

Да, это не есть правильно из-за нестандартного modal, но использовать можно везде. Для валидности можно засунуть в своё пространство имен.

Конечно можно было обойтись и onclick, но кроме модального окна этот элемент выполняет ещё кучу действий, которые так же должны быть проинициализированны при ready. Если для каждого элемента добавлять onclick: страдает скорость разработки, дальнейшая поддержка, объём кода - проверенно. Это самый простой случай. Ещё бывает так, что есть набор элементов, связанных с другим набором, которые связанны с третьим. Эту связь необходимо указывать именно в разметке, чтобы потом легко понимать что к чему относиться. Для небольших связей подойдут и классы, а когда уровень вложенности и разветвления неизвестен? В общем html сильно мешает разработке. Да и реализация xml в ишаке сильно подводит:(

В HTML5 для этого сделали dataset.

Ты немного не так понимаешь. Важна именно структура данных. Чтобы всё логично было... Грамотно...

разметка структуры, визуализации и поведения хотя и должна находиться в разных файлах, но в результате должен получаться один документ содержащий их все.
пример: http://smileg.akmedia.ru/html/lib/
смотри, как реализован компонент всплывающего меню: http://smileg.akmedia.ru/html/lib/cl...onent/popup.js
инициализируется сразу при загрузке элемента, а не страницы целиком.

Логично:)
Ну вот что-то вроде этого хочу:)

tenshi, не мог бы ты дать новую ссылку на твою статью, а то старая умерла.

которую? о0

На эту.

Ну так что?! Умерла статья чтоли? Мне нужны оттуда исходники примеров...

Можно из гугловского кэша достать:

<o:data xml:lang='ru' xmlns="http://www.w3.org/1999/xhtml" xmlns:h="http://www.w3.org/1999/xhtml" xmlns:h2="http://www.w3.org/2002/06/xhtml2/" xmlns:hx="http://d-o-b.ru/iface/#html-ext" xmlns:o="http://d-o-b.ru/iface/#smileg" xmlns:c="http://d-o-b.ru/iface/#control" xmlns:l="http://www.w3.org/1999/xlink">
    <o:section-list>
        <o:section>
            <o:uri>?article/list</o:uri>
            <o:title>Читай</o:title>
        </o:section>
        <o:section>
            <o:uri>?galery</o:uri>
            <o:title>Смотри</o:title>
        </o:section>
        <o:section>
            <o:uri>?track/list</o:uri>
            <o:title>Слушай</o:title>
        </o:section>
        <o:current>?article/list</o:current>
    </o:section-list>
    <o:base>http://smileg.akmedia.ru/branch/strana/</o:base>
    <o:style>main</o:style>
    <o:article-list>
        <o:title>Библиотека текстов</o:title>
        <o:uri>?article/list</o:uri>
        <o:time>2009-03-24 03:09:00</o:time>
        <o:rss>?rss/article/list</o:rss>
        <o:article>
            <o:uri>?article:div.make.up</o:uri>
            <o:title>Дивная вёрстка</o:title>
            <o:descr>Упорядочивание терминологии используемой для классификации подходов к формированию вэб-страниц.</o:descr>
        </o:article>
        <o:article>
            <o:uri>?article:hiqus</o:uri>
            <o:title>HiQuS (Hierarchical Query String)</o:title>
            <o:descr>Формат представления иерархических структур данных в виде одной строки.</o:descr>
        </o:article>
        <o:article>
            <o:uri>?article:no.selflink</o:uri>
            <o:title>Сэлфлинки недопустимы?</o:title>
            <o:descr>Критика распространённого заблуждения о недопустимости нахождения на странице ссылок на саму себя.</o:descr>
        </o:article>
        <o:article>
            <o:uri>?<b style="color:black;background-color:#a0ffff">article:kill.html</b>
            </o:uri>
            <o:title>Расследование убийства HTML</o:title>
            <o:descr>Описание техник использования возможностей xml-языков в браузерах текущего поколения. Трюки, хаки и прочие выкрутасы, позволяющие уже сейчас коснуться будущего.</o:descr>
        </o:article>
        <o:article>
            <o:uri>?article:trash</o:uri>
            <o:title>А вы любите рыться в мусоре?</o:title>
            <o:descr>Рассуждения на тему типичных правил организации обсуждений на сайтах и порождаемых ими социальных конфликтов.</o:descr>
        </o:article>
        <o:article>
            <o:uri>?article:uuu.hell</o:uri>
            <o:title>ЧПУ - великое зло!</o:title>
            <o:descr>Анализ существующих схем формирования ури и синтез той, которая «труъ».</o:descr>
        </o:article>
    </o:article-list>
</o:data>

--------------------
а нет, это наверное еще до обработки шаблонизатором

Я пытался найти в кеше, но ничего не вышло:(

Там ещё заголовок такой что вываливается куча левого материала в результатах поиска...

Там в статье были ссылки на демо-странички html css dtd и js - вот они то мне и нужны...

гомэн, только сейчас пришло уведомление о твоих коментах ._."

http://mojura.110mb.com/?article:kill.html

tenshi, во! Спасибо! На етот раз я сохраню у себя копию, если ты не против:)

tenshi,
Не мог бы ты ответить на пару вопросов?

1. urn:barbarian это что-то стандартное и какие варианты бывают? Например urn:my - уже не валидно.

2. Не мог бы ты дать подробнее комментарии к dtd? 30% я понимаю, а остальное пока очень смутно ибо с англицким не очень.

Ну или хотябы подскажи, как сделать элементы SVG валидными. Пробовал подключить DTD, как это сделано для XHTML 1.1:

<!ENTITY % svg11.dtd PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
%svg11.dtd;

Но так вообще все элементы стали не валидными:(

В ручную как-то не хочется вписывать все элементы...

осталось только подождать недельку и tenshi ответит :)

tenshi, помоги.

1. там может быть любой ури http://ru.wikipedia.org/wiki/Uri
2. это надо разбираться с форматом.. http://ru.wikipedia.org/wiki/DTD где-то видел ман на русском, но что-то не нашёл

я не виноват что тут уведомления так долго идут ^^'

http://www.gargona.com/art/doctype_html.php - тут есть список доктайпов включающих svg и mathml

В общем по DTD всё понятно. Непонятно только где используются сущности Core.extra.attrib, Block.extra. Их в DTD xhtml11 я не нашел. В статье говорится:
Где это можно посмотреть?

И ещё. Так же не нашел определения сущностей Flow.mix, Inline.mix, Block.mix. Как я понимаю, они ссылаются на определённые классы элементов (?, строковые, блочные). Правильно?

Сущность Common.attrib ссылается на все общие атрибуты? Где вообще всё это определяется?

http://www.w3.org/TR/xhtml11/xhtml11_dtd.html в комментах всё есть

tenshi, спасибо:)

Рождается мега-ацкая вещь...

Хех, почти ровно год назад оборвалась эта нить )
А чем всё закончилось? Или это было только начало? Таки ж интересно.

Начало.
А что конкретно интересует? В вопросе с DTD есть даже спецификация.

Раньше я вообще не знал о её существовании. Тогда бы она мне сильно помогла.

Вообще, у меня есть архитектура платформы client-side, под которую можно будет легко писать веб-приложения. Её я вылизываю уже почти год. В принципе архитектура готова. Сейчас работаю над техническими деталями: структура данных (скорей всего будет древовидная), событийная модель и т.п. Это непосредственно то, с чем будет работать веб-приложение, поэтому хочется что бы всё было идеально :)

Вообще смешно получается. Сейчас все кому не лень пишут и говорят о HTML5. Мода на XHTML, к сожалению, проходит. Архитектура моей платформы построена полностью на идеологии XHTML. Опоздал? :)

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

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