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

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

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

itemscope

Группа свойств ключ-значение.

itemtype

Тип объекта. Фактически это ссылка на страницу с описанием в свободной форме всех названий ключей, которые применимы к описываемому объекту. Этот атрибут неприменим к элементам без атрибута itemscope.

itemprop

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

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

Несколько свойств у одного элемента

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

<p itemscope itemtype="http://schema.org/Person">
  Автор:
  <a itemprop="name url" href="http://noteskeeper.ru/about/">
    Владимир Кузнецов
  </a>
</p>

Ссылка на свойства

Иногда так получает, что данные, относящиеся к размечаемому объекту, находятся за пределами «корневого» элемента. Специально для этого случая предусмотрен атрибут itemref . Он применяется к элементу с itemscope и содержит id другого DOM-элемента, где находятся остальные свойства. Можно указать через пробел идентификаторы нескольких элементов.

Например, из-за особенностей оформления страницы, автор и комментарии к статье физически не могут находиться внутри <article>.


<div itemscope itemtype="http://schema.org/Person" itemprop="author" id="author">
  <a itemprop="name url" href="http://noteskeeper.ru/about/">
    Владимир Кузнецов
  </a>
</div>

<article itemscope itemtype="http://schema.org/Article" itemref="author comments">
  <header>
    <h2 itemprop="name">Особенности микроразметки microdata</h2>
    <link itemprop="url" href="http://noteskeeper.ru/758/">
  </header>
  <div itemprop="articleBody">
    ... статья ...
  </div>
</article>

<section id="comments">
  <div itemprop="comment" itemscope itemtype="http://schema.org/UserComments">
    <div itemprop="name commentText">
      ... комментарий 1 ...
    </div>
  </div>
  <div itemprop="comment" itemscope itemtype="http://schema.org/UserComments">
    <div itemprop="name commentText">
      ... комментарий 2 ...
    </div>
  </div>
</section>

Тем не менее, в результате получилась отлично структурированная разметка. Автор статьи и комментарии примешались в основной поток свойств статьи так как, если бы они были фактически размещены там.


article
  itemType = http://schema.org/Article
  author
    person
      itemType = http://schema.org/Person
      name
        href = http://noteskeeper.ru/about/
        text = Владимир Кузнецов
      url
        href = http://noteskeeper.ru/about/
        text = Владимир Кузнецов
  comment
    usercomments
      itemType = http://schema.org/UserComments
      name = ... комментарий 1 ...
      commenttext = ... комментарий 1 ...
  comment
    usercomments
      itemType = http://schema.org/UserComments
      name = ... комментарий 2 ...
      commenttext = ... комментарий 2 ...
  name = Особенности микроразметки microdata
  url = http://noteskeeper.ru/758/
  articlebody = ... статья ...

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

Примешивать свойства с помощью itemref можно даже для элементов, которые не имеют содержимого. Например,


<article itemscope itemtype="http://schema.org/Article">
  <meta itemprop="aggregateRating" itemref="rating" itemscope
      itemtype="http://schema.org/AggregateRating">
</article>
<meta itemprop="ratingValue" content="5" id="rating">

Объект AggregateRating требует обязательного наличия свойства ratingValue, но его нельзя передать в атрибуте content. Зато можно указать ссылку на другой элемент с нужными атрибутами.

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

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

Равномерное выравнивание блоков по ширине

Подсказали шикарную статью про «равномерное выравнивание блоков по ширине». Решение работает с произвольным количеством блоков различных габаритов даже в самых старых, но всё ещё популярных, браузерах.

За базу берётся обычный список, построенный на элементах ul и li. Всем элементам списка назначается display: inline-block, а сам список получает стиль text-align: justify . А дальше идут мелочи и тонкости, которые в итоге и заставляют все блоки равномерно разместиться в контейнере, даже если они сами имеют разную ширину.

Равномерное выравнивание блоков по ширине

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

Профилирование CSS и неиспользуемые селекторы

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

А что произойдет, если браузер никогда не встретит элемент с нужными характеристиками во время такого обхода? Чтобы ответить на этот вопрос я решил сделать несколько замеров скорости отрисовки достаточно сложной страницы (около 2500 элементов и глубиной 20 уровней). Страница содержала реальные и вполне типичные для проекта данные — таблица на сотню строк, свёрстанная блочными элементами.

Для создания нагрузки я применил модифицированный скрипт, который постоянно прокручивает окно, заставляя браузер перерисовывать всё содержимое окна. А замеры делал с помощью профайлера Opera Dragonfly.

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

Сначала я сделал замер с подключенными стилями темы.

Эксперимент с подключенными стилями темы jQuery UI

А затем повторил эксперимент без подключения этих стилей.

Эксперимент без стилей jQuery UI

По рейтингу затраченного времени на пересчёт стилей видно, что самыми «тяжёлыми» оказались каскады, для которых никогда не находятся подходящие элементы. На странице множество элементов span (1123, если быть точнее), но, ни один не имеет предка с классом ui-datepicker-next или ui-datepicker-prev.

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

Отсюда напрашивается ещё один вывод: объединение разношерстных стилей в один файл с большой вероятностью ухудшит производительность стадий reflow и repaint. Деградация будет не так заметна, если в стилях гарантировано не применяются каскады с селекторами по тегу.

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

Подсветка области клика на iOS

Когда пользователь прикасается к ссылке или элементу, для которого указан обработчик клика, то Safari на iOS подсвечивает этот элемент.

Цвет этой подсветки задается с помощью CSS свойства -webkit-tap-highlight-color.

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

Предположим, что нас интересует только клик по элементу с классом item__add.


$(".list").on("click", ".item__add", function () { … });

Но подсветка будет активироваться у элемента с классом list , так как именно на него повешен обработчик события. Исправим это CSS свойством в селекторе .list.


.list {
    -webkit-tap-highlight-color: rgba(0, 0, 0, 0);
}
Комментарии к заметке: 3

Вертикальные метрики у веб-шрифтов

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

У Font Squirrel есть решение этой проблемы.

Исправление вертикальных метрик шрифта с помощью Font Squirrel

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

Отображение в OS X

Safari 5.1

PT Sans в Safari 5.1 (OS X)

Firefox 13

PT Sans в Firefox 13 (OS X)

Chrome 19

PT Sans в Chrome 19 (OS X)

Opera 12

PT Sans в Opera 12 (OS X)

Отображение в Windows

Interner Explorer 9

PT Sans в Internet Explorer 9 (Windows)

Firefox 13

PT Sans в Firefox 13 (Windows)

Chrome 19

PT Sans в Chrome 19 (Windows)

Opera 12

PT Sans в Opera 12 (Windows)

Интересное наблюдение

Любопытно, но рендеринг текста в Windows версиях Opera, Firefox, Chrome оказывается поразительно идентичен между собой вплоть до межбуквенных и межстроковых интервалов. Увы, но такого же постоянства нет в OS X браузерах.

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