Пользователь
5,6
рейтинг
29 января 2015 в 15:38

Разработка → Идеи для HTML6 или HTML.next перевод

image

Идея HTML6, несмотря на то, что спецификация HTML5 по плану должна была быть полностью внедрена и достичь максимальной совместимости к 2014-му, сейчас стали появляться мысли насчет того, как может выглядеть следующее поколение этой спецификации — HTML.next, как её обычно называют в консорциуме W3C.

Новые семантические элементы


<dеcompress>


Этот элемент был предложен для интеграции файлов из ZIP-архива (формат ZIP как основной, однако другие тоже возможны) прямо в веб-страницу. Преимущества такого подхода: доступ браузера к файлам из ZIP, снижение требований к пропускной способности (что особенно важно для мобильных платформ).

Пример использования:

<decompress href="http://example.com/mobile/familyreunion.zip">
<a href="familyreunion.zip/html/activities.html">Деятельность нашего семейного воссоединения</a>
<img src="">

Семантика для описания заголовков и авторов


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

[title: Похвала тени id:praise by:junichiro]
— книга, написанная [author: Дзюнъитиро Танидзаки id:junichiro]
пояснение … и т.д.
 


<lоcation>


Этот элемент (по аналогии с <time />) используется для описания географической информации. Для него предлагается использовать атрибуты: lat, long, altitude:

<location lat=27.9 long=-71.3 altitude=-100>Бермудский треугольник</location>

<tеaser>


Элемент предназначен для обёртывания блока с контентом, имеющего ссылку на полный блок. Такие структуры мы может видеть где угодно: в результатах поиска на первой странице блога, в блоке с резюме с медиаресурсами (или без) и так далее. В общем, это должен быть секционный элемент, который может быть вложен в другие секционные элементы, такие как страница навигации:

<nav>
  <teaser>
    <header>
      <h1><a href="http://www.example.com/myFirstPost.html">My First Post</a></h1>
    </header>
    <p>Это моя первая статья на странице и это реально круто!</p>
    <footer>
      <time>Три дня тому назад</time>
      <div><a href="http://www.example.com/myFirstPost.html">http://www.example.com/myFirstPost.html</a></div>
    </footer>
  </teaser>
  <teaser>
    <header>
      <h1><a href="http://www.example.com/mySecondPost.html">Моя вторая статья</a></h1>
    </header>
    <p>Эта статья на сверхподходящем поле и поэтому она круче, чем первая статья.</p>
    <footer>
      <time>Один день тому назад</time>
      <div>
        <a href="http://www.example.com/mySecondPost.html">http://www.example.com/mySecondPost.html</a>
      </div>
    </footer>
   </teaser>
</nav>


Преимущества использования этого элемента:

  • описание общих часто используемых структур в HTML
  • позволяет оптимизировать поисковые движки и компоненты управления, потому что различные виджеты могут использовать эту структуру по-разному
  • не требуется задействовать механизм нумерации списков
  • может использоваться в сочетании якорей для создания быстрого оглавления
  • По-видимому, должен хорошо работать в HTML5-блогах, если взять его за основу для разделения контента

Формы


Автоматическое написание с заглавных букв в полях формы


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

<form>
  Название: <input name="name" autocapitalize="words">
  Состояние: <input name="state" autocapitalize="characters">
</form>

autocapitalize=«words» означает, что каждое новое слово будет начинаться с заглавной буквы. Это полезно для полей, где нужно указывать имена, напр. «John Doe». autocapitalize=«characters» означает, что каждый символ будет записан с заглавной буквы. Это полезно для аббревиатур.

Улучшенные формы аутентификаций


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

Локализация управления


У разработчиков часто отсутствует возможность в локализации элементов управления, таких как: кнопка «Обзор» в полях />, элементы управления для настройки даты/времени

Мультимедиа


Адаптивные изображения


HTML6 предоставляет возможность загружать изображения разного размера, в зависимости от текущих настроек на стороне клиента.

Адаптивная потоковая передача данных


Существует ряд различных адаптивных форматов потоковой передачи данных (а также несколько различных прогрессивных медиаформатов для загрузки контента). Во многих случаях нам нужно передать потоковым методом какой-то защищенный контент. На данный момент мультимедийные элементы в HTML5 поддерживают выбор различных форматов. Тем не менее существуют определённые аспекты адаптивной потоковой передачи данных и защищённого контента, который требует улучшения возможностей HTML для широкого использования. В частности они включают:

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

  • дополнительный медиаэлемент для событий (напр. изменение скорости потока)

  • дополнительный медиаэлемент для свойств (напр. текущая скорость, которая связана с другими показателями QoS)


Баланс звука


Регулировка звукового баланса (правый/левый канал) для дорожек со стереозвуком при помощи HTML5.

Улучшение воспроизведения видео


  • быстрое / замедленное движение / быстрая перемотка вперёд

  • предыдущий / следующий кадр


Полноэкранный режим и скриншоты


Вот пример того, как мы можем справиться с полным экраном и получением скриншотов:

domElement.fullScreen(); 
domElement.getImageData(0, 0, domElement.offsetWidth, domElement.offsetHeight);


Редактирование текста


Элемент <editоr>


Этот элемент позволяет сохранять набранный текст.

<tеxtarea type=”wysiwyg”>


Основная цель: WYSIWYG-редактор для структурированного (семантического) текста. Предполагаемое применение: блоги, электронные письма, редактирование статей сайтов на CMS и т.д. Примерный список поддерживаемых элементов.

  • блочные: p, ul/li, ol/li, dl/dt/dd, blockquote, pre
  • строчные: strong/em/a/sup/sub/u/code/strike
  • строчно-блочные: img, br
  • табличные: table/tr/th/td


Возможности:

  • поддержка копирования / вставки изображений из / в системный буфер обмена (связанный атрибутом)

  • поддержка копирования / вставки текста и HTML из системного буфера обмена и обратно (посредством атрибута)
  • не должен поддерживать инлайн-стили

  • может иметь атрибут content-style=«style.css», который определяет стиль элемента в редакторе


Возможности копирования / вставки


Список, представленный в левой части таблицы будет отображаться так, как показано в правой части.

  • Lorem
  • Ipsum
  • Dolor
  • sit
  • et cetera

  1. Lorem
  2. Ipsum
  3. Dolor
  4. sit
  5. etc

(прим. перев. На сайте оригинальной статьи в левой части у списка нету маркеров. Здесь я не нашёл, как их убрать)

Если вы скопируете пункт «Dolor» и вставите его в обычный текстовый WYSIWYG-редактор, то вместо простой записи вы получите «3. Dolor» без необходимости копировать номер пункта.

Компоненты и ECMAScript


«behaviors» или динамические подклассы DOM-элементов


Эта функция очень полезна для структур компонента пользовательского интерфейса и инструментов

document.behaviors["ul.some>li"] = { // класс поведения:
  attached: function() {...},
  detached: function() {...},
  onmousedown: function() {...},
  onclick: function() {...},
  ...
};


«behaviors» — это набор методов, присвоенный всем элементам, которые соответствуют селектору в объявлении. Когда на элементе срабатывает событие, он вызывает соответствующую функцию. Точно также предложено работать с CSS. Это поведение похоже на «цепь» событий в jQuery.

include(‘url’);


Многим программистам, которые привыкли писать на C ++, PHP и т.д., ощутимо не хватает такой возможности. Чтобы сохранить модульность, рекомендуется использовать подключение внешних файлов следующим образом (работает аналогично import url(…) в CSS):

window.include("url"[,mime/type])


JavaScript: пространство имён и классы


JavaScript-код становится всё более и более сложным. На одной странице могут быть использованы несколько разных библиотек и отсутствие пространства имён (и классов) становится всё более серьезной проблемой для разработчиков.

Синтаксис выделения для элементов <cоde>


Учитывая, что у браузеров уже присутствуют инструменты парсинга HTML, JS и CSS, было бы неплохо иметь встроенную поддержку для синтаксиса выделения без необходимости парсить код на стороне клиента при помощи Javascript. Для начала было бы достаточно всех перечисленных выше языков, а другие могут быть добавлены путём подключения соответствующего CSS.
Перевод: script-tutorials.com
Максим Усачёв @psywalker
карма
82,0
рейтинг 5,6
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

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

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

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

  • +3
    >>> «behaviors» или динамические подклассы DOM-элементов

    Спустя много лет сообщество допёрло, что .htc — не такая уж плохая идея :D
    • +1
      Не думаю, что обозначенные в обзоре behaviors это хорошая идея. Использование побочного эффекта в чистом виде.
    • 0
      А пройдёт ещё некоторое время, и решат воскресить HTML+Time…
      • +1
        Так это ж SMIL.
    • +3
      как и hta :)
  • +2
    Не так давно читал где-то (кстати, по-моему, на вашем ресурсе, psywalker), мол, HTML5 это живой стандарт и никаких HTML6 и HTML Next не будет, а будет «дополняться» существующий «стандарт». Это мнение подкрепляется чтением данного обзора: некоторые фичи клёвые, но в целом никак не тянут на революционность или некстген, скорее, разумное продолжение в развитии HTML5. Прав ли я, что термины HTML5/Next здесь чисто маркетинговые?
    • НЛО прилетело и опубликовало эту надпись здесь
    • +2
      На самом деле существует "Живой стандарт WHATWG" и W3C-спецификации и + между ними есть отличия, типа таких. В этой же статье скорее говорится о следующем поколении именно «НЕживой» спеки (HTML5,6 и т.д.), т.е. спеки, которую сейчас намечает консорциум W3C.

    • –1
      Мне кажется, что следующее поколение HTML должно быть похоже на что-то вроде Ruby Slim.
  • +2
    Лучше бы что-то типа Grid Style Sheets запилили наконец нормально…
    • НЛО прилетело и опубликовало эту надпись здесь
  • –3
    <a href="familyreunion.zip/html/activities.html">Деятельность нашего семейного воссоединения</a>
    

    Наверно тогда лучше вот так:
    <a href="zip://familyreunion.zip/html/activities.html">Деятельность нашего семейного воссоединения</a>
    

    Вот пример того, как мы можем справиться с полным экраном и получением скриншотов

    Если появится возможность делать скриншоты со страниц, то опасность XSS атак в очередной раз повысится.
    • НЛО прилетело и опубликовало эту надпись здесь
      • +1
        Мне кажется тут проблема больше в том, что существует доменная зона .zip, поэтому возникает неоднозначность в выборе между файлом в подруженном zip-архиве и файлом, который расположен на гипотетическом сайте familyreunion.zip
        • +2
          Чтобы произошло обращение к зоне zip, нужно, чтобы URL начинался с «http://», "//" или тому подобных. В текущем состоянии эта ссылка ведет на что-то внутри папки с именем «familyreunion.zip», т.е. путь должен восприниматься относительно base URL текущей страницы. Тем не менее, это всё ещё неоднозначность. На мой взгляд, необходимо либо ввести отдельную схему (но непонятно, что делать, если доступно несколько одноименных архивов, так что вариант не очень), либо указывать путь в виде «httр://example.com/mobile/familyreunion.zip/html/activities.html» (если архив объявлен ранее, то никакой неопределенности тут не возникает). Путь к zip-файлу может быть относительным, тогда ссылка будет выглядеть менее страшно.
          • 0
            либо указывать путь в виде «httр://example.com/mobile/familyreunion.zip/html/activities.html»

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

            Может быть имеет смысл добавить атрибут тегу <a> и в нем напрямую указывать, из какого именно архива мы хотим получить страницу? Например:
            <decompress href="/mobile/archive.zip">
            ...
            <a href="/path/to/some/page.html" zip-src="/mobile/archive.zip">Click!</a>
            

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

            PS. Теоретически, при таком подходе можно вообще избавиться от тега <decompress> и загружать архив тогда, когда браузер встречает этот zip-src (разумеется, если этот архив не загружен ранее).

            PPS. По большому счету, все это можно упростить еще больше до указания где-нибудь в <head> ссылки на архив с сайтом: если браузер находит запрашиваемую с данного домена страницу в zip-архиве, то он использует ее, если нет — обращается непосредственно к веб-серверу (скажем, если страница динамическая).
            • 0
              Фактически это не сильно отличается от SPA, в котором весь сайт (по крайней мере статика) загружается одной страницей (запросом) и переключение между «страницами» происходит через JS и HistoryAPI.
            • 0
              вот в этом комментарии вроде бы приведен пример как сейчас можно обращаться к файлу из zip
      • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        deleted
    • –1
      deleted
      Обновляйте комментарии перед отправкой.
    • 0
      >появится возможность делать скриншоты со страниц
      так и сейчас можно
  • +1
    Вангую, что из всего этого добра использоваться будут туевы хучи вложенных <div>'ов со стилями. Как сейчас.
    • 0
      Но можно же надеяться на shadow-DOM…
  • –4
    Много лет прошло уже, одно время даже казалось, что вот-вот наступит счастье, но судя по всему мы обречены на вечное использование велосипедов и костылей, костылей для костылей и тд.
  • –3
    О, неужто я когда-нибудь доживу до WYSIWYG-редакторов и подсветки синтаксиса без подключения кошмарных библиотек циклопических размеров?
  • –4
    Жаль, что используется устаревший формат сжатия .zip (как и .jpeg для картинок), а не .7z например.
    • +1
      В статье же написано, что zip это просто для примера, как один из самых популярных
  • +1
    Почему-то я вспомнил про zip размером в килобайт, распаковывающийся в doc с миллиардом строк, вешающим любую машину при открытии.
  • 0
    autocapitalize надо вводить только вместе с dеcompress :)
  • 0
    А смысл в этой штуке с zip, если http итак поддерживает сжатие?
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Ну это в принципе плюс. Но все-таки думаю, что это не очень необходимо. Это усложнит и сервер, и клиент. Да и грузить этот zip чтобы с ним работать нужно будет целиком. Думаю было бы оптимальней реализовать это на javascript.
        • 0
          наконец-то перестанут минифицировать js и можно будет заглядывать в apk и jar
          • 0
            Не перестанут. Минификация и архивирование сейчас применяются вместе, непонятно почему потом откажутся от минификации.
            • 0
              ? не удобно отлаживать
              +зачем минифицировать если и так сжато
              • 0
                На девелоперских компьютерах обычно используется не минифицированная версия. И сейчас уже везде сжатая версия используется, почитайте о http compression.
                • 0
                  ушел читать ;)
  • 0
    А как же форматирование чисел? например, пробельчики «1 000 000»
  • +3
    Преимущества такого подхода: доступ браузера к файлам из ZIP, снижение требований к пропускной способности (что особенно важно для мобильных платформ).

    Давно уже решили это все через Keep-Alive. К сожалению, маленькие файлы продолжают лететь с заголовками, но в целом gzip+keepAlive дают примерно тот же результат.

    Семантика для описания заголовков и авторов

    Есть уже семантика для указания авторов

    <location lat=27.9 long=-71.3 altitude=-100>Бермудский треугольник</location>

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

    tеaser

    Не понял зачем. Тэга section мало?

    Автоматическое написание с заглавных букв в полях формы

    Только что проверил на поле ввода хабра. Вот это работает:
    <textarea style="text-transform: capitalize">
    


    Полноэкранный режим и скриншоты

    Через webGL можно делать скриншоты в хроме, как бы смешно не звучало.

    Элемент editоr

    Есть для этого на js уже решения. persistent.js называется, кажется

    tеxtarea type=”wysiwyg”

    ContentEditable

    «behaviors» или динамические подклассы DOM-элементов

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

    include(‘url’);

    Это как бы вообще к HTML не относится ни разу, даже комментировать не буду (хотя есть что сказать)

    JavaScript: пространство имён и классы

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

    Это перевод, я понимаю, потому и не пытаюсь как-то оскорбить или унизить переводчика. Но вот автору хочется сломать пальцы, чтобы он не нес такую вот доброту в массы.
    • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        Дело в том, что HTML, CSS, JS — служат разным целям.
        И их основная задача исконно выступать в качестве «платформы».
        В случае с JS, например, наиболее корректно воспринимать вкладку-сайт как виртуальную машину. Если вспомнить, что JS в рамках этой виртуальной машины может быть достаточно низкоуровневым, аналогия становится еще более понятной. Соответственно, при загрузке подключаются какие-то модули ядра и какие-то клиентские модули.
        Модули ядра служат для выполнения задач, которые сделать НЕЛЬЗЯ (например, Function.prototype.call) или делать СЛИШКОМ ДОЛГО(Function.prototype.bind — он дает прирост скорости) для клиентского кода.

        HTML служит языком СЕМАНТИЧЕСКОЙ разметки. Он описывает разбивание данных на семантические (ну, если проще — логические) составляющие.
        Поверх него можно строить языки-указатели (типа OpenGraph), служащие для как раз указания на авторов в том числе. Для этого есть специальный тэг meta.

        А гугловские/яндексовые карты и GPS в телефонах учитывают эти штуки? Насколько я понимаю, сейчас почти все используют WGS 84 + EGM96, полагаю, для типовых веб-задач этого хватит…


        Все несколько сложнее, просто поверьте. Я устану это объяснять, с навигацией всегда было очень много тонкостей. WGS-84 дает в некоторых точках земного шара (если не путаю, в Японии максимум) расхождение с геоидом 186, что ли, метров, что для многих ситуаций неоправданно. Более того — какое будет применение у этого тэга?
        Тэг для времени ввели для того, чтобы не происходило расхождение: если где-то пишут «встреча произойдет ...15 января в 15:00...», такой элемент теоретически сможет автоматически ввести поправку на часовой пояс пользователя и автора и показать дополнительно скорректированное время. А у координат такой смысловой нагрузки нет.

        Вот это работает:… text-transform: capitalize

        Но на сервер данные полетят с маленькими буквами. Что может дважды расстроить юзера — неуважением к его фамилии и фактом обмана. Не надо так:)


        При отображении имени и фамилии на клиенте тоже показывать через text-transform, какие проблемы.

        какое быстродействие будет у этой балалайки

        По-моему, при хорошей реализации — не особо меньшее, чем у стандартных интерактивных элементов типа details (не считая разовых затрат на инициализацию). registerElement решает всё-таки немного другую задачу, определение совсем новых элементов и расширение поведения нескольких старых — разные вещи, но они могут неплохо друг друга дополнять.

        Угу, только с нынешними селекторами и будущими можно будет нагородить конструкцию типа
        main.formatted > .container:not(:last-child):not(:first-child) + *:has(section:not(:only-child)) > section
        и при добавлении класса .formatted для main нужно будет это пересчитывать, например. Какова перспектива.
        Да, нужно не уметь себе стрелять в ногу, но лучше помочь не делать этого.
        document.createElement ввели потому что конструктор для неизменного тэга — это несложно и вообще весело, это в рамках выделения вообще всех элементов в потомки HTMLElement произошло.

        Ну почему, HTML-импорты ведь появились. Правда, будущее у них несколько туманно. Возможно, новому предложению повезет больше, кто знает?..

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

        Это вопрос скорее к авторам ES6, где как минимум классы уже ввели. Правда, тут уже я удивляюсь, как это относится к HTML:)


        Там много синтаксического сахара, не более. Компилируются примерно так же как классы в кофе или тайпскрипте. «Честные» классы на JS фундаментально нереально сделать.
        • НЛО прилетело и опубликовало эту надпись здесь
          • 0
            Да, можно, всякие schema.org и т.п. тоже этим занимаются. Но если семантика выносится в отдельный слой, что остается на основном уровне? Мне кажется, то, что в нашу соцсетевую эру в HTML нет стандартной штуки для указания на человека (которая «из коробки» могла бы интегрироваться с приложениями для контактов и т.п.) — это всё-таки недоработка языка. Не фатальная, конечно, но лишней такая штука бы точно не была)

            Я еще раз говорю — HTML и OpenGraph это несколько уровней одной модели, как в OSI. HTML — структурирует, оперируя абстрактной информацией. OpenGraph — оперирует конкретными понятиями и сущностями. Я говорю об этой семантике, а не о истерии хомячков на тему того, что правильнее — section или article
            Как это нет? А проложить/рассчитать маршрут до искомого места, а найти ближайшие к месту стоянку/гостиницу/кафешку, а в недалекой перспективе — указать пункт назначения для роботакси? По-моему, в нынешнем вебе, особенно мобильном, к геоданным что только ни привязывается…

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

            Проблем куча:
            На сервере будут некорректные данные, но юзер этого не поймет;
            Когда юзер попытается зайти со старого компа, не понимающиего text-transform для textarea, и введет визуально тот же текст, сервер скажет ему «ты кто такой, давай до свидания», что будет для юзера выглядеть необъяснимой ошибкой;
            Нельзя ввести фамилию «ван Бетховен», которая совсем не то же самое, что «Ван Бетховен» (CSS-отображение вручную никак не перебить, а от поля с автокапитализацией лично я жду поведения нынешней клавиатуры iOS после точки — по умолчанию большая буква, но это можно явно отменить);
            Путаница из-за одинакового отображения разных (в т.ч. по смыслу) входных данных.

            эмм. нет.
            1. Ну, на сервере хранятся данные для машин. Время там тоже не в особо человеческом формате.
            2. Насколько помню — text-transform — одно из самых первых свойств.
            3. А в предложенном решении с принудительной трансформацией как это решается?
            4. Где?

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

            Потребность у многих есть уже сейчас. И вполне нормально, имхо, прощупывать разные подходы — чтобы в итоге консорциуму было из чего выбрать лучший и довести до ума окончательно, и сделать это до 2022-го года:)


            Еще раз: если работает в полифилле — это можно использовать. Консорциум будет смотреть, изучать, вносить правки, а когда уже отлежится и все поймут, что им реально надо — примут.

            много синтаксического сахара

            И разве это плохо? :)


            И да и нет. Причем в основном нет. С одной стороны — классы — это хорошо для быстродействия. С другой — дело в том, что язык должен будет поддерживаться по сути бесконечноhttp://habrahabr.ru/post/249207/# долго (самые первые сайты до сих пор должны корректно отображаться). Из-за этого фичи и возможности продумываются достаточно долго, на это тратятся напряженные часы споров, тестов, изучения и проб. Для такого большого изменения, как классы — это сожрало туеву кучу времени. По факту из-за того, что куча набежавших хомячков затребовала классы, как у нормальных посонов на серверсайде, а то чо мы как лохи — меньше времени ушло на обсуждение тех фич, которые нельзя было бы реализовать без трансляторов на уровень JS. А классы — это реально огромное количество проделанной работы.
            В итоге — из-за того, что пахали над классами — до сих пор, например, в фазе обсуждения находятся async/await functions.
            Это абстрактный пример, я не слежу за происходящем в сообществе, но тем не менее.
            Просто чтобы понимать уровень сложности принятия решений однозначности ради — объясню на примере arrow functions и destructing assignment.
            У них вот такой синтаксис:
             var fn1 = var1 => var1 + 1,
                   fn2 = ({var2}) => {return var2};
            

            Это эквивалентно

             var fn1 = function(var1){return var1 + 1},
                   fn2 = function(d){return d.var2};
            

            То есть скобки не обязательны, если есть один аргумент. Если выполняется одна операция и нет фигурных скобок — ее результат возвращается.
            Вопрос на засыпку: во что должен превратиться и должен ли во что-то превратиться вот такой код?
            var fn3 = {var3} => {data: var3}
            

            • НЛО прилетело и опубликовало эту надпись здесь
              • 0
                То есть по остальным пунктам убедил?

                HTML как он сложился — увы, именно про «семантику-шмемантику для хомячков»

                Дело не в этом, дело в том, что он (как и любой другой язык разметки, т.е. семантичного структурирования данных) позволяет на базе себя, как абстрактного языка, не имеющего дела с реальными понятиями, реализовывать структуры конкретных данных.
                Условно, если HTML служит для описания деревьев (живых таких, зеленых) как абстрактного понятия — с листочками, веточками и так далее, то OpenGraph уже позволяет указывать точную породу древесины и ее возраст, а HTML предоставляет еще и табличку перед деревом, на котором можно написать в том числе это. Так понятнее?

                Не маскировка, а честное авторедактирование.

                Да, возможно, имелось ввиду указание для мобильных, нужно ли делать автокапитализацию каждого слова. С этим — ок, согласен, возможно, автор криво написал просто идею.
  • 0
    Сначала подумал, что внезапно пришла весна и настало время «нескучных html6» а нет, оказывается просто перевод.
  • +1
    Предлагаю вернуть теги marquee и blink, а font сделать рекомендованным к использованию.
    • 0
      Кстати, по теме))
    • 0
      Предлагаю верстку на table
      • НЛО прилетело и опубликовало эту надпись здесь
      • 0
        <frameset> forever!
  • +4
    Прочитала статью, решила записать интересное в свой блокнотик, но сначала полезла в поиск по хабру же. Ну как бы за 2011 год статья — вот.
    • 0
      А чо, нормально так, в 2015 году на голубом глазу перепечатывать статью из 2011 года )))
      • +1
        Справедливости ради эта статья не копипаста. А в той почему-то не указано, что это перевод. Хотя забавно конечно :)
      • +1
        Ну да, зато 21 плюсик и 56 комментов — неплохо, я считаю :)
        • +1
          … для тех кто фапает на плюсики.
          • +1
            Поставлю вам плюсик.
    • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Идеи для HTML6 можно брать также из XAML, полагаю оттуда много ещё чего можно подчерпнуть.

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