HTML5 INSIGHT
New open standards created in the mobile era, such as HTML5, will win on mobile devices (and PCs too).


Thoughts on Flash, Steve Jobs


10k Apart

(Анонс на русском на Хабре: http://habrahabr.ru/company/microsoft/blog/125641/)



* Это вторая статья из серии погружения в HTML5 — их можно рассматривать как заметки к более объемному труду, который также постепенно готовится, но вместе с тем, они могут служить и просто кратким в введением в тематику HTML5*

Семантика – это о понимании значения. Сегодня мы поговорим о важности смысловой разметки верстки и извлечении данных, традиционных подходах и новых возможностях, предоставляемых стандартом HTML5.

(Для жаждущих дополнительного вдохновения, сразу рекомендую статью Вадима Макеева про семантическую верстку в двух частях – раз и два, а также его доклад с РИТ про верстку со смыслом.)

О чем мы будем говорить и почему это важно?

Говорить, или размышлять, мы будем о смысле и структуре. Это, если коротко.

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

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

Вообще все разговоры о семантике и структуре можно свести к вопросу извлечения смысла. Эта задача возникает в трех ключевых точках:

  1. Разработка или дизайн 
  2. Автоматический анализ
  3. Человеческое восприятие

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

Представьте, что вы делаете какое-то веб-приложение и не сильно заботитесь о том, как будет внутри выглядеть конечный код, например, вы пользуетесь средствами генерации кода из другого языка (например, Java или C#) или исключительно визуальным дизайнером, который генерирует код для вас (ха, например, сохраняете страницу из Word). Когда дело доходит до отладки страницы в реальных условиях, наступает легкий приступ паники от окружающих вас непролазных джунглей и неведомых зверей – вплоть до того, что вы можете потратить несколько часов, чтобы понять, откуда именно вылезла та или иная строчка кода и где ее нужно править.

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

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

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

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

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

Облегчить решение этих задач как раз и может правильная разметка контента.

Другой важный момент, где автоматическое извлечение и понимание контента играет огромную роль – это вопросы доступности (accessebility), когда, к примеру, человек, чтобы взаимодействовать с вашей станицей использует специальные программы (screen reader), которые в свою очередь, чтобы сделать это взаимодействие возможным, как раз должны понять, что есть на вашей странице, какая роль у каждого кусочка и какие возможности вы предоставили пользователю. Все это делается на основании изучения кода станиц.

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

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

Семантика сегодня: от тегов и атрибутов к классам и микроформатам

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

 

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

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

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

Другие важные элементы – это разумное именование id и классов в элементах и правильное использование заголовочных (title) или альтернативных (alt) атрибутов, которые также, безусловно, добавляют смысла.

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

Наконец, переходим к HTML5!

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

Структурная семантика

Традиционная сегодня, блоковая верстка страниц никуда не уходит, но видоизменяется – в HTML5 появляются новые элементы для еще более осмысленной разметки страницы.

(Оставляю на усмотрение читателя изучить самостоятельно историю появления новых тегов и выяснения, почему они именно такие – это, правда, интересно!)

Если сегодня мы делаем примерно вот так:

<div class="header">
<h1>...</h1>
<h2>...</h2>
</div>
<div class="section">
<div class="article">...</div>
</div>
<div class="sidebar">...</div>
<div class="footer">...</div>

То с новыми элементами HTML5 эта разметка преображается в более красивую и стройную фигуру:

<header>
<h1>...</h1>
<h2>...</h2>
</header>
<section>
<article>...</article>
</section>
<aside>...</aside>
<footer>...</footer>

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

Зачем тогда все это? Ответ, на самом деле, очень прост – единообразие. В реальности, если я хочу понять автоматически, где тут навигация по названиям классов, то я столкнусь и с “nav”, и с “navigation”, и c “menu” и тысячей других вариантов, не говоря уже о транслитерации с русского ;)

Если я знаю, что навигация – это всегда элемент <nav>, моя жизнь сразу обретает радостные краски.

В HTML5 есть целый ряд таких новых элементов – и мы не будем останавливаться на каждом из них подробно:

  • header и footer – группировка заголовочных и подвальных элементов, важный момент – они могут встречаться не только наверху и внизу страницы, но и внутри различных блоков, если в них имеет смысл выделять собственные заголовочные и подвальные блоки (например, вставленный виджет).
  • aside – врезка слабо связанного с содержимым страницы (от просто интересной информации до баннеров)
  • hgroup – группировка нескольких заголовочных элементов (h1 - h6) в единый блок.
  • nav – группировка элементов навигации
  • section – общий блок для документа или раздела приложения
  • article – отдельный кусок контента, например, пост в блоге или статья в газете
  • figure и figurecapture – вставка дополнительного, но в общем-то самостоятельного контента, вроде схем, видео, картинок. Может быть с подписью.

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

Что делать, если браузер не поддерживает HTML5?

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

1. Нужно сказать браузеру, что эти элементы блочные с помощью соответствующих css-правил:

article, aside, figcaption, figure, footer, header, hgroup, nav, section { 
    display:block;
}

2. Для браузеров, которые не поддерживают по умолчанию вставку нестандартных (для HTML4) элементов, нужно инициализировать возможность их использования через JavaScript. В целом, достаточно сослаться на библиотеку html5shim:

<!--[if lt IE 9]> <script src="scripts/html5.js"></script> <![endif]-->

(К слову, это верно не только для старых версий IE, но и для старых версий других браузеров, если среди вашей аудитории если любители раритета.)

Текст и контент

Другой блок больших нововведений и изменений касается вставки текстового и и другого контентного содержимого (учтите, что я намеренно не рассматриваю в этой статье графические и мультимедийные элементы, а также элементы веб-форм):

 

  • mark – маркерное выделение фрагмента текста (по умолчанию – черный шрифт на желтом фоне), релевантное в другом контексте (например, веб-версия документа, в котором кто-то уже выделил маркером фрагменты текста).
  • ruby, rt и rp –специальные элементы для аннотации текста, как правило, используемые при работе с иероглифами для уточнения смысла в текущем контексте.
  • bdi – специальный элемент для изоляции из основного контекста блока для двунаправленного форматирования текста (это важно при смешении текстов на разных языках, например, английском и иврите, – в этом случае нужно логически обозначить, какой блок текста относится к другому семейству языков и поэтому при отображении может быть обработан иначе). См. также пост Ричарда Ишида (Internationalization Activity Lead, W3C) – html5′s new bdi element.
  • wbr – рекомендация по месту разрыва текста в случае переноса на другую строку – может быть полезно как в случае "неразрывной" “в одно слово” фразы, так и внутри длинных слов. Нужно, чтобы обеспечить возможность корректных переносов, если слово не умещается в отведенные рамки.
  • summary и details – краткая версия и дополнительные подробности (детали), которые пользователь, возможно, хочет также получить. Браузер должен обеспечивать возможность скрыть или показать детали.
  • time – специальный элемент для обозначения дат и времени и обеспечения возможности автоматического извлечения этих данных в стандартном формате (то есть, например, внутри можно написать 4 августа, а в атрибуте нужно указать 2011-08-04). 
  • meter и progress – еще два элемента для смысловой разметки измеримых данных, соответственно, измерения состояния чего-либо (счет, загруженность диска и т.д.) и прогресса в каком-то измерении. В зависимости от обстоятельств, конкретная визуализация этих элементов может быть различной. (К слову, в стандарте оба этих элемента относятся к блоку Controls & Forms.)
  • embed – наконец-то, в стандарте ;)

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

В стандарте HTML5 отчетливо проявилось стремление расставить все точки над i, выкинуть все лишнее (т.е. стилистическое) и, в частности, убрать дублирование элементов там, где это имеет смысл.

  • dl – для описания пар элементов-значений (определений), но теперь никак не для диалогов.
  • cite – название работы (книги, статьи, поэмы, фильма и т.п.), но не отсылка на имя автора.
  • menu – теперь может использоваться для тулбаров и контекстных меню.
  • address – внесено разъяснение в использование данного тега – только для контактной информации с человеком, ответственным за данную страницу, но не для обозначения любых адресов (почтовых или email) самих по себе.
  • hr – тематическое разбиение на уровне параграфов (например, переход к другой истории или другой теме).
  • small – дополнительные заметки, то что обычно пишется “мелким шрифтом”, вроде заметок на полях.
  • em – выделение смысла, когда нужно поставить акцент на конкретное словое в предложении.
  • i – выделение голосом или настроением или подчеркивание выделения из контекста (слова, чье написание обычно делается наклонным – термины, иностранные слова, названия).
  • strong – выделение важности, когда нужно обозначить особо важные моменты.
  • b –выделение текста из контекста без придания ему дополнительной важности, например, ключевые слова, названия продуктов, а также блоки текста, написание которых традиционно делается жирным, в том числе для переключения контекста.
  • s –неверный или более нерелевантный контент.

Также стоит отметить, что для ряда элементов спецификация рекомендует использовать вместо них соответствующие правила CSS (<basefont>, <font>, <big>, <center>, <blink>, <u>, <tt>, <strike>), для еще ряда элементов рекомендуется использовать другие элементы вместо них (<applet> –> <object>, <acronym> –> <abbr>, <bgsound> –> <audio>, <dir> –> <ul>), и, наконец, фреймы рекомендуется не использовать ни при каких обстоятельствах – используйте iframe.

Осталось еще совсем немного ;)

Доступность документов

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

Для обеспечения доступности, помимо традиционных атрибутов вроде alt и title, теперь есть специальные aria-* и role атрибуты, определяемые в соответствии со стандартом Accessible Rich Internet Applications (WAI-ARIA).

Эти атрибуты позволяют разметить роль (назначение) различных элементов разметки – будь то ссылки, заголовки или элементы меню. Так, например, элемент aside может играть как роль заметки/сноски, так и просто дополнительной информации, а то и вовсе быть блоком для поиска. И в каждом случае конкретная роль можем менять характер взаимодействия с блоком.

В целом вопрос доступности – тема, пронизывающая многие аспекты верстки веб-страниц (вплоть до написания кода на JavaScript) и хороший предмет для отдельной большой статьи.

Переходим к заключительному краткому блоку!

Как встроить данные в документ

Последний важный блок, продолжающий тему добавления дополнительной информации к контенту страниц.

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

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

HTML5 добавляет возможность плодить в любом количестве собственные data-* атрибуты и иметь к ним программный доступ внутри приложения (как к обычным атрибутам или через интерфейс dataset). Важный нюанс заключается в том, что эти атрибуты предназначены для внутреннего использования внутри страницы или приложения и, вообще говоря, не должны использоваться для предоставления информации внешним сущностям (как это делают, к примеру, микроформаты).

Наконец, есть еще одна важная опция для аннотации данных – это HTML MicroData, требующая отдельного рассмотрения. 

И в заключение

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

p.s. Как всегда, если найдете в этом длинном повествовании нехватающие важные элементы, неточности или ошибки, дайте знать.



Хороший пост от Joe Marini (@joemarini) об использовании Navigation Timing API в Mango-обновлении для WP7 (напоминаю, там полноценный IE9!).

Navigation Timing API – это специальный стандартный API для анализа производительности приложения.



The Expressive Web

Новый ресурс от Adobe, посвященный новым веб-стандартам.



* Это первая статья из серии погружения в HTML5 – их можно рассматривать как заметки к более объемному труду, который также постепенно готовится, но вместе с тем, они могут служить и просто кратким в введением в тематику HTML5*

Откуда взялся HTML5?

Я не буду вдаваться глубоко в историю HTML и HTML5 – это тема для отдельного большого рассказа, но суть вопроса вот в чем.

Сама история HTML имеет весьма давние корни, начиная с языка GML (Generalized Markup Language), родившегося в недрах IBM в конце 60х годов, продолжая  стандартизированным в первой половине 80х языком SGML (Standard Generalized Markup Language) и переходя непосредственно к работам Tim Berners Lee в начале 90х, которые и вылились в первые наброски HyperText и HTML и первую официальную стандартную версию HTML 2.0 в 1995 г.

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

В конце-концов уже в течение года эта активность дала дорогу HTML 3.2, довольно быстро перешедшему в состояние официальной рекомендации W3C.

Появлялись новые идеи, стандарт продолжал усложняться и в 1997 г. был выработан и утвержден HTML 4.0, спустя 2 года обновившийся до ревизии HTML 4.01.

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

Волнующий многих вопрос: а что же дальше? А дальше нужно вернуться на несколько лет назад – в 1996 г., когда появился первый черновик нового языка разметки – знакомый сегодня всем разработчикам язык XML (eXtensible Markup Language), довольно быстро (по сегодняшним меркам) стандартизированный и нашедший огромное применение во множестве сфер благодаря своей универсальности и формализму, крайне удобному при машинной обработки данных.

Не оказался неподвластным влиянию XML и наш любимый HTML, что, как вы уже догадались, вылилось в XML-версию HTML, известную как XHTML. В новом статусе язык обретает новые возможности, получает модульность и… развитие самого языка разметки практически прекращается.

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

Фокус W3C тем временем смещается в новые области, особенно завязанные на развитие и использование XML – от языков разметки специализированных данных до языков обработки XML.

(Оставляю на усмотрение читателя самостоятельно проследить параллельные истории развития CSS и JavaScript.)

С возвратом конкуренции в середине 2000х и накоплением довольно большого опыта в работе с XML в W3C появляется новый проект – XHTML 2.0, на практике явивший собой несовместимую со старыми версию языка для разметки веб-страниц – хотя и со множеством новых идей, но преимущественно в силу обозначенного недостатка, не принятый активно в сообществе.

В конечном счете в 2009 работа над XHTML 2.0 была заморожена, а в конце 2010 перестала работать и соответствующая рабочая группа.

Параллельно со всем этим процессом шла активная работа по разработке новой версии HTML, совместимой с HTML 4.01. Начиная с новой версии веб-форм WebForms 2.0, разрабатываемой Яном Хиксоном (Ian Hickson) и внесенной в 2005 г. на рассмотрение в W3C, годом позже формально принятой в качестве черновика, – и переходя к новым возможностям для создания веб-приложений Web Applications 1.0. Вместе оба документа вылились в черновик стандарта HTML5, в начале 2008 г. внесенный на рассмотрение в W3C.

(Надо отметить, что работа над стандартом изначально велась в рамках рабочей группы WHATWG и впоследствии проходила и сегодня проходит в параллельном режиме в W3C и WHATWG. Группы имеют несколько разные подходы к работе, но обе версии стандарта синхронизируются между собой и у них также общий редактор – Ян Хиксон.)

На сегодня HTML5 находится в стадии Last Call Working Draft и в целом уже устоялся и находит активную поддержку как среди производителей браузеров, так и в сообществе разработчиков.

Спецификация HTML5 значительна по объему — она в три раза больше описания HTML 4.01. Но пусть вас не смущает размер: значительная часть спецификации адресована разработчикам браузеров и нацелена на обеспечение совместимости реализаций HTML5, выполненных различными производителями.

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

Актуальную версию черновика стандарта HTML5 можно найти тут: http://www.w3.org/TR/html5/

В W3C также ведется специальный документ, описывающий отличия HTML5 от HTML 4.01 – их можно посмотреть в этом документе: http://dev.w3.org/html5/html4-differences/

Ну хорошо, сегодня у нас есть HTML5, что с того? Зачем он взялся и зачем он нужен?

Что происходило, пока HTML спал?

Если кратко, то весь фоновый (хотя какой он фоновый? он как раз самый что ни на есть активный!) мной уже описан в одном из предыдущих постов с вот этой картинкой:

HTML Evolution

Фактически, пока спал HTML и спали или подремывали сопутствующие технологии (главным образом, CSS и JavaScript), интернет продолжал активно развиваться, требовал новых возможностей и находил способы их воплощения.

Подумайте, в рамках стандартного четвертого HTML и тогда еще не окончательно принятого CSS 2.1 и предыдущего стандарта JavaScript – ECMAScript 3, вооруженные мощностью плагинов (прежде всего, Flash и позднее Silverlight), веб-разработчики совершили целую революцию в интернете:

  • Насыщенные интернет-приложения (RIA) и вообще веб-приложения, работающие целиком в браузере
  • Асинхронное взаимодействие (AJAX – хотя технология XMLHTTPRequest, лежащая в его основе появилась еще в IE 5.5, но только с 2004 этот подход начал активное шествие по вебу)
  • Web 2.0, социальные сети
  • Онлайновое видео и аудио в браузере, живой стриминг
  • Общение через веб-камеру и микрофон прямо в браузере
  • Расцвет мобильного веба и специфических возможностей вроде геолокации
  • Драматическое ускорение JavaScript (за последние несколько лет это увеличение на порядок)

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

Веб изменился. А HTML все спал и спал :) Тут самое время сказать: дождались!

In HTML5 we trust!

Если вы читаете этот пост, вы наверняка уже много слышали про HTML5. А то и вовсе вам уже приелось слышать из всех углов истории про HTML5 и увлекательные рассказы разработчиков браузеров про всеобщую любовь к HTML5?

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

Давайте уже к сути?

Почему HTML5 – это мега-мега-круто?

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

HTML5, на мой взгляд, дает три основных преимущества на концептуальном уровне, которые важно понимать прежде, чем мы перейдем к деталям:

1. Нативная поддержка. Браузеры, поддерживающие HTML5 (а на сегодня это современные версии всех популярных браузеров), делают это нативно, из коробки, то есть без необходимости устанавливать дополнительные плагины. Функционал из коробки – это всегда хорошо, если он работает не хуже того, что в принципе можно доставить сверху. За надежность и интеграцию встроеного функционала отвечает производитель браузера, он же следит за обеспечением безопасности и приватности. Для встроенного функционала проще обеспечить доступ к системным ресурсам – будь то данные или вычислительные мощности.

2. Полноправные элементы. В отличие от плагинов, работающих как черный ящик, вставленный на страницу и в лучшем случае взаимодействующий с ней через специальные интерфейсы на JavaScript, встроенный в браузер функционал полноправно интегрируется во всю экосистему технологий и поддерживаемых стандартов. Например, это означает, что видео-элементы HTML5 можно стилизовать через CSS, к ним можно напрямую обращаться через DOM и JavaScript. Это единая хорошо связанная экосистема.

3. Открытые технологии. Открытость – штука двоякая и есть палка о двух концах. Открытые стандарты, доступные любому для изучения, использования и реализации, – с одной стороны, и необходимость в стандартизации и стремлении к совместимости разных реализаций – с другой. И вместе с этим относительно легкий доступ к коду (благо в каждом уважающем себя браузере сегодня есть встроенные средства разработки, ну или популярный плагин :)). Открытость, да! Да, с побочными эффектами.

Так что там нового?

Как я уже писал выше, спецификация HTML5 несет в себе множество изменений разного уровня и разной важности. Принципиально, ключевые изменения можно разделить на 5 блоков:

HTML5 Main Pillars

  • Семантика. В HTML5 появился ряд новых семантических тегов, позволяющих более осмысленно организовывать внутреннюю структуру веб-страниц. Это включает как блочные теги вроде header, footer, article, так и теги для разметки текста, например, mark, ruby, details. Ряд существующих тегов HTML4 признан устаревшим, отдельные теги поменяли свое значение, определенные изменения претерпели атрибуты.
  • Мультимедиа. HTML5 добавляет нативную поддержку мультимедийного контента (аудио и видео) прямо в HMTL-разметке — с соответствующим API для управления воспроизведением (и некоторыми заморочками с кодеками).
  • Графика. Работать с графикой на стороне клиента стало заметно проще. В HTML5 добавлен элемент canvas и специальный API на JavaScript для работы с ним. Canvas представляет собой динамическую «поверхность», поверх которой можно программного рисовать. Также в HTML5 официально включен тег svg, позволяющий внедрять векторную графику, описываемую соответствующим веб-стандартом (SVG, Scalable Vector Graphics).
  • Веб-формы. Новые элементы веб-формы: как типы, так и атрибуты, позволяющие расширить возможности традиционных форм встроенными средствами без использования дополнительных библиотек — от подсказок в поле ввода (placeholder) и проверки вводимых значений до специальных элементов для ввода дат и цвета.
  • JavaScript APIs. Как обозначенные выше API для работы с графикой и мульмедиа, так новые возможности по перемещению объектов (Drag & Drop) и работе с историей переходов (History API), а также ряд мелочей, вроде возможности сделать контент редактируемым прямо в текущем месте с помощью Content Editable атрибутов.

В следующих статьях мы рассмотрим все это подробнее.

– Хей! – скажите, наверняка, вы, – А как же все эти сокеты, воркеры, стораджи и скругленные уголки?

А это, скажу я вам, следующая история.

Зонтик HTML5

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

(Кстати, про историю логотипа читайте также вот тут: http://blogs.msdn.com/b/kichinsky/archive/2011/01/22/html5.aspx)

HTML5 – это спецификация. HTML5 – это и зонтичный термин, объядиняющий в себе целое семейство спецификаций, или даже, как правильнее будет сказать, новое поколение веб-стандартов.

Вы это наверняка слышали и, наверняка, еще много раз услышите – “HTML5” – это и про верстку, и про новые стили CSS, и про множество новых API, и даже про новую версию JavaScript – ECMAScript5.

HTML5 Generation

Так случилось – и да, это маркетинг. Чертовски хорошо раскрученный маркетинг. И в этом маркетинге вам, как специалистам или потенциальным специалистам в веб-разработке, я могу сказать только следующее.

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

HTML5 Umbrella

И в этом контексте, абсолютно все равно, будете ли вы называть левую и правую части соответственно HTML5 и все остальное, или смотреть на них как стандарт HTML5 и большой маркетинговый “HTML5”, или вполне справедливо полагать первое просто HTML5, а второе каким-нибудь “HTML5 Extended” или “HTML5+” или “HTML5*” или как вам больше нравится.

Это все веяние одного времени и одной цели – современные и будущие веб-приложения средствами веб-стандартов, с широкими возможностями большими надеждами. И огромной армией вас – веб-дизайнеров и веб-разработчиков!

И будьте уверены – это игра с большими ставками, в которую активно играют все крупные игроки – от Microsoft до Apple и Google, Firefox, Opera, Adobe и множество других компаний, организаций, сообществ и просто разработчиков, дизайнеров… и даже журналистов :)

p.s. Если найдете в этой длинной истории нехватающие важные элементы, неточности или ошибки, дайте знать.

Dark side of mutual cacophony.


Dark side of mutual cacophony.

Guess what they all say?


Guess what they all say?



HTML5 Support for VS2010The Visual Studio Web Standards Update provides you with intellisense and validation for: HTML 5 features (from Audio & Video tags to Microdata), Browser APIs (Geolocation and WebStorage), CSS3 (from Backgrounds and Borders to Transitions).

Cool!

[en] HTML & Plugins Evolution (dark version)


[en] HTML & Plugins Evolution (dark version)