альтернатива HTML5 прямо сейчас

Пишу js-фреймворк, который является подобием флекса для x(ht)ml + js.
Чтобы немного ввести в курс дела, пейзажи типа такого (упрощённо и бессвязно):
var myAnchor = new DOM.html.A(...);
DOM.html.A.prototype.onclick = ...; // в любое время, а не только перед созданием dom-элементов, как в других фреймворках
DOM.app.Thumbnail= DOM.html.Img.extended(...); // а внутре пишем например так, чтобы запрашивалась отмасштабированная сервером картинка по реальным размерам блока
DOM.app.Div.onBorderWidth = ...; // css транслируется в свойства, т.е. в css можно придумывать собственные свойства, типа shadow:..., и они будут обрабатываться как .setShadow(...); побочный эффект — хаки браузеров легко и непринуждённо
DOM.app.Thumbnail.onRender = ...; // много разных хороших событий
DOM.app.User.onGoodDrop = ...; // и прочих маленьких радостей разработчика
Шаблонизатор клиентский.
Всё само оживает из обычного x(ht)ml, например, при загрузке страницы. Можно и кодом рулить.
Навигация через data binding с проведением через #.
Если js отключен, видна версия для печати/кпк/поисковика (она-то и разворачивается при наличии js).
Понятно, что подход в целом предполагает много реализаций элементов и библиотек и каждый будет норовить придумать лисапед и т.п., но, вообще-то, уже и так есть куча фреймворков и никто не жалуется.

Увлёкся.
Дык вот. Общий подход, как не трудно догадаться, располагает к пути, описанному в статье — свои элементы, полная, рулимая js-ом гибкость поведения и вида, здравствуй тот самый «X». Ан нет, всё упирается, как всегда, в ie. Например, как известно, можно заставить выводить xml в нужном визуале, приложив css. Но при этом ie создаёт свои head и body и всё в них по своему усмотрению раскладывает, хошь иначе — перемещай. Или: если основной неймспейс не html, в ie начинаются глюки с распознаванием префиксов html: элементов (а они нужны — это, как минимум, img, script, style, input). И т.п., все закидоны уже не припомню (хотя давно пора записывать и издавать книгой). Да они все какбе и лечатся, но, вдоволь накувыркавшись, решил поступить проще. На текущий момент страница — обычный html, даже не «Х». Кастомные элементы объявляются в своих неймспейсах, в вёрстке выделяются префиксами (связь — xmlns:app=«DOM.app», соответственно, элемент app:thumbnail это DOM.app.Thumbnail), это успокаивает html-парсер. Всё хml-ные dom-фишки, типа распознавания префиксов, понимание неймспейсов и т.п., тупо эмулируются, — на случай, если вдруг вся система изначально запляшет из xml, для разработчика ничего не меняется. Но вот о теме статьи — полном отрыве от html, пока можно только мечтать.

Бред.

1) Вы не сможете описать поведение всех элементов, например, img, object, video, audio.
2) Реализация на скрипте вместо нативной будет тормозить по определению.