Выхлоп: HTML должен быть…
…основанным на логике. Да, это первое и самое главное. В принципе, это главное предназначение было описано еще в SGML.
Принцип логики нарушил ещё Папа вэба — Тим Бернерс-Ли, который в своём первом драфте накидал кучу визуальных тэгов. Shame on you, Tim! Хорошо хоть, исправляешься. Я неожиданно удивился изменениям в XHTML 2.0:
- Элемент <blockcode>, которого всем так не хватает, на замену тупой конструкции <pre><code> … </code></pre>
- Элемент <l>. Для обработки строк, незаменимая вещь. Опять же избавляемся от мусорного <br />
- Элемент <separator> взамен <hr />. Человечное и логичное название.
- Ну про <section> уже все успели написать и раскритиковать, но я поддерживаю это нововведение. Мне, например, не удобно постоянно следить за уровнем заголовков. Я бы предпочёл автоматизировать этот процесс наподобие нумерованных списков.
- Очень не хватало группировки терминов и значений. Именно из-за отсутствия такой возможности в статье о позиционировании картинок в галерее приходилось в качестве группирующего элемента использовать сам элемент <dl>, что было не логично и неудобно для восприятия.
- <nl> — это, насколько я понимаю в замен устаревшему <menu>. Насчёт обязательного присутствия элемента <label> я не согласен. Почему у меня не может быть навигации без заголовка? Тем более получается конфликт с одноимённым элементом в формах.
- Супер-пупер вещь — href в любых элементах! Сколько мучений с тем, что в тэг <a> не допустимо засовывать блочные тэги!
- Логичный атрибут edit вместо элементов <ins>, <del>, с дополнительными значениями. Похоже на свойства файла.
- Почти отказ от элемента <img>. Атрибуты src, usemap, ismap, shape, coords можно добавить для любого элемента, содержимое которого заменится на картинку переданную в src. Причём в src может быть не только картинка, но и любое другое содержимое, любой mime‑контент. Но чтобы это корректно работало, нужно указать тип содержимого в srctype. <img> в свою очередь стал парным тэгом, а содержимое его выступает в качестве альтернативного текста.
- <handler> вместо <script>. Зачем? Неужели <handle> семантически точнее, чем <script>? Опять же предлагается прямо в нём писать javascript. Да ещё и модуль XML событий добавили! А как же «Васька — отдельно, сосиски — отдельно»?
- Атрибут media во всех элементах. Т. е. можно сразу определить в элементе для какого девайса его показывать. Удобно когда нужно сделать страницу корректно отображаемую на мобильнике или печатаемую на принтере. Например, для мобильных браузеров не поддерживающие CSS это очень кстати. Хотя, к тому времени, когда XHTML 2.0 станет общеиспользуемым, у нас не останется таких мобильников.
- Элемент meta превратился в парный тэг. Логично. Информации много, её надо куда-то девать. В content всё не умещается.
- Нагородили огород с <link>. Народ cite толком не использует, а они ещё хотят писать дополнительные элементы <link> и <meta> для указания источника, языка, автора…
- Указание внешнего источника стилей расширено xml-ным способом, через элемент <?xml-stylesheet?>
- Нет объяснения, зачем к id добавили ещё xml:id. Видимо по той же причине что и xml:lang. Да, но зачем вообще явно указывать namespace?
- Отличнейший атрибут role. Любым приложениям, а так же поисковикам, можно будет рассказывать о предназначении того или иного элемента.
Сырой документ. Много недописанного, в том числе XForms. Но в целом «верной дорогой идёте, товарищи!» Но идти вы так будете очень долго.
Что мы имеем сейчас?
Самые непопулярные браузеры имеют самые быстрые темпы развития и поддержку новых технологий. Хочу обратить ваше внимание на тот факт, что браузеры Opera, Firefox и Safari поддерживают несуществующие тэги. Любой вами придуманный тэг (в HTML, а не в XML) является по‑умолчанию строчным, но его внешний вид можно настроить с помощью CSS как угодно.
IE6, который является самым долгоиграющим браузером на рынке и самым устаревшим и глючным и IE7 не далеко ушедшим от его старшего собрата не поддерживают такие фривольности. Вернее поддерживают, но только через пространства имён.
Каким я вижу HTML?
XML + CSS. Разработчик не должен ограничиваться тем количеством элементов, что допускает спецификация. Он должен иметь возможность использовать любое название элемента. А любой элемент, в свою очередь может быть описан с помощью CSS.
Любые специфические элементы (элементы форм, внедряемые объекты, мета‑информация) нужно переводить в атрибуты и иметь возможность задавать их любым элементам.
Единственное, что можно допустить, это разделение невидимого контента, предназначенного для браузера (head), от отображаемого пользователю контента (body).
Убрать возможность добавлять скрипты и стили непосредственно в HTML‑документ. Только выносные.
Проблемы
Я не говорю о такой глобальной проблеме, как убеждение производителей браузеров в использовании такого метода. И так понятно, что их прошибить сложно. У них бизнес-план расписан на несколько лет вперёд.
Есть ещё одна — браузеры не поддерживающие CSS не имея чёткого представления о том, как должен отображаться тот или иной придуманный разработчиком элемент, отобразит всё содержимое всех элементов в виде сплошного одноразмерного текста без какого-либо форматирования.
Выхода два:
- оставить совместимость с существующим HTML;
- стандартизировать понятие «браузер», как программу отображающую содержимое размеченное HTML‑тэгами и стилизованное CSS‑описанием. Любые нестандартные проявления встречать свистом и недовольным улюлюканьем.
Второй вариант предпочтительней.
Жду гневные комментарии, господа верстальщики-гуру!
]]>Ezga Jups]]>Недочитал. Потомушта – несогласен.
»Чем тебе неугадил? нормальному прогеру – чем короче тем лучше.
]]>Ezga Jups]]>*тег hr
»]]>Fenrir]]>Комментарии на “Каким я вижу HTML?”:
1. От верстальщика. Убрать все inline-скрипты и стили значит непомерно раздуть подключаемые файлы. А каждый лишний запрос – лишний тормоз. Плюс если _всю_ динамику навешивать по onload, этот самый момент загрузки будет ознаменовываться нехилым ступором браузера. Да и для немалой части таких “вынесенных” стилей и скриптов их придется генерировать на лету. В сравнении с текущей ситуацией, когда CSS/JS/IMG месяцами лежат в кеше…
2. От программиста. Разброд и шатание всегда хуже, чем четко заданные правила. Если есть элемент input, четко описанный, то его можно генерировать по шаблону. А если инпутом может быть произвольный элемент… То все шаблоны идут лесом, и в каждом конкретном случае нужно его выводить “руками”.
3. От другого программиста. Парсить произвольный код сложнее. Особенно, если тебе из всей страницы нужна только пара элементов. Причем только их значение. А в ситуации “сам себе режиссер” это значение может быть еще и трудновытаскиваемым. Откуда известно, какие теги можно безболезненно выкинуть, чьи и какие атрибуты имеют значение?
Комментарий на описание XHTML 2.0:
Кто бы объяснил?..
»1. Сколько не читаю, упорно не доходит смысл тега l (для обработки строк). Равно как и наезды на br. Лично меня он нервирует только в ипостаси “другого программиста”
2. К href отношение неоднозначное. Хотя в сочетании с role при достаточном наборе ролей – сгодится.
3. Пляски вокруг img и атрибутов src/srctype – было бы решение, а задача найдется. С другой стороны, есть же object или как его там. Вроде как раз для этой цели.
4. Возня с handler неясна. С одной стороны, зачем там вложенность? С другой – почему он опять парный при указании src? С третьей – а где аналог noscript?
]]>Curly Brace]]>Меня мучает вопрос, что в конце концов останется от HTML5 и XHTML2? Не вижу смысла “to stick” к одной из технологий пока не будет ясности по поводу стандартизации.
Я кстати за объединение двух языков в один. Например в (x)sgml 2.0
»]]>Артём Курапов]]>Насчёт будующего в виде XML+CSS я согласен, но тогда DTD не нужен, а взамен нужен набор каких-то функциональных основ для правильного отображения тех или иных тэгов. Будь то потоковое видео, 3D и тп. А они связаны с программированием и сложными вычислениями, получается что надо их либо описывать в скриптах (js/flash actionscript/vbscript), либо писать плагины к браузерам, либо придумывать новый стандарт для мультимедийных особенностей объектов.
»]]>Sam]]>Вроде как можно уже попробовать нагородить что угодно:
»http://meiert.com/en/blog/2008.....se-html-5/
]]>Никита]]>Ezga Jups, а что в нём хорошего? 7 лишних пикселей оступа, что выдаёт IE? Семантически понятное название? Horizontal rule (горизонтальная линейка) vs. Separator (разделитель).
Fenrir,
> 1. От верстальщика…
учитесь оптимизировать свой код.
> 2. От программиста.
на xml за его гибкость никто не наезжал, просто взяли и создали формальные описания (RDF, RSS, MathML, XHTML, SVG). Почему тоже самое не сделать с HTML?
> 3. От другого программиста.
Разве программист не может контактировать с верстальщиком при работе над проектом?
> 1. Сколько не читаю, упорно не доходит смысл тега l (для обработки строк).
Элемент <l> можно использовать очень гибко, от обработки строк, до организации списков (при учёте использования CSS3). А что означает <br />? Тупо перевод на новую строку? И какой в этом смысл?
> 3. Пляски вокруг img и атрибутов src/srctype – было бы решение, а задача найдется. С другой стороны, есть же object или как его там. Вроде как раз для этой цели.
object слишком громоздкий. А так, идёт приближение к xml-формату. Вставляем объект в любой элемент.
> 4. Возня с handler неясна. С одной стороны, зачем там вложенность? С другой – почему он опять парный при указании src? С третьей – а где аналог noscript?
Если handler не срабатывает, то показывается текст находящийся внутри — вот вам и noscript.
Артём Курапов,
функциональные основы отображения уже существуют во всех известных браузерах и MIME стандарт существует. В чём проблема? Или я не так понял?
Sam,
»да, но толком это не всеми браузерами поддерживается. Opera 9 продвинулась в HTML 5 больше всех. А FF3 и Opera 9 — в XHTML 2.0
]]>pepelsbey]]>> Каким я вижу HTML?
> XML + CSS
Ага. Значит кто-то напишет , кто-то , а кто-то … а Google в ответ на такое скажем «Мээ… ребята, вы чего? Как же мне теперь вытаскивать из страниц самые важные заголовки?»
Сегодняшний веб развился во многом благодаря поисковикам, поэтому чистый XML его просто прикончит. А вот XML с общими пространствами имён, определяющими роли элементов, поможет всем нам договориться, а поисковикам искать. Только, постойте… у нас же есть XML с пространством имён! Он называется XHTML
А в целом — вполне здравый «выхлоп», не в пример предыдущей, пардон, истерике.
»]]>pepelsbey]]>WP слопал уголки. Попробую вот так: «кто-то напишет <heading>, кто-то <zagolovok>, а кто-то <h1>»
»]]>Никита]]>pepelsbey, согласен. В таком случае нужно, чтобы стандарты диктовал не консорциум, а непосредственно поисковые системы. Эти стандарты должны быть как расширение, но не запрещать использование каких-либо других тэгов.
Пространства имён конечно хорошо, но только не всегда удобно. Много мусора с этими <myns:header> и в CSS обращение некрасивое: myns\:header.
Мне лично всего лишь нужно, чтоб IE как и дургие браузеры стал поддерживать произвольные тэги в xhtml. И я заткнусь.
»]]>Sam]]>Да, было бы неплохо… хотя сервисам, которые это дело будут разбирать придётся несладко…
»]]>Никита]]>Sam, каким сервисам?
»]]>Sam]]>К примеру, поисковикам. Это ж придётся усложнять и без того сложные алгоритмы ранжирования, борьбы с нечестными SEO-чернокнижниками и т.д.
»]]>Никита]]>Sam, я же только что про поисковики написал. )) Если они будут диктовать свои стандарты их соблюдать, а остальное пускать на самотёк, то это им не повредит. Они будут индексировать только тот контент, который размечен по их правилам.
»]]>Sam]]>Повредит. Как минимум 50% «веб-мастеров» неквалифицированы.
»]]>Никита]]>Разве сейчас ситуация лучше?
»]]>Sam]]>Лучше. По крайней мере можно из каши хитрыми методами выделить нужное.
»]]>mixaM]]>> Если они будут диктовать свои стандарты их соблюдать, а остальное пускать на самотёк, то это
> им не повредит. Они будут индексировать только тот контент, который размечен по их
> правилам.
Ещё как повредит. Забываешь одну простую вещь – контент превыше всего. Пользователю пофиг какими тегами размечен тот или иной контент, ему главное чтобы поисковик его нашел.
»]]>Никита]]>mixaM, основной контент они будут размечать по правилам поисковиков, а всё вспомогательное — как хотят.
»]]>3AHO3A]]>…Каким я вижу HTML?
XML + CSS …..
В корне не согласен…. как верстальщику мне ето может показаться манной небесной, но как програмисту ето будет тихий ужос…. можно будет смело забыть про шаблоны (особенно если над проектом работает несколько человек, и особенно если работа ведется удаленно), а если предется пропарсить какую-либо чужую страничку, или еще лучше весь сайт, то можно смело забить и на без того недолгий сон…
Соглашусь разве что с етим: “Мне лично всего лишь нужно, чтоб IE как и дургие браузеры стал поддерживать произвольные тэги в xhtml. И я заткнусь.” (c)
Ну и на сладкое выдержка с ресурса http://www.w3schools.com:
The Difference Between XML and HTML
XML is not a replacement for HTML.
XML and HTML were designed with different goals:
XML was designed to transport and store data, with focus on what data is.
HTML was designed to display data, with focus on how data looks.
HTML is about displaying information, while XML is about carrying information.
Ну и пока писал етот комент подумалось: а какже будет оформлять коменты на блогах где допускается ввод тэгов….
»]]>Никита]]>3AHO3A,
> можно будет смело забыть про шаблоны (особенно если над проектом работает несколько человек, и особенно если работа ведется удаленно)
если работа ведётся согласованно, то ничего не случится. Интересно, если ты используешь в вёрстке классы, то программист тоже будет ругаться? Всего-то делов — классы заменить на тэги. Причём парсинг тэгов легче чем парсинг тегов + атрибутов.
Чужие странички парсить нельзя без согласия, поэтому махайтесь. А если владелец сайта предоставляет возможность получения контента, то он выводит его, например в RSS. Только в мною предложенном случае RSS можно писать напрямую в странице, а не отдельно. Опять же микроформаты могут писаться тэгами, а не классами.
«Therefore – by combining HTML and XML, and their strengths, we got a markup language that is useful now and in the future – XHTML» из http://w3schools.com/xhtml/xhtml_why.asp
Вот ещё чуть-чуть в сторону xml продвинуться и будет отлично.
> а какже будет оформлять коменты на блогах где допускается ввод тэгов….
»RTE
]]>3AHO3A]]>> «Therefore – by combining HTML and XML, and their strengths, we got a markup language that is useful now and in the future – XHTML»
… но ето уже XHTML а не XML + CSS
> если работа ведётся согласованно, то ничего не случится….
угу
хорошее слово – если 
»]]>Zigzag]]>Не согласен с тем, что нужен XML. Просто XML приведет к хаосу, который мы видели во времена Browser wars. Вот ты говоришь о преимуществах XHTML2, а ратовал в прошлом посте за тэги из HTML5. По мне так упрощение гипертекстовой разметки гораздо лучше. Пусть все внешние объекты вставляются через object, а не через кучу других тэгов, а тип объекта путь определяется через mime type. Единственное, что я не до конца понимаю в XHTML2, так это section. Мне удобнее всетаки через h1-h5 выделять их.
»]]>Никита]]>Zigzag, зачем тогда создан формат RSS? Если всё и так хорошо? Почему бы не делать стандарты разметки для отображения на основе XML, как это сделано с RSS? Те же микроформаты, только тэгами, а не атрибутами.
Я говорю о преимуществах XHTML2 перед HTML5.
»]]>Рейтинг самых лучших тем]]>первое место в рейтинге…
http://seleckis.lv/journal/res.....hen-byit...
»]]>Seleckis.lv :: журнал Никиты Селецкого » » Всемирная HTML 5 истерия]]>[...] Всемирная HTML 5 истерия Я не знаю, об этом просто сейчас модно писать или народ действительно в восторге? На самом деле, я бы с удовольствием, присоединился к толпе ликующих, если бы событие произошло год назад, именно тогда я написал статью «HTML должен быть…». [...]
»