Вы всё ещё используете изображение в качестве логотипа сайта? Я, в общем-то, тоже.

Перевод статьи:  Your logo is still an image… and so is mine!
Автор:  Harry Roberts.

Около двух лет назад я написал статью на тему семантики изображений, в которой рассматриваются подходящие варианты разметки для логотипа вашего сайта. Если коротко, то в ней утверждается, что логотипы веб-ресурсов по сути своей являются контентом и по этой причине для их включения в разметку необходимо использовать элементы изображения <img>, а не элементы заголовки высшего уровня <h1>, как это зачастую делается.

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

  1. Это позволяет вам использовать спрайты для оформления логотипа.
  2. Ошибочное мнение, что логотип можно отнести к категории заголовков.

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

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

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

Изображение.

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

Итак, как я уже писал ранее, не следует использовать заголовки <h1> для оформления логотипов, а вместо этого необходимо применять элементы изображения <img>. Вот соответствующий фрагмент разметки, который я использую на данный момент (январь 2013 года) на своем сайте "CSS Wizardry":

<a href="/" class="site-logo">
<img src="/img/dot.gif" alt="CSS Wizardry" class="s s—csswizardry-logo">
</a>

Вы, вероятно, заметили, что атрибут src используемого мной элемента изображения не указывает на файл логотипа (что-то вроде logo.png), как в принципе должно быть. Вместо этого мы ссылаемся на файл dot.gif, который, как вы вероятно догадались, является прозрачным gif изображением размером 1×1 пиксель (*dot — точка).

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

Кошмар, и что дальше?

Вот что здесь происходит. Первоначально я привязываю элемент изображение к мелкому, полностью прозрачному gif файлу, далее средствами CSS применяю нужный мне SVG спрайт в качестве фона элемента. Использование в данном случае элемента <img> является правильным решением с точки зрения семантики. Далее я применил хитрость, определив с помощью CSS требуемую картинку, которую, собственно, и видит пользователь. Вот соответствующий (S)CSS код:

.s{
background-image:url(/img/css/sprites/main.svg);
}
.s—csswizardry-logo{
width:64px;
height:64px;
background-position:-5px -5px;
@include vendor(background-size, 250px 250px);

@include media-query(desk){
@include vendor(background-size, 500px 500px);
width:128px;
height:128px;
background-position:-10px -10px;
}
}

Самый важный момент здесь – это определение объекта спрайта при помощи класса .s. Далее применяем к элементу еще один класс, который содержит дополнительные свойства форматирования.

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

Перед тем, как я объясню логику своих действий, нам необходимо отвлечься и установить соответствующий контекст.

Люди и машины.

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

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

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

Семантику оставим для машин.

Теперь, мы уже начинаем понимать, что элементы изображения <img> важны лишь для машин. Если смотреть с точки зрения пользователя, то ему, собственно, все равно, какой элемент мы используем для дизайна – изображение, объект Flash, блочный элемент <div> с фоновым изображением или что-либо другое. Элемент изображение необходим только для машин (поисковых роботов, читалок и т.д.). Вот, в сущности, зачем нам нужна семантика.

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

То есть, с семантической точки зрения, корректным способом реализации изображения является соответствующий ему элемент разметки <img> с определенными пояснениями к нему в атрибуте alt, что и требуют от нас машины. При этом они совершенно не обращают внимания на то, какое пиксельное содержание у этого изображения (что нас, как Front-end разработчиков и интересует в данном случае). Если у вас имеется элемент <img>, в котором в качестве источника указан пустой gif файл, а альтернативный текст содержит строку "CSS Wizardry", то все программы будут рассматривать это как полноценное изображение с пояснениями, не обращая при этом никакого внимания на содержание файла изображения.

А изображения для людей.

Но для реальных пользователей ситуация прямо противоположная — пиксельное содержание изображения имеет немаловажное значение, в то время как код – нет. Принимая все это во внимание, можно сказать, что то, как мы будем применять стили к обязательному для машин элементу <img>, не имеет никакого значения для пользователей (поэтому мы просто используем CSS).

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

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

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

И какой в этом смысл?

Нам пришлось рассмотреть некоторые сопутствующие вопросы, но вот мы уже подошли к сути дела. Зачем же все это нужно?

Если говорить коротко, то всему виной является производительность.

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

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

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

Если с точки зрения семантики логотип должен быть реализован элементом <img> и вам нужно оформить его с помощью спрайта, то самым лучшим вариантом в этом случае будет применение изображения, которое будет полностью прозрачным. Используя для этих целей однопиксельную 1×1 px прозрачную gif картинку, вы сможете удовлетворить требуемым условиям.

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

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

Вы, конечно же, можете предложить другой вариант, в котором атрибут src указывает на несуществующий файл изображения, что приведет к ошибке 404, после чего не потребуется отправка каких-либо данных с серверной стороны и как следствие, это снизит нагрузку на сетевое соединение. Но здесь мы имеем следующую проблему: поскольку браузер не получает ничего для загрузки, то и кэшировать ему, собственно, нечего. Это значит, что если у вас имеется спрайт с пятью изображениями, используемыми на загружаемой странице, то в данном случае это приведет к пяти дополнительным HTTP запросам, возвращающим ошибку 404, и как результат в кэше браузера будет отсутствовать информация, которую мы могли бы использовать повторно. Изначальные затраты, связанные с единственным HTTP запросом для загрузки файла dot.gif будут с лихвой окуплены по той причине, что его можно поместить в кэш на неопределенный срок и использовать при необходимости в любое время. И это без учета того, что все наши действия в данном случае связаны с последующим использованием спрайтов, которые как раз и созданы для того, чтобы сократить количество запросов к серверу.

Здесь очень важно помнить, что использование технологии спрайтов не всегда необходимо и/или возможно. Я не настаиваю на использовании этого способа в любом случае, тем более, что это зачастую просто невозможно (к примеру, при использовании «резиновых» изображений). Это просто еще один эффективный инструмент из набора профессионального веб-разработчика.

Итак, что мы имеем? Применение спрайтов к элементам изображениям позволяет вам придерживаться рамок семантически корректного документа, а также расширяет возможности по использованию спрайтов. Машины видят элемент <img> с описанием "CSS Wizardry" (отлично!), а пользователь видит на экране мой логотип (чудесно!). Все счастливы и всё корректно.

Как многие советуют, вы можете применить Base64 кодирование данных (если вам позволяют условия) вместо предложенного мной gif изображения, что позволит избежать дополнительного HTTP запроса. Изображение в этом случае не кэшируется (что и не требуется), но, так сказать, «зиппируется» :).

* Примечание переводчика.

Обзор комментариев

Как и ожидалось, первыми ласточками были предложения по использованию технологии Data URI, т.е. включению данных однопиксельного изображения непосредственно в разметку, что исключает необходимость выполнения связанных с ним запросов и загрузок. Здесь какие-либо возражения просто бессмысленны.

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

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

Что касается отношения Google к авторским приемам, предусматривающим скрытие текста, то они на самом деле отмечаются данной поисковой системой как негативные. Казалось бы все должно быть наоборот, поскольку наличие заголовка страницы как раз таки является положительным моментом с точки зрения семантики. Да, все верно, но только текст прятать нельзя. Если без включения текста не обойтись, то лучше поместить его в атрибут alt. Сайты, использующие сдвиг текста в невидимую область, Google ассоциирует с ресурсами, которые скрывают свои реальные намерения, пытаясь ввести пользователя в заблуждение, тем более, если дело касается заголовка высшего уровня. На YouTube есть специальный канал Google, предназначенный для веб-разработчиков, на котором содержится видео (точного URI так и не удалось отыскать, но есть схожее по тематике видео), в котором говорится о изображениях внутри h1 заголовков, а точнее, выражается отношение Google к методам, скрывающим текстовую информацию. К тому же в большинстве случаев этого можно избежать, а экранные дикторы все равно смогут озвучить содержимое атрибута alt. Один из разработчиков предлагает свой способ решения проблемы, который предусматривает использование вот такой структуры: a > h1 > img для главных страниц, а для остальных, «рабочих» страниц: a > img. Ссылка ведет пользователя на главную страницу сайта. В последнем случае заголовок первого уровня используется по назначению — содержит название, отображающее контент текущей страницы.

Следует учитывать и то, что видео, о котором идет речь в комментариях к данному посту, было опубликовано в 2009 году, и вероятно Google уже успел изменить свое мнение к таким приемам в веб-разработке. На эту мысль подталкивает то, что участники дискуссии так и не смогли отыскать ссылку на соответствующее видео — возможно, оно было удалено. Точных данных на этот счет нет. Кстати, трудно не признать несколько странным и тот факт, что автор, делая в своей статье акцент на семантику, заканчивает использованием бессмысленного gif изображения. Хотя, все, конечно же, зависит от ситуации.

Однако вопросы к использованию спрайтов в случае с логотипом сайта/компании все еще остаются. С производительностью здесь все более и менее в порядке, но как насчет индексирования службой Google Images, которая может выбрать как мизерный gif, так и спрайт, что, ни в том, ни в другом случае не будет в вашу пользу. Или в худшем случае ваш логотип будет просто проигнорирован. Идем дальше — печать страницы. Здесь ситуация тоже не из лучших, хотя отчасти ее может спасти отдельный вариант страницы для печати. И, в конце концов, что если пользователь захочет просто загрузить ваш логотип через контекстное меню путем правого клика мышью. Неувязочка получается. В общем вопросы все-таки остаются. Возможно у вас есть свои варианты их решения.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *