Заметки в категории «Вёрстка» (страница 5)

Вложенные объекты microdata

Связывание нескольких вложенных в друг друга объектов microdata происходит через атрибут itemprop.


<article itemscope itemtype="http://schema.org/CreativeWork">
  <aside itemprop="author" itemscope itemtype="http://schema.org/Person">
    <link itemprop="url" href="http://noteskeeper.ru/about/">
    <span itemprop="name">Владимир Кузнецов</span>
  </aside>
  <link itemprop="url" href="http://noteskeeper.ru/811/">
  <h1 itemprop="name">Вложенные объекты microdata</h1>
</article>

Получаем такую структуру:


creativework
  itemType = http://schema.org/CreativeWork
  author
    person
      itemType = http://schema.org/Person
      url = http://noteskeeper.ru/about/
      name = Владимир Кузнецов
  url = http://noteskeeper.ru/811/
  name = Вложенные объекты microdata

Если убрать атрибут itemprop="author", то объект CreativeWork потеряет связь с Person и тот, в свою очередь, переместится на корневой уровень в иерархии объектов, хоть, фактически, останется на том же самом месте в документе.


creativework
  itemType = http://schema.org/CreativeWork
  url = http://noteskeeper.ru/811/
  name = Вложенные объекты microdata

person
  itemType = http://schema.org/Person
  url = http://noteskeeper.ru/about/
  name = Владимир Кузнецов

Очевидно, что элементы, которые будут находиться внутри Person для объекта CreativeWork будут не доступны.

Комментарии к заметке: 2

Обратные связи в микроразметке microdata

Экспериментируя с микроразметкой и отслеживая реакцию поисковиков на это, я пришел к печальному выводу, что Google не очень-то любит так называемые обратные связи. Если, например, вы размечаете AggregateRating, то он должен быть частью структуры CreativeWork.

Хорошая разметка:


<div itemscope itemtype="http://schema.org/CreativeWork">
  <link itemprop="url" href="http://noteskeeper.ru/807/">
  <meta itemprop="name" content="Обратные связи в микроразметке microdata">
  <span itemprop="aggregateRating" itemscope
      itemtype="http://schema.org/AggregateRating">
    Оценка читателей <span itemprop="ratingValue">4</span> на основе
    <span itemprop="reviewCount">1</span> комментария
  </span>
</div>

Не совсем хорошая разметка:


<div itemscope itemtype="http://schema.org/AggregateRating">
  <span itemprop="itemReviewed" itemscope
      itemtype="http://schema.org/CreativeWork">
    <link itemprop="url" href="http://noteskeeper.ru/807/">
    <meta itemprop="name" content="Обратные связи в микроразметке microdata">
  </span>
  Оценка читателей <span itemprop="ratingValue">4</span> на основе
  <span itemprop="reviewCount">1</span> комментария
</div>

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

Есть подозрение, что по тем же причинам Google игнорирует объекты, соединённые через itemref . Хоть валидаторы и формируют правильную структуру, но поисковик эту связь почему-то не учитывает. Хочется верить в то, что это временное явление.

Оставте свой комментарий

Эксперимент: Доступность vs. Поисковая оптимизация

Дано: Макет облака тегов

Макет облака тегов

Задача: Сверстать его. Помимо визуального отображения обеспечить доступность виджета для скринридеров. Скрыть от поисковых роботов.

Очевидное решение

Изначально виджет был свёрстан примерно так:


<section class="widget tags-cloud">
  <h4 class="widget__title">Облако тегов</h4>
  <ul class="tags-cloud__list">
    <li class="tags-cloud__item tag-item tag-item_rank_9">
      <a class="tag-item__link" href="http://noteskeeper.ru/tag/jquery/">
        jquery
      </a>
    </li>
    <li class="tags-cloud__item tag-item tag-item_rank_8">
      <a class="tag-item__link" href="http://noteskeeper.ru/tag/css/">
        css
      </a>
    </li>
    <li class="tags-cloud__item tag-item tag-item_rank_2 tag-item_position_last">
      <a class="tag-item__link" href="http://noteskeeper.ru/tag/html5/">
        html5
      </a>
    </li>
  </ul>
</section>

Облако тегов — это, очевидно, список. Пункты списка выводятся как строчные элементы, а разделители (запятые) после каждого тега расставляются через CSS-свойство content.

В таком виде виджет просуществовал достаточное количество времени. Сайт индексировался поисковыми роботами. И я заметил, что поисковики активнее выдают страницы-концентраторы статей (архивы), на которые ведут ссылки из облака тегов, чем сами страницы со статьями. По этому таки страницы я закрыл от индексации <meta name="robots" content="noindex, follow">, а самим ссылкам добавил атрибут rel="nofollow".

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

Сниппет, никак не относящийся к содержанию статьи

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

Улучшения

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


<section class="widget tags-cloud" role="navigation">

Ранее заголовок блока был скрыт с помощью display: none . Но это так же делало его невидимым и для вспомогательных технологий. Чтобы его скрыть только при отображении на экране применим класс visuallyhidden.


<h4 class="widget__title visuallyhidden">Облако тегов</h4>

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

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


<section class="widget tags-cloud" role="navigation">
  <h4 class="widget__title visuallyhidden">Облако тегов</h4>

  <span class="tags-cloud__item tag-item tag-item_rank_9"><a
    class="tag-item__link" rel="nofollow"
    href="http://noteskeeper.ru/tag/jquery/"
    title="Заметки с тегом &laquo;jquery&raquo;"><span
    data-name="jquery" class="tag-item__title"></span></a></span>

  <span class="tags-cloud__item tag-item tag-item_rank_8"><a
    class="tag-item__link" rel="nofollow"
    href="http://noteskeeper.ru/tag/css/"
    title="Заметки с тегом &laquo;css&raquo;"><span
    data-name="css" class="tag-item__title"></span></a></span>

  <span class="tags-cloud__item tag-item tag-item_rank_2 tag-item_position_last"><a
    class="tag-item__link" rel="nofollow"
    href="http://noteskeeper.ru/tag/html5/"
    title="Заметки с тегом &laquo;html5&raquo;"><span
    data-name="html5" class="tag-item__title"></span></a></span>

</section>

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

Ключевые стили виджета:


.tag-item {
  /* чтобы запятая не отделялась от названия тега */
  white-space: nowrap;
}
.tag-item:after {
  /* запятая после каждого названия */
  content: "\2c";
}
.tag-item_position_last:after {
  /* у последнего тега нет запятой */
  content: "";
}
.tag-item__link {
  /* без этого ссылка не кликабельна */
  display: inline-block;
}
.tag-item__title:after {
  /* выводит содержимое атрибута на экран */
  content: attr(data-name);
}

Так как у элементов списка нет текста, то и от самого списка пришлось избавиться.

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

Так же не понятно пока как к этим изменениям отнесутся поисковики. Буду ждать обновление индекса.

Комментарии к заметке: 12

Дефект в IE при большом количестве начертаний в @font-face

В статье « Setting Weights And Styles With The @font-face Declaration» рассматривается любопытный случай, возникающий в IE7 и IE8 при объединении различных начертаний шрифта. Если количество начертаний для одной гарнитуры будет больше четырёх, то браузер будет не корректно их использовать.

Так же упоминается тот факт, что это вызывает падение браузера на iPad 1. Но в комментариях указывают на то, что дефект, приводящий к падению браузера, был исправлен более двух лет назад. У меня он не воспроизвёлся.

Комментарии к заметке: 2

White-space, word-wrap и их друзья

Для разного контента нужны разные правила форматирования: фрагменты кода должны сохранять все переносы строк и табуляцию; текст, написанный случайным посетителем сайта, не должен «порвать» вёрстку и т.п. Форматирование можно контролировать с помощью CSS.

Свойство white-space

CSS свойство white-space описывает то, как будут обрабатываться пробельные символы внутри элемента.

 Новая строкаПробелы и табуляцияПеренос текста
normalсхлопываетсясхлопываютсяесть
nowrapсхлопываетсясхлопываютсянет
preостаётсяостаютсянет
pre-wrapостаётсяостаютсяесть
pre-lineостаётсясхлопываютсяесть

Значения pre-wrap и pre-line доступны во всех современных версиях браузеров и в IE начиная с версии 8.0.

Подробнее o white-space на w3.org

Свойство word-wrap

Изначально это свойство появилось в линейке браузеров IE и только потом перекочевало в другие браузеры, так и не появившись в спецификации CSS2. В CSS3 аналогичное поведение закреплено за свойством overflow-wrap, а word-wrap останется в качестве псевдонима.

Это свойство может принимать значения:

normal

Переносы строк будут формироваться только в дозволенных позициях.

break-word

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

Это свойство можно использовать для переноса строк в теге <pre> даже в старых версиях IE:

pre {
  word-wrap: break-word; /* IE 5.5-7 */
  white-space: pre-wrap; /* current browsers */
}

Подробнее o word-wrap (overflow-wrap) на w3.org

Свойство word-break

Когда нужно применить «грубую силу» и переносить любую строку в любом месте (я даже не представляю себе где это может потребоваться), то в дело вступает word-break.

.text_user-generated_yes {
  word-break: break-all;
}

Это свойство имеет больший приоритет, чем word-wrap (overflow-wrap) и будет разрывать слова даже там, где это особо и не требуется.

В браузерах на Webkit это свойство имеет ещё одно нестандартное значениеbreak-word, которое по своему действию аналогично word-wrap .

Подробнее o word-break на w3.org

Свойство hyphens

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


.text {
  -webkit-hyphens: auto;
  -moz-hyphens: auto;
  hyphens: auto;
}

Основным препятствием на пути внедрения этой технологии стоит то, что браузеру требуется описание правил переноса слов для различных языков. На сегодняшний день только Safari и Firefox могут похвастаться этим.

Подробнее o hyphens на w3.org

Комментарии к заметке: 3