Comments 28
Честно сказать не понял как он мне облегчит жизнь.
Ну если расположение блоков верстается при помощи div, то лично меня напрягает (чисто по скорости) писать
<div class="ClassName">...</div>, мне быстрее написать .ClassName{...}
а работать в редакторе со снипетсами не судьба?
Не понял что вы имеете ввиду, поясните, пожалуйста.
http://macromates.com/screencasts
2006-10-16: Text Transformations (in HTML) — 13.3 MB
Various useful key equivalents and text transformations for HTML, amongst others how to obfuscate email addresses in your web page.
2006-10-16: Text Transformations (in HTML) — 13.3 MB
Various useful key equivalents and text transformations for HTML, amongst others how to obfuscate email addresses in your web page.
То есть надо учить XOWML, чтобы писать на XHTML, который мы уже все, в принципе знаем?
В таком случае лучше уж ASCIIDoc.
В таком случае лучше уж ASCIIDoc.
Нет, если вы знаете XHTML и CSS, то учить XOWML вообще не нужно, достаточно посмотреть на примеры и всё.
Просто конструкция
<tag attr="value">...</tag>
в XOWML записывается как
%tag attr="value"{...}
Атрибуты class и id особые:
<tag class="Value">...</tag>
<tag id="value">...</tag>
в XOWML записывается как
%tag.Value{...}
%tag#value{...}
И ещё одна приятная особенность, — название тега div можно опускать, т.е.
%div.Value{...}
эквивалентно
.Value{...}
Т.е. это просто другая нотация XHTML (в этом её ключевое отличие от ASCIIDoc), причем писать в XOWML намного быстрее, чем в виде обычного XHTML, а результат одинаков.
Просто конструкция
<tag attr="value">...</tag>
в XOWML записывается как
%tag attr="value"{...}
Атрибуты class и id особые:
<tag class="Value">...</tag>
<tag id="value">...</tag>
в XOWML записывается как
%tag.Value{...}
%tag#value{...}
И ещё одна приятная особенность, — название тега div можно опускать, т.е.
%div.Value{...}
эквивалентно
.Value{...}
Т.е. это просто другая нотация XHTML (в этом её ключевое отличие от ASCIIDoc), причем писать в XOWML намного быстрее, чем в виде обычного XHTML, а результат одинаков.
а как перечислить несколько классов?
<div class="class-a class-b">test</div>
<div class="class-a class-b">test</div>
Не самая лучшая идея.
А не для этих ли целей в текстовых редакторах есть Bundles и прочие хоткеи? Разве это не тоже самое? Только там каждый может настроить этот язык под себя. ИМХО это гораздо гибче чем использовать кому то в голову пришедший синаксис.
Нет, это немного другое. Всё таки мне как верстальщику намного понятнее видеть перед глазами код XOWML, чем XHTML.
http://mihazimin.habrahabr.ru/blog/24383…
Синтаксис XHTML содержит большую избыточность. Этого не отрицают в W3C, они и сами разрабатывают human-readable нотации для XML-based языков.
http://mihazimin.habrahabr.ru/blog/24383…
Синтаксис XHTML содержит большую избыточность. Этого не отрицают в W3C, они и сами разрабатывают human-readable нотации для XML-based языков.
Вообщето XOWML что-то здорово смахивает на HAML, но только если HAML действительно может облегчить жизнь верстальщику вследствие его простого и понятного систакса, то XOWML больше напоминает какую-то кривую поделку.
Да,да я ждал этот вопрос. Кстати, если вы заметили, то я в тегах к этой записи указал HAML. В принципе XOWML и возник как ответ на HAML.
Что мне не нравится в HAML, так это его очень большая зависимость от отступов.
Да, в языке Питон отступы как элемент синтаксиса использованы с умом, сошлашусь, отчасти, что и YAML хорош (хотя имхо JSON лучше).
Но вот рассмотрим такой пример, - есть у нас один HAML файл и второй;
а мы хотим все дерево тегов из первого файла вставить в определенное место файла второго, но тогда придется подправлять у этого первого файла отступы во всех строках, что, по-моему, не очень хорошо.
С XOWML таких проблем не будет.
Насчет кривой поделки всё таки не соглашусь. При продумывании синтаксиса были учтены многие существующие языки и их особенности.
Верстальщику ничего не надо учить, чтобы начать верстать на XOWML (достаточно знать XHTML и CSS). Количество строчек в XOWML файле будет всегда совпадать с количеством строк в HTML файле, поэтому, допустим, отлаживать скрипты будет удобно (номера строчек сбиваться не будут).
Ещё из вкусностей то, что невалидность в текстовых редакторах будет достаточно легко светить.
А создать ПО для перевода XOWML в XHTML тоже будет достаточно легко (это требование тоже учитывалось при дизайне языка). Может даже десятком регэкспов всё обойдется (продумать надо).
Что мне не нравится в HAML, так это его очень большая зависимость от отступов.
Да, в языке Питон отступы как элемент синтаксиса использованы с умом, сошлашусь, отчасти, что и YAML хорош (хотя имхо JSON лучше).
Но вот рассмотрим такой пример, - есть у нас один HAML файл и второй;
а мы хотим все дерево тегов из первого файла вставить в определенное место файла второго, но тогда придется подправлять у этого первого файла отступы во всех строках, что, по-моему, не очень хорошо.
С XOWML таких проблем не будет.
Насчет кривой поделки всё таки не соглашусь. При продумывании синтаксиса были учтены многие существующие языки и их особенности.
Верстальщику ничего не надо учить, чтобы начать верстать на XOWML (достаточно знать XHTML и CSS). Количество строчек в XOWML файле будет всегда совпадать с количеством строк в HTML файле, поэтому, допустим, отлаживать скрипты будет удобно (номера строчек сбиваться не будут).
Ещё из вкусностей то, что невалидность в текстовых редакторах будет достаточно легко светить.
А создать ПО для перевода XOWML в XHTML тоже будет достаточно легко (это требование тоже учитывалось при дизайне языка). Может даже десятком регэкспов всё обойдется (продумать надо).
а мы хотим все дерево тегов из первого файла вставить в определенное место файла второго, но тогда придется подправлять у этого первого файла отступы во всех строках, что, по-моему, не очень хорошо
А это может и редактор сделать..
Насчет кривой поделки всё таки не соглашусь.
Тоже. Понравилась нотация, стройная.
Спасибо. Первый позитивный комментарий.
К тому же в HAML сегодня есть очень большая проблема, решение которой (если это решение создатели создадут) будет навряд ли красиво смотреться синтаксически:
Дело в том, что в HAML невозможно записать, допустим, просто картинку в слой:
<div><img src="..." /></div>
В HAML можно сделать лишь так:
<div>
<img src="..." />
</div>
Что будет интерпретировано большинством браузеров как тег div, а в нём по порядку:
1. TextNode (" ")
2. ElementNode (img)
3. TextNode (" ")
А это может реально отразиться на вёрстке, т.к. браузеры, при некоторых обстоятельствах, отрисуют эти TextNode, т.е. пробелы.
И это очень большая проблема, которая стоит на пути "индустриального" применения HAML в более-менее крупных,серьёзных проектах.
Поэтому, думаю, что HAML хорош, конечно, но XOWML (как его приемник), возможно уже сейчас, лучше, т.к. по крайней мере позволяет писать любой XHTML код, а не набитый иногда категоричекси-ненужными текстнодами.
Дело в том, что в HAML невозможно записать, допустим, просто картинку в слой:
<div><img src="..." /></div>
В HAML можно сделать лишь так:
<div>
<img src="..." />
</div>
Что будет интерпретировано большинством браузеров как тег div, а в нём по порядку:
1. TextNode (" ")
2. ElementNode (img)
3. TextNode (" ")
А это может реально отразиться на вёрстке, т.к. браузеры, при некоторых обстоятельствах, отрисуют эти TextNode, т.е. пробелы.
И это очень большая проблема, которая стоит на пути "индустриального" применения HAML в более-менее крупных,серьёзных проектах.
Поэтому, думаю, что HAML хорош, конечно, но XOWML (как его приемник), возможно уже сейчас, лучше, т.к. по крайней мере позволяет писать любой XHTML код, а не набитый иногда категоричекси-ненужными текстнодами.
UFO just landed and posted this here
Кстати, насчет HAML (если интересно). Всё таки у него есть проблемы:
http://mihazimin.habrahabr.ru/blog/24383…
http://mihazimin.habrahabr.ru/blog/24383…
А почему сразу язык? Почему не просто горячие клавиши?
Потому что и сам Тим Бернерс Ли (создатель HTML и вообще мега чел) говорит, что XML не является удобным для чтения его людьми. XML был придуман для удобства ПО. (И эти надежды он оправдал).
Для языка RDF вот например есть несколько нотаций. RDF/XML — для обмена данными между машинами и человеко-читаемый (human-readable) язык N3.
Я и не ставил целью при создании этого языка заменить XHTML. Нет, я его люблю. Но, всё таки дерево тегов (тем более когда большинство из них являются div) можно представлять и в более удобной форме.
И помоему, нам эту более удобную форму найти удалось.
Для языка RDF вот например есть несколько нотаций. RDF/XML — для обмена данными между машинами и человеко-читаемый (human-readable) язык N3.
Я и не ставил целью при создании этого языка заменить XHTML. Нет, я его люблю. Но, всё таки дерево тегов (тем более когда большинство из них являются div) можно представлять и в более удобной форме.
И помоему, нам эту более удобную форму найти удалось.
По-моему, ваш язык на вид ужастен (по-моему, конечно... объяснять лень, объясните лучше почему он выглядит лучше XML), а исключительно для ПО удобнее использовать байткод. Дело как раз в том что байткод плохо читается людьми.
Что касается быстрого набора (у вас там жирным написано "быстро и эффективно _писать_ валидный XHTML код"), то возьмем тег image.
Вы набираете:
.Image{%img src="images/elephant.jpg" width="240" height="181"{}
Итого: 65 нажатий.
Я в VIM'е:
Далее
images/elephant.jpg{LEFT} width="240" height="181" = 49 нажатий
Итого: 54 нажатия.
Что касается валидности, то для ее проверки не нужен отельный язык.
Вы не запутались в том, чего хотели?
Что касается быстрого набора (у вас там жирным написано "быстро и эффективно _писать_ валидный XHTML код"), то возьмем тег image.
Вы набираете:
.Image{%img src="images/elephant.jpg" width="240" height="181"{}
Итого: 65 нажатий.
Я в VIM'е:
Далее
images/elephant.jpg{LEFT} width="240" height="181" = 49 нажатий
Итого: 54 нажатия.
Что касается валидности, то для ее проверки не нужен отельный язык.
Вы не запутались в том, чего хотели?
Вы не запутались в том, чего хотели?
Нет. И ваши комментарии сделают эту идею ещё лучше, потому что, банально, - в споре рождается истина.
Итак, насчет VIM. Всё таки в вашем примере генерируется код
<img src="images/elephant.jpg" width="240" height="181" />
а в мое:
.Image{%img src="images/elephant.jpg" width="240" height="181"{}}
генерит
<div class="Image"><img src="images/elephant.jpg" width="240" height="181" /></div>
т.е. Image в примере это произвольное название класса, в принципе, не связано с тегом img. Поэтому надо пересчитывать :)
Верстальщики в ужасе закричали: «А-а-а-а! Еще один ML учить! Нет, лучше я буду писать валидный XHTML!». Честно не понял зачем хорошему верстальщику этот jQuery для XHTML. Библиотеки хороши, но не в языках же разметки.
Для меня привычнее [X]HTML, переучиваться будет проблемотично.
Sign up to leave a comment.
XOWML, который преобразуется в XHTML