Какой элемент вы используете для логотипа сайта? По-прежнему <img>? Я, в общем-то, тоже.

Перевод статьи:  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 — точка).

Последняя информация:   На данный момент я применяю прозрачное 1×1 px изображение кодированное в 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> элемент, в котором в качестве источника src указан пустой gif файл, а альтернативный текст содержит строку "CSS Wizardry", то все программы будут рассматривать это как полноценное изображение с пояснениями, не обращая при этом никакого внимания на содержание файла изображения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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