зачем? на асемблере можно работать с регистрами. например, 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#

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

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

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

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