Да мне всё хватает. Просто изначально это пошло из XHTML. Что забыли - да, не нравится :)
Не нашли применение.

Например, selenium.
Допустим, ты написал модуль. Его оттестили. Далее инициализация указывается в разметке на нескольких страницах. Если разметить не правильно (порядок элементов, обязательные атрибуты, значения атрибутов), понятно что скрип не сработает. Валидатор об этом скажет быстрее, чем ошибка найдется.
В данном случае структура полностью отражает функционал, поэтому можно проверять её.
Так и я не призываю :)
Я просто даю объектную среду. А как ты там с ней будешь работать - дело второе.
Ну да. Не замечал? Наш отдел вообще считается как обслуживающий персонал для серверных кодеров. Клиентские профи тоже есть. Например, мы :)
Да во всем разница :)

1. Тут мы вклиниваемся в мир CSS. Наглядно использование атрибута не по назначению. Меня блевать тянет от такой разметки и кода. В итоге это приводит только к постоянным багам/фиксам лучи поноса в сторону jQuery

2. Нестандартный атрибут. Ну это вообще каша получается. Зачем тогда в стили выносить остальное? Вчера я правил один интересный баг. Скрипт писался давно. Его код устанавливал свойство hidden для DOM-узла ссылки. Это задумывалось просто как флаг. В итоге, в html5 вводят тег hidden и ссылки исчезают. Мораль - не засирай чужое пространство, когда есть свое.

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

4. В догонку:
http://www.w3.org/TR/2004/WD-xhtml-m...dule_namespace

Может потом ещё что вспомню.

т.е. раз мы протестировали модуль и валидатор проверил разметку, это значит что больше тестировать нету смысла? По-моему спорное утверждение. В идеале, возможно. Просто готовые компоненты часто подгоняют под свои требования и в результате вылазят всякие проблемы. Но идею я понял

хм, странно, читая вот это:
видно, что тебе это не нравится, и закрадывается подозрение, что все-таки призываешь

ok, поспешил, попытка номер два

<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>

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

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

Этот случай я учел. Я сам допиливал не один плагин. Ну я уже говорил - пишем либо модуль, либо расширение к модулю, если нам нужно что-то изменить. Код модуля остается прежним. Это некая прослойка.
Поясню. Стиль кодирования я не навязываю. Можешь говнокодить сколько хочется, но это всё в пределах модуля и ни на что не влияет. Сейчас же сложно анализировать большую кучу кода - что к чему относится, что за что отвечает. Вспоминаются слова моих бывших коллег, Java-кодеров: "Как вы тут вообще разбираетесь? Не видно ведь кто что делает. В Java, например, видно какой класс для чего написан.".
Валидатором можно оттестить именно применение того или иного модуля на разных страницах. Создал страницу - новый тест писать не надо, всё уже написано до вас.
Ну там не совсем библиотека была. Просто самописный кусок логики с использованием jQuery. В нем же и устанавливалось это свойство.
Ну не пойдет такая попытка. Не видно по коду что к чему относится. Зачем вообще эмулировать пространства имен, если они уже вшиты в браузер, спецификацию, валидатор и т.д.?
Ради того что бы один раз написать "удобный" код, придется постоянно его фиксить - сомнительное преимущество. Не лучше ли сразу огородится от всех и делать что хочется?

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

Ты мне лучше расскажи, что не нравится в пространствах имен?

Хоть что-нибудь то скажите, что вы вообще думаете о такой архитектуре?

- подозреваю что реализация на клиенте будет работать очень медленно. или делать как GWT.

Откуда такие подозрения?

Мне кажется наоборот. Вот структура платформы:
V(HTML, CSS, DOM) - C(Platform) - M(Module 1, Module , Module 3...)

Общение между платформой и модулями происходит на объектном уровне. Т.е. быстро. Это ведь не работа с DOM.

После того, как модули сделали все необходимые изменения, контроллер направляет их в представление. Представление пачкой применяет все инструкции уже непосредственно в HTML, CSS и DOM. Понятное дело, что будут реализованы все возможные оптимизации на этом этапе.
Получается, что все действия модулей нагружать не будут.

Покажите мне код )
нужны примеры. а там будет видно как это все красиво и быстро.

Будет тебе код. Ещё годик погоди только. Шутка.

Скорость программы обеспечивает алгоритм. Если алгоритм неправильный - страдает реализация.

Чем профессионал отличается от начинающего кодера? Опытный программист способен выбрать правильный алгоритм (ну или направление) ещё до начала написания кода. Он и без кода может дать предварительные оценки.
Так что включи мозг.

Ты же сказал, что скорей всего будет медленно. Вот и объясни, на основании чего такие подозрения.

тому что xml нужно парсить. преобразовывать ваши модули во чтота, что понимает браузер. это все будет DOM манипуляции, а то как работает ишак с DOM методами все знают.

Это уже давно не XML :)
Сейчас речь идет о XHTML.