Текст книги "Идеально! Как создать и переделать свой сайт. Правильный подход и передовые техники разработки"

Новые семантические теги и их использование

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

Прежде чем использовать какой-то новый тег, не забудьте о так называемом HTML5 Shiv. Этот скрипт важен для нас. Без него Internet Explorer 6, 7 и 8 не смогут распознать незнакомые стили (т. е. новые HTML5-теги, которых не было, когда создавались указанные версии IE).

Вы можете скопировать HTML5 Shiv из сервиса Google Code, где выложен этот проект[28]28
  smashed.by/steve.


[Закрыть].

Также вы можете получить HTML5 Shiv, используя js-библиотеку Modernizr[29]29
  smashed.by/modernizr.


[Закрыть]. В этом разделе мы не говорим об этом скрипте подробно, но тем не менее держите его на вооружении. Я использовал его на каждом сайте, созданном за последние два года.

Сброс HTML-стилей по умолчанию

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

Применяйте одну из новых версий CSS reset, поскольку старые версии не задают нормированный стиль элементам HTML5.

Очень советую познакомиться с Normalize.css[30]30
  smashed.by/normalize.


[Закрыть] Николаса Галлахера[31]31
  smashed.by/nicolas.


[Закрыть] и Джонатана Нила[32]32
  smashed.by/jon.


[Закрыть].

Многие из старых сценариев сброса (классический пример – сброс от Эрика Мейера) тяжеловесны: они сбрасывают каждый элемент, а некоторые их изменения можно оспорить, например тег strong при установке не выделяется жирным шрифтом по умолчанию. Normalize.css сбрасывает элементы более изящно и сглаживает некоторые причуды браузеров. Это позволит вам максимально нивелировать различия между ними. Джон Нил и Николас Галлахер «раскладывают по полочкам» все, что делают скрипты. Изучите подробно прокомментированный код – он фантастичен!

Строим сайт заново

Дойдя до этого пункта, вы, наверное, подумали: «OK, пора начинать писать сайт, пользуясь самыми замечательными новейшими тегами!» Когда были установлены новые семантические теги, разработчикам пришлось потрудиться: проанализировать, какие классы иидентификаторы они будут применять для своих сайтов. Ничего экстраординарного они не обнаружили: на деле все они пользовались одними и теми же именованиями (иногда с небольшими перестановками).

Итак, возможно, имена новых тегов уже подходят для того, что мы делаем.

Тег SECTION

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

<section class="статьи"></section>

<section class="о себе"></section>

<section class="презентации"></section>

Возможно, каждая из этих частей носит свою «шапку», поэтому мы можем считать их довольно важными. Так что наше решение по поводу разбивки на разделы оправдано. Если бы вы писали книгу наподобие этой, вы могли бы для каждой из глав создать раздел, а затем внутри каждого раздела – подраздел. Что касается семантики на сайте, общий совет: не «зависайте» на деталях. Выберите элемент, основанный на самой полной информации, которая у вас есть сейчас – и вперед! Семантика субъективна. И не парьтесь по пустякам!

Тег ARTICLE

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

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

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

<section class=”presentations”>

<header>

<h1>Моипрезентации</h1>

</header>

<article>

<h2>Введениев HTML5</h2>

<p>4-часовой мастер-класс, который я проводил

в Австралии</p>

</article>

<article>

<h2>Compass и SASS</h2>

<p>Используйте качественную библиотеку CSS,

и вы сможете сконцентрироваться на важных вещах.</p>

</article>

</section>

Зоркие читатели могут спросить «Похоже на список! Почему бы не использовать тег ul?» И будут правы. Он, безусловно, может быть элементом списка. Но article показывает, что, хотя эти элементы похожи, они не имеют отношения друг к другу. Мы можем спорить об этом до бесконечности. Но, в конце концов, на вкус и цвет товарищей нет, и решение за вами.

Тег HEADER

Вы когда-нибудь использовали класс или идентификатор как «шапку» или баннер? Или даже для заголовка сайта? Тег header может использоваться как нечто большее, чем просто заголовок сайта. Его можно (но совсем не обязательно) применять внутри тегов article или section. Просто используйте его, когда нужно, чтобы блочный элемент разграничивал пространство на странице для ясности. Например, я часто храню заголовки и метаинформацию в шапке поста блога.

Тег FOOTER

Тег footer аналогичен тегу header. Вы можете использовать его внутри тегов article или section, или глобально, внутри body.

Тег ASIDE

Тег aside может использоваться на уровне страницы или внутри article. Его содержимое можно считать полезной информацией, но вовсе не основной.

Например, для мобильных версий своего сайта вы можете скрыть aside-элементы. Как бы вы ни обошлись с тегом, он заставит вас принять решение о контенте. Запись в блоге можно представить так:

<article>

<header>

<h1>Все о тракторах</h1>

<time datetime=”2012-01-01”>1 января 2012</datetime>

</header>

<aside>

<p>Написано полностью Брюсом Лосоном</p>

</aside>

<! – Тело поста идет здесь.->

</article>

Тег TIME

Вы заметили в предыдущем примере новый тег? Тег time прост: используйте его для показа времени. Вы также можете представить машинно-читаемую версию.

<article> <p>Опубликовано <time datetime=”1984-04-03” pubdate>3 April 1984</time></p> </article>

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

NAVIGATION

Элемент nav явно предназначен для навигации сайта. Вы можете вставлять теги nav, чтобы создавать выпадающее меню. Тег не годится для списка презентаций, который я показывал вам, когда мы говорили о теге article. Приберегите nav для своего сайта, когда дело дойдет до структурной навигации сайта. Например:

<nav>

<ul role=”navigation”>

<a href=”/products”>Продукция</a>

<a href=”/contact”>Контактная информация</a>

<a href=”/about”>О компании</a>

</ul>

</nav>

(Хотите узнать, для чего нужен атрибут role? Тогда читайте дальше!)

Теги FIGURE и FIGURE CAPTION

Возможно, вы добавляете на свои страницы много изображений. А задумывались ли вы когда-нибудь о том, как лучше задать подписи к ним? Вот было бы здорово, если бы можно было аккуратно подписать изображение! Для этого-то нам и нужен тэг figure.

<figure>

<img src=”whisky.png” alt=”Бокал виски,

рядом маленькая бутылочка с водой.”>

<figcaption>Бокал виски, рядом

маленькая бутылочка с водой.</figcaption>

</figure>

Это еще не все. Вы можете использовать тэг figure для видео, svg и всего визуального, к чему может потребоваться подпись.

Тег DIV

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

Div (division) означает «раздел», и порой нет лучшего тега для описания куска контента. Возможно, все, что вам нужно, это контейнер для применения стилей. Так бывает. Это не в упрек вам. Семантика – штука коварная. Если вы на самом деле не умеете описывать куски контента с использованием каких-то тегов HTML, о которых мы говорили выше, берите div и не казните себя за это.

Несколько слов о семантической структуре

Теперь, когда у нас есть несколько новых элементов для разметки блоков (т. е. section и article), простая структура старого документа, которую мы использовали, чуть-чуть изменилась. Элементы разметки блоков можно рассматривать как блоки всего html-документа. Другими словами, теги заголовков от h1 до h6 могут использоваться внутри них.

Но будьте внимательны! Вы можете столкнуться с чем-то подобным:

<body>

<header role=”banner”>

<h1>Блог о велоспорте</h1>

</header>

<article>

<h1>Раннее утро на дороге Блэкспур </h1>

…

</article>

</body>

Многократно вставлять h1 в один и тот же документ? Это безумие! Вместо этого я применяю заголовки, чтобы показать структуру внутри заданного раздела:

<body>

<header role=”banner”>

<h1>Полноформатный кадр: Блог о фотографии</h1>

</header>

<article>

<h2> Раннее утро на дороге Блэкспур </h2>

…

</article>

<section>

<h2>Купите нашу книгу!</h2>

…

<section>

<h3>Печатное издание</h3>

…

<button>Купитьза $90</button>

</section>

<section>

<h3>Электронное издание: PDF или eBook</h3>

…

<button>Купитьза $15</button>

</section>

</section>

</body>

Это не только упрощает оформление заголовков, но и выглядит лучше: меньше путаницы и не надо плыть против течения.

До того, как в наше распоряжение попали теги section и article, мы могли использовать для описания глубокой иерархии сайта только теги от h1 до h6. Теперь мы вольны описывать безграничные уровни глубины и можем точно представлять каждый уровень контента.

Если после всего этого вы все еще сомневаетесь, какой элемент применить, проштудируйте классную блок-схему по элементам разметки блоков в HTML5[33]33
  smashed.by/h5doc.


[Закрыть]. Разработчики – Оли Студхолм и Петр Петрус. Распечатайте ее, приколите на стену, и вы всегда будете знать, какой элемент использовать.

Как обычно, вы захотите провести валидацию кода HTML, чтобы он был без ошибок.

Я предпочитаю это делать через Validator.nu[34]34
  smashed.by/vldnu.


[Закрыть].

Работа со стандартом WAI-ARIA с самых азов

Роли стандарта доступности активных интернет-приложений WAI-ARIA (сокр. от Web Accessibility Initiative: Accessible Rich Internet Applications) всегда входили в состав современной технологии HTML. У многих разработчиков темнеет в глазах при одном только упоминании о них. Роли созданы для того, чтобы сделать сайты и приложения более доступными для пользователей с ограниченными физическими возможностями, которые полагаются на программы, читающие вслух текст с экрана. Разработчики, посвятившие себя этому благородному делу (на самом деле их не так уж и много!) постоянно говорят о важности WAI-ARIA, но профессиональное сообщество в целом их как будто не замечает.

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

Для слепых и людей с пониженным зрением WAI-ARIA роли описывают контекст и цель информации, лежащей за ним. Разделы страницы отличаются не только визуально, но и по контексту. А программа, читающая с экрана, может объяснять эту разницу пользователям и позволяет им без проблем взаимодействовать с разделами.

Я ни в коем случае не позиционирую себя как эксперта по стандартам доступности. Но очень постараюсь внятно и серьезно объяснить вам, почему важность стандарта WAI-ARIA не ограничивается только вопросами доступности. Если вы когда-нибудь пользовались блочными элементами, которые описаны в этом разделе, то, скорее всего, встречались с чем-то вроде этого:

<body>

<header>

<h1>Тракторы: Интерактивное руководство</h1>

</header>

<article>

<header>

<h2>Обслуживание тракторов</h2>

</header>

</article>

</body>

Заметили? У документа два тега header, и оба использованы правильно. Вся проблема в CSS:

hheader {

margin: 0 2em;

}

Этот селектор элемента описывает оба тега header. Мы могли бы использовать селектор наследования (т. е. body > header), но это кажется немного тяжеловесным, не говоря уже о том, что верхний заголовок может стать «шапкой» целого сайта. Здесь мы можем выгодно использовать роль WAI-ARIA, просто добавив role=”banner” в HTML:

<body>

<header role=”banner”>

<h1>Тракторы: Интерактивное руководство</h1>

</header>

<article>

<header>

<h2>Обслуживание тракторов</h2>

</header>

</article>

</body>

Этот ролевой атрибут говорит о том, что элемент <header role=”banner”> – «глобальный» и его содержимое лучше применять ко всему сайту, а не только к текущей странице. А благодаря простому селектору атрибутов, несложно задать стиль:

header [role=”banner”] {

margin: 0 2em;

}

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

Добавляя роль “main” к article (таким образом, получаем <article role=”main”>), мы можем легко определить, что основной контент для текущего документа расположен внутри article. (В примерах выше вы могли заметить, что тег h1 используется в верхнем заголовке (корневом), а h2 – во вложенном.) В сочетании они в лучшем виде описывают иерархию документа).

Вы, вероятно, уже отметили изящество этого подхода. Описание контента становится более детальным, и мы можем применять стили к нашим новым тегам, не особо напрягаясь. Третья из ролей ARIA – это contentinfo, которая часто применяется для конфиденциальных заявлений, уведомления об авторских правах и общей информации о текущей странице сайта. (Некоторые называют это «метаинформацией»).

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

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

Хранилище на стороне клиента

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

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

• Данные, которые вы сохраняете, имеют лимит в 4 kB.

• Все куки ограничены во времени.

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

С localStorage и sessionStorage, у нас есть два JavaScript API для сохранения строк для браузера. SessionStorage очищается, когда заканчивается сеанс пользователя (т. е. когда «вкладка» или «браузер» закрываются), а в это время localStorage хранится, пока разработчик (через JavaScript) или пользователь (через свои браузерные настройки) не решают удалить его.

Интерфейсы API виртуально идентичны – единственная разница будет в сроках хранения. Откройте свою панель инструментов разработчика в современном браузере (имеется в виду выпуска последних трех лет).

Введите localStorage.setItem (“name”, “Ben”). В Webkit-браузерах вы увидите мое имя, сохраненное под вкладкой «Ресурсы» (для этого вам нужно будет раскрыть “Local Storage”). Вы только что сохранили свой первый элемент данных в localStorage.

А теперь давайте извлечем то, что вы сохранили, используя localStorage.getItem(“name”). Вы увидите “Ben”, четко напечатанное в консоли.

И, наконец, чтобы очистить все после себя, воспользуйтесь либо localStorage.deleteItem(“name”), чтобы удалить мое имя, либо localStorage.clear(), чтобы убрать все из localStorage. Когда пользователи вызовут localStorage.clear(), они лишь очистят его для текущего домена.

Итак, если пользователь сохраняет какие-либо данные на сайте, расположенном на example.com, а потом переключают вкладки на google.com, они увидят, что у них нет доступа к данным, сохраненным ими на вкладке example.com.

Интерфейс localStorage – чрезвычайно полезная штука. Допустим, вы создаете Twitter-клиент и хотите, чтобы он мог делать следующее:

• Использоваться в вашем интернет-браузере для настольных компьютеров и на мобильном устройстве.

• Отображать в режиме онлайн сообщения с вашего последнего сеанса.

• В режиме офлайн ставить сообщения в очередь и отправлять их позже.

Рисунок 3.6. Инспектор хранилища в браузере Safari

С localStorage все это возможно. Пример ниже наглядно демонстрирует это. (Он чисто гипотетический, поэтому не обращайте внимание на мелочи.)

postTweet = function(tweetText) {

// Проверяем, в онлайне ли мы

if(navigator.onLine) {

// Привет, мы – онлайн! Отправь это сообщение, крошка!

} else {

// Хм, мы сейчас не в Сети. Лучше сохраните это для другого случая.

localStorage.setItem(“queue-” + +new Date(), tweetText)}

}

Несложно, правда? Чтобы увидеть все эти элементы в localStorage, мы должны повторить код и создать массив:

for (item in localStorage) { console.debug(item) }

Это выведет список всех ключей элементов, которые вы сохранили. Вы хотите вывести на экран твит, поставленный в очередь? Посмотрите, как это можно сделать:

for (item in localStorage) { console.debug(localStorage[item]) }

API localStorage и sessionStorage можно найти во всех современных браузерах (включая версию IE 8+). Итак, нет ни одной причины, мешающей вам создавать свои собственные приложения или просто начать экспериментировать с этим в клиентских приложениях.

В заключение

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

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

Не существует «режима HTML5», так что смело ныряйте!

Это всего лишь апробация платформы, которую мы называем HTML5. Мы могли бы говорить о ней еще несколько дней, но лучше дадим вам несколько полезных ссылок:

• HTML5 Please, html5please.us Хотите знать, когда вам пора «латать» старые браузеры? Или определять, когда суперновые теги не совсем готовы к прайм-тайму? Этот сайт даст вам основу для того, чтобы подняться на ступеньку выше.

• HTML5: Техническая спецификация для веб-разработчиков, smashed.by/whatwg Это руководство – сокращенная версия полной спецификации HTML5. Из нее убраны все те бестолковые детали, которые нужны поставщикам браузеров для их создания. В ней есть поиск, она работает на мобильных устройствах (даже офлайн) и, к слову, была создана вашим покорным слугой.

• HTML5 Rocks, html5rocks.com Этот сайт поддерживается сотрудниками Google, почти каждая статья не просто познавательная, но и увлекательная.

• HTML5 Doctor, html5doctor.com Помимо того, что сайт создан компанией классных парней, HTML5 Doctor проник на такую глубину, на которую осмелится не каждый. Прекрасный источник знаний!

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

Очень советую примкнуть к ним на Twitter или Google+, подписаться на их блоги, да просто купить им пива. Ничто не даст вам больше знаний и опыта в вебе, чем помощь в создании крепкого онлайн-сообщества. Засим я вас оставлю, а вы начинайте переделывать свой сайт. Желаю удачи!

Об авторе

* * *

Бен Шварц вкладывает свою любовь к хорошей еде (дома) и саке (в барах), разрабатывая сложные веб-приложения на технологиях, основанных на стандартах. Больше всего на свете им движет маниакальное желание производить не только элегантный код, но и красивое программное обеспечение для своих пользователей. Он также член комитета Руби (Австралия) и присоединился к рабочей группе W3C CSS (World Wide Web Consortium) в качестве «приглашенного эксперта» в декабре 2011 года.