Pull to refresh

Comments 161

интересно, а ie кушает нормально то что вы предложили?
в 7ой не работает. что-то подсказывает, что и в более старших не будет.
Нет, я написал в каких браузерах это работает.
Если браузеры начнут поддерживать Javascript для XML-документов, проблема будет решена.
Они уже поддерживают, нужно пространство имён указывать.
Подскажите тогда как сделать? Я спросил на StackOverflow — никто не предложил решение.
<myhtml xmlns="http://www.w3.org/1999/xhtml">
Поправил, так лучше. Но проблемы все равно не решает: браузер по прежнему думает, что перед ним xhtml-документ и, соответственно, он определяет внешний вид и поведение элементов.

А в идеале нужно, чтобы к xml-документу можно было подключить js так же, как можно подключить css уже сейчас:

<?xml-stylesheet type=«text/css» href=«myStyleSheet.css»?>
<?xml-javascript type=«text/javascript» href=«script.css»?>
Если для документа сервер выдаёт в заголовках Conent-Type: application/xml, то IE (и Opera версия меньше толи 7.5, толи 8.5) выдают структуру XML-документа.
Чтобы страница работала, нужно выдавать Content-Type: text/html. + для всех браузеров нужно указывать DOCTYPE XHTML.

Правда, если выдавать text/html, то идея уже не будет работать: придётся использовать HTML-тэги вместо выдуманных myhtml, handlers и пр.

(я экспериментировал с XML-страницами, но собирать я их хотел на сервере в Aptana Jaxer. но я тогда зашёл в тупик и перестал что-либо делать. если интересно, вот тестовая страница: joos.nnov.ru. Она работает во всех браузерах (вроде бы =))
как минимум в хроме не пашет
В момент «наступления тупика разработки» хрома не было. Так что не считается )
сафари тоже не было? =)
UFO landed and left these words here
UFO landed and left these words here
xlst — это жеский ппц. Зачем какая-то технология посредник, когда можно обойтись без нее?
Идея как раз не в том, чтобы работать по стандарту. Идея в том, чтобы четко отделить Структуру от Представления и Поведения и перестать ждать, пока производители браузеров реализуют тот или иной стандарт. Язык разметки должен быть живым и меняющимся. А текущее положение дел таково, что html меняется медленнее чем какой-нибудь язык программирования типа php, Ruby или Python, в то время как именно во фронтэнде происходят самые значительные изменения.
UFO landed and left these words here
UFO landed and left these words here
UFO landed and left these words here
В даннос млучае XSLT — таки ппц и ни разу не нужен.
Потому что результатом трансформации будет — что? — правильно, документ на языке из подмножества XML. Тоесть — html 5 (6, 7,...) от чего мы и хотим отказаться…
XSLT — это теоретически хорошо, точно так же хорошо, как RDF и прочие идеи и технологии из semantic web. Однако XSLT очень сложен, его тяжело сопровождать, по нему мало специалистов и так далее. Короче, чисто «быт заел».
при правильном подходе он так же прост как и css. но да, на нём можно и прострелить себе ногу ;-)
UFO landed and left these words here
Никто не предлагает данный подход для описания шахматных партий. Подход предлагается для создания языков разметки, описывающих веб-страницы.
UFO landed and left these words here
Вот, прочитав последний абзац, я вас понял и почти поддерживаю. Возражение заключается в том, что XSLT не обязательно должен транслировать в xhtml. Он может транслировать, в принципе, во что угодно, в том числе и в язык, созданный по принципу DSRB.
xslt — интересная задумка, которая практически ничего не добилась. Пользуются единицы. Почему? Потому что с его ролью прекрасно справляются шаблоны в MVC-фреймворках. Возможно я неправильно выразился: использовать xslt — это жоский ппц в 90% случаев.
UFO landed and left these words here
Довольно разговоров. Реализуйте HTML5 на xslt. Если получится — потом будем говорить, чтот проще, понятнее и удобнее поддерживать.
Это можно сделать, только в отличие от приведенного в топике способа, преобразование xml в html (или другой формат) будет происходить на стороне сервере, а не браузера. Собственно xml — это как раз модель (можно попробовать повторить модель html5), html — представление, а xslt — контроллер, где можно и нужно подключать css и js.
А вы для начала подумайте о XSLT не только как о шаблонизаторе для веб-фронтенда. Это далеко не так.
Мы сейчас говорим именно о фронтэнде. Просто подумайте, во сколько раз усложнится задача прикручивания яваскрипта, если мы будем пользовать xslt.
Ну а еслиг оворить о фронтенде… Вы ничего нового не придумали. Для избыточной реализации стандарта поведения html-элементов, вы будете вынуждены повторить не малую часть движка браузера на JS. В определенных случаях это может быть оправдано. Но по опыту, куда чаще оправдываются решения позволяющие гибко и прозрачно реализовать имеющиеся стандарты. xslt — одно из таких. Во многом это имхо конечно же…
UFO landed and left these words here
Гм. Простите, вы воспринимаете js только в качестве инструмента dhtml?
UFO landed and left these words here
Вы просто не понимаете, что xslt — это непрямой инструмент. Он преобразует xml в html и, таким образом, опосредованно, определяет поведение. Javascript же в данном примере напрямую определяет поведение элементов без необходимости переводить их в html.
UFO landed and left these words here
Вы не поняли, все равно. Название топика — просто чтобы заинтересовать. Я придумал не альтернативу HTML5, а способ его реализовать до того, как производители браузеров это сделают.
UFO landed and left these words here
Вы не хотите видеть общей картины. Попробуйте посмотреть на это вот с какой точки зрения: js — это не эмуляция поведения ссылки, это инструкция браузеру, что ссылка должна вести себя так-то. Когда этой инструкции нет, браузер либо ничего не делает (в моем примере), либо применяет встроенную, дефолтную инструкцию к тэгу <a>
UFO landed and left these words here
Главное преимущество HTML5 (для меня, по крайней мере) — в том что он стандартизует теги. И они могут правильно обрабатываться не только браузерами. Этого преимущества ваше решение лишено: в вашем случае в каждом документе — своя, особая, жизнь и как её орбатабатывать чем-либо, кроме браузера — непонятно.

То, что вы предлагаете предлагалось как вариант лет уже 10 назад… но не прижилось. Хотя может просто время таких решений тогда не пришло: работало только в новейшем (тогда) MS IE 5.0 и больше нигде. Причём с изрядным количеством глюков…
Как я написал выше, язык разметки должен быть живым и коммьюнити должно иметь прямую и перманентную возможность вносить изменения. С описанным мной подходом никто не мешает вам использовать в своей работе какую-то конкретную версию языка. Но мне кажется неверным оправдывать этим нежелание следить за изменениями и привыкать к нововведениям. Это просто язык разметки, это же не китайские иероглифы.

Кроме того, в верстке основная проблема это как раз не структура документа, а css. А его как раз никто и не предлагает менять.
всё это делается ради мобильных браузеров
Как я написал выше, язык разметки должен быть живым и коммьюнити должно иметь прямую и перманентную возможность вносить изменения.
С тем же успехом можно заменить все ваши теги на классы и использовать ровно два элемента HTML: div и span. Ибо возможность «прямо и перманентно вносить изменения» приведёт к тому, что на разных сайтах все теги будут иметь разные названия. Как и чем это всё потом обрабатывать?
С описанным мной подходом никто не мешает вам использовать в своей работе какую-то конкретную версию языка.
Мешает. Пока ваш язык не понимает Google и Yandex — вы можете использовать все эти навороты только если вас не интересуют посетители…
Как я уже неоднократно писал в ответных комментариях тут, скорее всего новые языки разметки будут процентов на 80-90% основываться на элементах HTML4/XHTML, иначе их никто не будет использовать. Таки образом, решается проблема с разными названиями тэгов и с пониманием поисковиками сайтов. В посте описан инструмент, которым можно пользоваться как угодно: можно написать язык разметки, где все тэги будут непохожи на HTML, а можно расширить HTML набором новых тэгов и потом использовать это решение повсеместно. Более того, разумно предположить, что второй вариант гораздо вероятнее первого.
современная анархия вэба вынуждает поисковики игнорировать даже те крупицы семантики, что всё-таки есть в хтмл. какие тэги поисковики считают полезными и действительно хоть как-то учитывают в ранжировании?

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

<picture url="example_picture.png" width="300px" height="385px" style="background-image: url(example_picture.png); width: 300px; height: 385px;"/>
Какой в ней смысл?
Экспериментировал, забыл убрать атрибут styles.
Стоп, стоп. Это вы откуда взяли? У меня сейчас в коде только />
Чертов парсер:
<picture url=«example_picture.png» width=«300px» height=«385px»/>
Это Firebug показывает сгенерированный код, получившийся в результате выполнения javascript, который прописывает атрибут url в background-image.
Да, я уже так и подумал.
Здесь вопрос в том, где проводить грани между структурой, представлением и поведением. Валидация полей формы к чему относится? К структуре или поведению? С одной стороны, поле — это некая сущность, которая имеет тип и может быть отнесена к структуре. С другой стороны, проверка на соответствие этому типу — явное поведение.
Цель HTML5 — не охватить необъятное, а всего лишь уменьшить рутинное кодирование, переложить часть наиболее востребованных фич на «представление», сняв их с «поведения». Честно вам скажу, я уже запарился каждый раз прикручивать ту же валидацию полей, это напрягает, даже если не писать всё это заново, а использовать свои или чужие готовые модули. А ведь много достаточно простых сайтов, где JS кроме как для валидации и не используется — т.е. с HTML5 их можно будет делать без выполнения кода на стороне клиента. Ну и нормальные котейнеры для мультимедиа давно были нужны, потому что от этих простыней невалидного кода с трижды дублирующимися пармаетрами, которыми все вставляют флэш, уже воротит.

Естественно, какой-то уникальный функционал всегда будет добавляться к сайту с помощю JS, но мне кажется, что перенос на HTML большего количества функций принесет только пользу.
Объясните мне, чем описанный подход усложнит вам жизнь? Уже сейчас можно написать HTML5 таким образом с валидацией полей (и все это будет работать в IE причем). Как верстальщику, вам все равно, где она будет происходить — в каком-то написанном за вас js-файле или в жеско вшитом в браузер коде.
1) отключим скрипты и что получим?
www.w3.org/TR/WAI-WEBCONTENT/#tech-scripts
2) как будет у вас реализована поддержка таких элементов как video? напишете js декодер?
3) абстракция — это хорошо, но тогда каждый начнёт писать свою версию html и совместимости документов совсем не будет каждый будет вставлять ссылки как захочет, я считаю, что footer лучше, чем div class=«footer» потому что второе уже де факто стандарт и лишь немного варьируется. когда только разрабатывали html никто ведь до конца не представлял как будут выглядеть страницы через 10 лет
1. зачем отключать скрипты? Их не надо отключать. Не рассказывайте про безопасность. Если на Хабре скрипты отключить, много вы комментариев напишите?
2. Очень просто. JS-код вставляет в страницу флэш-плеер, например.
3. Стандарты тормозят развитие. Не оправдывайте стандартами свое нежелание принимать изменения. Свобода выбора языка разметки — это положительный момент, способствующий развитию всех языков. Также, как с дистрибутивами линукса практически.
то есть если я захочу сохранить документ и открыть его электронной книге с чернилами, то получу фигу?
почему флэш лучше вставлять через js?
стандарты не тормозят развитие, развитие тормозит MS, например, в SVG они не вмешивались — мы и имеет нормальную рекомендацию версии 1.1 и завершающуюся 1.2

я совсем не понял, что же вы предлагаете чего ещё нет? отображать дивы прописнными другим способом? ну это умеет css (a{display:block})
Сами по себе стандартны не тормозят развитие. Но их реализация в браузерах — тормозит. Стандарты должны реализоваться и корректироваться не производителями браузеров, а сообществом. Сейчас же стандарты разрабатываются какой-то удаленной группой людей и реализуются за закрытыми дверьми производителями браузеров в течение нескольких лет.
UFO landed and left these words here
есть такая история про пожар в чикаго
стандарты может быть развитие и тормозят но появились не просто так
При обещаемой оптимизации js-движка и кэшировании — в будущем все будет заебись.
UFO landed and left these words here
HTML5, для сравнения, сейчас вообще нигде не работает.
Что вас смутило? Отсутствие в списке IE, или то что автор указал не браузеры а движки?
а бедные поисковые боты будут каждый раз гадать где на странице находится контент; может в paragraph или para? или p?
а т.к. xml поддерживает юникод (т.е. можно и <параграф> написать), то и подумать страшно про автоматическую обработку веб страниц
Есть DTD, который поисковые машинки должны будут научиться читать, чтобы отличать блочные элементы от инлайновых и так далее. Это не так уж сложно.
проблема в том, что сайтов (о-очень) много, а если у каждого свой DTD, то это надо под каждый подстраиваться
Да с чего вы взяли, что у каждого будет свой DTD? Будет 2-3 самых популярных языка разметки. Остальные либо будут как-то подстраиваться под поисковики, используя понятные ему элементы, либо забиватьт на это.

Никто не предлагает завтра взять и отменить тэги, к которым все привыкли и написать полностью новый язык разметки. Понятно же, что претендующие на популярность новые языки, которые будут использовать предложенный подход, будут в большинстве использовать привычные элементы из HTML4/XHTML.
Если я правильно помню, то HTML это частный случай XML который в свою очередь частный случай SGML и в целом HTML5 является общепринятым DTD для XML.

Да?
UFO landed and left these words here
Перечитал. Согласен.

Но хотел я сказать что HTML это и есть тот самый популярный DTD и остальные будут либо как-то подстраиваться под поисковики либо забивать на это.
UFO landed and left these words here
dtd для этого слабо подходит. вот rdf+owl — совсем другое дело.

например, там можно сказать, что menu на нашей странице — это подмножество ul из языка html.
С той частью, где «браузер не должен учиться», не согласен. Я в этих делах дуб дубом, но текущие средства реализации верстки… Это плохо! Это так не должно! ))
я вот о чем подумал — написанные таким образом сайты сможет поддерживать (в плане изменения) только разработчик, создавший их. другому же человеку придется сперва очень серьезно париться, если сайт будет состоять не из 1 страницы. наверное поэтому как раз html5 будет лучше, чем предложенное вами решение
Читайте комментарий выше. Ни один разработчик в своем уме не будет изобретать собственный язык разметки для своего сайта без серьезной на то необходимости. Будет несколько популярных языков в большой степени использующих привычные всем элементы из HTML4/XHTML.
Идея очень и очень любопытная, я бы даже сказал, красивая.
Одновременно она очень противоречивая — возможность самому развивать язык разметки является очень и очень привлекательной, с другой стороны, можно найти много подводных проблем — например:
1. обучение. Хорошо, если ваш «диалект» написали вы сами, и знаете все в нем — но что вы будете делать, если к вам на работу придет 10 человек, и их тоже надо будет учить этому диалекту? А если сто человек?
2. Безопасность. Вы, наверное, заметили, что при наведении на ссылке статусная строка браузера не изменяется — это оттого, что у клиентского javascript урезана эта возможность. И урезана она была из-за того, что находились деятели, которые прятали статусную строку, обманывая пользователя на тот счет, где он сейчас находится и т.п. Я веду к тому, что если дать javascript возможность влиять на браузер в той же мере, что и html сейчас, то это может привести к огромному количеству проблем с безопасностью.

Но, взвешивая все за и против, могу сказать, что идея мне нравится. Она достойна того, чтобы ее развивать и продвигать в массы. Только представьте, что может сделать коммьюнити, если ему предоставить такую возможность ;)

Думаю, лучшей рекламой этого подхода было бы реализовать какую-то часть фич html5 (и несколько кастомных) чтобы показать: «Будущее здесь и сейчас наступает, участвуйте!»

Я бы с большим удовольствием поучаствовал.
Совершенно верно, я как раз и думал взять и реализовать html5, пока эти дрочеры будут там писать стандарты на бумажках ) Поучаствовать — это прекрасно, давайте держать связь.
UFO landed and left these words here
есть же у нас «мобильные» версии сайтов ;-)
UFO landed and left these words here
UFO landed and left these words here
вот автор и предлагает начать уже делать шаги, а не валяться по полу с улюлюканьем, и наивной верой в «семантический хтмл».
А, скажем, для людей с плохим зрением вы тоже будете отдельный стиль писать? или для текстовых или мобильных браузеров? Или в эпоху больших мониторов и хорошего соединения Вы уже забыли об этих пользователях?

Summary, alt, dl/dt, select — вообще убрать надо или все-таки какие-то стандарты оставить?
Уже придумали, как будете «объяснять» браузеру, который ничего не знает о стандартах, что textlink'и — это ссылка, которую можно показать в отдельном окошке списка ссылок?..

Возможно, хтмл5 — не идеальное решение, но ваш вариант… минимум — Очень не доработан.
Полностью поддерживаю! Теги video и audio, например, кому они нужны? Давным давно существует поддержка элемента embed, но никто им не пользуется! Почему? Да потому что уровень доступа ограничен. Ни youtube ни last.fm не станут использовать эти теги ведь у них уже сейчас есть мощный инструмент в виде flash!
Вот она суть, нужен просто напросто свой DTD
Скоро на 8ИЕ прикрутят вебкит и тогда я думаю станет совсем просто
только размеры документов возрастут в разы :( да и скорости обработки XML пока не особо впечатляют
Спасибо, snitko, за реализацию. Эта идея давно витает в воздухе. Давно известно, что с помощью css можно получить любое представление от любого тега, давно понятно, что теги как таковые вообще не должны нести никакой нагрузки, кроме семантической, смысловой. И тут такая внятная реализация.

Хотелось бы пожелать вам уделять больше внимания всему тому, что приготовлено для XML: XSL, XSLT, Xpath и тому подобным вещам. Особенно рекомендую больше внимания уделять умолчаниям, которых, по идее, не должно быть; для примера: свойство display должно быть указано для каждого тега без исключений.

Я краем сознания чувствую в памяти что-то, какой-то костыль, какой-то способ загружать в well formed xhtml такой же well formed — настоящий — xml со всеми его возможностями, но ничего более подробного память не возвращает. Штепсель-переходник между современными браузерами и XML со всеми его возможностями есть, вот только бы вспомнить…
Есть несколько вариантов:

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

2. Определить javascript и css события, поведение и внешний вид элементов. Сейчас можно запросто имитировать элементы формы. Да, это будет не нативно, но будет работать.
Еще две проблемы: семантика и обработка ошибок.

Без описания семантики XML никому не нужен. Ну, для этого есть DTD. Теоретически он снимает проблему, но ДТД для более-менее нормального языка, это немаленький такой файл. Если ДТД не встроен в браузер, каждому пользователю придется его качать и при первом посещении и в дальнейшем из-за протухания кэша. Врде так, на сегодняшний день?

А вот с ошибками вы уже ничего не сделаете. Один неправильный знак — и страница не отображается. При этом, в HTML5 работа с ошибками — одна из главных фич. Все потому, что без ошибок, код

Когда вы говорите, о 2-х или 3-х ДТД, и о широких возможностях для работы сообществ, вы описываете уже существующую ситуацию. Сообществ полно (начиная с w3c), языков — тоже (наприм., MathML), браузеры с ними как-то работают. Но вот примеров практического применения как-то маловато. Люди за HTML5 не от хорошей жизни взялись (еще один язык, от пары сообществ).

Или я пока не разобрался, или вы изобрели велосипед, извините. Какие конкретные проблемы пользователей сможет решить XML+CSS? И почему за годы существования, они их еще не решили?
А вот с ошибками вы уже ничего не сделаете. Один неправильный знак — и страница не отображается.
А вот это — как раз самое основное и главное преимущество XML.
При этом, в HTML5 работа с ошибками — одна из главных фич.
Если бы. Весь этот кошмар там появился не с целью облегчить жизнь сайтостроителям, а с целью формализовать всё то безобразие, которые браузеры вынуждены интерпретировать, чтобы пользователь увидел в Web'е хоть что-нибудь. Много вы видели сайтов, которые проходят валидацию? Вот отсюда и весь этот ужас в HTML5…
Вот об этом я недоговорил: «Все потому, что без ошибок, код… редко встречается.»
С какой стати люди и программы, делающие ошибки в коде годами, вдруг перестанут это делать? Откуда возьмутся методы «безошибочного кода»? Все вдруг станут сознательнымии?
Я не против кода без ошибок, но пока, судя по всему, ошибки неизбежны. Можно ждать когда код будет без ошибок, а можно сделать программы терпимые к ошибкам. Второе — пока что реалистичней.
С какой стати люди и программы, делающие ошибки в коде годами, вдруг перестанут это делать? Откуда возьмутся методы «безошибочного кода»? Все вдруг станут сознательнымии?
Всё просто: если код с ошибкой == неработающий сайт, то ошибка будет обнаружена и исправлена. Никуда разработчики не денутся. Им просто не заплатят если сайт не будет работать. А сейчас — никого не волнует сколько там проблем в вёрстке: запустилось на компьютере у заказчика — и слава богу.
Я не против кода без ошибок, но пока, судя по всему, ошибки неизбежны. Можно ждать когда код будет без ошибок, а можно сделать программы терпимые к ошибкам. Второе — пока что реалистичней.
Бред. Все виды ошибок вы, разумеется, не искорените, но многие — запросто. Много вы видели программ с синтаксическими ошибками на C или Java? Правильно: практически нисколько. А почему? А потому что если у вас в программе синтаксическая ошибка то вы её запустить не можете. Вот и с сайтами: если бы браузеры не показывали сайты с ошибочной вёрсткой — то таких сайтов бы просто не было.

Самая большая проблема современного Web'а — это толерантность браузеров к ошибкам!

Это — самая большая беда. Просто катастрофа. Все остальные проблемы — меркнут на её фоне. Joel хорошо на эту тему пишет: Counter-intuitively, Postel’s robustness principle (“be conservative in what you send, liberal in what you accept”) often leads to deployment problems.

Вся эта обработка ошибок, зафиксированная в HTML5 — это попытка смягчить проблему. Если браузеры будут допускать определённые виды ошибок, и не будут допускать никаких других, то, возможно, у нас ещё есть шанс. Не знаю — насколько удачной будет попытка, но то, что это именно попытка решить проблему (огромную, катастрофическую проблему!) излишней толерантности браузеров — очевидно всем кто хоть немного понимает степерь опасности.
Ошибки могут возникнуть независимо от воли разработчика. Например, если сервер «задумается» и не сможет до конца передать XML-файл, то страница не отобразится, даже если весь код правильны, но последний тег не пришел от сервера — страница все никак не догрузится. Думаете редкость?

>Много вы видели программ с синтаксическими ошибками на C или Java.
Дык, есть даже статистика, сколько в любой программе возникает ошибок в зависимости от количества кода. Практически все программы содержат ошибки, приводящие к неработоспособности на машине пользователя. Вот только веб-страница — не программа.

То что вы изложили — это радикальный взгляд. И он давно существует, но вот не приводит это ни к чему. При всей теоритеческой правильности, реально жить так никто не может. Даже те кто это исповедуют.
Конкретные проблемы можно начать решать уже сейчас. Для этого необязательно использовать xml. Обычный html или xhtml можно точно таким же способом расширить, добавив новые элементы. Например можно существенно упростить колоночную верстку, или добавить новые тэги из html5 с уже определенным в js поведением. При этом, браузер не будет ругаться, если кто-то забыл закрыть тэг.

И да: dtd, css и js файлы, имеющие отношение к DSRB можно хостить в публичном месте (например в гугле, как библиотеки jQuery). Таким образом мы их кэшируем и загружаем только один раз.
Я так и не понял какие именно проблемы так срочно нуждаются в решении?

XHTML и придумали чтобы HTML можно было расширять. И он от XML ничего не отличается, это одно и то же. Но практического применения технология не нашла. Почему? Вы думали над этим?

И да, все что вы описали — возможно. Для этого XML и придумали, но вот не нужно это пользователям (те которые «юзеры» и «чайники»). Увы! А вот HTML — нужен. Я бы и рад, чтобы было по другому, но вот не получается.
> Например можно существенно упростить колоночную верстку
Кто будет отвечать за реализацию сего: браузер или JS?
вообще-то css.
Добавляем стили для новых элементов, которые заранее работают во всех браузерах. Problem solved.
В смысле «добавляем»? Расширяем язык CSS или как? Еще, вы неоднозначно написали, кто «заранее работает»: стили или элементы?
Недопонял просто.
В документе:

<three-columns>
<one></one>
<two></two>
<three></three>
</three-columns>

В css:

three-columns {}
three-columns one {}
three-columns two {}
three-columns three {}

Ну и в js нужно будет генерить wrapper-ы и прочие технические элементы, которые нужны, чтобы верстка работала во всех браузерах.
Не вижу новизны, извините. Типичная «хакерская» верстка. Никаких проблем не рашает. Вы предлагаете микроскопом гвозди забивать.
Всё оттого, что вы слишком любите JS ;) Шутка!
UFO landed and left these words here
>Семантику вообще ничего не определяет, кроме конкретно оговоренных соглашений
Но эти соглашения как-то задокументированы? Как и где, по вашему?

>Браузеру DTD не нужен, задача браузера (в идеале) — вывести элементы на экран, выполнять указанные скрипты и обеспечивать специальное поведение для HTML, вроде ссылок, форм, или объектов.

Ну браузеры уже это делают. В чем новизна предлагаемого в статье подхода, если вам известно?
UFO landed and left these words here
Понятно. Спасибо! Мои сомнения подтверждаются :)
То есть если вот завтра вам скажут: вот мы тут написали расширение для HTML, которое позволяет писать на HTML5, нужно только подключить .js файл — откажетесь?
Напоминает «IE7». Не браузер, а JS-библиотеку, которая заставляля IE 6.0 делать то, что должен уметь «современный браузер». Все апплодировали, но самолет так и не взлетел (никто не пользовался).
Видимо, такова реализация.
Вот, например, prototype.js — тоже «улучшитель-расширитель», а смотри-ка — все пользуются.
UFO landed and left these words here
Так пишите, вам никто не запрещает юзать ваш любимый xslt. Вопрос не в том, можно его юзать или нельзя, а в том, тянет ли это на массовость.
UFO landed and left these words here
Пишу 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) Реализация на скрипте вместо нативной будет тормозить по определению.
1) При наличии смекалки еще как смогу.
2) При наличии быстрого движка — не будет.
1. Зачем описывать, если поведение уже есть. Надстроить же вполне реально.
2. Корректно говорить, что будет работать медленнее. А вот будет ли тормозить — другой вопрос. Если вы всё проспали, то сообщу: в последнее время идёт прямо таки гонка движков. И неспроста, я замечу.
UFO landed and left these words here
Нифига подобного. Я тебе приведу в пример развитие Ruby. У Ruby есть несколько реализаций: MRI, JRuby, Ruby 1.9, .NET Ruby, Rubinuis. И это нормально. Каждый сам выбирает, какую реализацию ему юзать. Так же как и с Линуксом: кто проиграл от разнообразия дистрибутивов? Наоборот, все выйграли, потому что практически каждый дистр помимо своих фич сделал какой-то контрибьюшн, который потом все позаимствовали. А w3c — это бюрократия и дрочерство )

То что я предлагаю — это реально работающий на сегодня способ. Сторонники консорциума могут сколько угодно рассуждать о стандартах и правильности, но мы знаем немало примеров, когда предложенные им стандарты просто медленно всеми забывались, будучи так никем и не реализованными. Так что извини, не убедил.
«бюрократия и дрочерство» правят миром, руби-армия — родинка на их теле. Стандарты(w3c, jcp...) нужны — без них никуда. это вам не dhh, который решил и нахуячил тупых методов к массиву в рельсе — это корпорации, каждая из которых строит свой бизнес и преследует свои интересы, скажите спасибо, что они хоть на это согласились.
так и запишем — не вкурил.
xbl — это очень вкусная технология. в принципе, её не сложно сэмулировать на яваскрипте, что я и хочу в скором времени замутить…
аргументируйте
Flex, ну а когда SVG будет везде — GWT.
я все жду, когда же наконец браузеры начнут поддерживать хотя бы часть w3c стандартов (которые в данное время не поддерживаются)
было бы здорово использовать в разработке такие вещи как xpath, xpointer, xlink, xquery, xforms
UFO landed and left these words here
Каждый браузер поддерживает тэг <embed> — от этого можно плясать.
UFO landed and left these words here
Это очень тонкий вопрос, нужно понимать, что тут может быть несколько стратегий. Я уверен, что вы их себе представляете. Решение в чистом виде не может работать в 100% случаев.
UFO landed and left these words here
Идея интересная, но по моему довольно утопичная. В данном случае методы решения задачи выбраны довольно однобоко — как разработчика которого не устраивают текущие возможности стандарта. Такой подход добавит больше хаоса, и все плюсы и возможности этого подхода не окупят проблем, которые он породит.
Одна из основных задача любого стандарта — это регулирование интересов различных сторон. Даже сейчас производители браузеров (которы вообщем то немного) не могут синхронно и полно реализовывать все уже утвержденные и четко описанные стандарты, что тут говорить если эти субстандарты будут реализовываться независимыми группами из коммьюнити, которые будут рождаться и умирать, также как и порожденные ими субстандарты.
> При этом вы можете добавить в документ нужный
> вам доктайп или написать свой собственный DTD.
>…
> В будущем, если идея приживется…

Идея не приживётся. Она просто не рабочая. И это диагноз!
IE при любом раскладе не будет отображать страницу как HTML, и особенно если указать DTD:
— он либо будет отображать структуру XML-документа;
— либо покажет только текст и проигнорирует все выдуманные вами тэги и, как следствие: CSS не будет работать вообще.
Во-первых никто не обязывает сейчас делать прямо xml. Первоначально можно расширять таким способом обычный xhtml. И это уже вот прямо щас работает ) Во-вторых, есть такие слухи, что IE собирается переходить на WebKit. Так что откинемся на спинку кресла…

А вот что точно не работает пока ни в одном браузере, так это HTML5.
> можно расширять таким способом обычный xhtml
Мне кажется, в этом случае теряется весь смысл статьи. Ведь тогда все «новые тэги» переименовать в DIV и присвоить каждому из них отдельный className

> есть такие слухи, что IE собирается переходить на WebKit
Идея будет считаться работоспособной не в момент перехода на WebKit, а в момент смерти IE6 и IE7 (а это будет ой как не скоро)

> И это уже вот прямо щас работает
А дайте ссылку, пожалуйста, на какую-нибудь страницу, где бы IE7 отобразил выдуманный тэг, используя ваши CSS-правила.
UFO landed and left these words here
/* Как же я забодался это повторять все любителям XML */

Нынешний интернет держится и развивается только благодаря поисковикам.
Кому нужен ваш сайт, если его нельзя проанализировать и включить в поисковый индекс?
Кто и как найдёт вашу информацию, которая не размечена по строгой договорённости имя которой (X)HTML?
ru.wikipedia.org/wiki/Dublin_Core — вот это строгая договорённость о семантике.

а язык, где «диалог» и «определение» записываются одними и теми же тэгами — это фигня на посном масле.

на тему индексирования: yandex.ru/yandsearch?text=«расследование+убийства+html»
Т.е. давайте сделаем вместо HTML… мм… ZTML и он точно будет лучше.
Зачем развивать язык, на котором написан интернет? Всё сломаем, сделаем по-другому.

Я так понимаю, TWWC (Tenshi World Wide Consortium) уже основан и работает над спецификацией? ;)
это философский вопрос. зачем что-то развивать, если можно просто фигачить?

Для меня HTML5 — это шаг вперёд.
Поэтому я не вижу в этом фигаченья, а только развитие.
как с помощью htm5 разметить, например, шахматную партию? никак? тогда реквестирую специальные тэги для этого дела в html6, который выйдет не раньше 2030 года. но я до этого счастливого момента, боюсь, не доживу…
«Никак» — это значит, что ты не умеешь использовать абстрактную разметку данных. В частности, об этом говорит давнишний разговор про DT/DD.
да-да, что угодно можно разметить с помощью div и span. но какой толк от такой разметки, если никто не может выудить из неё хоть грамм смысла?
Я говорил о чуть менее абстрактных элементах — о списках.
Мне кажется, что в примере с шахматами отлично можно заюзать два пересекающихся OL'а. Но это так — навскидку.

А если использовать стерильные элементы, то заговорить их можно заставить на втором уровне семантики — на уровне именования элементов.
ну и в чём принципиальная разница между div, ol и table в контексте шахматной партии? они несут какую-то полезную информацию? есть где-то в спецификации упоминание о том, что шахматные партии нужно размечать исключительно через OL? или каждый должен фигачить во что горазд? вот ты, допустим, разметил через OL, а я — через DL (в dt — имя фигуры, в dd — описание её перемещения).
Когда я говорил про шахматную доску, я имел в виду список букв и цифр. Хотя, во многом, это таблица — т.к. имеет ценность не только строк, но и столбцов.

Ок. Все фигачат кто во что горазд. Но программа вроде браузера, даже не понимающая CSS, выведет такую таблицу вполне адекватно, сохранив структуру.

А что у нас с XML'ем? Для браузера или поисковика — это просто массив текста. И ни к чему не прицепиться.
сферический браузер не понимающий css в вакууме? =)
вот и получается, что в выборе нужного элемента для вёртски ты руководствуешься не столько его семантикой, сколько его визуализацией по умолчанию, а это уже визуальная разметка.
Table Data — это всё-таки тэйбл дата. И как только я прохожу к решению, что это табличные данные, то я использую таблицы. Всё просто.

Я не против XML как основы для веба, я только не хочу, чтобы сотни тысяч авторов придумывали сотни тысяч пространств имён, которые будут видны в поисковиках как массивы текста.

Все крутые — да, хотят придумывать свои имена. Кому дело до новых и вполне абстрактных элементов из HTML5…
UFO landed and left these words here
UFO landed and left these words here
Я категорически за то, чтобы интегрировать в HTML фрагменты других XML-структур вроде:

— Canvas / SVG
— MathML
— ChessML, etc…

Вырывать с корнем весь опыт развития сети и делать сайт в абстрактном XML и неведомом пространстве имён — это болезненный фанатизм.
UFO landed and left these words here
кстати, на xslt можно решить задачу обхода шахматной доски конем :-)
[ Если браузеры начнут поддерживать Javascript для XML-документов ]

мозилла имнип уже

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

как создать файловый инпут средствами xml+css+js?
нет никакого смысла отказываться от хтмл, ибо он предоставляет кучу элементов с уже определённой семантикой, которые понимают баузеры. но, с помощью css+js можно реализовывать поддержку элементов, отсутствующих в html.

[ я покажу вам, собственно, страницу, сделанную описанным выше образом, работает в Mozilla, WebKit и Opera ]

d-o-b.ru работает даже в ие6. заауузаа \(^_^)/
Блестяще — работает даже в IE6!

А вот в Opera и Safari не работает. Точнее, работает как сферическая страничка в вакууме, с которой не уйти ни по каким ссылкам. Ах, ну да — работает в Firefox.

Давайте-ка, ребята, делать сайты, которые работают от случая к случаю.
о, спасибо, что напомнил, ща выкачу патч.
Only those users with full accounts are able to leave comments. Log in, please.