Заметки за 2013 год (страница 6)

Повседневные задачи для команды OpenSSL

Мне порой бывает нужно закодировать содержимое файла в base64 или наоборот раскодировать. В этом случае выручает команда openssl. Она, скорее всего, уже установлена в большинстве ОС. И 100% есть в Windows, если вы пользуетесь Git.

Содержимое файла кодируется следующей командой

openssl base64 <file.bin >file.base64

Если в выходных данных не нужны переносы строк, то их легко можно убрать

openssl base64 <file.bin | tr -d '\n' >file.base64

Декодируется файл аналогично с дополнительным ключом -d

openssl base64 -d <file.base64 >file.bin

Вообще, команда openssl – это многофункциональный комбайн. Он может создавать ключи и сертификаты для подписи и шифрования, вычислять контрольные суммы (message digests), шифровать и расшифровывать данные, проверять подпись, тестировать SSL/TLS клиенты и серверы.

Так, например, можно подсчитать md5-сумму файла

openssl md5 <file.bin

или строки текста

echo "Hello" | openssl md5
Оставте свой комментарий

Вложенные объекты 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