0,0
рейтинг
21 января 2009 в 14:22

Разработка → Семантика в HTML 5 перевод

Я собираюсь сделать смелый прогноз. Еще долго после вас и меня HTML будет вокруг. Не только в миллиардах архивных страниц нашей эры, а как живые дыхательные органы. Слишком много сил, энергии и инвестиций пошло на разработку web-инструментов, протоколов и платформ, что бы все это было легко брошено.

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

HTML 5, W3C недавно удвоило усилия по формированию нового поколения HTML, за прошедший год или около того набрал значительные темпы. Это огромны проект, который охватывает не только структуру HTML, но и разбор моделей, модели обработки ошибок, DOM, алгоритмы для извлечения ресурсов, медиа-котента, 2D графики, шаблоны данных, модели безопасности, модели загрузки страницы, хранение данных на стороне клиента и многое другое.

Так же существуют изменения в структуре, синтаксисе и семантике HTML, некоторые из них описал Lachlan Hunt в статье "Обзор HTML 5" (перевод на хабре).

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

BBC недавно объявила о том, что они будут снижать долю микроформата hCalendar в своей программе телепередач, в пользу доступности и удобства abbr design pattern. Это свидетельствует о том, что мы, вне всяких сомнений, вытолкнули семантические возможности HTML далеко за те пределы, которые когда-либо предназначались, и действительно это возможно для языка. Мы просто исчерпали элементы и атрибуты HTML, которые способны повысить семантику документа. Если мы будем и далее хитрить с существующими конструкциями HTML, то будет возникать все больше таких проблем. Потому что HTML страдает от фундаментального деффекта, как семантический язык разметки — его семантика фиксирована и не расширяема.

Это не просто теоретическая проблема. Сотни тысяч разработчиков используют class и id для создания более семантической разметки (они так же используют их в качестве «крючков» для CSS стилей, но это другой вопрос). Почти всегда эти разработчики используют специальные словари, значения которых они сами составляют, а не значения существующих схем. Это псевдосемантическая разметка — в лучшем случае.

Многие страницы по всему интернету используют микроформаты, что бы добавить более структурированной семантики, чем при помощи обнищавшего набора элементов и атрибутов HTML. В этом случае значения использованные для атрибута class согласованы со словарями, иногда взяты из других стандартов, такие как vCard, иногда из недавно созданных словарей, где нет жесткого существующего стандарта (как в случае с hReview).

Расширяемая семантика


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

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

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

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

Итак, как HTML 5 решит этот вопрос? HTML 5 вводит ряд новых элементов. Некоторые я назвал «структурные» — section, nav, aside, header и footer. Элемент dialog который по типу и содержанию схож с blockquote. Есть так же целый ряд элементов данных, как например meter, который представляет собой «скалярное измерение в пределах известного диапазона или дробное значение, например использование диска»; и элемент time{http://www.w3.org/html/wg/html5/#the-time}, который представляет собой дату и/или время.

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

Рассмотрим каждое препятствие

Обратная совместимость


Как современные броузеры обрабатывают эти новые элементы, такие как section? Хорошо, последние версии Safari, Opera, Mozilla и даже IE7 все делают на странице следующим образом.
<h1>Top Level Heading</h1>
<section>
  <h1>Second Level Heading</h1>
  <p>this is text in a section element</p>
  <section>
  <h1>Third Level Heading</h1>
  </section>
</section>


* This source code was highlighted with Source Code Highlighter.

В начале это выглядит прекрасно. Но когда мы пытаемся задать стили CSS, например, для элемента section, который выглядит следующим образом:

section {color: red}

… Большинству из упомянутых броузеров это удается, но IE7 (и тем более 6) нет.

Поэтому у нас есть проблема обратной совместимости с 75% броузеров, использующихся в настоящее время. Учитывая, период полураспад Internet Explorer, мы можем прогнозировать, что большинство пользователей будут использовать IE6 и IE7, даже через несколько лет.

Если HTML 5 вводит новые элементы, какова вероятность, что они будут использоваться подавляющим большинством разработчиков — учитывая то, что они не совместимы с большинством используемых броузеров?

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

Совместимость снизу вверх


Сначала мы поставим вопрос: «Зачем мы изобретать эти новые элементы?». Разумным ответом будет: «Потому что не хватает семантики в HTML, а добавление этих элементов мы увеличим семантику HTML, что не может быть плохим, или может?».

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

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

Остаюнся несколько вопросов о новых элементах. Откуда взяты названия новых элементов? Как было решено, что элемент навигации нужно называть «nav»? Зачем в навигации применяются термины page-level, site-level и meta-site-level?

Почему бы не принять существующий словарь, такой как DocBook? Его словарь структуры документа более богат, он был разработан путем публикаций экспертов, на протяжении многих лет. Это не является аргументом в пользу DocBook, а дело в том, что чрезвычайно важная задача подготовки механизма обеспечения семантикой HTML проходит путь, уделяя малое внимание практике в работе которая началась более 30 лет назад. (Оригинал работы по GML начался в начале 1970-х годов)

Некоторые идеи решения


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

Если добавление новых элементов не обсуждается, по крайней мере в этой дискуссии, атрибуты — другая логическая область HTML, сконцентрируемся на ней. В конце концов, мы на протяжении, почти, десяти лет использовали атрибуты class и id, как механизмы расширения семантики HTML. Многие разработчики уже знакомы с этим и чувствуют себя комфортно. Проект microformats показал, что существующих атрибутов не достаточно, для использования их как механизм расширения семантики HTML. Так что, если мы хотим использовать атрибуты для решения проблемы, мы должны ввести один или более новых атрибутов. Пред тем, как перейти к механики, того как это может работать, справедливо подвергнуть это предложение тем же требованиям, как и новые элементы в HTML 5. Самое главное во внедрении новых атрибутов — это будет ли обратная совместимость HTML. Если да, то обеспечивает ли это работоспособный механизм расширения семантики в HTML?

Давайте изобретем новый атрибут. Назовем его «structure», но название не важно. Мы можем использовать его так:

<div structure="header">

Давайте посмотрим, как наши броузеры это оценят.

Конечно, все наши броузеры обработают следующий элемент CSS.

div {color: red}

А как насчет этого:

div[structure] {font-weight: bold}

На самом деле, почти все броузеры, включая IE7, обработают стиль div с атрибутом structure, даже если нет такого атрибута. К сожалению, наше счастье изчезает, потому что IE6 нет. Но мы можем использовать этот атрибут в HTML и все существующие броузеры распознают его. Мы даже можем использовать стили CSS для нашего HTML, с использованием атрибута во всех современных броузерах. И если мы хотим обойти старые броузеры, мы можем добавить class, со значением стиля. В сравнении с HTML 5 решением, которое добавляет новые элементы, не работающие в Internet Explorer 6 или 7, мы видим, что это, безусловно, более обратно совместимое решение.

Расширяемость через атрибуты


Вместо новых элементов, HTML 5 должна принять ряд новых атрибутов. Каждый из этих атрибутов будет относиться к категории или типу семантики. Например, как я уже подробно изложил в другой статье, HTML включает в себя: структурную семантику, риторическую семантику, ролевую семантику (принятую из XHTML) и другие классы и категории семантики.

Эти новые атрибуты, могут быть использованы как атрибут class: для придания элементу семантики, описывать характер элемента или для метаданных элемента.

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

Например XHTML атрибут role работает следующим образом:

<ul role="navigation sitemap">
  <li href="downloads">Downloads</li>
  <li href="docs">Documentation</li>
  <li href="news">News</li>
</ul>


* This source code was highlighted with Source Code Highlighter.

Значение атрибута role является разделенное пространство списка из слов определенного стандартным словарем или заданным словарем.

Почему бы не принять атрибут role, как есть? Ведь существуют другие виды семантики, для которых определение роли не применимо. Например:

<p rhetoric="irony">He’s a fantastic person.</p>

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

Вот еще один пример. Все более очевидно, что в HTML не хватает представления машино-читаемого значения понятным для человека, например даты. Это лежит в основе проблемы BBC с микроформатом hCalendar, о ней мы говорили ранее. Хотя May Day next year действительно не имеет смысла, зато по аналогии May Day next year будет.

Опять же, когда мы используем конкретный термин «equivalent» в качестве атрибута или какой либо другой для обозначения такого рода семантики, это не является проблемой. Важно отметить, что это не так просто, как использование атрибута class или role, где в один элемент помещается целый набор элементов семантики информации. Для, должным образом, расширяемого решения, которое обеспечит обратную совместимость и достаточную гибкость, стоит исследовать в этом направлении.

Я назвал этот раздел «Некоторые идеи решения», поскольку значительный объем работы необходимо сделать, для того, что бы создать действительно работоспособное решение. Открытые вопросы включают в себя следующее.

  • сколько различных семантических атрибутов должно быть. Будут ли эти категории расширяемыми, если да, то каким образом?
  • Каким образом определять словарь?
  • Мы просто изобретаем термины, которые мы хотим, почти тем же образом, как и разработчикки использовали значение class, или возможные значения должны быть определены стандартизированной спецификацией?
  • Если у нас есть конфликт, между двумя словарями, например двум идентичным терминам дают определения два различных словаря, как это решить?
  • Нужно ли пространство имен или же существует другой механизм?


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

Надеюсь понятно, что просто внесение новых элементов в HTML не является решением проблемы расширения семантики в HTML.

Давайте не спешить с легким решением — с изменением «климата» все это обременит наших внуков проблемой, как и сейчас. По крайней, мере давайте оставим им максимально хороший HTML, на сколько возможно.
Перевод: John Allsopp
Константин Жандов @kostos
карма
66,3
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (79)

  • +6
    Как-то туго читается. Хотя в целом весьма интересно. Спасибо.
    • 0
      К сожалению, не очень силен в английском, поэтому не смог перевести более «литературным» языком, в противном случаем мог потерять авторские мысли.
      • +8
        >… период полураспада Internet Explorer…

        Гениально! :))))
        • 0
          Ага, мне тоже понравилось, несколько раз перепроверил, пока переводил, действительно полураспада :)
          • 0
            Вот уж нечасто встретишь удачный перевод шутки автора в технической статье. Спасибо! :-)
      • 0
        Опечаток много. Местами прямо глаза режет. Но в целом хорошо. Спасибо.
  • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      ↓ — вам
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          стрелочка вниз=) Нижний комментарий был адресован вам
          • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    На мой взгляд, HTML 5 больше напоминает очередное улучшение парового двигателя, когда рядом уже вовсю работает бензиновый или электрический.

    Если я правильно понял автора статьи, и если придерживаться ваших терминов, туда пытаются добавить функции бензинового и электрического, с возможностью расширения до… ммм ядерного например :)
    • НЛО прилетело и опубликовало эту надпись здесь
      • +6
        Минуснул. Вы своими апплетами и кастомными кнопками делаете уродливыми мои интернеты.
        • НЛО прилетело и опубликовало эту надпись здесь
          • +11
            Понимаете, HTML и HTTP проектируется с учетом того, что эти технологии будут использованы на абсолютно разном железе. Поэтому одна из основных задач w3c — это не придумать в новом стандарте как можно больше новых «рюшечек», которые бы дали креативным ребятам простор для творчества, а придумать гибкую систему, которая бы позволяла пользоваться www из консоли, из графического браузера, со смартфона со слабым процом, с гпс-навигатора, со стиральной машинки, через колонки (для слепых людей) наконец.

            Далее. P2P — это хорошо, но далеко не всегда, и зачем вы его приплели к HTML, я понятия не имею. Как вы собираетесь сделать P2P решение «на базе HTML»? Хотя, кажется, я понял, что вы имеете ввиду. Вы хотите, чтобы HTML передавался посредством какого-нибудь P2P-протокола. С этим нет никаких проблем, уже есть децентрализованые сети с шифроваными каналами. Названия не помню, но гугль вам в помощь.

            Третее, самое важное. Флэш, ява, эктивх, сильверлайт и прочая байда нужна КРАЙНЕ редко. Крайне! Редко! Я ебал в рот интерактив, звуки, мигающие кнопачки, летающие облачка и прочую дрянь. На данный момент флеш чаще всего нужен для аудио и видео плееров, но HTML5 обещает исправить ситуацию (в нем будут специальные теги, по которым браузер будет вставлять нативный контрол). Я молюсь своим богам, чтобы когда-нибудь вся эта проприетарная закрытая хрень исчезла вовсе.

            Четвертое. По поводу «изменить интерфейс». Я считаю мудаками всех тех дизайнеров, которым не нравятся «стандарнтые» скроллбары, кнопки, чекбоксы, селекты и пр. Если я вижу, что мои любимые убунтовские кнопки заменяют на плод чьего-то больного воображения, я сатанею. Если у дизайнера рождается «оригинальное творческое решение», и он хочет заменить мой любимый серенький скролбарчик, к которому я привык, на котором работает колесо мыши, хоткеи и пр. на оранжево-зеленую дрянь, которая и на скроллбар вовсе непохожа, то я шлю ему лучи профессиональной импотенции. А если он подключает для этого своего скроллбара флеш-плеер, то таких лучей летит в 2 раза больше.

            Дизайнер, блядь, должен работать в рамках технологии. В HTML не зря так «тяжело изменить интерфейс». Кнопки (и другие элементы интерфейса) должны рисоваться такими же, как и в нативном ГУИ операционки. Это повышает юзабилити и об этом пишут все известные юзабилити-специалисты со времен Якоба Нильсена. Если дизайнер заявляет, что серенькая кнопка рушит цветовой баланс его макета, то это значит, что херовый макет получился. Правильный дизайнер, рисуя макет, помнит, что кнопка (чекбокс, текстовое поле) у клиента может быть отрисована как угодно, и он не в праве менять ее внешний вид.

            Конечно, существуют исключения. В основном это контролы, для которых в HTML не предусмотрено нативных реализации (автокомплит, календарь и пр.), но HTML5 и эту проблему решает.

            У меня все.
            • 0
              эмоционально, но со многим согласен
            • НЛО прилетело и опубликовало эту надпись здесь
            • 0
              Все правильно.
              Но вы забываете, что здесь обсуждается именно семантика HTML.
      • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          Ничего-ничего. Так всегда было и будет.

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

          Не сцать! :)
          • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Жаль только что производители броузеров не особо то и смотрят на стандарты.
    Все равно какой нибудь IE прикрутит у себя «Фичу» описанную и работающую только в нем, а другие повторят ее но используя свои тэги. и пошло поехало.

    Как по мне то должен действовать международный закон который бы регулировал эти вопросы.
    • +4
      Ага, с уголовной ответственностью. =)
      • –3
        А если школьник написал свой браузер на паскале, его тоже?
        думаю чтобы всем было хорошо, всех браузерописателей пересадить на 1 открытый движок рендеринга и обработки кода. тогда все новое будет появляться во всех браузерах одновременно и не нужно тестить в 10ти браузерах, а чтобы не застаивалось у пользователя — во всех браузерах авто-апдейт по тихому, например как в ff
        • +3
          По законам РФ — уголовную ответственность человек несет с 14 лет:
          1. 0-14 лет — сажаем родителей, что б не подпускали своих детей к написанию броузеров
          2. 14-18 — в колонию
          3. 18-и более — на зону или расстрел

          :)
        • –2
          Плохой вариант, так как открытый движок может быть хуже или мделенней (или просток ак ФФ есть больше памяти). Лучше уж хороший закрытый.
      • +1
        Можно и с уголовной.

        Для начала можно просто высылать разработчикам полосатую робу, для предупреждения.
      • 0
        с уголовной — не с уголовной, а с административной вполне уже начинают работать подобные законы ;)
    • 0
      Как по мне то должен действовать международный закон который бы регулировал эти вопросы.

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

      Но, как вы написали «фича», это же не нарушает стандарты, это «бонус» от создателей броузера, не нужно это копировать. А вот кривость обработки кода — это вопрос открытый
    • 0
      Давно всем разработчикам надо собраться и написать письмо в общество по защите прав человека.
      Сколько можно терпеть издевательства от производителей браузеров? Точнее производителя. Браузера.
  • 0
    возможно, я чего-то не понял… но я не увидел никаких преимуществ у предложенного автором статьи подхода по сравнению с XML :/
  • НЛО прилетело и опубликовало эту надпись здесь
    • НЛО прилетело и опубликовало эту надпись здесь
    • 0
      Обоснуйте.
      • НЛО прилетело и опубликовало эту надпись здесь
    • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    «Зачем мы изобретать эти новые элементы?»
    «добавление этих элементов мы увеличим семантику HTML».

    Выглядит, как перевод Stylus'ом или Promt'ом.
  • –1
    автор переведённого поста не в теме

    во-первых, он не знает про то, что ие начинает нормально стилить любые элементы после яваскриптового вызова, например, document.createElement('section')

    во-вторых, он не знает, для чего делается html 5: в первую очередь для того, чтобы огромная масса существующих сайтов разной степени кривости обрабатывалась браузерами одинаково
    • –1
      Да уж куда ему, сирому.
  • +3
    Немного не по теме, но все же. Если будет возможность я буду использовать XHTML 2, вместо HTML 5. Меня, например, пугают элементы nav, footer и т.п. и ввергает в ступор возможность не закрывать теги (насколько я помню, в HTML 5 это разрашено). Если же говорит о большей привлекательности для поисковых роботов, то я не вижу особого преимущества тега nav перед sitemap (отдельной xml-картой сайта).
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        А вы не думали, что не на каждом клиенте можно гонять ява-машину?
        • НЛО прилетело и опубликовало эту надпись здесь
      • НЛО прилетело и опубликовало эту надпись здесь
        • НЛО прилетело и опубликовало эту надпись здесь
          • 0
            открой для себя сорцы мозиллы =)
            • НЛО прилетело и опубликовало эту надпись здесь
              • 0
                как рендерер коннектится к xml…
                • НЛО прилетело и опубликовало эту надпись здесь
                  • 0
                    там xpcom, но и байткод можно прикрутить аналогично.
                    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        > В то же время, смотрим, куда движется CSS. В каждой версии добавляют визуальные возможности, сейчас речь идёт о тенях и разноцветных рамках.

        Нас всех спасет декларативное программирование.

        Тот же CSS можно заменить реактивным программированием, а потом добавить сахару, чтобы дизайнерам поменьше думать.
        • НЛО прилетело и опубликовало эту надпись здесь
    • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    role уже используется в htmlayout. там же есть такие свойства селекторов css, о поддержке которых остальными браузерами остается лишь мечтать.
  • +2
    html — стандарт для представления информации. И именно в сторону качественного улучшения механизмов представления движется HTML 5. Некоторым (в том числе автору статьи) иногда кажется, что это движение слишком мягкое, осторожное, медленное… не революционное, наконец. Но только им не хватает чего-то, чтобы понять, что этот как раз и вызвано наличием немалого опыта (HTML <= 4.1, XHTML), заботой о совместимостях любого уровня и направления, просто на порядки другой глубиной понимания проблемы — не ограниченной высплывшей откуда-то семантикой. Вам кажется, что никаких других целей, кроме расширяемости семантики HTML 5 не преследует? Сочувствую.

    А вот расширяемый (и в первую очередь с т.з. семантики) формат данных есть и с успехом используется теми, кому это в самом деле необходимо. И имя ему, как ни странно, XML. Для связи второго с первым есть, как минимум, XSLT.

    Извините, если где резковато, но статья и многие ваши комментарии при её обсуждении сформировали у меня именно такой эмоциональный фон для комментария.
    • 0
      Вам кажется, что вы умнее и опытнее автора статьи? Тогда почему я не видел ваших статей на A List Apart?
      • +2
        все умные и опытные люди обязаны что-нибудь написать для этого сайта на буржуйском языке?
        • +1
          Нет, но это для меня показатель уровня автора.
          К сожалению Джон не может, в силу языкового барьера, вам ответить. Прежде чем выступать с комментариями, прочитайте ответ автора в обсуждении статьи: www.alistapart.com/comments/semanticsinhtml5?page=7#65
          Было бы, конечно, неплохо перевести это и прикрепить к самой статье, но я плохой переводчик.
          • 0
            не, показатель уровня автора в том, что он нигде не указал, что это перевод…
            • +4
              • –2
                так и знал, что где-то в тексте есть приписка мелким шрифтом, чтобы никто не заметил…
                • 0
                  Это не приписка и не в тексте.

                  Зачем писать в тексте, что это статья того то, от туда то. При написании поста есть специальные поля.
                  • –2
                    так и представляю себе: юзер в приступе сомнений водит мышью по всем контролам на странице в поисках заветного тайтла «автор оригинала»…

                    • 0
                      Кому надо, найдут, вернее они и так знают, а кому пох… ну тут не о чем разговаривать.
                      • –1
                        я кажется начинаю понимать, почему такие аффтары как ты предпочитают публиковать свои переводы на хабре… можно кому угодно дать ссылку на свою ленту и пришедшие на неё читатели будут уверены, что все эти умные слова написаны тобой, а не каким-то дятькой из буржуиндии.

                        а кому надо… (а кому надо _искать_?) — того всегда можно ткнуть носом в последнюю страницу книги, где мелким шрифтом написано имя реального автора, а надпись «автор оригинала» проявляется только при поднесении бумаги к огню…

                        • 0
                          Знаешь, ты же увидел что этот пост написал я? Так вот, прям перед моим ником, на той же «последней странице», написано имя автора, неправда ли странно?
                          • 0
                            перейдя с этой страницы kostos.habrahabr.ru/blog/ никто не будет искать твой ник в конце страницы.
      • –2
        >Вам кажется, что вы умнее и опытнее автора статьи?
        >Тогда почему я не видел ваших статей на A List Apart?
        Простите, обсуждать статьи авторов A List Apart нельзя вообще или только на хабре?
        Я что-то пропустил?
  • 0
    кстати, расследование убийства хтмл скоро подойдёт к концу ;-) d-o-b.ru/?article:kill.html
  • 0
    мне кажется к тому времени когда html 5 будет использоваться повсеместно и в полную силу ie6 уже отомрет, так что нету смысла брать его в расчет…
  • +1
    проблема html5 — это проблема IE6 :)

    проблема развития интернета, форматов, возможностей дизайна, безопасности пользователей — проблема IE6.

    я бы на месте людей, заинтересованных во введении новых единых форматов, вел активную пропаганду отказа от IE6. а лучше — вообще от IE.
    • 0
      Хотел бы отметить, что дедушка ie6 родился очень давно, а стандарт HTML5 еще не родился. То что есть — это только рабочий проект.
      • 0
        :)
        дедушка IE6, родившийся в 2001 году (кажется, может, чуть ранее), и сейчас, сцуко, как Ленин, — живее всех живых.
        а у w3c затянувшаяся беременность html5 :)
        • 0
          Ну примерно. И дедушка зажился, а затянувшиеся роды чреваты паталогией.
  • 0
    в html5, для каждого сайта должна быть своя либа тегов и атрибутов (по необходимости), в которой бы указывалось браузеру, как обрабатывать неизвестные ему теги/атрибуты — мне кажется решается проблема статьи…

    некоторые теги конечно стоит объявить стандартными, но постоянного гоняться за новым не получится, вот эта либа будет играть роль таких стандартов. Более ужившиеся, заносить в какую-то базу, где можно будет их постоянно черпать :) как делает виста/вин7 сейчас

    а вообще вода в ступе, это всё уже обсуждалось… разложение ИЕ6 ускорилось заметно!
    • 0
      а вообще вода в ступе, это всё уже обсуждалось… разложение ИЕ6 ускорилось заметно!

      К сожалению ие7 не многим лучше 6-го :(
  • 0
    с abbr действительно глупость получилась.
    но что мешает нам использоват другой элемент, например var или вообще span?
    спека не запрещает, а что operator не понимает hcalendar без abbr — так это проблемы hcalendar, т.к. по спеке обязан.
    парсер понимает замечательно.

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