Заметки за май 2012 года

Шаблонирование на JavaScript

Динамическое создание и обновление блоков страницы с давних пор принято делать через свойство DOM-элемента innerHTML. Если речь идет о куске HTML, пришедшего с сервера в асинхронном запросе, то другого адекватного варианта просто нет. С другой стороны, когда с сервера получаем только данные, а разметку создаем скриптом на JS, то тут уже появляются варианты.

Различные реализации JS-движка имеют свои сильные и слабые стороны. Долгое время создание DOM-элементов через document.createElement было очень дорогой по времени операцией. Не самый лучший дизайн API требовал многословности при создании увесистой структуры из элементов с атрибутами.

var container = document.createElement("div");
var link = document.createElement("a");
link.setAttribute("href", "http://yandex.ru/");
link.setAttribute("title","Яндекс");
link.appendChild(document.createTextNode("Поиск"));
container.appendChild(link);

Этот фрагмент фактически соответствует:

<div><a href="http://yandex.ru/" title="Яндекс">Поиск</a></div>

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

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

HTML – всегда был и остается результатом сериализации древовидной структуры документа в текстовый формат, который может легко восприниматься и редактироваться человеком. Браузер, получая его на вход из файла или через поле innerHTML, разбирает его, превращая в DOM-дерево, прежде чем примется его отображать.

Современные браузеры достаточно быстро выполняют JavaScript, чтобы дать сборке фрагментов DOM-дерева через соответствующие методы API, ещё один шанс.

Синтаксический сахар

Neil Jenkins сделал «сахарок» для создания отдельных элементов и целых иерархий – Sugared DOM. Однако его код не работает в IE из-за отличной от других движков реализации метода split() у строк. Я переделал работу в этой части кода и добавил unit-тесты.

el("div");

Элементы можно создавать с установленными атрибутами id и class, используя знакомый CSS синтаксис

el("div#id.class1.class2");

Элементу можно установить другие атрибуты. Например,

el("div#id", { tabindex: -1, title: "Контейнер" });

Дочерние элементы передаются в массиве последним аргументом

var container = el("div", [
    el("a", {"href": "http://yandex.ru/", "title": "Яндекс"}, [
        "Поиск"
    ])
]);

Производительность

Тесты показывают превосходство DOM версии во всех браузерах кроме Оперы, где разница в скорости почти не заметна и Интернет Эксплорера, который всё же быстрее работает с полем innerHTML.

Ноутбуки и настольные компьютеры в настоящее время настолько мощные, что разница в скорости создания фрагментов не так уж и важна. С другой стороны, на мобильниках и планшетах – это может быть критичным. Тесты показали, что DOM версия быстрее от 45 до 100% в WebKit браузерах (браузеры в iOS устройствах и браузер по-умолчанию в Android устройствах), и примерно одинакова с innerHTML версией в Opera Mobile.

Заключение

Sugared DOM метод имеет ряд преимуществ перед шаблонизаторами:

  • Прост в отладке (описание шаблона – это и есть исполняемый код).
  • Не нужно дополнительно искать элементы после создания фрагмента – все ссылки на готовые элементы можно получить в процессе построения дерева.
  • Не нужно беспокоиться об экранировании данных. Нулевая вероятность XSS. Текстовая стока явно преобразуется в текстовый узел DOM-дерева.
  • Нет пустых текстовых узлов из-за пробелов между тегами.
  • Среда разработки помогает отслеживать ошибки в таком шаблоне, так как он является обычным JS-скриптом.
  • Гибкость шаблонирования обеспечивается полным доступом к объектам и функциям JS.

PS. Заметка вдохновлена статьёй Building the new AJAX mail UI part 2: Better than templates, building highly dynamic web pages

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

Вёрстка независимыми блоками

Кажется, в крупных проектах рунета «БЭМ» становится стандартом де-факто.

Если хочется попробовать и получить некоторые плюсы от разработки в стиле БЭМ, но нет возможности внедрять всю технологическую цепочку, то стоит для начала перенять именование классов. Разумеется, это будет уже не БЭМ. Тем не мене, методом проб и ошибок ребятам из Яндекса удалось выработать хорошую методику именования CSS-селекторов для абсолютно-независимых блоков.

Блок

Канонические имена блоков в БЭМ начинаются с префикса b- и отвечают на вопрос «Зачем нужен это блок?»:

.b-menu {}

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

.menu {}

Элемент

Элемент – часть блока, которая не имеет смысла вне этого блока и не может быть использована вне него.

<nav class="menu">
    <h3 class="menu__head">Menu</h3>
    <ul class="menu__list">
        <li class="menu__item">Item 1</li>
        <li class="menu__item">Item 2</li>
        <li class="menu__item">Item 3</li>
    </ul>
</nav>

Селектор элементов именуем следующим образом: .имя-блока__имя-элемента.

Модификатор

Модификатор служит для изменения внешнего вида (возможно, и поведение) блока или элемента. Селектор записывается в виде: .имя-блока_тип-модификатора_значение-модификатора или .имя-блока__имя-элемента_тип-модификатора_значение-модификатора

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

<nav class="menu menu_footer">
    <h3 class="menu__head">Menu</h3>
    <ul class="menu__list">
        <li class="menu__item">Item 1</li>
        <li class="menu__item menu__item_state_current">Item 2</li>
        <li class="menu__item">Item 3</li>
    </ul>
</nav>

Модификатор menu_footer у блока menu, например, меняет размер шрифта у меню в подвале страницы

.menu { font-size: 16px; }
.menu_footer { font-size: 12px; }

А модификатор menu__item_state_current у элемента menu__item может поменять цвет фона у текущего раздела

.menu__item { background: black; color: white; }
.menu__item_state_current { background: yellow; color: black; }

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

Дополнительные материалы

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

Конвертируем AVCHD для последующей обработки

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

Первое что пришло мне в голову – это пересобрать видео- и аудио-потоки в другой контейнер без перекодировки. Эксперимент закончился неудачей – полученные файлы (а были перепробованы и avi, и mpeg, и mov контейнеры) опять нормально воспроизводились, но либо не импортировались в редактор, либо видео оказывалось местами испорченное.

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

ffmpeg -i 00001.MTS -copyts \
    -acodec libfaac -ar 48000 -ab 256k \
    -vcodec libx264 -crf 15 -coder 0 \
    -filter:v yadif,scale=1280:720 -r 25 \
    output.mp4

Поясню параметры, которые тут использовались:

  • copyts – копирует временные метки и нужен для правильной синхронизации видео и звука;
  • cfr – задает качество при однопроходном кодировании (меньше – лучше качество);
  • coder 0 – отключаем CABAC так как не требуется оптимальный битрейт.

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

Полезная документация:

PS. Собрать свежую стабильную версию FFmpeg всегда можно с помощью Homebrew

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