Я вот верстаю, и последнее время задался вопросом, неужели html и xml так идеален... что использовать их в чистом виде, неужели W3C будет каждый год выдавать стандарты... и т.д.... неужели никто не додумался до такой простой вещи как язык разметки как бы высокого уровня... 

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

Я конкретно говорю о том, что можно наверно было бы сделать как бы WEB-компилятор для языка разметки, который по уровню выше html - a, (он бы просто переводил запись на язык html), и все... все стандарты бы соблюдались...

Просто если задуматься, это же была бы экономия времени и нервов... меньше кода... больше возможностей...

P.S. Я долго искал что-то подобное в нете, в гугле, в википедии... ничего даже близкого не встречал... Если кто понял о чем я?   

для начала, html - менее стргоий в отношении оформления подтип xml, с предопределенным набором тегов. так что можно говорить просто об xml.

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

спецификации.
стандарт один - на язык разметки(скажем) html. описано, как могут быть вложены элементы, как описывают элементы, как определяются атрибуты. а спецификация описывает, что <b> - усиление текста(необязательно за счет жирного шрифта), <img> - отображение графического элемента и т.д. 
впрочем, могу ошибаться с толкованием терминов, но все равно: каждый год w3c не выдает ничего нового. оптимизируется и дополняется старое.

это не проблемы языка разметки. если некоторые люди неверно понимают правила дорожного движения, не думаю, что есть смысл менять правила. проще научить людей. продолжаю аналогию: если браузеры отображают один и тот же код по-разному, значит у них проблема несоблюдения того или иного раздела спецификации той же w3c(проблемы с отступами, внутренними полями и float'ами отсюда). Или же потому, что в спецификации не указано то или иное(например, как отрисовывать по умолчанию содержимое тега <b> - ведь есть браузеры для слепых, а шрифт Брайеля жирным не сделаешь), и браузеры каждый по-своему отрисовывает, внося неприятное разработчику разнообразие не только во внешний вид(цвет, размер), но и в верстку целиком.
резюме: сам по себе xml  - практически универсален(ну, почти), задачу свою(структурирование инфомрации) выполняет; проблемы некроссбраузерности не связаны с языком разметки как таковым.

Меньше кода - для разработчика или для браузера?
Если тебе хочется писать меньше кода - посмотри на языки/системы генерирования текста(к примеру, РНР или ASP вполне могут использоваться для этих целей) и на системы шаблонизации(+1 к абстракции при написании) под эти системы.
Или речь о "меньше кода" для браузера? 
А зачем? 
"Больше возможностей"... Хм, так набор возможностей зависит от клиентской программы - браузера. Вот, положим, я хочу, чтоб тег "<calendar>" выводил на странице календарь для выбора даты. А браузер не понимает. И что? при чем тут язык разметки? надо делать другой браузер, чтоб понимал...
Вообще говоря, все не ограничивается html/xml.
например, есть svg - специализированный язык разметки для вывода векторной графики. является подтипом xml. поддерживается(правда, в неполной мере) opera, mozilla, amaya, safari. ie игнорирует этот формат.
или xul - специализированный язык разметки пользовательского интерфейса. тоже базуирется на xml, поддерживается пока тоько mozilla. любой плагин, выводящий собственное окно под firefox использует xul.
vml - базирующийся на xmlязык разметки графики(более стар, чем svg, но поддерживается ie)
---
видишь, сколько всего специализированного построено на основе универсального xml? т.е. деол не в языке разметки, а в том, как программа (не)обрабатывает нечто в этой разметке построенное

Добавлено через 5 минут и 36 секунд
кстати, в англоязычной версии статьи о xml на википедия красиво и подробно расписаны недостатки и достоинства xml. причем, большинство недостатков связаны как раз с обработкой и вопросами эффективности(сравнительно большой размер "технической информации" - сами теги с аттрибутами; обработка неиерархических отношений требует больших затрат - например, при поиске "соседнего" узла, а не "дочернего" и т.д.)

Добавлено через 6 минут и 44 секунды
есть в wiki и список языков разметки вообще. можешь посмотреть, какие ещё есть, были или только готовятся "выйти в люди"

да вы меня не поняли... 


skyboy, ты смотришь на это как веб разработчик...

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

(Это вообще моя не реализованная идея..): Почему разметку текста все представляют как теговую модель, возможно она и так идеальна, и ничего идеальнее нет, но не ужели никто не пробовал поломать стериотипы, вед html, xml это все равно движение в одну сторону.

Я имею ввиду то что ничего не нужно менять, ни браузеры, ни стандарты, и сделать на базе html, css, javascript, xml один мощный язык разметки со своим синтаксисом... Существовала бы какая нить программа-парсер, которая бы переводила этот синтаксис на html смешанный с javascript и css. Ведь если придумать такой язык, с одним синтаксисом, то жить станет намного легче...  

Вот наглядный пример несовершенства css и html:

есть элементы в html, у элемента может быть 1 бэкграунд... это ОГРАНИЧЕНИЕ, но его можно побороть вложенностью дивов, так зачем этот прием повторять несколько раз, когда можно придумать мощный язык разметки, который бы позволял задавать элементу несколько бэкграундов, а уж как это реализовать в html проблема программы-парсера... (назовем его web-компилятором)... 


Примерная схема такова:


Запись разметки на языке высокого уровня -> (Web - компилятор) -> Запись разметки на языке низкого уровня с использованием css и java

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

Добавлено через 4 минуты и 30 секунд
с таким же успехом можно было бы до сих пор усовершенствовать язык АССЕМБЛЕР... и все бы были рады как щас... 

хм, писал-писал, ссылки приводил, а оказалось - не так понял )))

такого я не утверждал. всегда есть преимущества, но и недостатки тоже всегда есть и будут. просто разные   

теперешняя ситуация - это как раз более абстрактный вариант.
вот, если брать аналогию с ассемблером: отдельно - ЯП высокого уровня, отдельно - запросы к БД на SQL, отдельно - интерфейс на XUL, а потом все переводится даже не в ассемблер, а команды процессора. 
так и с web-программированием: отдельно(по возможности) структура(html), отдельно - внешний вид(css + svg + xul), отдельно - реакции и логика(javascript), а браузер уже "компилирует" - собирает части воедино так, чтоб у конечного пользователя и надпись мигала, и по нажатию на кнопку что-то происходило ;) а ты предлагаешь, практически, скомпилировать сразу. практически, подобный язык "весь-в-себе" должен будет описывать алгоритм: от загрузки, через отрисовку и все реакции на действия пользователя. Такой себе web-ориентированный ассемблер. Не спорю, кроссбраузерность должна быть если не идеальной, то близкой, но трудозатраты на написание...  

Добавлено через 2 минуты и 14 секунд

хехе. вот в IE куча фильтров. И что? стремящиеся к кроссбраузеру, естественно, не используют. Да и работа от версии ИЕ к версии вполне может отличаться... и дело не в том, что в спецификацию не включено, а в поддержке браузером. а в FireFox, в противовес, есть возможность рисовать из-под javascript(canvas). и что? повсеместно используется? тоже нет 

Добавлено через 11 минут и 38 секунд

потому что. потому что человеку так привычно описывать разметку вне зависиммости: компьютерное представление или нет. потому что человек когда создает разметку, говорит: "а вот этот текст надо выделить жирным", "а вот эту картинку взять в рамочку", "а тут список без нумерации". Т.е. какие-то смысловые единицы обладают набором атрибутов.
Единственный ньюанс: древовидная структура xml не позволяет описывать графовидную структуру любого вида. Т.е. если у нас строка в таблице с серым фоном, а некий столбец - с текстом красного цвета, то описать однозначно понимаемую структуру(какая-то ячейка будет иметь двух предков - строку и столбец, а, значит, это уже не дерево) на xml не выйдет. потому в html изворот с тегом <col>(ЧТО, в принципе, не решает проблему: а если некоторые ячейки объединены в одну?). с другой стороны, можно было просто изменить саму спецификацию html, чтоб каждая ячейка указылвала номер строки и столбца, к которым принадлежит и стили которых наследует. но все равно - это вопрос поведения браузеров, все равно это остался бы старый добрый xml.
--------------------------------
кстати говоря, а какие собственно претензии к текущему положению вещей?

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

просто html, css, частенько javascript используется для посторения документа, т.е. для верстки... поэтому почему бы это все не объединить, ведь если подумать, то можно практически сделать все на этих технологиях... только нужно копаться и искать как это сделать... 

Я же предлагаю, один раз покапаться... и заложить это все в один язык разметки... Кроссбраузерности можно добиться... это не так сложно... просто нужно сухо придерживаться стандартов... 

Язык разметки выс. уровня (ЯРВУ   ), это вообщем то просто программа-парсер... которая всю запись переводит на html, css, javascript, придерживаясь стандартов... а уж браузер прочитает получившийся результат как он умеет...   

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

Добавлено через 5 минут и 40 секунд
допустим даже эфект тени вокруг картинки можно будет заложить в язык... он просто сам все нарисует... и положит в нужную папку... пропишет пути и т.д.

Это сообщение отредактировал(а) lukas - 29.5.2008, 21:04

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

версткой является только html.
css - это обобщенный механизм аттрибутов тегов(практически, цель - реализовать наследование аттрибутов, чего не было в "чистом" html). впрочем, есть расширения css(например, механизм сыы expressions), которые позволяют внедрить в css элементы логики.
javascript, как механизм логики, конечно может менять верстку, но при этом он не становится языком верстки. 
давай не будем сваливать все в кучу, ладно? мы все ещё говорим о языках разметки?   
кстати говоря, CSS не единственный 
язык описания стилей   просто опять же - вопрогс поддержки браузерами...

сам не знаю, но если верить Вики(смотри пункт "Lack of multiple backgrounds per element "), в черновике CSS 3 этот вопрос уже будет решаться

Добавлено через 2 минуты и 8 секунд

допустим, даже эффект тени вокруг картинки можно сделать:
а) предобработкой картинки(особенно просто сие будет, если браузер поддежривает чатичную прозрачность - к примеру 32-битный png) любым графическим редактором с соответствующим функционалом
б) подложенным под картинку слоем с соотвествующим бекграундом 

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

А вообще к чему-то подобному отчасти движется HTML 5 (aka WebApplications 1.0) - в основе DOM-структура (динамическая, разумеется), нативно умеющая выдавать нужный юзеру функционал (типа тех же дейтпикеров) и которую можно сериализовать в разметку разными способами - хоть в HTML, хоть в XML. Отдельные фичи оттуда уже работают в новых браузерах (новые элементы форм - в 9-й Опере, клиентское хранилище данных - в FF2+ и IE8...).


Уже решается, и даже работает в последних сборках WebKit-а. Для частного случая 2-х фонов существует такой трюк, который работает везде (даже в IE).


Если забить на IE5 (что давно пора), можно положить бэкграунд прямо на тег <img>, да добавить ему padding (чтоб тень просвечивала).

Да нет, по-моему товарищ рассуждает о другой стороне, о простоте вёрстке, т.е. о банальном визивиг, или а-ля fckeditor

т.е. рисуем в редакторе блоке, запихивает туда текст, выделяем строчку, тыкаем в кнопку "жирный шрифт" - текст становится жирный, вставляем картинку из папочки при странице, она появляется (ну и дальше вводим и другие украшательства), жмём кнопку компиляции и получем правильно сгенерированный html код

то бишь "сохранить как web-документ" в том же word'е, только "правильно", а не в том винегрето-состоянии

ну и соотетственно, чтобы были такие прибамбахи, чтобы щёлкаешь правой кнопкой по элементу, выбираешь в контекстном меню строчку "оформление" и тебе всплывает окошко со всеми возможными css-атрибутами для элемента, там выбрал (не строчку font-size, а "размер шрифта"), а оно потом само скомпилируется в css-стили. ну и т.д.

куча WYSIWYG-редакторов есть. далеко не все дают "винегрет"  вот только побоку - придется под каждым целевым браузером проверять и дорабатывать напильником. так смысл тогда? 

Вы немного меня не поняли... вы не понимаете основную идею.... я вообще не очень люблю WYSIWYG редакторы... я просто хочу предложить язык верстки более абстрактный которые уже имеются... т.е. он просто будет переводится на html и прописывать все стили... вставлять в нужных местах javascript например... и весь полученный результат html файл с стилями и javascript'om... 

ну как бы так сказать, если имеется всё равно написание кода вручную, то трудно представить себе что-то более простое, чем html

куда проще? и так, абзац обозначается одной буквой и двумя символами выделяющими командное слово <p>

lukas, я уже два раза спрашивал: какие преимущества ты хочешь получить? как выглядит уровень, более абстрактный, чем уровень xml? "draw~my~home~site()"?

Добавлено через 3 минуты и 40 секунд
lukas, может, тебя устроить framework на javascript, заточенный под твои нужды? типа, "draw_table(/*rows*/3,/*columns*/5);" или "setOnClick(XPath('html[0]>body[0]>input[3]'), myfunction)"

Если будет время сделаю что нить подобное, на словах всеравно трудно это объяснить... xml и html не идеален... с их стандартами... если же делать язык высокого уровня, то стандартов не будет для таких языков... а развиваться они будут намного быстрее чем языки со стандартами... 

Представьте себе, когда такие языки будут развиваться, в них будут добавляться новые конструкции... новые свойства, а html и xhtml будут застаивать из-за стандартов, которые нужно утвердить... и чтобы что-то добавить новое требуется несколько лет... 

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

P.S. Пишите свое мнение, я вообще хотел узнать чужое мнение на счет чего-то подобного... 

Это сообщение отредактировал(а) lukas - 31.5.2008, 16:12

я до тебя докричусь?! назови задачи, в которых проявляется "неидеальность"! ты приводил примеры с бекграундом: проблема решаетcя в CSS3 и доступно при помощи небольшого финта ушами в ранних версиях. что ещё?

убил. без объявленных стандартов и спецификаций ВСЕ реализации будут разными. это будет проблема кроссбраузерности "умножить на 911". не вижу  в этом ни хорошего, ни веселого.

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

Добавлено через 1 минуту и 29 секунд

не надо. если есть четкая мысль, как раз словами проще, чем кодом на несуществующем языке. 

skyboy, 

так вопервых... этот язык не будет обрабатываться браузером... он будет переводится в html со всеми прибамбасами... поэтому кроссбраузерность будет еще какая... это язык будет выполняться один раз, на компьютере разработчика...




Вот я и об этом...

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



тут же человек (как ты) говорит, так такое можно на асм сделать... зачем что то придумывать... на асм уйдет немного больше конструкций раз в 6сть.... но это можно сделать....

только сначала выделить память под переменную, затем к ней добавить 2, затем умножить на 6, затем отнять 7, и все это в отдельных операциях.... 


Это сообщение отредактировал(а) lukas - 31.5.2008, 16:34

зачем? на асемблере можно работать с регистрами. например, EAX.

а html у нас уж и кроссбраузерно обрабатывается? ты описываешь принцип работы генераторов html, в роли которых используются perl, php, python, asp, java etc. в чем тогда отличие? в том, что язык "свой"?
насчет примера на С++ и противопоставления ассемблера зело посмеялся. нет, тут другая ситуация: ты говоришь, что не хочешь писать "int v=((2 + 2) * 6) - 7", а хочешь делать "высокоуровнево", чтоб потом транслировалось в это самое "int v=((2 + 2) * 6) - 7". Причем, как ты себе представляешь "более абстрактный уровень" сложения и умножения и чем тебя не устраивает текущая форма, ты не уточняешь.
вот переход от процедурного к объектно-ориентированному, а потом - и к объектному -- это качественное изменение; переход от императивного к декларативному программированию - качественное изменение. Повышаеющее уровень абстракции. 
HTML и так декларативный, кроме того - довольно объектно-ориентированный(если можно применить такое определение в отношении языка разметки). 
Примеры сих утверждений:
а) "декларативный" - потому что мы не описываем алгоритм отрисовки таблицы, а указываем просто "тут у нас таблица 5 строк и 6 столбцов". декларативно? вполне.
б) объектно ориентированный - потому что каждый набор узлов обладает набором аттрибутов(а-ля поля-свойства) и обработчиков событий(предопределенный набор методов).  Т.е. инкапсуляция.  Вложенные элементы наследуют стили(свойства) и, с точки зрения программиста, наследуют методы-реакции(вообще-то, дело в "просачивании" событий, но "выглядит" так, будто вложенные и родительские элементы наследуют обработчики событий). Это наследование.    Два из трех китов - уже неплохо(остался полиморфизм; что это может быть в масштабах языка разметки - не представляю)
Возможно,  указанные параллели и некорректны, но раз уж начались аналосии с ассемблером и С++, то, думаю, можно сделать такой ход конем.

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

Цели такого языка:
 1. Уменьшить время затрачиваемое на верстку сайта
 2. Облегчить читабельность html текста... ну и т.п.

Задачи языка:

 1. Упростить некоторые приемы html и css (где используются например вложенные див и т.п.) до простых конструкций
 2. Объединить html и javascript (не все естественно, а то что нужно для верстки) со всем его DOM в одно целое
 3. Создание чистого html кода, где оптимизатор языка будет оптимизировать код html для всех браузеров, применяя естественно разные способы
 4. Естественно усовершенствовать конструкции, добавить новые, которые позволят писать намного меньше кода.
 5. Возможно добавить конструкции с элементами OOП, усовершенствовать то что есть в html с наследованием
 6. Добавить новые свойства css, которые позволят не задумываясь создавать более сложные вещи за меньшее время.

Следствия:

 1. В несколько раз более быстрое развитие такого языка.
 2. Легкость в использовании.


P.S. Для меня это не самый высокий уровень абстракции... вернее я предлагаю в каком то роде не повысить уровень абстракции, а создать язык который расширит возможности верстки и добавит новые возможности.

P.S.S. Нужно учитывать что всего этого добиться можно с помощью предварительно парсировки, т.е. выполняться этот язык будет 1 раз, у разработчика.

Это сообщение отредактировал(а) lukas - 31.5.2008, 17:44

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

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

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

К теме разговора, конечно, это мало относится,  но не удержался...
Что значит "менее строгий в отношении оформления подтип xml"?  Никаких менее строгих подтипов xml не существует.  
"Свежесть бывает только одна — первая, она же и последняя. " © М.Булгаков
Видимо SGML имелся ввиду,  а не XML.


Это сообщение отредактировал(а) check - 2.6.2008, 22:38

Меня тоже давно удивляет отсутствие альтернативы (x)html+css, но немного с другой стороны.

Эти технологии мне кажутся крайне неюзабельными для вёрстки, даже учитывая CSS level 3. Ну не предназначены они для расположения элементов на странице и толкового управления контентом. Заголовки да абзацы отформатировать - это на 5 реализовано, а общую структуру документа обозначить - это в хтмл/цсс сделано как небрежная заплатка.

Я бы с радостью поддержал инициативу по созданию не транслятора в хтмл, а нового XML-based языка размётки. Однако пока что такового не на горизонте не видно 

December, 
а почему именно xml... мне интересно вообще как, кто все это представляет... ну язык верстки высокого уровня...

XML - это древовидная структура... А древовидная структура - это правильно.

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

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

По моему даже эта функция будет революцией в верстке.

Плюс куча мелочей можно сделать: например - составная кнопка ролловер (та которая делается дивами-матрешками) в качестве единого элемента с параметрами картинок, автоматическим созданием жаваскрипта-ксс...

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

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

Блин, было бы время, сам бы сделал, честное слово   

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

круто. набок резиновую верстку под произвольное разрешение монитора ))

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

Да, вот это ключевые пункты, которых не хватает для _удобного_ языка размётки...

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

если я начну, то проект будет opensource...

чтобы реализовать все это нужно найти любые способы в html чтобы это для начала как нибудь реализовать...

Добавлено через 6 минут и 58 секунд
чесно говоря есть идея ... может что то уже в задумках... создать новый способ верстки в языке... сделать его предсказуемым и фундаментальным, гибким и понятным...

Это сообщение отредактировал(а) lukas - 4.6.2008, 16:42

Я чесно говоря представляю что-то вроде этого... думаю логически можно понять что это за код... и что может дать язык высокого уровня... 

А кстати, помоему в xhtml можно давать тегам свойства???

Это сообщение отредактировал(а) lukas - 4.6.2008, 18:33

да. называются "атрибутами". некоторые - предопределены(например, src у <img>), можно добавлять свои. правда, обработка "незнакомых" атрибутов зависит от браузера: одни включают такие атрибуты в DOM-модель, другие - нет

Собственно говоря на уровне упрощения хтмл у меня уже работает, решение в общем элементарно и думаю его многократно реализовывали (хотя вроде идея воткнуть его именно в этом ключе и пришла самостоятельно) ,так что революцией не является ни в коей мере..  
Реализовал в связке ХМЛ+ C#

напридумывал новых тегов, из которых + стандартный хтмл делается файл, потом при загрузке на страницу видоизменяются с помощью модуля обработки ХМЛ, в который вписан правила преобразования этих моих личных тегов... Ну там к примеру 

может выглядеть как

Т.е. оно и получится, что если стандартных шаблонов понаделать, то код будет выглядеть короче (но увеличится число стандартных элементов   )
правда ксс у меня без изменений (меня он и такой как есть устраивает пока), но если делать не так как я, а по идее с отдельным парсером, который парсит код один раз (мне лично это не было нужно), то можно типовые решения ксс автоматом вставлять в файлы ксс.

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