Веб-стандарты — Статьи

OKLCH в CSS: почему мы ушли от RGB и HSL

Tue, 10 Jan 2023 00:00:00 GMT

В CSS мы чаще всего пишем цвета через rgb() или hex — но так сложилось исторически. Новая спецификация CSS Color 4 позволит нам описывать цвета через новые методы. В этой статье мы расскажем, почему нам больше всего нравится oklch().

Краткое объяснение

oklch() — новый способ определять цвета в CSS. В oklch(L C H) или oklch(L C H / a) компоненты из аббревиатуры расшифровываются так:

L, lightness — яркость (0%–100%), передаётся так, как её увидит глаз, в отличие от L в hsl();
C, chroma — насыщенность, варьируется от серого до наиболее интенсивного оттенка;
H, hue — оттенок, угол поворота на цветовом круге (0–360);
a, alpha — непрозрачность (0–1 или 0%–100%).

a:hover {
    /* синий */
    background: oklch(45% 0.26 264);
    /* белый */
    color: oklch(100% 0 0);
    /* чёрный с прозрачностью 50% */
    color: oklch(0% 0 0 / 50%);
}

Формат OKLCH обладает многими преимуществами:

В отличие от rgb() или hex (#ca0000), OKLCH легко читается. По числам внутри oklch() мы без труда сможем определить записанный цвет. Это похоже на удобство формата HSL, но тот не передаёт яркость так, как её видит человек;
oklch() лучше подходит для изменения цвета, чем hsl(). Он правильно передаёт яркость — она не меняется при смене оттенка (вспомните неожиданные результаты у darken() в Sass из-за использования HSL);
Из-за предсказуемой яркости у OKLCH гораздо лучше с доступностью. Это очень важно при создании палитр для дизайн-систем;
Многие новые устройства (например, от Apple) поддерживают больше цветов, чем старые мониторы sRGB. OKLCH позволяет использовать эти P3-цвета.

Работая с OKLCH, следует помнить о важных нюансах:

Для OKLCH при подборе L, C и H есть риск получить цвет, выходящий за пределы возможностей экрана. Хоть браузеры и попытаются найти ближайший поддерживаемый цвет, нам стоит проверять результат в цветовом миксере;
OKLCH — цветовое пространство, которое появилось совсем недавно. На момент написания этой статьи в 2022 году его экосистема ограничена. Но у нас уже есть полифилы, генератор палитры, цветовой миксер и много конвертеров.

Пространство OKLCH в цветовом миксере.

Развитие цвета в CSS

CSS Colors Module 4

Немного истории: 5 июля 2022 года спецификация CSS Color Module Level 4 стала кандидатом в рекомендации W3C. В ней появляется синтаксический сахар для всех функций цвета, которым мы будем пользоваться в этой статье:

.old {
    color: rgb(51, 170, 51);
    color: rgba(51, 170, 51, 0.5);
}

.new {
    color: rgb(51 170 51);
    color: rgb(51 170 51 / 50%);
}

Но что ещё важнее, CSS Color 4 добавляет 14 новых способов для определения цвета. И это не просто синтаксический сахар. Новые форматы записи (среди которых и oklch()) улучшают читаемость кода, доступность и могут принести прямую пользу для наших сайтов.

P3 Colors

Человеческий глаз способен различить гораздо больше цветов, чем способны отобразить многие устройства. Современные мониторы в основном показывают небольшой набор цветов, который называется sRGB.

Но уже сейчас все современные устройства Apple и многие OLED-экраны поддерживают на 30% больше цветов, чем есть в sRGB. Этот расширенный набор цветов называется P3. Он также известен, как широкий цветовой охват (wide-gamut colors).

Поддержка дополнительных 30% цветов будет полезна для дизайнеров:

Новые цвета зачастую заметно насыщеннее старых. Это поможет создавать более привлекательные и красочные сайты;
Больше цветов — больше гибкости при создании палитр для дизайн-систем.

По сравнению с sRGB, в P3 гораздо больше зелёных оттенков и цвета могут быть ярче.

Итак, теперь у нас появились P3-цвета, но радоваться ещё рано: чтобы их использовать, нам нужно найти формат, который поддерживает охват P3. rgb(), hsl() или hex не поддерживают P3. Хотя мы и можем использовать новую запись color(display-p3 1 0 0), но по числам в ней непонятно, какой указан цвет.

К нашему везению, OKLCH очень легко читать и менять прямо в коде. К тому же он поддерживает не только P3, но и любые цвета, которые способен увидеть человек.

Производные цвета в CSS

CSS Color 4 — большой шаг в мире стилей, но грядущий CSS Color 5 будет ещё полезнее. В нём, наконец, появятся производные цвета — изменения цвета, встроенные прямо в CSS.

В качестве примера в следующих CSS-правилах используются hsl(). Не используйте формат hsl() в реальных проектах для трансформации цветов, это может привести к проблемам с доступностью.

:root {
    --accent: hsl(63 61% 40%);
}

.error {
    /* Красный вариант акцентного цвета */
    background: hsl(from var(--accent) 20 s l);
}

.button:hover {
    /* Вариант на 10% светлее */
    background: hsl(
        from var(--accent) h s calc(l + 10%)
    );
}

С новым синтаксисом мы можем взять один цвет — например, из кастомного свойства — и легко изменить его, переписав отдельные компоненты цвета.

Но, как мы упоминали, у hsl() есть ощутимый недостаток: этот формат может привести к проблемам с доступностью. Для него значение L зависит от оттенка, поэтому после изменения через hsl() может получиться плохой контраст текста и фона.

Здесь мы возвращаемся к старой проблеме: нам необходимо пространство, где работа с цветом даёт предсказуемый результат. И OKLCH отлично подходит для этой задачи.

:root {
    --accent: oklch(70% 0.14 113);
}

.error {
    /* Красный вариант акцентного цвета */
    background: oklch(
        from var(--accent) l c 15
    );
}

.button:hover {
    /* Вариант на 10% светлее */
    background: oklch(
        from var(--accent) calc(l + 10%) c h
    );
}

Отметим: --accent в oklch(from …) не обязательно должен быть тоже в формате OKLCH. Но для улучшения читаемости мы рекомендуем писать в едином формате.

Сравнение OKLCH с другими форматами цветов в CSS

Конечно, мы можем в разных файлах писать цвет в разных форматах. Необязательно везде использовать oklch(). Но единый подход к записи значительно улучшает читаемость и поддерживаемость кода.

Давайте попробуем выбрать единый, универсальный формат записи цвета. Наши критерии для выбора:

У него должна быть встроенная поддержка в CSS;
Он должен уметь работать как минимум с широким цветовым охватом P3;
Он должен хорошо подходить для изменения цвета. Компоненты формата должны быть удобочитаемыми и при этом не зависеть друг от друга. Например, изменение яркости должно сохранять прежний уровень контраста, а изменение насыщенности не должно менять оттенок.

OKLCH против RGB и hex

Все форматы rgb(109 162 218), #6ea3db или P3-аналог color(display-p3 0.48 0.63 0.84) записываются тремя числами, которые определяют количество красного, зелёного и голубого соответственно. Обратите внимание: 1 в color(display-p3) кодирует большее значение, чем 255 в RGB.

Какая проблема объединяет все эти форматы? Они абсолютно нечитаемы для большинства разработчиков. Люди часто просто копируют их как магический набор символов, не пытаясь их прочитать и понять.

RGB, hex и color(display-p3) неудобны для трансформаций цвета, поскольку большинству людей интуитивно сложно задавать цвета, изменяя количество красного, голубого и зелёного. Кроме того, с помощью RGB и hex нельзя определить P3-цвета.

С другой стороны, OKLCH, LCH и HSL кодирует цвет так, как люди думают о цветах — через оттенок, насыщенность, яркость.

Сравните hex и OKLCH:

.button {
    /* Голубой */
    background: #6ea3db;
}

.button:hover {
    /* Более яркий голубой */
    background: #7db3eb;
}

.button.is-delete {
    /* Красный с той же насыщенностью */
    background: #d68585;
}

.button {
    /* Голубой */
    background: oklch(70% 0.1 250);
}

.button:hover {
    /* Более яркий голубой */
    background: oklch(75% 0.1 250);
}

.button.is-delete {
    /* Красный с той же насыщенностью */
    background: oklch(70% 0.1 20);
}

OKLCH-цвета можно прочитать и сравнить. Но пространство появилось совсем недавно — его экосистема только находится в стадии активного развития.

OKLCH против HSL

Теперь сравним OKLCH и HSL. HSL использует три компонента для кодировки оттенка, насыщенности и яркости, например hsl(210 60% 64%). Главная проблема с HSL в том, что это цветовое пространство растягивается в цилиндр.

В цилиндре HSL каждый оттенок должен иметь одинаковое значение насыщенности (0%–100%). Но в реальности экран и глаз имеют разную максимальную насыщенность для разных оттенков. HSL не обращает внимания на это различие. Он деформирует цветовое пространство и растягивает цвета до одинакового показателя максимальной насыщенности.

Срез яркости и оттенка в пространствах HSL и OKLCH. На чёрно-белой версии ниже видно, что у HSL реальная яркость меняется непредсказуемо.

HSL растягивает цветовое пространство, поэтому через него нельзя менять цвет. Компонент L в нём является непредсказуемым, зависящим от оттенка. Это приводит к неприятным проблемам с контрастом и доступностью.

Вот несколько реальных примеров, где проявляются эти проблемы:

Добавление 10% яркости для зелёного или для фиолетового цвета приведут к разным результатам. Если вы когда-нибудь использовали функцию darken() в Sass, то помните, как по одной формуле нельзя было сделать одинаковый :hover-стиль для всех оттенков;
Если вы поменяете оттенок (например, чтобы из фирменного цвета сделать красный цвет ошибки), то с ним может измениться яркость, и текст на этом фоне станет нечитаемым.

Изменение оттенка в пространстве HSL может привести к проблемам доступности из-за непредсказуемого изменения контраста.

HSL плох для работы с цветом. В сообществе многие просят избегать HSL при создании палитр. Кроме того, подобно RGB или hex, формат HSL не может быть использован для определения P3-цветов.

OKLCH не искажает цветовое пространство; этот формат показывает нам реальную физику цвета. Это помогает добиться предсказуемого контраста при изменениях цвета.

С другой стороны, некоторые комбинации значений для OKLCH порождают цвета, которые обычные экраны отобразить не способны. Ряд из них можно увидеть только на P3-мониторах. Но это не критическая проблема: браузеры будут искать ближайший поддерживаемый цвет.

OKLCH против Oklab; LCH против Lab

В CSS есть две функции, связанные с Oklab: oklab() и oklch(). Аналогичные есть и для CIE LAB: lab() и lch(). Так в чём же разница?

Есть разные способы задать точку в пространстве. Oklab и LAB используют декартовые координаты с осями a и b (a — от красного до зелёного, b — от голубого до жёлтого). OKLCH и LCH используют полярные координаты, где есть угол оттенка и расстояние для насыщенности.

Декартовы координаты для Oklab и полярные координаты для OKLCH.

OKLCH, и LCH удобнее для работы с цветом, так как люди думают о цвете через насыщенность и оттенок, а не количество красного и зелёного.

OKLCH против LCH

Формат LCH построен на пространстве CIE LAB. Он решает все проблемы, которые существуют в HSL и RGB. Также он позволяет работать с P3-цветами, и в большинстве случаев изменение цвета даёт предсказуемый результат.

Однако формат LCH имеет одну неприятную проблему: неожиданный сдвиг оттенка при изменении насыщенности и яркости для голубого цвета (оттенок между 270 и 330 градусами).

Срезы пространств LCH и OKLCH, где яркость и насыщенность изменяются, а оттенок — одинаковый. Срез LCH голубой с одной стороны и фиолетовый с другой. Оттенок в OKLCH остаётся постоянным, как и ожидается.

Небольшой пример из реальной жизни:

.temperature.is-very-very-cold {
    /* Выглядит голубым */
    background: lch(35% 110 300);
}

.temperature.is-very-cold {
    /* Мы изменили только яркость,
    но голубой стал фиолетовым */
    background: lch(35% 75 300);
}

.temperature.is-cold {
    /* Глубокий фиолетовый */
    background: lch(35% 40 300);
}

.temperature.is-very-very-cold {
    /* Выглядит голубым */
    background: oklch(48% 0.27 274);
}

.temperature.is-very-cold {
    /* Всё ещё голубой */
    background: oklch(48% 0.185 274);
}

.temperature.is-cold {
    /* Всё ещё голубой */
    background: oklch(48% 0.1 274);
}

Пространства Oklab и OKLCH были созданы для решения этой проблемы со сдвигом оттенка. Но OKLCH — не просто исправление. В нём появляется много полезных возможностей, связанных с математическими преобразованиями. Например, упрощается коррекция охвата (gamut correction), поэтому CSSWG рекомендует для этого OKLCH.

Принципы работы OKLCH

Создание и развитие OKLCH

Бьёрн Оттоссон создал пространства Oklab и OKLCH в 2020 году. Главная задача была в исправлении проблемы CIE LAB и LCH. Бьёрн написал отличную статью с описанием деталей реализации. Также в ней он рассказал о причинах, побудивших его разработать эти пространства.

Стоит отметить, что Oklab появилось гораздо позже других пространств. Изначально это было его главным слабым местом. Но всего два года спустя стало понятно, что сообщество отлично приняло Oklab:

Оно было добавлено в спецификацию CSS;
Chrome, Safari и Firefox поддерживают oklch() и oklab();
В Photoshop добавили Oklab для градиентов;
OKlab стали использовать в генераторах палитр для улучшения доступности.

Неважно, что OKLCH молодой. Всё равно грядущие изменения в CSS Colors 4 и 5 потребуют сильных перемен в экосистеме разработки. Мы верим, что раз мы начинаем сначала, то лучше взять самое современное и эффективное решение.

Оси

Цвета в OKLCH записываются четырьмя числами. В CSS это выглядит как oklch(L C H) или oklch(L C H / a).

Оси OKLCH.

Объясним значение каждого компонента более детально:

L — воспринимаемая яркость. Варьируется от 0% (чёрный) до 100% (белый). Указывать % необходимо даже для нулевых значений;
C — насыщенность, интенсивность цвета. Варьируется от 0 (серый) до бесконечности. На практике у насыщенности всё же есть максимальное значение, но оно зависит от поддерживаемого цветового охвата (например, для P3 она чуть больше, чем для sRGB). Каждый оттенок имеет разную максимальную насыщенность. Но и в P3, и в sRGB значение всегда меньше 0.37.
H — оттенок, угол поворота от 0 до 360. От 0 — красный, 100 — жёлтый, 150 — зелёный, 200 — голубой, 250 — синий, 300 — фиолетовый и затем вновь идут значения красного (можно использовать поговорку «каждый охотник желает знать, где сидит фазан», где каждое слово будет добавлять ещё 50). Так как это угол, то значение 0 и значение 360 означают одинаковый оттенок. H можно записать как с единицей измерения 60deg, так и без неё 60.
a — непрозрачность (0–1 или 0%–100%).

Обратите внимание, что размеры осей неодинаковы. 1% для яркости — тот же 1%, но для насыщенности это 0.004, а для оттенка — 3.6.

Вот некоторые примеры цветов OKLCH:

.bw {
    /* Чёрный */
    color: oklch(0% 0 0);
    /* Белый */
    color: oklch(100% 0 0);
    /* Тоже белый, любой оттенок
    с 100% L будет белым */
    color: oklch(100% 0.2 100);
    /* Серый */
    color: oklch(50% 0 0);
}

.colors {
    /* Жёлтый */
    color: oklch(80% 0.12 100);
    /* Тёмно-жёлтый */
    color: oklch(60% 0.12 100);
    /* Серо-жёлтый */
    color: oklch(80% 0.05 100);
    /* Голубой, с той же
    воспринимаемой яркостью */
    color: oklch(80% 0.12 225);
}

.opacity {
    /* Прозрачный жёлтый */
    color: oklch(80% 0.12 100 / 50%);
}

Стоит помнить, что некоторые компоненты могут содержать none в значениях. Например, у белого цвета нет оттенков, и некоторые конвертеры поставят в оттенке none. Браузеры будут трактовать none как 0.

.white {
    /* так можно записывать */
    color: oklch(100% 0 none);
}

Производные цвета

В CSS Colors 5 появятся производные цвета, встроенный механизм изменения цветов. Это раскрывает один из наиболее весомых плюсов OKLCH: изменение цвета будет давать предсказуемый результат.

Синтаксис выглядит следующим образом:

:root {
    --origin: #ff000;
}

.foo {
    color: oklch(from var(--origin) l c h);
}

Начальный цвет (var(--origin) в примере выше) может являться:

Цветом в любом формате: #ff0000, rgb(255, 0, 0), или oklch(62.8% 0.25 30).
Кастомным свойством с цветом в любом формате.

Любой компонент (l, c, h) после from X может быть:

Буквой (l, c, h), которая укажет сохранить компонент таким, каким он был для начального цвета;
Выражением calc(). Вы можете использовать буквы (l, c, h) вместо числа, чтобы сослаться на значение в начальном цвете;
Новым значением, которое заменит компонент.

Это может звучать сложно, но примеры ниже должны внести ясность:

:root {
    --error: oklch(60% 0.16 30);
}

.message.is-error {
    /* Тот же цвет, но с другой прозрачностью */
    background: oklch(
        from var(--origin) l c h / 60%
    );
    /* На 10% темнее */
    border-color: oklch(
        from var(--error) calc(l - 10%) c h
    );
}

.message.is-success {
    /* Другой оттенок (зелёный)
    с той же яркостью и насыщенностью */
    background: oklch(
        from var(--error) l c 140
    );
}

У OKLCH предсказуемая яркость — поэтому нам легко сделать цвет интерфейса из произвольного цвета, который задаёт пользователь (и сохранить читаемость текста). Посмотрите, как выбранный цвет влияет на цвета чекбоксов в цветовом миксере Злых марсиан:

:root {
    /* Яркость и насыщенность
    заменены для хорошего контраста */
    --accent: oklch(
        from (--user-input) 87% 0.06 h
    );
}

body {
    background: var(--accent);
    color: black;
}

В примере выше, нам не нужно указывать цвет текста с color-contrast(), потому что OKLCH имеет предсказуемую яркость. Любой фон с L меньше или равно 87% имеет хороший контраст с чёрным текстом.

Коррекция охвата

У OKLCH есть и другая замечательная особенность: независимость от устройств. OKLCH создан не только для обычных мониторов с набором цветов sRGB.

Мы можем указать абсолютно любой цвет с помощью OKLCH: sRGB, P3, Rec2020 и далее. Ряд комбинаций компонентов поддерживается только на P3-мониторах; а для некоторых сочетаний ещё предстоит изобрести экраны, которые смогут их отображать.

Не пугайтесь выхода за пределы возможностей экрана — браузеры найдут максимально похожий цвет. Процесс поиска наиболее похожего цвета в другом охвате называется коррекцией охвата.

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

Например, при некоторой яркости только у синего цвета может быть самая большая насыщенность — в зелёном или красном оттенке не будет цвета с той же насыщенностью.

На sRGB-мониторах для 44% яркости максимальная насыщенность синего сильнее, чем у остальных цветов.

Есть два способа коррекции охвата:

Конвертировать цвет в RGB или P3 и отсечь значения более 100% или менее 0%: rgb(150% -20% 30%) → rgb(100% 0 30%). Это наиболее быстрый способ, но у него наихудший результат — он может заметно изменить оттенок цвета;
Перевести цвет в формат OKLCH и уменьшить насыщенность и яркость. Это сохранит тот же оттенок, но немного замедлит отрисовку.

Крис Лилли создал интересное сравнение между разными методами коррекции охвата.

Спецификация CSS Colors 4 требует от браузеров применять OKLCH-метод для коррекции охвата. Однако прямо сейчас Chrome и Safari используют быстрый, но неточный метод отсечения.

Именно поэтому мы рекомендуем ручную коррекцию охвата — указывать как sRGB, так и P3-цвета:

.martian {
    background: oklch(69.73% 0.155 112.79);
}

@media (color-gamut: p3) {
    .martian {
        background: oklch(69.73% 0.176 112.79);
    }
}

Превью этого цвета вы сможете увидеть только на P3-мониторе.

И здесь есть хорошая новость: stylelint-gamut может автоматически определять все P3-цвета которые нужно обернуть медиавыражением.

Внедрение OKLCH в проект

Шаг 1: Добавление полифила OKLCH в CSS

К марту 2023, oklch() поддерживают Chrome и Safari. Для стабильного результата в старых версиях у нас есть полифилы для статичных значений (без кастомных свойств).

Есть два полифила, поддерживающих oklch():

Очень популярный postcss-preset-env;
И крайне быстрый Lightning CSS, написанный на Rust.

Скорее всего, в вашем проекте уже есть postcss-preset-env. Например, он есть в каждом проекте, созданном с помощью Create React App.

Поищите postcss-preset-env в вашем лок-файле (package-lock.json, yarn.lock или pnpm-lock.yaml). Убедитесь, что он использует версию 7.x или выше;
Добавьте oklch(100% 0 0) в ваш CSS и посмотрите, скомпилируется ли его сборка в rgb().

Если у вас нет postcss-preset-env, но есть сборщик фронтенда (например, Webpack):

Установите postcss-preset-env с помощью пакетного менеджера. Для npm запустите следующую команду:
```
npm install postcss-preset-env postcss
```
Проверьте документацию PostCSS, чтобы узнать, как добавить поддержку PostCSS в ваш инструмент сборки. Например Webpack требует postcss-loader, а в Vite уже есть встроенная поддержка.
Если у вас уже есть интеграция с PostCSS, найдите файл с его конфигурацией. Многие проекты уже используют PostCSS (например, Автопрефиксер). В корневой папке проекта найдите postcss.config.js (.postcssrc.json), или раздел "postcss" в package.json или конфигурации сборщика.
Если вы смогли найти файл конфигурации PostCSS, добавьте postcss-preset-env в плагины:
```
{
    "plugins": [
+       "postcss-preset-env",
        "autoprefixer"
    ]
}
```
Если вы не смогли найти файл конфигурации, создайте файл .postcssrc.json в корневой папке проекта:
```
{
    "plugins": [
        "postcss-preset-env"
    ]
}
```

Если у вас ещё нет инструмента сборки, мы рекомендуем использовать Vite или компилировать CSS с помощью CLI lightningcss.

Добавьте в файл .test { background: oklch(100% 0 0) }, скомпилируйте стили. Если в итоговом CSS есть .test{background:#fff}, то всё работает.

Шаг 2: Перевод цветов приложения на OKLCH

После установки OKLCH-полифила вы можете заменить все цвета в форматах hex, rgb() или hsl() на oklch(). Они будут работать в любом браузере.

Найдите любой цвет в вашем CSS-коде и переведите его в oklch(), используя цветовой миксер OKLCH.

.header {
-   background: #f3f7fa;
+   background: oklch(97.4% 0.006 240);
}

Вы также можете использовать convert-to-oklch, чтобы автоматически перевести все цвета:

npx convert-to-oklch ./src/**/*.css

Помните, что эти полифилы поддерживают только CSS, и не будут работать в HTML- или JS-файлах.

Дополнительно: добавление палитры

Раз уж мы рефакторим CSS, то давайте воспользуемся моментом и заодно внедрим общую палитру.

Что такое общая палитра?

Все цвета указываются как кастомные CSS-свойства;
Компоненты фреймворков используют эти цвета в виде var(--error);
Дизайнерам стоит стремиться к переиспользованию цветов;
Тёмная тема или тема с высоким контрастом создаются через переопределение кастомных свойств в палитре через @media.

Вот небольшой пример такого подхода:

:root {
    --surface-0: oklch(96% 0.005 300);
    --surface-1: oklch(100% 0 0);
    --surface-2: oklch(99% 0 0 / 85%);
    --text-primary: oklch(0% 0 0);
    --text-secondary: oklch(54% 0 0);
    --accent: oklch(57% 0.18 286);
    --danger: oklch(59% 0.23 7);
}

@media (prefers-color-scheme: dark) {
    :root {
        --surface-0: oklch(0% 0 0);
        --surface-1: oklch(29% 0.01 300);
        --surface-2: oklch(29% 0 0 / 85%);
        --text-primary: oklch(100% 0 0);
    }
}

После создания единой палитры, перейти к использованию oklch() станет проще.

Шаг 3: Проверка OKLCH с помощью Stylelint

Stylelint — статический анализатор стилей, который будет полезен для поиска распространённых ошибок и внедрения хороших практик. Он работает как ESLint, но для CSS, Sass, или CSS-in-JS.

Stylelint будет очень полезен при переходе на oklch(), вы сможете:

Напомнить коллегам, что цвета в форматах hex, rgb() и hsl() больше не используются и что следует хранить все цвета в oklch() для единообразия; — Проверить, что все P3-цвета находятся внутри @media (color-gamut: p3). Это поможет избежать автоматической коррекции охвата в браузере (Chrome и Safari делают её неправильно).

Давайте установим Stylelint и плагин stylelint-gamut. Для npm:

npm install stylelint stylelint-gamut

Затем создадим конфигурацию .stylelintrc следующим образом:

{
    "plugins": [
        "stylelint-gamut"
    ],
    "rules": {
        "gamut/color-no-out-gamut-range": true,
        "function-disallowed-list": ["rgba", "hsla", "rgb", "hsl"],
        "color-function-notation": "modern",
        "color-no-hex": true
    }
}

Добавим вызов Stylelint в команду npm test, чтобы запустить его в CI. Изменим следующую строку в package.json:

"scripts": {
-   "test": "eslint ."
+   "test": "eslint . && stylelint **/*.css"
}

Запустим npm test, чтобы увидеть, какие цвета должны быть переведены в oklch().

Мы также рекомендуем добавить stylelint-config-recommended в .stylelintrc. Этот конфиг убедится, что вы используете самые популярные лучшие практики в вашем CSS.

Дополнительно: P3-цвета

Просто переведя цвета в oklch(), вы улучшите читаемость и поддерживаемость кода, но не добавите что-то заметное для пользователей. А вот если ещё и внедрить в дизайн красочные и глубокие P3-цвета, то и пользователи смогут оценить рефакторинг.

P3-цвета очень полезны при создании палитр. Но прямо сейчас мы не можем их использовать: пока небольшая часть устройств поддерживает P3.

Вот, как можно добавить P3-цвета в проект:

Выберите любой насыщенный цвет в вашем CSS-коде;
Скопируйте его и вставьте в цветовой миксер OKLCH;
Измените значения Chroma и Lightness так, чтобы цвет оказался в области P3-цветов. Легче всего это сделать, смотря на график Lightness: выберите любой цвет выше тонкой белой линии на этом графике;
Скопируйте результат и оберните его в медиавыражение с color-gamut: p3.

:root {
    --accent: oklch(70% 0.2 145);
}

@media (color-gamut: p3) {
    :root {
        --accent: oklch(70% 0.29 145);
    }
}

Дополнительно: OKLCH для SVG

OKLCH можно использовать не только в CSS, но и в SVG или HTML. Это полезно при добавлении ярких красок в иконки.

Обратите внимание: полифилов для SVG нет. По этой причине мы рекомендуем использовать oklch() только для P3-цветов.

Дополнительно: OKLCH и Oklab в градиентах

Градиент — путь между двумя или более точками цветового пространства. В разных пространствах градиент для одних и тех же цветов может получиться совершенно разный.

Так выглядят градиенты в разных цветовых пространствах.

Нет единого решения, какое пространство лучше для работы с градиентами — это зависит от конкретной задачи. Но в цветовом пространстве Oklab (родственнике OKLCH, живущем в декартовых координатах) обычно получается хороший результат:

У него нет сероватой области в центре, как в sRGB (пространство, используемое по умолчанию);
У него нет сдвига от голубого к фиолетовому, в отличие от Lab;

В спецификации CSS Image 4 есть специальное выражение, изменяющее цветовое пространство для градиентов:

.oklch {
    background: linear-gradient(
        in oklab, blue, green
    );
}

Код выше будет работать только в Chrome и Safari Technology Preview. Вы можете использовать полифил PostCSS, чтобы применять Oklab-градиенты уже сейчас.

Градиенты получаются ещё более красивыми с easing-gradients.

Дополнительно: Изменение цветов с помощью OKLCH

Уже очень скоро мы сможем увидеть истинную силу OKLCH: с CSS Colors 5 браузеры начнут поддерживать производные цвета в CSS.

OKLCH крайне хорош для работы с цветом. В отличие от HSL, его яркость предсказуема — в нём нет сдвига оттенка при изменении насыщенности, чем не может похвастаться LCH.

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

Следующий пример иллюстрирует, как можно при наведении на кнопку сделать её фон на 10% темнее:

.button {
    background: var(--accent);
}

.button:hover {
    background: oklch(
        from var(--accent) calc(l - 10%) c h
    );
}

С кастомными свойствами CSS достаточно один раз определить логику :hover. В дальнейшем мы можем создавать разные варианты стилей, просто изменяя исходный цвет.

.button {
    background: var(--button-color);
}

.button:hover {
    /* Один :hover для обычного,
    вторичного и ошибочного состояния */
    background: oklch(from var(--button-color) calc(l + 10%) c h);
}

.button {
    --button-color: var(--accent);
}

.button.is-secondary {
    --button-color: var(--dimmed);
}

.button.is-error {
    --button-color: var(--error);
}

Поскольку у OKLCH предсказуемый контраст, то мы можем взять случайный цвет от пользователя и сделать из него тему сайта с отличной доступностью:

.header {
    /* JS установит --user-avatar-dominant */
    background: oklch(
        from var(--user-avatar-dominant) 80% 0.17 h
    );
    color: black;
}

В примере выше, OKLCH позволяет убедиться, что чёрный текст всегда будет читаемым на любом оттенке, так как мы установили L равным 80%. В будущем, с OKLCH и производными цветами мы сможем генерировать всю палитру дизайн-системы прямо в CSS.

Дополнительно: OKLCH в JS

Нам не нужно ждать CSS Colors 5, чтобы использовать OKLCH для изменений цвета. Color.js и culori позволяют менять цвета в JS со всеми преимуществами OKLCH. Как это сделать в culori, можно посмотреть в исходном коде цветового миксера OKLCH.

Пример ниже генерирует тему из пользовательского цвета с помощью Color.js:

import Color from 'colorjs.io'

// Разбираем любой CSS цвет
let accent = new Color(userAvatarDominant)

// Устанавливаем яркость и насыщенность
accent.oklch.l = 0.8
accent.oklch.c = 0.17

// Применяем коррекцию охвата для sRGB,
// если мы вышли за пределы sRGB
if (!accent.inGamut('srgb')) {
    accent = accent.toGamut({ space: 'srgb' })
}

// Делаем цвет на 10% светлее
let hover = accent.clone()
hover.oklch.l += 0.1

document.body.style.setProperty(
    '--accent',
    accent.to('srgb').toString()
)
document.body.style.setProperty(
    '--accent-hover',
    hover.to('srgb').toString()
)

Вы можете использовать эти библиотеки, чтобы создавать целые палитры в цветовом пространстве OKLCH. Они будут обладать предсказуемым яркостью и хорошей доступностью. Например, Hueone, генератор доступных палитр, по умолчанию использует Oklab.

Подведение итогов: почему мы перешли на OKLCH?

Мы, Злые марсиане, уже используем OKLCH в наших проектах. Ответим на главный вопрос: какие же преимущества мы получили, перейдя на OKLCH?

1. Лёгкое чтение цветов

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

.text {
    /* Ошибка: разницы в 20% яркости
    мало для хорошего контраста и доступности */
    background: oklch(80% 0.02 300);
    color: oklch(100% 0 0);
}

.error {
    /* Ошибка: цвета имеют немного разный оттенок */
    background: oklch(90% 0.04 30);
    color: oklch(50% 0.19 27);
}

2. Лёгкая работа с цветами

Мы изменяем цвета прямо в коде и получаем предсказуемые результаты:

.button {
    background: oklch(50% 0.2 260);
}

.button:hover {
    background: oklch(60% 0.2 260);
}

3. Использование как sRGB, так и новых P3-цветов

Мы используем одинаковые CSS-функции как для sRGB, так и для P3-цветов:

.buy-button {
    background: oklch(62% 0.19 145);
}

@media (color-gamut: p3) {
    .buy-button {
        background: oklch(62% 0.26 145);
    }
}

4. Взаимопонимание между разработчиками и дизайнерами

Математика OKLCH ближе к тому, как работают наши глаза. Поэтому, работая с oklch(), мы глубже понимаем, как работает цвет.

А понимание работы цвета позволяет разработчикам и дизайнерам стать ближе друг к другу. Современные генераторы палитр уже используют Oklab или Lab для хорошей доступности — использование oklch(), как в инструментах дизайнеров, так и в коде, помогает лучше понимать друг друга.

5. Готовность к будущему

Перейдя на OKLCH сегодня, мы подготовили себя к завтрашнему дню, когда в CSS появятся производные цвета. OKLCH — лучшее пространство для работы с цветом, и мы советуем познакомиться с ним как можно скорее.

.button:hover {
    background: oklch(
        from var(--button-color) calc(l + 10%) c h
    );
}

Попробуйте и вы добавить oklch() в свой проект. Мы уверены, что результат вам понравится. Если у вас возникнут вопросы, пишите нам: @andrey_sitnik и @ninoid_.

Аудит доступности: основы

Thu, 03 Feb 2022 00:00:00 GMT

Доступность становится одним из показателей качества сайтов и приложений. Но с чего начать её улучшение? Как узнать, есть ли с ней проблемы? Насколько они критичны и как их исправить? На эти вопросы ответит аудит.

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

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

Определение

Аудит доступности — это оценка продукта на соответствие требованиям доступности, которые описаны в разных стандартах и руководствах. Он оценивает пригодность интерфейса для максимально большого числа пользователей, в том числе для людей с особыми потребностями. В результате получается отчёт об уровне доступности с рекомендациями по исправлению проблем.

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

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

В статье используется термин «аудит», но в других местах можете встретить «оценку» (evaluation или assessment), это синонимы.

Зачем проводить

Компании проводят аудит по разным причинам.

Для расширение аудитории и улучшения интерфейса. Доступным интерфейсом сможет пользоваться больше людей, а 71% пользователей с особыми потребностями не уйдёт с недоступного сайта сразу же. К тому же доступность влияет на положение в поисковой выдаче Google.
Как стартовую точку для внедрения доступности, если компания решила за это взяться.
Для того, чтобы принять решения об изменениях в интерфейсе, когда разрабатываются новые возможности.
Если интерфейс изменился — чтобы проверить его доступность. Актуально для больших проектов, в которых уже поддерживается определённый уровень доступности.
Чтобы проверить соответствие требованиям закона. Особенно актуально в США и странах Евросоюза. Там компании могут получить штраф или потратить деньги на судебные разбирательства из-за нарушения законов.
Для участия в госзакупках для компаний из США. Доступность — одно из требований для выигрыша тендера.

Принципы и источники критериев

Аудит основывается на нескольких принципах.

Содержит измеряемые критерии, а не оценочные суждения.
Определяет уровень доступности в целом, например, всего сайта.
Основывается на чёткой методологии.
Включает так называемые контрольные точки доступности.

Контрольные точки доступности (Accessibility Checkpoints) — это проверка выполнения конкретных требований руководств или законов. Например, во WCAG 2.1 (Web Content Accessibility Guidelines, Руководство по обеспечению доступности веб-контента) контрольная точка — это выполнен или нет критерий успешности.

Критерии для аудита берутся из международных и локальных руководств, стандартов и законов. Это могут быть:

WCAG 2.1, а скоро будет WCAG 2.2.
Section 508 (Section 508 of the Rehabilitation Act of 1973, Раздел 508 Федерального Закона о реабилитации 1973 года).
ADA (Americans with Disabilities Act, Закон об американцах-инвалидах).
EN 301 549 (Standard EN 301 549, Европейский стандарт EN 301 549).
Похожие законы и стандарты других стран.

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

WCAG — это: основа, а не ответ; ориентир, а не цель; ресурс, а не инструмент; непрерывный процесс. «A Little Book of Accessibility», Гарет Форд Уильямс.

Когда и как часто проводить

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

Размеры продукта напрямую влияют на то, как часто проводить аудит. Для небольшого продукта без больших изменений достаточно одного раза в год. Средние проекты с умеренным количеством новых функций можно проверять раз в полгода–год. Уровень доступности активно развивающихся больших продуктов постепенно снижается из-за постоянных изменений. В их случае лучше проводить аудит не только каждый год, но и ежеквартально. Годовой будет более полным и глубоким, а квартальные — небольшими и точечными.

Типы аудита

Пока нет универсальной классификации типов аудита. Разные компании даже могут называть их по-разному. В этом разделе мы собрали самые распространённые типы и сгруппировали их так, чтобы было проще в них разобраться и выбрать походящий.

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

Кто проводит

Внешний аудит (External Expert Audit или Expert Audit). Его проводит приглашённый эксперт или компания, которая занимается аудитом. Он дороже, но более профессиональный, полный и показывает взгляд со стороны.
Самостоятельный аудит (Self-audit). Проводится собственными силами. Дешевле, но не всегда найдёт все проблемы. Этот тип подходит компаниям, где есть сотрудники с нужными навыками и знаниями о доступности.

Для самостоятельного аудита создаётся отдельная рабочая группа внутри компании. Она состоит из инициатора аудита, который за ним следит, и нескольких аудиторов. Их количество зависит от размера продукта и выбранных параметров аудита. Максимально объективную оценку они смогут дать, если в этот момент активно не участвуют в разработке.

По цели

Подробный аудит (Detailed Audit). Проводится на основе выбранного документа. Например, WCAG 2.1 или Section 508. Также подходит для проверки на соответствие специфическим требованиям. К примеру, для видеотрансляций, банкоматов или терминалов.
Аудит рисков (Risk Audit). Описывает и считает количество критичных ошибок, с которыми могут столкнуться пользователи. В отчёт попадёт информация о потенциальных рисках без рекомендаций по их исправлению. Так что это, скорее, подготовительный этап, а не полноценный аудит.
Аудит масштаба работ (Level-of-effort Audit). Цель такого аудита — узнать стоимость и объём работ по исправлению проблем.
Проверочный аудит (Validation Audit). Повторный аудит после внесения изменений.

По степени автоматизации

Тестирование — важный этап аудита. В этой категории типы выделены на основе того, какой вид тестирования преобладает.

Автоматический аудит

Также известный как Software/Automated Audit. Проводится с помощью автоматических инструментов и автотестов. Помогает быстро выявить основные проблемы с доступностью.

Однако у него есть несколько недостатков:

Не всё можно проверить автоматически. Например, читаемость текстов, качество альтернативных описаний для изображений или понятность иконок. Автоматическое тестирование поможет отловить только 30–50% проблем с доступностью. Интересно, что axe от Deque обещает найти 57% от всех проблем.
Не всегда гарантируется соответствие рекомендациям и указывается их источник. Какие-то инструменты проверяют по последним версиям WCAG, какие-то нет.
Не все инструменты валидируют HTML и ARIA (Accessible Rich Internet Applications). К примеру, они могут пропустить вложенные друг в друга заголовки или явные ошибки с ARIA-атрибутами.

Так что начинать оценку хорошо с автоматического аудита, но не стоит на нём останавливаться.

Ручной аудит

Он же Manual Audit. Заполняет пробелы автоматического. Можно проверить интерфейс с клавиатуры, посмотреть страницу с экранной лупой, провести юзабилити-тестирование или интервью с пользователями.

Смешанный аудит

Или Hybrid Audit. Совмещает ручные и автоматические методы. С ним легче подстроить процесс тестирования под нужды компании и избежать сложностей и пробелов только ручного или автоматического тестирования.

По этапу разработки

Технический аудит. Оценка кода. В основном это автоматическая проверка с элементами ручного тестирования.
Аудит дизайна. Важный тип аудита, ведь примерно 67% проблем с доступностью связаны с дизайном. Его можно разделить на два дополнительных подтипа:
- Дизайн-аудит (Design/UI Audit). Оценка целой дизайн-системы или отдельных UI-компонентов и паттернов вручную или с помощью специальных инструментов вроде axe или WAVE.
- Юзабилити-аудит (Usability/UX Audit). Этот тип помогает детальнее изучить то, как пользователи с особыми потребностями взаимодействуют с интерфейсом, и с чем у них возникают проблемы. Сочетает ручной аудит и юзабилити-тестирование. Например, оценивает читаемость текстов, информационную архитектуру или навигацию с клавиатуры.
Совмещённый аудит. Оценка того, как работает весь интерфейс. Проверяются код, дизайн и контент.

По проверяемым технологиям

Аудит сайтов и десктопных приложений (Website Audit и App Audit).
Мобильный аудит (Mobile Audit).
Аудит документов (Document Audit). Можно проверять любые форматы. К примеру, PDF, DOC или PPT.
Приёмочное тестирование скринридеров (Screen Reader Audit). Оценка доступности для пользователей программ экранного чтения. Обычно проверяется то, как читаются заголовки, медиаконтент, интерактивные элементы, отдельные области страницы, а также порядок фокуса.
Аудит терминалов (Kiosk Audit). Оцениваются терминалы, в основном вручную.
Аудит голосовых помощников (Conversational Audit). Оценка интерфейсов для голосового управления. Например, с помощью голосовых ассистентов Alexa или Google Home.
И другие технологии.

Как выбрать нужный тип

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

Какая цель у аудита?
- Проверить весь продукт на соответствие рекомендациям уровня AA из WCAG 2.1.
- Узнать, насколько доступна дизайн-система.
- Уточнить примерную стоимость аудита.
- Или что-то другое.
Что это за продукт? Может быть, это сайт, веб-приложение или сервис с голосовым управлением.
Насколько продукт объёмный, как часто обновляется и как много стороннего кода используется?
Насколько хорошо команда разбирается в доступности? Есть ли сотрудники, которые могут провести аудит?
Сколько можете выделить на это ресурсов?
Какие сроки проведения?

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

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

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

Когда недостаточно средств для проведения смешанного или ручного аудита, то в первое время поможет автоматический. Он не выявит всех проблем, зато сократит объём работы к моменту, когда вы сможете провести более подробный и глубокий аудит.

Методологии

Одна из базовых составляющих любого аудита — методология.

Методология — это набор методов, правил и этапов, который помогает стандартизировать процесс аудита.

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

Методологии включают определённое количество этапов. Обычно их пять:

Проработка требований к аудиту. На этом этапе определяются его цели, примерная стоимость и выбирается подходящий тип. Это обсуждается с аудитором или со специалистами по доступности внутри команды.
Изучение продукта. Здесь нужно выяснить, что это за продукт и какие технологии в нём используются. Например, это многостраничный сайт или небольшой лендинг, написанный на чистых CSS или HTML.
Проведение тестирования.
Составление отчёта.
Исправление ошибок, когда есть рекомендации.

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

WCAG-EM

WCAG-EM (Website Accessibility Conformance Evaluation Methodology, Методология оценки сайтов на соответствие доступности) — публичная методология W3C. Она содержит рекомендации об оценке доступности на соответствие критериям успешности WCAG. Несмотря на название, подходит для любого цифрового продукта, не только для сайтов.

Аудит по этой методологии состоит из пяти шагов.

Определение охвата аудита.
Изучение продукта.
Подбор репрезентативной выборки.
Проведение тестирования.
Составление отчёта.

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

Теперь давайте рассмотрим каждый шаг подробнее.

1. Определение охвата аудита

На первом шаге определяются границы того, что планируется оценивать. Чтобы это было проще сделать, шаг лучше разбить не несколько подзадач.

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

Также следует разобраться с поддерживаемыми технологиями. Это могут быть определённые операционные системы, браузеры и вспомогательные технологии.

Легче всего выбрать популярные комбинации:

Windows: JAWS или NVDA и Chrome.
macOS: VoiceOver и Safari.
iOS: VoiceOver и Safari.
Android: TalkBack и Chrome.

Важно определить желаемый уровень соответствия WCAG. Во WCAG 2.1 и 2.2 их три: A (минимальный), AA (средний) и AAA (максимальный). Чаще всего ориентируются на AA.

Опционально можно добавить дополнительные требования. Они зависят от целей аудита и особенностей продукта. Это могут быть:

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

2. Изучение продукта

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

Для начала надо выбрать популярные страницы. Обычно это главная и другие внутренние страницы, на которые есть ссылки в хедере и футере. Конечно, выбор упростит статистика по посещениям.

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

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

Отдельно стоит подумать о важных пользовательских путях. К примеру, добавление товара в корзину и оформление заказа.

Кроме этого, нужно определить используемые технологии. Какие фреймворки и CMS используются, есть ли CSS-анимация, ARIA-роли и атрибуты и другое.

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

3. Подбор репрезентативной выборки

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

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

Когда сайт большой и страниц много, то для начала лучше сформировать структурированную выборку. В неё включают все типы страниц и пользовательские пути. Хорошо, когда есть хотя бы одна страница, которая относится ко всем типам.

В выборку ещё хорошо включить все страницы и их состояния, которые являются частью одного процесса. Например, форма заказа товара, которая состоит из нескольких страниц (этапов). В этом случае они — часть одного большого процесса покупки, и не работают друг без друга.

Дополнительно может понадобиться случайная выборка. Она полезна для объёмных сайтов, когда структурированной выборки не хватает для полной оценки. Случайных страниц должно быть 10% от числа страниц из структурированной выборки. То есть, если в структурированной выборке их 80, то в случайную попадут 8. Случайные страницы выбирают разными способами. Например, с помощью инструментов и скриптов для случайного выбора или просмотра серверных логов.

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

4. Проведение тестирования

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

Полезно провести и автоматическое, и ручное тестирование. К ручному идеально привлекать не только экспертов, но и пользователей вспомогательных технологий. А перед этим лучше исправить критичные ошибки, которые обнаружили автоматические инструменты. Это ускорит пользовательское тестирование и поможет избежать лишних расходов.

Оценка проводится на основе пяти требований соответствия из WCAG.

Уровень соответствия. Если цель — проверка на соответствие уровню AA, то в результате получится утверждение, соответствует ли ему элемент или нет.
Страницы целиком. Если часть страницы соответствует рекомендациям уровня A, а другая — AA, то она не соответствует уровню АА.
Соответствие процесса в целом. Для этого проверяются пользовательские пути. Например, если в корзину нельзя попасть из карточки товара, то это критичная ошибка.
Способы использования технологий, поддерживающих доступность. Контент оценивается с помощью поддерживаемых вспомогательных технологий. Если он не поддерживается напрямую, то проверяются альтернативные версии. Например, видео без субтитров или титров считается доступным, если у него есть текстовая расшифровка на этой же или отдельной странице.
Невмешательство. Если технологии недоступны, но не мешают пользователям или не важны для них, то это не ошибка. К примеру, рекламные баннеры.

Результаты оценки лучше сразу записывать в таблицу вместе с указанием проблемных страниц, элементов и состояний. Если есть несоответствия, то отмечаются их причины. Некоторые элементы получат статус «предупреждение». Это субъективная оценка, а не ошибка.

Тестирование можно разделить на несколько небольших задач.

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

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

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

5. Составление отчёта

На последнем шаге все выводы объединяются в один отчёт.

Отчёты составляются по шаблону, который состоит из обязательных и опциональных пунктов.

Общая информация.
- Имена аудиторов.
- Имя ответственного за проведение аудита. Это может быть владелец сайта, разработчик и любой другой человек, который предложил провести аудит.
- Дата проведения.
Охват из первого шага.
- Особенности продукта. Например, поддерживаемые языки и внешние сервисы.
- Желаемый уровень соответствия.
- Какие технологии планировалось поддерживать. Ими могут быть браузеры, операционные системы, скринридеры, экранные лупы и прочее.
- Дополнительные требования (опционально). Например, какие-то особые функции или страницы, которые хотелось отдельно протестировать.
Описание продукта из второго шага.
- Технологический стек.
- Важные страницы, например, главная (опционально).
- Ключевая функциональность (опционально).
- Типы страниц и их состояний (опционально).
- Страницы, которые имеют значение для людей с особыми потребностями (опционально).
Репрезентативная выборка из третьего шага.
- Какие оценивались страницы, состояния и типы.
- Важные пользовательские пути.
- Список случайно выбранных страниц (опционально).
Результаты тестирования из четвёртого шага.
- Оценка страниц из структурированной выборки.
- Оценка страниц из случайной выборки (опционально).
- Сравнение результатов оценки страниц из случайной и структурированной выборок (опционально).

Примечание. Для отчётов об аудите инструментов для разработки и проверки доступности используют машиночитаемый формат EARL (Evaluation and Report Language, Язык для оценки и отчёта).

Можно не останавливаться на рекомендациях WCAG-EM и добавить в отчёт ещё больше деталей. Включить можно всё, что кажется полезным.

Какие автоматические инструменты для тестирования использовались.
Количество страниц и элементов, которые соответствует или не соответствуют рекомендациям.
Общая статистика по количеству найденных проблем и сколько обнаружено глобальных блокеров. Ещё можно указать, какой тип тестирования помог их выявить.
Влияние барьеров на людей. Например, какие категории пользователей они затронули и насколько серьёзно.
Интересные выводы из пользовательского тестирования.
Какой процент проблем выявило автоматическое или ручное тестирование.
Следующие шаги по внедрению доступности.

Сделать отчёт ещё нагляднее помогут скриншоты и графики. К примеру, в панели мониторинга Deque есть круговая диаграмма с процентом выполненных и невыполненных критериев успешности WCAG, а ещё гистограммы с серьёзностью ошибок и частотой проблем.

«What to look for in an accessibility audit», Гленда Симс.

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

Публичные заявления, VPAT и ACR

Многие аудиторские компании оценивают продукты для составления публичных заявлений, шаблонов добровольной доступности (VPAT) и отчётов о соответствии ей (ACR). В этих документах нет рекомендаций, в отличие от полноценного отчёта об аудите. Они описывают только доступные фичи и соответствие критериям WCAG или требованиям законов.

Публичные заявления

Компании публикуют такие заявления на своих сайтах, если хотят рассказать пользователям и партнёрам о доступности сайта или приложения. Как правило, это не обязательно делать.

Есть несколько видов заявлений.

Заявление о доступности (Accessibility Statement) — перечисление и описание типов фич и их уровня соответствия критериям успешности из WCAG или требованиям законов. Обычно описывает доступность самых важных страниц и экранов. Пример — Заявление о доступности Twitch.

В странах Евросоюза заявление о доступности обязательно должно быть у сайтов и мобильных приложений государственных органов. Для него разработана отдельная европейская модель.

Заявление о соответствии (Conformance Claims) описывает уровень соответствия сайта рекомендациям из WCAG. Пример — Заявление о соответствии Panasonic.

Заявление об оценке (Evaluation Statement) — это публичные выводы о проведении аудита по методологии WCAG-EM. Состоит из нескольких пунктов:

Дата проведения аудита.
Версия WCAG в основе аудита.
Желаемый уровень соответствия.
Краткое описание охвата: сайт, приложение, что-то другое. В общем, информация, которая была собрана на первом шаге аудита по методологии.
Какие технологии используются.
Поддерживаемые вспомогательные технологии.
Если продукт частично соответствует требованиям доступности, то какие части им не соответствуют.
Причины несоответствия.

Пример — Заявление об оценке сайта правительства округа Камберленд.

VPAT и ACR

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

Нужны американским и европейским компаниям, которые участвуют в государственных закупках в США. Без этого они не смогут сотрудничать с американскими государственными органами.

VPAT (Voluntary Product Accessibility Template, Шаблон добровольной доступности продукта) — зарегистрированный знак обслуживания ITI (Information Technology Industry Council, Совет индустрии информационных технологий). Изначально составлялся для того, чтобы государственным органам США было проще проводить исследования доступности американского информационного рынка.

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

Существует четыре вида VPAT:

Редакция WCAG про соответствие WCAG 2.0 или 2.1.
Редакция 508 про соответствие Section 508.
Редакция EU про соответствие EN 301 549.
Редакция INT про соответствие всем трём документам.

Пример — GitHub VPAT.

ACR (Accessibility Conformance Report, Отчёт о соответствии доступности) — финальный отчёт о доступности продукта с бо́льшим количеством деталей. Он включает заполненный VPAT, информацию о продукте или услуге, поддерживаемых вспомогательных технологиях и другие детали.

Кроме стандартного ACR, есть ещё версия с поддержкой машинного чтения — OPAT (Open Product Accessibility Template, Открытый шаблон добровольной доступности продукта).

Оценка доступности пользователями

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

В проведении исследований есть особенности, которые могут привести к ошибочным выводам. Поэтому лучше всего привлекать людей, которые умеют проводить интервью или юзабилити-тестирование. Если такой возможности нет, лучше найти компанию, которая этим занимается. Однако можно провести исследования и собственными силами. Это всё равно лучше, чем ничего.

Методы исследований

Для такой дополнительной проверки можно провести анкетирование, интервью, юзабилити-тестирование. На выбор варианта исследования и его параметры здесь влияют:

Особенности продукта и этап его развития.
Выбранный тип аудита.
Количество доступных ресурсов у компании. Исследования могут быть довольно продолжительными и дорогими. Для них потребуется выделение дополнительных сотрудников и физический выезд к каждому респонденту.
Количество выделенных ресурсов для поиска респондентов.

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

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

Полезные ссылки по теме:

Just Ask: Integrating Accessibility Throughout Design, Шона Генри.
Юзабилити-тестирование по дешёвке, Влад Головач.
Как сделать сайт удобным. Юзабилити по методу Стива Круга, Стив Круг.
Основы юзабилити-тестирования, Кэрол М. Барум. Исчерпывающая книга про юзабилити-тестирование.

Требования к респондентам и их поиск

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

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

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

Примеры критериев для отбора респондентов:

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

Можете начать поиски респондентов с этих мест:

Специализированные региональные и международные организации, занимающиеся поддержкой людей с инвалидностью. Например, Всероссийское общество инвалидов, Всероссийское общество глухих или Всероссийское общество слепых.
Фонды, ассоциации и местные группы поддержки людей с особыми потребностями и с нейроотличиями. К примеру, благотворительный фонд поддержки людей с аутизмом «Антон тут рядом» или Ассоциация родителей детей и взрослых с дислексией.
Университетские программы для студентов с особенностями развития.
Организации, занимающиеся поддержкой пожилых людей.

Можно попросить помощи у экспертов по доступности с инвалидностью. Они подскажут, как и где найти нужных респондентов. Также есть компании, которые сами подберут подходящих респондентов.

Полезные ссылки по теме:

В книге «Just Ask: Integrating Accessibility Throughout Design» Шоны Генри есть больше информации о том, как отбирать участников для тестирования и как правильно с ними взаимодействовать.
Поиск респондентов для юзабилити-тестирования. Часть 1: критерии отбора, UsabilityLab.
Поиск респондентов для юзабилити-тестирования. Часть 2: самостоятельный поиск, UsabilityLab.
Как подбирать респондентов для UX исследования — опыт Crowdtesting, Writes.

Что делать после аудита

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

После исправления ошибок бывает полезно перепроверить, точно ли их больше нет. Для этого пригодится регрессионное тестирование или проверочный аудит. Они обнаружат пропущенные ошибки в уже протестированных частях продукта или только подтвердят, что всё хорошо.

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

Ещё полезно найти среди коллег защитника доступности (Accessibility Champion) и собрать команду из специалистов, которые в ней разбираются (Accessibility Champion Unit). Эти люди будут менторить других, помогать решать сложные задачи и следить за уровнем доступности продукта.

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

Не забывайте про регулярное автоматическое и ручное тестирование. Их можно внедрить на нескольких этапах разработки. К примеру, на этапе дизайна и написания кода. Это поможет заранее отлавливать ошибки и быстро их исправлять. Ещё полезно периодически проводить тестирование с клавиатуры. Так можно найти часть потенциальных проблем со скринридерами.

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

Выводы

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

У него чёткая структура и критерии в основе. Чаще всего они берутся из WCAG, но бывает и из локальных законов и стандартов о цифровой доступности.

Кроме этого, у любого аудита есть чёткая методология, по которой он проводится. Одна из самых популярных — WCAG-EM от W3C.

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

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

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

На отчёт чем-то похожи публичные заявления, VPAT и ACR. Но, в отличие от отчёта, в них нет рекомендаций по исправлению ошибок. Это просто перечисление фич и того, что в продукте доступно, а что нет.

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

Полезные ссылки

Онлайн-обучение: советы студентам

Thu, 25 Nov 2021 00:00:00 GMT

В первой части серии мы поговорили про основы обучения взрослых и о плюсах и минусах онлайн-обучения. Во второй части мы посмотрим на процесс с другой стороны — глазами студента.

Раньше, чтобы получить профессию, нужно было поступить в университет. Это было целое приключение: подать заявление, сдать несколько экзаменов, а потом дежурить возле списков зачисленных. Если везло не очень, то ещё и заплатить денег за обучение. Всё это сильно повышало ценность обучения и полученных знаний. Знакомые предприниматели и владельцы бизнеса, по их словам, смотрели на диплом как на подтверждение, что человек способен довести начатое до конца и достаточно упорен, чтобы преодолеть все трудности.

Сегодня образование превратилось в сервис. Ты буквально с телефона можешь нажать пару кнопок и получить доступ к знаниям. Эта простота отлично сказывается на доходах онлайн-школ, но плохо влияет на мотивацию студентов. С каждым годом я вижу всё меньше студентов, которые действительно готовы учиться. Из-за простоты доступа к курсам у них создаётся ошибочное ощущение, что и получение знаний будет таким же простым.

К сожалению, процесс доступа к знаниям упростился, но процесс самого получения знаний — нет. До сих пор не существует технологии репликации знаний: достать флешку из одной головы и вставить в другую. Чтобы действительно научиться чему-то нужно приложить усилия. Вы сами несёте ответственность за итог обучения.

В этой статье я хочу дать несколько советов будущим или настоящим студентам. Верю, что они помогут качественному обучению, освоению навыков и в конечном счёте — освоению новой профессии.

Нематериальный мир

Мотивация

Первое, о чём стоит сказать — это о мотивации. Если вы пошли на курсы потому что действительно хотите изменить свою жизнь, сменить работу, зарабатывать больше и так далее, то это будет помогать вам дойти до конца. Если же в основе лежит простой интерес или скидки-акции-реклама, то ваша заинтересованность быстро спадёт. Получится эффект фитнеса: вы покупаете годовой абонемент, ходите несколько раз и забиваете. Всем хорошо. Вы утешаете себя мыслью, что вы походили и ещё пойдёте — абонемент-то в кармане! Фитнесу вообще отлично, он получил деньги ни за что.

Поэтому очень советую вам перед покупкой любого курса провести с собой маленький психологический анализ и разобраться, что вас мотивирует на эту покупку. Ответьте для себя на несколько вопросов:

Что меня толкает на покупку курса?
Как я использую полученные знания потом?
Как я верну потраченное?
Что изменится в моей жизни после курса?

Список вопросов не полный, расширяйте и меняйте его на своё усмотрение. Главное чтобы у вас было чёткое понимание точки А и точки Б, между которыми обязательно лежит курс и никак иначе этот путь не преодолеть.

Работа с мотивацией тем более нужна, если вы выбрали бесплатный курс. Там вы ничем не жертвуете, кроме времени. Процесс доступнее, проще, но от этого менее ценный для вас. Для эффективного обучения на бесплатном курсе у вас должна быть тройная мотивация.

Из ответов на вопросы лучше всего сформулировать конкретную цель. Лучше всего будет сформулировать её в формате SMART (Specific, Measurable, Achievable, Realistic, Timely):

Конкретная
Измеримая
Достижимая
Значимая
Ограниченная по времени.

Например, цель «хочу стать разработчиком» не подойдёт. В ней нет критериев оценки успешности достижения этой цели, нет временных рамок. Для кого-то это может не быть значимой целью, ведь он всегда хотел быть ветеринаром.

Лучше так: «Хочу устроиться на позицию джуниор фронтенд-разработчика через три месяца после окончания курса». Такая цель:

Конкретная,
Измеримая — либо устроились, либо нет,
Достижимая — множество примеров трудоустройства джунов после курсов,
Значимая — тут, конечно, только вам решать, на сколько это значимо лично для вас,
Ограничена по времени — это поможет достичь её в установленные сроки, а не размазать на двадцать лет.

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

Вопросы

Ещё один грустный вздох на тему неизобретённой репликации знаний. Поехали дальше.

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

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

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

Многие люди ищут менторов чтобы те отвечали на их вопросы и помогали двигаться вперёд. А у вас бонусом к курсам идут менторы — пользуйтесь этим!

Не знаю откуда, но у многих моих студентов существует страх задать вопрос, если они чего-то не поняли. Думаю, ноги растут из неприятного опыта в детстве. Но это не моя специализация =) Регулярно сталкиваюсь с ситуацией, когда студент безмолвно присылает неверно сделанную работу на проверку. В ходе обсуждения оказывается, что он не понял тему. Но не задал никаких вопросов! Вместе формулируем вопрос — вместе находим на него ответ.

Не бойтесь показаться навязчивым, надоедливым. Задавайте вопросы пока не получите ответы на них. У вас есть цель, помните? Вам нужно к ней добраться кровь из носу!

Есть другая гипотеза, что вопросы не задают потому, что человек не может их сформулировать. И правда, нас этому навыку нигде не учат специально. Примерный список вопросов к себе, который может вам помочь обозначить проблему и сформулировать вопрос к преподавателю, может выглядеть так:

Тема, которую вы осваиваете.
Что делаете (если это код, прикладываете ссылку).
Что ожидаете получить.
Что получаете.
Какие способы пробовали.

В зависимости от осваиваемой профессии список может расширяться, но возьмите этот за основу.

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

Из этого совета, кстати, вытекает важность посещения вебинаров онлайн, если они есть в вашем курсе. Это возможность напрямую задать свой вопрос и получить на него ответ. Возможно даже с примером от преподавателя.

Формат усвоения знаний

Наверняка, большинство из вас слышали, что люди условно делятся на визуалов, аудиалов и кинестетиков. В этой системе существует и четвёртый тип, о котором всегда забывают — дигиталы. Дигиталы выстраивают логическую модель мира в процессе внутреннего диалога.

Скорее всего ещё в школе вы выяснили про себя подходящий вам способ усвоения знаний. Кому-то важно было вести конспект, кому-то было достаточно послушать учителя, а кто-то запоминал только когда проговорит вслух. Это всё относится к вашему личному способу запоминания и понимания.

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

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

Со сменой профессии ваш жизненный опыт не обнуляется. Всё, что вы знали и умели до поступления на курс может вам помочь в освоении новых знаний. Проводите аналогии с уже известными вам вещами, привязывайте новые термины и понятия к объектам из понятного для вас мира. Мозгу так проще строить связи, меньше тратится энергии.

Практика

Теория это, конечно, прекрасно. Но мы все учимся для освоения конкретных практических навыков.

Большинство курсов измеряют доходимость курсов: количество студентов, успешно закончивших курс. Отсюда возникает необходимость подгонять программу под самых слабых. Лично мне кажется, что это наследие классической педагогики, но сейчас не об этом.

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

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

Широкий кругозор

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

Как можно раньше начните изучать источники информации по интересующей вас теме. Подпишитесь на новости технологий, следите за наиболее яркими представителями профессии, читайте книги, общайтесь с сообществом. Это позволит вам понять всю широту интересной вам области знаний.

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

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

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

Проще говоря не теряйте природную любознательность. Интересуейтесь всем, что окружает вашу будущую профессию.

Основы

Программирование в целом и фронтенд в частности — очень стремительно развивающаяся область. Регулярно появляются какие-то новые фреймворки, технологии, меняются спецификации. В этом хаосе студенту очень легко запутаться и свернуть не туда.

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

Не поддавайтесь на клик-бейты и пёстрые названия, углубитесь в основы. Не пожалеете.

Критическое мышление

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

Зачем всё время жить в ожидании подставы? На самом деле это называется критическим мышлением и поможет вам не раз и не два.

Критическое мышление — способность человека ставить под сомнение поступающую информацию, включая собственные убеждения. Википедия

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

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

Материальный мир

Время

Предположим, что с целью вы определились и мотивация у вас прямо зашкаливает. Настало время распланировать своё обучение. Многие онлайн-курсы бравируют тем, что обучаться можно в любое время, когда захотите, хоть лёжа на диване по воскресениям.

Спешу огорчать вас, что это так не работает. Если вы учились в универе, то помните, что пары всегда были по расписанию. Такое же расписание вам нужно будет составить для себя.

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

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

Расписание может быть любым, в зависимости от ваших временных возможностей. Главное чтобы оно было. Можете полчаса каждый день после работы? Ок, запланируйте эти полчаса. Можете четыре часа в субботу и воскресенье? Ок, пусть будет так. Важны регулярность и постоянство.

Обстановка

В предыдущей части «Онлайн обучение: взгляд очевидца» я упоминала, что существуют санитарные нормы, регламентирующие температуру, освещение, влажность в учебных классах. В случае с онлайн-обучением контроль всех аспектов ложится на вас. И поверьте, не стоит ими пренебрегать.

Понимаю, что у каждого свои условия, но постарайтесь максимально организовать своё пространство для комфортного обучения. Лучше всего учиться сидя за удобным столом на удобном стуле. Обеспечьте хорошее освещение. Если ведёте конспект, то помните, что лампа должна быть с противоположной стороны от ведущей руки, чтобы на записи не падала тень.

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

Идеально, если никто вас не будет беспокоить, не будет никаких отвлекающих факторов, посторонних звуков. Но тут уж как повезёт. В крайнем случае купите хорошие наушники, желательно с шумоподавлением и попросите близких вас не отвлекать.

Физкультура

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

Я не призываю вас готовиться к Iron Man, бегать марафоны или ежедневно тягать железо. Обычной зарядки или прогулки будет вполне достаточно. Наши предки миллионы лет бегали по саваннам, охотились, собирали плоды с деревьев и просто много ходили. Но из-за глобализации, цифровизации и прочих визаций мы сидим часами, а то и днями. Мозг не получает достаточно кислорода и питательных веществ. Я уже молчу про другие неприятные сайдэффекты для остального организма.

Не пренебрегайте физической активностью хотя бы в период обучения. А там, может, и в привычку войдёт =)

«Руки в стороны, ноги на ширину плеч. Раз, два, три, четыре!»

Портфолио

Перефразируя поговорку: «Готовь сани летом, а портфолио на курсах». Если вы учитесь прямо сейчас, посмотрите сколько студентов в вашей группе. Умножьте это количество примерно на 25 потоков за год. Вычтите примерно 20% тех, кто бросит (очень оптимистично). И вы получите большое количество людей, постоянно выходящих на рынок труда с одинаковыми дипломами и с одинаковым набором навыков.

Чтобы повысить свою конкурентоспособность, я советую вам задуматься о портфолио с самого начала обучения и постоянно пополнять его. Причём пополнять не только учебными работами. Так сделают все ваши однокурсники. Тут мы возвращаемся к необходимости дополнительной практики.

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

Заключение

Помните, что кажущаяся простота и доступность знаний — обман и иллюзия. Обучение — тяжёлый и часто изнуряющий труд. Вы несёте ответственность за полученный результат.

Мне очень хочется верить, что мои советы помогут вам в процессе обучения и вы сможете достичь поставленных целей.

Доступный компонент «из коробки»

Thu, 18 Nov 2021 00:00:00 GMT

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

Зачем мне делать что-то доступным?

У вас идеальное зрение? У вас всегда оно будет таким?

Ломали ли вы когда-нибудь руку? Или, может, получали вывих? Возможно, по неосторожности порезали палец? Удобно было пользоваться интернетом одной рукой?

Ломалась ли у вас мышка? Или тачпад? Представьте, что у вас сломался тачпад, при этом вам срочно надо найти сервис для его ремонта, но телефон разряжен, а поисковик сделан так, что с клавиатуры вы не можете перейти по ссылке. Удачи и терпения!

Мы, разработчики, всё ещё не умеем считать упущенную выгоду. Как на одной из конференций сказал Анатолий Попко (незрячий эксперт в сфере невизуальной доступности), он готов тратить деньги в различных сервисах, чтобы вести свой бизнес. Но многие сервисы почему-то не хотят принимать его деньги, не давая пользоваться функциями полноценно.

Делая удобные интерфейсы для людей с особыми возможностями, вы делаете очень удобные интерфейсы для самих себя.

Как люди могут пользоваться вашим сайтом?

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

Со скринридером — сайт озвучивается. Полезно незрячим людям.
С клавиатуры — когда есть возможность пользоваться навигацией без мышки, кнопками Tab, Enter, Space и стрелками. Полезно людям с ограничениями опорно-двигательного аппарата и тем, кто не хочет тянуться к мышке.
Мышкой — когда нет возможности пользоваться клавиатурой.
С включённым зумом — потому что ослабленное зрение.
С включённым контрастом — потому что изначальный контраст не подходит. Полезно людям с цветовой слепотой.
С выключенной анимацией — потому что мельтешение вредит. Полезно людям с эпилепсией.
Левой рукой — потому что так удобнее. Полезно левшам.

Как сразу создавать доступные компоненты?

Делайте по готовым инструкциям, не мудрите. До вас уже многое придумано, и придумано хорошо. На Smashing Magazine есть отличный гайд по теме.
Верстайте семантично — тогда скринридер сможет большую часть задач решить сам, без сложностей со стороны разработки.
Используйте ARIA, если семантики не хватает. Но сначала всё же постарайтесь справиться в пункте № 2.
Мелкие кликабельные области — плохо. Попробуйте своим пальцем попасть на тачах в мелкую кнопку, чтобы закрыть какой-нибудь попап, перекрывающий контент. Бесит? Придерживайтесь минимума в 44 пикселя для меньшей стороны интерактивного блока — этого обычно достаточно для пальца.
Внутри ссылок должен быть текст, иначе скринридер постарается прочитать href ссылки. Вряд ли у вас все адреса на странице красивые и понятные. Нет текста по дизайну — добавьте . А лучше пообщайтесь с дизайнером, договоритесь с ним, какой можно добавить текст.

Не путайте кнопки и ссылки: переход в восстанавливаемое по URL состояние? Это ссылка . Нет перехода? Кнопка

Не используйте только иконки для подписи интерактивных элементов. Пусть это будет текст, не только иконка. Добавьте скрытый span или примените aria-label. По иконке и зрячие не всегда поймут, что хотел сказать автор. Текст универсален для носителей языка.

Подписывайте картинки. Люди без зрения тоже хотят понимать, что там. Не можете подписать — поставьте пустой alt="", иначе скринридер постарается прочитать URL картинки. Если у вас настроена раздача статики с CDN, то адреса картинок будут не самые красивые и понятные.

Не прячьте визуальный фокус. Если нужно спрятать «некрасивый» дефолтный фокус, оформите кастомный. Объясните дизайнеру, что прятать нельзя. Если он против, попросите его добавить cursor: none в его графический редактор для большей наглядности проблемы.

Захватывайте фокус в модальных окнах. Фокус не должен проваливаться за пределы модалки.

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

Верните фокус обратно к кнопке, которая открыла модальное окно, после того, как оно закроется.

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

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

Используйте медиафичи prefers-*, которые подхватывают настройки операционной системы. Например, prefers-reduced-motion или prefers-contrast. Если пользователь поставил такую настройку, у него есть на это причины.

Не используйте мелкий шрифт, он бесит даже людей с идеальным зрением. Я, например, мелкий шрифт не вижу. Дизайнер говорит, что так надо? Попросите его выставить в графическом редакторе font-size: 5px !important, чтобы лучше продемонстрировать проблему.

Не переусердствуйте. Делать идеальную доступность нет смысла, пока не работают основные сценарии. Нужно делать хорошо и дать возможность пользоваться важными сценариями сайта. Когда кнопка «Купить» в интернет-магазине не работает, идеальные подписи к картинкам бессмысленны.

Используйте правильные тексты. Не пишите на кнопке «Кнопка», роль элемента и так читается скринридером. Он умеет зачитывать роли для списков, кнопок, ссылок, навигации и других элементов.

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

Пути в кастомных свойствах. История одного бага

Tue, 09 Nov 2021 00:00:00 GMT

В недавнем выпуске «Веб-стандартов» обсуждались релиз-ноуты Safari TP 133, среди которых оказался интересный фикс. О нём рассказал Никита Дубко:

Беда была в том, что CSS-переменные работали не так: если вы в CSS-переменную задаёте URL, то он резолвился относительно HTML-документа. Оказывается, эта история связана с тем, как работают CSS-переменные. В Safari починили, или скорее поменяли это поведение, и теперь CSS-переменные точно так же резолвятся относительно URL стилевой таблицы — вполне себе ожидаемая штука.

Поведение действительно поменяли, но если сказать точнее — скорее исправили ошибку, ведь в других браузерах всё работало по-другому, согласно спецификации. А ещё всё намного сложнее, чем кажется. Но начнём с начала.

История фикса

Несколько месяцев назад я узнал (не без помощи Руслана Берендеева), что в WebKit функция url() в кастомных свойствах резолвится не так, как ожидается, в отличие от движков Gecko (Firefox) и Blink (Chrome). Я нашёл уже давно заведённый баг 200092 — в нём была тишина, которую я и не надеялся расшевелить. Оставил этот баг на несколько месяцев, пока в него не заглянул Вадим Макеев. И, оказывается, там отвечают 😮

Тогда я решил посмотреть, как теперь дела обстоят с этим багом, и с удивлением обнаружил, что в заброшенной ветке сломанные пути починились, но почему-то не везде. Разница в коде небольшая, но существенная. Вдобавок оказалось, что надо учесть ещё одну особенность, шлейфом тянущуюся из уже исправленного на тот момент бага 198512, из которого в уже знакомый мне баг пришли Вадим и разработчик WebKit Дарин Адлер. Обе эти особенности кода обозначу ниже.

Для прояснения ситуации я решил собрать тест, максимально совпадающий с описанием из заметки в спецификации, на которую сослался Дарин.

Например, относительные URL-адреса в CSS сопоставляются с базовым URL-адресом таблицы стилей, в которой объявляется значение. Однако, если кастомное свойство, к примеру, --my-image: url(foo.jpg) объявляется в таблице стилей /a/style.css, оно не будет немедленно преобразовано в абсолютный URL-адрес; если эта переменная позже будет использоваться, например background: var(--my-image), в другой таблице стилей /b/style.css, то она преобразуется в путь /b/foo.jpg.

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

Но оказалось, что я заметку понял как описание того, как это должно работать, а Дарин — как не должно. В итоге, до выяснения правильного поведения, ни о каких правках в коде не могло быть и речи. Подход правильный, надо было разобраться. Понимая, что со своим так-себе английским могу не замечать какого-то нюанса в формулировке, я стал просить помощи известных мне гуру спецификации. И таки помог «человек-спека» — Илья Стрельцын. Он заметил, что вообще-то этот баг про регистрируемые кастомные свойства, которые:

Передаются не как токены, а уже как обработанные значения.

Кажется это вывело из тупика, оживилось обсуждение, в результате которого, чтобы не менять этот, Дарин открыл новый баг 230243, про взаимоотношения URL уже с обычными кастомными свойствами. Исправил и закрыл. Дело за отгрузкой этого исправления в Safari.

Тест работы путей с кастомными свойствами

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

Обычное (не регистрируемое) кастомное свойство объявляется в стилевом файле в одной директории /a/style.css:

.test {
    --my-image: url('foo.svg');
}

А используется оно в другой /b/style.css:

.test {
    background: var(--my-image);
}

Этот вариант я назвал inside, где url() находится внутри кастомного свойства.

Но Дарин с Вадимом пришли из бага, пример кода в котором можно назвать beside, где url() не в кастомном свойстве, а просто рядом, через пробел от var() с кастомным свойством, в котором может быть вообще любое значение, например цвет:

.test {
    background: url('foo.svg') var(--my-color);
}

И раз уж возможно такое, то нельзя исключать и вариант outside, где var() находится от url() вообще в соседнем (через запятую) значении множественного значения.

.test {
    background:
        url('foo.svg'),
        linear-gradient(
            var(--my-color),
            var(--my-color)
        );
}

Но и это ещё не всё. Упомянутое ранее небольшое, но существенное, отличие в коде, которое ломало разрешение пути — это всего лишь форма свойства, в значении которого применяется путь. Представленные выше варианты используют сокращённую форму свойства, и все их можно назвать shorthand. Для beside возможен только такой вариант. Но остальные сценарии возможны и с отдельными (не сокращёнными) формами свойства — longhand. В таком случае inside выглядит так:

.test {
    background-image: var(--my-image);
}

Вариант outside выглядит вот так:

.test {
    background-image:
        url('foo.svg'),
        linear-gradient(
            var(--my-color),
            var(--my-color)
        );
}

Во всех случаях url() содержит путь до файла без переходов по директориям url('foo.svg'). И во всех случаях он должен резолвиться в путь /b/foo.svg, по которому находится изображение:

Для inside стоило предусмотреть разрешение пути по месту объявления кастомного свойства, то есть в путь /a/foo.svg, поэтому там я разместил изображение:

И остаётся последнее из возможных разрешений пути — рядом с HTML-страницей /foo.svg:

Вся структура проекта выглядит так:

├─ a
│  ├─ foo.svg
│  └─ style.css
├─ b
│  ├─ foo.svg
│  └─ style.css
├─ foo.svg
└─ index.html

А вот и сам тест во фрейме или, если удобно, на отдельной странице.

До 14-й версии в Safari все пять сценариев теста фэйлились. Начиная с 14.1 — все варианты теста с shorthand стали проходить успешно (видимо это и был фикс бага 198512), но оба longhand — фейлятся.

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

Думаю, если повнимательнее присмотреться, например, к коду сценария longhand + outside, то станет понятно, что разрешение пути до /foo.svg ну никак не может считаться нормальным поведением движка браузера. Это очевидная ошибка. Поэтому всё-таки «починили», а не «поменяли» поведение.

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

Заключение

Напоследок пара советов:

Если вам понадобится заиспользовать url() хотя бы где-то рядом (внутри одного свойства) с использованием кастомного свойства, и тем более url() внутри кастомного свойства — используйте для этого пока, до релиза фикса, сокращённые свойства background и mask, а не отдельные background-image и mask-image.

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

Веб и устройства: баланс между пользой, безопасностью и приватностью

Thu, 28 Oct 2021 00:00:00 GMT

Около года назад, Apple опубликовала список API для веба, которые они не собираются внедрять в Safari из соображений приватности и безопасности. Они беспокоились, что эти API позволят создавать цифровой след пользователей и отслеживать их. И это конечно же большое табу с точки зрения современной приватности. Звучит разумно, верно?

Что за API оказались в том списке? Среди прочих, аппаратные API, которые появились в браузерах Chrome и Edge за последние пару лет:

WebBluetooth
WebHID
WebMidi
WebNFC
WebSerial
WebUSB

Звучит ну прямо очень опасно, да?

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

Но нам следует взглянуть на фактическую опасность, рассмотреть её должным образом и не верить всяким «нутром чую» или страшилкам из того эпизода «Чёрного зеркала», что мы однажды видели…

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

Любой API, потенциально влияющий на безопасность и приватность, не может использоваться на сайте без согласия пользователя. Такой сайт должен запросить разрешение у пользователя, чтобы использовать веб-камеру — аналогично и для использование Bluetooth-устройства или USB-устройства. И разрешение получает не API целиком — оно даётся отдельно взятому устройству. Сайт не знает, какие есть устройства, и не может получить их список. Сайт может только попросить разрешение для доступа к определённому типу устройств. Он его либо получит, либо нет.

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

Проблемы с безопасностью

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

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

Я бы рад сказать, что это невозможно, но, к сожалению, это существующая проблема. Социальная инженерия — это общая проблема, которая не ограничивается лишь использованием API.

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

Во-первых, необходимо найти уязвимое устройство, которое принимает драйверы или код, не подписанный производителем. У большинства устройств такой проблемы не будет, но не у всех. Во-вторых, у пользователей, на которых направлена атака, должно быть это устройство. У большинства, скорее всего, его не окажется. И, в-третьих, ещё нужно обмануть пользователей, чтобы они выбрали это устройство. Скорее всего, большинство засомневаются и откажутся. И наконец, запрашивать доступ к устройству — довольно подозрительное дело, которое легко заметить. Я не думаю, что такого рода атаку можно будет поддерживать длительное время.

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

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

Блокировка доступа к отдельным устройствам, у которых известны уязвимости.
Запрет доступа к целому классу устройств с проблемами.
Удалённое прекращение работы API, когда его активно используют для эксплуатации уязвимости в устройстве.

Несмотря на это, риск всё ещё не нулевой.

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

В 2018 году оказалось возможным извлечь ключ из устройства двухфакторной авторизации Yubico U2F, используя WebUSB в обход проверки происхождения запроса, которую обычно делают браузеры. После того, как это стало известно, Google сразу отключил WebUSB и следом выпустил обновление, которое снова включало WebUSB, но добавляло все устройства Yubico в чёрный список.

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

Не только Google думает, что эти API достаточно безопасны, чтобы предлагать их реальным пользователям. Так же думают Microsoft и Samsung. В действительности, эти API поставляются на 70% мобильных браузеров и 78% десктопных браузеров по всему миру. И поставляются уже достаточно давно.

Но я думаю, что настоящий безопасный выбор лежит не между браузерами с API и браузерами без API.

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

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

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

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

Приватность и цифровой след

Что насчёт цифрового следа? Возможно ли проследить цифровой след пользователя, используя эти API?

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

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

Такие точки могут быть ничем не примечательны сами по себе с точки зрения приватности. Это могут быть даже вещи, которые по иронии были предназначены для улучшения приватности. Например, HTTP-заголовок «Do Not Track». Он выключен по умолчанию, поэтому это идеальная опорная точка для отслеживания пользователей. Например, если у вас есть набор из 1 миллиона пользователей и один из сотни включил этот заголовок. Теперь вы уже можете наблюдать за 1 из 10 000 пользователей вместо одного из миллиона. Теперь попробуйте скомбинировать это с ещё хотя бы 30 типами вполне невинных опорных точек и вы можете отслеживать конкретных пользователей на разных сайтах — святой грааль отслеживания пользователя.

HTTP-заголовок «Do Not Track» был удалён из Safari как раз из соображений выше. Ну и правильно.

Вопрос вот в чём: добавляют ли эти API опорные точки для отслеживания конечных пользователей?

Теоретически, да. Простая поддержка таких API уже может считаться опорной точкой. Но на практике — нет. Возьмём, например, WebBluetooth. Он был доступен во всех версиях Chrome, начиная с 56-й. Поэтому единственное, о чём это говорит, так это то, старше ли Chrome 56-й версии или нет. И эту информацию можно добыть, просто заглянув в строку User-Agent, которая всегда есть в HTTP-запросе. Поэтому эти точки выглядят крайне бесполезными для создания цифрового следа.

Для цифрового следа нужны API, дающее разные результаты на разных устройствах. Например, установленные шрифты или GL-расширения, поддерживаемые графической картой. Эти параметры могут отличаться на устройствах с одинаковыми версиями браузеров. Такие опорные точки добавляют энтропии в цифровой след.

И что же эти API? Дают ли они какую-то дополнительную информацию для цифрового следа? Если браузер знает, какие USB-устройства подключены к вашей ОС или какие Bluetooth-устройства доступны поблизости, я бы сказал: «да, конечно». Но эти API работают не так. Их проектировали, зная о цифровом следе, поэтому они не могут использоваться для этого напрямую.

Возьмём для примера снова WebBluetooth как представителя аппаратных API.

Давайте проговорим это ещё раз. Вы не можете получить список устройств поблизости. Так нельзя сделать ни с помощью WebBluetooth, ни с помощью каких-либо других API устройства. Эта информация не доступна сайтам. Вы можете не переживать, что сайты увидят ваши устройства и смогут идентифицировать вас через них. Потому что они не смогут.

Что сайты смогут сделать, так это сказать браузеру, с какими устройствами они бы хотели взаимодействовать. Обычно вы даёте API набор фильтров, основанных либо на имени устройства, либо на его сервисах. И тогда вы просите у браузера разрешение подключиться к устройству.

Затем браузер показывает попап, спрашивающий разрешение. В нём перечислен список устройств, соответствующий фильтрам, которые вы запросили. Этот список доступен только самому пользователю, ни один скрипт на сайте его не видит. Дальше пользователь может дать доступ к определённому устройству или отказать в доступе в целом.

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

API устройств просто не подходят для создания цифрового следа. Они слишком ненадёжны и очевидны, когда используются.

Так что там с Safari…

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

Я даже не против, если Safari не будет внедрять эти возможности. Каждый производитель браузеров должен самостоятельно оценивать баланс между пользой, безопасностью, приватностью, и решать, стоит ли оно того. Apple подумала и решила, что не стоит. Я считаю иначе, но это ничего.

Я уверен, что они игнорируют опасность перевода пользователей на нативные приложения, но понимаю, почему для Apple это не выглядит так.

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

Подборка ссылок для знакомства с доступной разработкой

Fri, 01 Oct 2021 00:00:00 GMT

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

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

Отбирала их по нескольким критериям:

о них часто упоминают другие разработчики;
в текстах есть важная или актуальная информация;
эти источники помогли мне самой в изучении доступности.

Постаралась собрать здесь и ресурсы на русском языке, но пока их больше на английском. Как и с другими веб-технологиями, многие специалисты по доступности из англоговорящих стран.

Основы основ

Про веб-доступность в общем

Ресурсы WAI W3C

Один из главных двигателей доступности — W3C WAI (W3C Web Accessibility Initiative). Это специальная рабочая группа W3C. У неё много базовых материалов по этой теме. Например, обзор основ доступности. В нём разобраны основные понятия, категории пользователей, которым критически важна доступность, как они пользуются сайтами, принципы доступности и другие важные вещи.

MDN

На MDN есть отдельный раздел про доступность и вводное руководство. Многие материалы переведены на русский.

Google Web Fundamentals

Google тоже писала вводные статьи про доступность. Например, о важности семантической вёрстки, про доступные стили и управление фокусом.

WebAIM

Это некоммерческая американская организация при Университете штата Юта. Проводит аудит компаний, сертификацию и обучает другие команды доступности.

На её сайте тоже много базовых материалов. Ещё WebAIM каждый год проводит исследования пользователей с особыми потребностями. Например, из них можно узнать о распространённых проблемах в вебе или рейтинге скринридеров и операционных систем.

A Little Book of Accessibility

Сборник советов и принципов доступности, которые повлияли на стратегию BBC.

Гайдлайны и стандарты

У W3C WAI есть краткий обзор стандартов по доступности. Самые важные — спецификация HTML, WCAG и WAI ARIA.

HTML

Во многих статьях, постах и руководствах встретите идею о том, что доступность начинается с семантики. А где самая полная информация об HTML-тегах и атрибутах? Конечно в стандарте HTML.

Не призываю читать её от начала до конца, но туда стоит заглядывать в любой непонятной ситуации с разметкой.

Другие полезные ссылки:

HTML: A good basis for accessibility с MDN.
Периодическая таблица HTML-тегов.
HTML5 Doctor — на сайте есть список всех HTML-элементов и их краткое описание, а ещё статьи о хороших практиках.
HTML5 Accessibility — доступность фич HTML5 в популярных браузерах.
HTMHell — проект Мануэля Матузовича, который собирает примеры плохой и хорошей разметки из реальных проектов.

WCAG

WCAG (Web Content Accessibility Guidelines) — руководства по обеспечению доступности веб-контента. Содержат основные рекомендации о том, как сделать любой цифровой продукт доступным.

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

У руководств несколько версий:

WCAG 2.1 — актуальна на момент выхода статьи, есть перевод на русский.
WCAG 2.2 — будет принята до конца 2021.

Ещё несколько полезных ресурсов:

How to Meet WCAG — справочник по критериям успешности и техникам WCAG. Поможет разобраться, что конкретно от вас хотят в руководствах.
WCAG Guide — наглядные карточки с критериями успешности.
Understanding the Web Content Accessibility Guidelines — руководство на MDN.

WAI ARIA

WAI-ARIA (WAI Accessible Rich Internet Applications Suite) — рекомендации, которые описывают вспомогательные техники создания более доступного контента для скринридеров (программ чтения с экрана). Расширяет возможности HTML с помощью специальных атрибутов и ролей. В 2021 действует WAI-ARIA 1.1.

Дополнительные ссылки:

Обзор WAI-ARIA на MDN.
Руководство по основам ARIA на MDN.
Периодическая таблица ролей ARIA 1.1.
ARIA Spec for the Uninitiated — серия статей в блоге Deque, есть перевод первой части.

Небольшая справка: Deque — американская компания, которая проводит аудиты, разрабатывает инструменты для тестирования доступности и занимается обучением.

Accessibility API

Для большего понимания того, что происходит под капотом у браузеров, полезно копнуть чуть глубже в сторону Accessibility API.

Больше всего технических подробностей содержится в рекомендациях W3C Core Accessibility API Mappings 1.1.

Дерево доступности

Дерево доступности (accessibility tree) похоже на DOM-дерево, только вместо HTML-элементов в него попадают их доступные роли и имена. Именно с ним взаимодействуют скринридеры, когда им нужно прочитать контент страницы.

The Accessibility Tree — вводная статья Google.
Accessibility APIs: A Key To Web Accessibility — одна из самых подробных и популярных статей с разбором того, как работает доступность в браузерах.
Accessibility API и доступность — статья на русском, в которой тоже разбирается дерево доступности.
Список доступных имён и ролей HTML-элементов в дереве доступности Chrome.

AOM

Если интересно, то дополнительно можно почитать про AOM (Accessibility Object Model, Объектная модель доступности). Она похожа на DOM, только нужна для доступа JavaScript к дереву доступности. Пока что это экспериментальный JavaScript API.

Информацию из первых рук найдёте в репозитории рабочей группы, которая разрабатывает этот API.

Вспомогательные технологии

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

Список и обзор вспомогательных устройств для людей с глухотой и особенностями речи на сайте американской NIDCD (The National Institute on Deafness and Other Communication Disorders).
Список вспомогательных технологий для людей со слепотой и сниженным зрением на сайте AFB (The American Foundation for the Blind).

В веб-доступности много внимания уделяется скринридерам. Это одна из самых популярных вспомогательных технологий, которой пользуются люди со слепотой, сниженным зрением и, на самом деле, не только они. Из статьи «What is a screen reader?» можно больше про них узнать.

У скринридеров есть особенности поддержки HTM-тегов, атрибутов и ARIA. Ссылки по этой теме собраны дальше в разделе про тестирование.

Пользователи

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

Inclusive design in action — фильм из гайда Microsoft.
Раздел о пользователях из гайда по доступности Сбербанка.
Web Accessibility Perspectives Videos — видео с пользователями в разных ситуациях на сайте W3C.
Videos of people with disabilities using tech — ещё одна подборка видео про пользователей вспомогательных технологий на Axess Lab.

Законы

В какой-то момент на вас начнут со всех сторон наступать странные слова и аббревиатуры. ADA, Section 508, EN 301 549. Это всё связано с законами, которые регулируют доступность.

Раздел про законы в статье о доступности на Википедии — краткий разбор законодательства о доступности в разных странах.
Web Accessibility Laws & Policies — краткая информация W3C WAI о законах некоторых стран, которые регулируют доступность.
Доступность и закон — статья на «Веб-стандартах» с обзором основных европейских, американских и российских законов в области доступности. Кстати, в 2020 в России был принят новый ГОСТ Р 52872-2019.

Чек-листы

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

Самые популярные чек-листы:

Пишем доступный код

Официальные руководства W3C

Обзор полезных ресурсов для разработчиков — базовые советы и подсказки по доступной разработке.
Web Accessibility Tutorials — больше подробностей про то, как сделать доступные меню, изображения, таблицы, формы, карусели и структуру страниц.
Index of ARIA Design Pattern Examples — примеры правильного использования ARIA в компонентах.

Другие руководства

A11ycasts — серия коротких видео Роба Додсона из Google про основы технической доступности.
A Complete Guide To Accessible Front-End Components — серия коротких постов на Smashing Magazine. Разобраны полезные техники и инструменты для создания доступных компонентов.
Accessibility for front-end developers — небольшой чек-лист в гайде американской Администрация общих служб с базовыми советами для разработчиков.
Accessible to all — советы по доступной разработке на web.dev.
Гайдлайн Сбербанка о доступности для веб-разработчиков.
Веблайнд — рекомендации на русском о доступной разработке для людей с нарушениями зрения.
101 Digital Accessibility (a11y) tips and tricks — много практических советов о доступной разработке.
Inclusive Components — серия статей Хейдона Пикеринга. Подробный разбор того, как правильно сверстать и задизайнить карточки, переключатели тем, тултипы, слайдеры, оповещения, таблицы, выпадающие секции, вкладки, меню и списки дел. На «Веб-стандартах» есть переводы части статей.
Руководство по доступности на W3Schools — краткие советы о доступной разметке. Например, про ориентиры, заголовки, ссылки, кнопки и формы.

Библиотеки доступных компонентов

A11Y Style Guide — опенсорсная библиотека доступных паттернов с примерами разметки и демками доступных карточек, форм, навигации, заголовков, списков, ссылок «Читать дальше».
Библиотека кода Deque — примеры доступных компонентов. Например, вкладок, слайдеров, каруселей и чекбоксов. Пока в бете.
Компоненты из дизайн-системы GOV.UK.
Компоненты из дизайн-системы правительства Новой Зеландии — можно выбрать формат сниппетов, например: HTML, Handlebars, React JavaScript или TypeScript.
Компоненты из проекта «No Style Design System» — дизайн-система из книги «Form Design Patterns» Адама Сильвера. Можно посмотреть, как сделать доступно автозаполнение, поле для пароля с возможностью его показа или выбор даты.
Accessible Components — репозиторий Скотта О’Хары на GitHub. Есть аккордеон, вкладки, переключатели, тултип, модальное окно, хлебные крошки, формы.
Vuetensils — библиотека доступных Vue-компонентов.
Chakra — библиотека доступных React-компонентов.
Angular Material — доступные Angular-компоненты от Google.

Доступные CSS и JavaScript

В основном в руководствах, гайдах и библиотеках компонентов упор делается на HTML. Это логично, но CSS и JS тоже могут влиять на доступность.

CSS and JavaScript accessibility best practices — руководство на MDN.
CSS Can Influence Screenreaders — Бен Майерс про все возможные ситуации, когда CSS может повлиять на скринридеры.
The effect of CSS on screen readers — дополнение к посту Бена Майерса, которое сверяет: изменилась ли в 2021 году ситуация с CSS и доступностью.
Modern CSS Upgrades To Improve Accessibility — как CSS помогает улучшить доступность.

Дизайн

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

Инклюзивный дизайн

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

Accessibility, Usability, and Inclusion — W3C про разницу между доступностью, юзабилити и инклюзией.
Inclusive Design Principles — общие принципы инклюзивного веб-дизайна.
Гайд по инклюзивному дизайну Microsoft.

Советы по дизайну

Постеры про доступность — проект команды по доступности сайта британского правительства GOV.UK. Проиллюстрированы советы о том, как можно и как нельзя дизайнить для людей со сниженным зрением, глухотой, расстройствами аутистического спектра, дислексией, моторными и физическими особенностями и для пользователей скринридеров.
Раздел с дизайн-паттернами на Smashing Magazine — статьи про паттерны инклюзивного дизайна: кнопки, слайдеры, аккордеоны, фильтры и много чего ещё.
The Mental Health Patterns Library — библиотека доступных принципов и паттернов для людей с особенностями ментального здоровья.
Манифест о доступности для людей с цветовой слепотой — базовые правила для доступного интерфейса с точки зрения цвета.
Making Content Usable for People with Cognitive and Learning Disabilities — рабочие замени специальной группы Coga TF (Cognitive and Learning Disabilities Accessibility Task Force) из W3C о том, как сделать интерфейс доступным для людей с когнитивными особенностями.
Доступность в дизайне — гайдлайн Романа Шамина, арт-директора Evil Martians, с подробностями о том, как создать доступную дизайн-систему, есть перевод на английский.

Тестирование

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

Accessibility best practices for screenreader testing — Шери Бирн-Хабер с кратким описанием основных принципов тестировании доступности.
Web Accessibility Evaluation Tools List — список W3C WAI со всеми одобренными ей инструментами для оценки доступности.
A Complete Guide To Accessibility Tooling — Ник Чан разбирает самые популярные инструменты для автоматического тестирования, проверки контрастности, линтеры и другие полезные тестерские штуки.
Accessibility Support — аналог Can I Use в мире доступности. Можно проверить поддержку ARIA-атрибутов и ролей, а также HTML-элементов и атрибутов в разных скринридерах.
База поддержки HTML-элементов PowerMapper Software, также на сайте есть базы по атрибутам, ARIA и WCAG.
Гайдлайн BBC по тестированию в скринридерах — поэтапное описание, как проводить тестирование скринридеров на разных платформах.
Шорткаты и жесты в скринридерах — есть JAWS, NVDA, Narrator, VoiceOver и TalkBack.

Курсы

Здесь собрала только пару популярных курсов, о которых часто упоминают. Больше ссылок на платные и бесплатные англоязычные курсы найдёте на Digital a11y.

Introduction to Web Accessibility — курс W3C, есть возможность пройти бесплатно с некоторыми ограничениями.
Бесплатный курс по доступности от Google.
Платный курс про цифровую доступность Валерии Курмак.

Быть в курсе

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

Сообщества

Статьи и посты о доступности на CSS-Tricks.
Категория «Accessibility» на Smashing Magazine.
Блог The A11Y Project — опенсорсный проект, посвящённый всем аспектам веб-доступности.
Посты по тегу «a11y» на DEV Community.
Статьи «Веб-стандартов» по тегу «a11y» — авторские статьи и переводы, да вы и сами знаете.
Хаб про доступность на Хабре — авторские посты и переводы статей про доступную разработку.

Подкасты и стримы

A11y Rules Podcast.
13 Letters — подкаст об универсальном дизайне, законодательстве и лучших практиках цифровой доступности со специалистами из разных стран.
Подскаст «Веб-стандарты» — не концентрируется только на доступной разработке, но новости и события из мира доступности обсуждаются почти в каждом выпуске.
Accessibility Talks — стримы о доступности.
Стримы Some Antics на Twitch и их записи на YouTube — проект Бена Майерса о доступной разработке в формате дискуссий с разработчиками, тестировщиками, дизайнерами и всеми, кто занимается доступностью.
Technica11y — стримы про проблемы и хитрости, связанные с технической доступностью.
Список других подкастов на The A11Y Project.

Конференции и митапы

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

Inclusive Design 24 — 24-часовая онлайн-конференция об инклюзивном дизайне и доступности.
Axe-con — конференция Deque о доступности для разработчиков, дизайнеров, менеджеров и всех неравнодушных.
#a11yTO Conf — трёхдневная онлайн-конференция, состоящая из тщательно отобранного «плейлиста» из лекций, демо и лайтнингов.
Accessibility Club Minsk — русскоязычный митап о доступности, часть международной сообщества Accessibility Club. Записи митапов на YouTube.
Pitera11y_meetup — митап о доступности в Санкт-Петербурге. Плейлист записей докладов на YouTube.
Список других событий на The A11Y Project.

Персональные блоги

Много технический деталей прячется в персональных блогах.

Tink — блог Леони Уотсон, директора TetraLogical, члена W3C Advisory Board и BIMA Inclusive Design Council, а также сопредседателя W3C Web Applications Working Group.
Блог Скотта О’Хары, бывшего дизайнера, который сейчас специализируется на доступной разработке и UX.
Блог Бена Майерса, веб-разработчика и адвоката доступности.
Accessabilly — блог Мартина Менгеле, фронтенд-разработчика и консультанта по доступности.
Блог Сары Суайдан, разработчицы пользовательских интерфейсов и дизайн-систем, автора статей и спикера. Блог не посвящён доступности, но она часто становится темой статей.
Блог Эрика Бэйли, адвоката доступности и инклюзивного дизайна, мэйнтейнера The A11Y Project.
HTML Accessibility — блог Стива Фолкнера, технического директора TPGi, ведущего разработчика Web Accessibility Toolbar, члена W3C Web Platforms Working Group и W3C ARIA Working Group.
Блог Адриана Розелли, консультанта, автора статей, спикера, члена нескольких рабочих групп W3C. Например, W3C HTML Accessibility Task Force и W3C Accessible Rich Internet Applications Working Group.

Конечно, не обязательно начинать с этих блогов. Можете сами попробовать найти в Твиттере интересных вам разработчиков и следить за их блогами через RSS, рассылку или другим удобным способом.

Рассылка

Здесь собраны рассылки, на которые я подписана. Другие можете поискать у The A11Y Project.

Accessibility Weekly — еженедельная рассылка с полезными статьями, постами и новостями за неделю. Приходит по понедельникам.
The WebAIM Newsletter — ежемесячная рассылка.

Другие подборки ссылок

Public Library — библиотека, собранная компанией Stark, которая занимается разработкой инструментов для проверки доступности.
Digital Accessibility Resources на Digital A11y.
Список ресурсов по доступности на The A11Y Project.

Как не дать текстовым глифам превратиться в эмоджи

Wed, 29 Sep 2021 00:00:00 GMT

В прошлом году передо мной стояла интересная задача: сделать символ сердечка частью заголовка страницы. Мы организовывали конференцию «Я Люблю Фронтенд», а слово «Люблю» для большей эмоциональности хотели заменить символом сердечка.

Казалось бы, какие могут быть проблемы?

Если у вас есть заголовок «Я ❤ Фронтенд», он рендерится по-разному в разных браузерах в разных операционных системах. Например, на Android и iOS сердечко выглядит как эмоджи. И это огромная проблема, если вам нужно этот заголовок стилизовать.

Юникод

Всё дело в рендеринге. Никита Прокопов описал этот нюанс в своей подробной статье про эмоджи.

Каждый символ, который вы используете, имеет свою UTF-8 последовательность, свой код. Например, английская буква A имеет код U+0041, буква Z — U+005A, символ $ — U+0024 и так далее. То же касается и эмоджи: ❤ имеет код U+2764.

Вы можете вставлять символы в свой HTML как Юникод-последовательность, а не готовыми символами.

Я ❤ Фронтенд
или
Я ❤ Фронтенд

&#x — префикс для указания Юникод-последовательности.

Но что делать, если текущий указанный шрифт не содержит внутри себя глифа, который может отрендерить ваш UTF-8 символ? Операционная система пытается найти любой шрифт, который содержит такой глиф. Для iOS это будет Apple Color Emoji, для Android — Noto Color Emoji. Но, кажется, мы можем контролировать этот процесс.

Шрифты

Первое решение — иметь в наличии шрифт, который содержит все необходимые нам глифы. Например, Arial. Или какой-то кастомный шрифт. Вам нужно добавить его в фолбеки внутри CSS.

body {
    font-family: 'Text Font', 'Custom Glyphs Font', sans-serif;
}

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

Селекторы варианта начертания

К счастью, есть другое решение. В UTF есть специальные символы для управления рендерингом — селекторы варианта начертания (англ. variation selectors). Символ U+FE0E просит ОС и браузер отрендерить предыдущий глиф в виде текста, а U+FE0F — в виде эмоджи.

Давайте попробуем.


    ☀ может отрендериться по-разному.
    ☀️ должен выглядеть как эмоджи солнца.
    ☀︎ должен выглядеть как текстовый символ солнца.

☀ может отрендериться по-разному.
☀️ должен выглядеть как эмоджи солнца.
☀︎ должен выглядеть как текстовый символ солнца.

Получается, если вам нужно выключить эмоджи в тексте, нужно сконвертировать выбранный символ в последовательность UTF-8 или UTF-16 (например, при помощи symbol.codePointAt(0).toString(16) в JS), потом добавить к этому символу ︎.

Я ❤︎ Фронтенд

И это всё не работает для эмоджи сердечка на Android. Я не знаю, почему. Когда мы тестировали это в прошлом году, всё было хорошо, но… Вы можете поиграть с различными символами в песочнице. Но как по мне, что-то лучше, чем ничего.

Доступность

Помните, что все эмоджи имеют своё текстовое представление. Например, ⭐︎ — это «белая средняя звезда», ► — «чёрная стрелка, указывающая вправо». И скринридеры будут использовать эти тексты.

В итоге наш заголовок «Я ❤ Фронтенд» зачитывается утилитой VoiceOver как «Я Красное сердце Фронтенд». Кажется, это не то, что мы хотели сказать.

Чтобы починить это, используйте глифы правильно.

❤

Итоговый результат, который мы использовали на сайте конференции, ниже.


    Я 
        ❤︎
     Фронтенд!

Источники

Пять правил использования ARIA

Mon, 27 Sep 2021 00:00:00 GMT

Эта статья — вольный перевод оригинала. Я добавляю свои примеры и мысли, пишу как чувствую и ставлю смайлики :) Автор статьи сказал, что ему понравилась моя интерпретация! Джерард занимается доступностью в Twitter и попросил поделиться с вами ссылкой на его курсы по доступности. Курсы лаконичные и очень понятные, я их посмотрела по 10-дневной бесплатной подписке. Итак, к делу!

Глафира Жур.

Опасности, которые таит в себе ARIA

В оригинальной статье введение более содержательное, так что почитайте его хотя бы ради практики английского языка :) Я передам только несколько тезисов — прим. переводчицы.

ARIA — (Accessible Rich Internet Applications) это набор атрибутов, который позволяет сделать наши приложения более доступными, особенно если они написаны на JS. Из моего опыта — это, например, легаси-код, где давно-давно наверстали дивами, а теперь надо как-то добавить доступность, но нет доступа к HTML.

Когда вы узнаёте о существовании ARIA, вы начинаете везде использовать эти атрибуты, где бы только ни захотели. Например, у вас React-компонент (типичный, на дивах), и вам нужно, чтобы скринридер начал читать его правильно, поэтому вы добавляете компоненту роль, например, role="button" и какие-то ещё важные ARIA-атрибуты (aria-required, aria-disabled и так далее), но забываете про клавиатуру. Ошибка тут в том, что вы мало что знаете про ARIA, поэтому вероятность упустить нечто важное крайне высока. Дальше выясняется, что некоторые ARIA-атрибуты могут не иметь поддержки на определённых платформах или сочетаниях браузер + скринридер.

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

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

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

Важно: роли (и вообще любые ARIA-атрибуты) не добавляют элементам никаких стилей и поведения!

У ролей есть классификация. Например, бывают роли для виджетов, для структуры документа, для лайв-областей, которые как-то обновляются на фоне независимо от действий пользователя и о чём-то ему сообщают. Практически для каждой роли есть свой набор обязательных ARIA-атрибутов. Некоторые роли нельзя использовать отдельно от родительских ролей.

Вот и пробежались по введению в статью :) Переходим к правилам!

Пять правил использования ARIA

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

Правило 1

Не используйте ARIA

Читая это правило, я всегда очень радуюсь — так однозначно и бескомпромиссно оно звучит :) На практике смысл его в том, что сначала вы должны полностью положиться на HTML и использовать его семантику, и только тогда, когда вам не хватило или есть какой-то сложный составной случай (например, аккордеон или вкладки) — тогда подключайте ARIA. Также приходится использовать эти волшебные атрибуты в уже упомянутом мной легаси-коде, где нет доступа к HTML и можно только с помощью JS добавлять что-то к существующим тегам.

Правило 2

Не изменяйте семантику нативных контролов.

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

была table, и скринридер говорил, что вы попали в таблицу, такой-то столбец, такая-то строка;
вы не решились перевёрстывать все места и просто добавили таблице role="list", её детям тоже расставили нужные роли;
скринридер теперь читает это как список.

Так вот, не переопределяйте дефолтную семантику без острой необходимости! Лучше замените тег:

превратится в

Когда мне приходится менять семантику:

если нужно спрятать таблицы для раскладки от скринридера (чтобы он не читал, что это ячейка таблицы) — задаю role="presentation" для таблицы;
если со значимой картинкой — могу задать role="img";
если это
в составе виджета и для него нет HTML-эквивалента (например, tab, tablist, tabpanel);
иногда бывают баги, например, есть

Уровни	Скринридер	Браузер	Поведение
7–9	JAWS	Все	Сбрасываются ко второму уровню
7–9	NVDA	Все	Читаются с заданным уровнем
7–9	VoiceOver	Все	Читаются с заданным уровнем
7–9	Narrator	Все	Читаются с заданным уровнем
10+	JAWS	Все	Сбрасываются ко второму уровню
10+	NVDA	Chrome	Сбрасываются ко второму уровню
10+	NVDA	Firefox	Читаются с заданным уровнем
10+	VoiceOver	Все	Читаются с заданным уровнем
10+	Narrator	Chrome	Сбрасываются ко второму уровню и объединяются в один, если идут последовательно
10+	Narrator	Firefox	Игнорируются как заголовки в принципе

Подводя итоги

Наиболее корректно ведёт себя скринридер JAWS, который во всех случаях сбрасывает нестандартные заголовки ко второму уровню. В репозитории JAWS на Гитхабе есть ишью, с просьбой исправить этот баг. Был даже пул-реквест, меняющий это поведение, но его так и не приняли — фактически это не баг, а фича.

Наименее корректно ведёт себя VoiceOver, который передает все дополнительные уровни заголовков без возможности навигации по ним. О странном поведении Narrator говорить нет смысла, он имеет крайне малую аудиторию и приведен в таблице лишь для полноты картины.

Получается, что если вы хотите предоставить пользователю скринридера возможность навигации по вашему документу, вам следует использовать стандартные заголовки от первого до шестого уровня из спецификации HTML. А если вам приходится имитировать заголовки с помощью ARIA-роли, убедитесь, что уровни заголовков остаются в тех же границах.

Положение 4.1 WCAG гласит:

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

Таким образом не скринридеры должны подстраиваться под спецификацию ARIA или под ваш сайт, а ваш код должен быть совместим со скринридерами, грамотно используя возможности ARIA. Поэтому так важно вести разработку не на основе спецификаций, а консультируясь и тестируя ваши интерфейсы с опытными пользователями скринридеров. Только так вы сможете сделать их не формально доступными, а по-настоящему удобными для всех.

Липкая шапка таблицы на CSS

Fri, 02 Jul 2021 00:00:00 GMT

Практически на всех сайтах есть таблицы. А если эти таблицы имеют более дюжины строк, то вам, рано или поздно, понадобится сделать шапку таблицы «липкой». Многие до сих пор делают это с помощью JavaScript, но есть способ на чистом CSS.

Position Sticky

Надо добавить position: sticky к (или , что там у вас в роли шапки?) и не забыть указать top:

thead {
    position: sticky;
    top: 0;
}

Еще недавно в Chrome был баг, который не позволял делать липкими и , но в версии 91 его исправили. А всё благодаря тому, что в браузере теперь используется новый движок для рендеринга таблиц TablesNG.

Если вам всё-таки нужна поддержка и более старых версий, то можно сделать липкими сами ячейки () в шапке таблицы. Правда при этом будет сложно указать всем правильное значение top, когда шапка состоит из нескольких строк.

Как не выходить за рамки?

К сожалению почти у всех таблиц, которые я встречаю, используется border-collapse: collapse. С этим свойством проще делать рамки для ячеек, но при этом сами рамки им уже не принадлежат, а как бы становятся частью самой таблицы. А это значит, что если шапка таблицы и стала липкой — рамки её ячеек всё равно прокручиваются вместе с таблицей.

Чтобы избавиться от этой проблемы, можно использовать border-collapse: separate. Да, с этим свойством рамки ячеек перестанут схлопываться, но нам это не помешает.

В некоторых дизайн-системах у ячеек есть только горизонтальные рамки, а значит достаточно просто указывать border-top или border-bottom. Но даже если вам нужно указать рамки со всех сторон, то есть много способов это сделать:

Рамки для конкретных сторон

:root {
    --border-width: 2px;
    --border-color: #CED4DA;
    --border: var(--border-width) solid var(--border-color);
}

table {
    border-collapse: separate;
    border-spacing: 0;
}

thead {
    position: sticky;
    top: 0;
}

th, td {
    border-right: var(--border);
    border-bottom: var(--border);
}

th:first-child, td:first-child {
    border-left: var(--border);
}

thead tr:first-child th {
    border-top: var(--border);
}

Рамки как box-shadow

table {
    border-collapse: separate;
    border-spacing: var(--border-width);
}

thead {
    position: sticky;
    top: var(--border-width);
}

th, td {
    box-shadow:
        0 0 0
        var(--border-width)
        var(--border-color);
}

В примере выше мы устанавливаем расстояние между ячейками с помощью border-spacing для таблицы и отступ для прилипания с помощью top для шапки, равный размеру рамки. А затем добавляем ячейкам тень box-shadow, имитирующую рамку.

Рамки как outline

table {
    border-collapse: separate;
    border-spacing: var(--border-width);
}

thead {
    position: sticky;
    top: var(--border-width);
}

th, td {
    outline: var(--border);
}

В примере выше мы повторяем трюк из предыдущего примера, но имитирурем рамку с помощью outline.

Как организована веб-платформа

Tue, 22 Jun 2021 00:00:00 GMT

Вы наверняка слышали про веб-платформу, спецификации, W3C, CSSWG и другие организации, которые создают технологии, которыми мы пользуемся каждый день для создания веб-интерфейсов. Но от этого всегда веяло какой-то тайной, всё казалось переусложнённым и не вызывало доверия. Давайте разберёмся, как устроено создание спецификаций и как можно принять участие в развитии веб-платформы.

Веб-платформа

«Веб-платформа» — это набор стандартизированных API (HTML, CSS, JavaScript, SVG…), которые разработчики используют для построения сайтов и веб-приложений. Помимо «корневых» технологий платформа включает ещё и локальные браузерные API, которые добавляют в браузер новую функциональность: DOM, Console, Fetch и другие.

Стандарты

Как всё работает в браузере, описано в специальных документах — спецификациях. Это подробные инструкции для разработчиков, как должна работать какая-то определённая фича. Например, как должны строиться сетки на флексах или как должен работать console.log.

Спецификации

Спецификаций в веб-платформе много. Спеки создаются в специальных организациях: W3C, WHATWG, Ecma International, OpenJS Foundation и другие — в них и создаются HTML, CSS, SVG, JS, Node.js. Дальше мы подробнее поговорим о том, как работают W3C и WHATWG.

W3C

World Wide Web Consortium — международная организация, в штате которой примерно 60 человек из мировых университетов (MIT, ERCIM, Keio University, Beihang University). Также в W3C есть членство для внешних компаний.

На апрель 2021 в W3C состоит 438 компаний-членов: производители браузеров (Mozilla, Google, Apple, Samsung), софтверные компании (Adobe, Zoom), технологические гиганты (Amazon, Facebook, Visa, Alibaba), сервисы (Airbnb, Netflix, Shopify), железо (Huawei, Intel) и другие.

Чтобы иметь членство W3C, компании нужно платить членские взносы (для бедных стран — меньше, для богатых — больше). Например, если небольшая российская компания захочет вступить в «клуб» W3C, то это в 2021 году будет стоить минимум 1950 € в год (для больших компаний в 10 раз больше).

Компании отправляют своих сотрудников для работы в W3C. Вместе со штатными сотрудниками W3C приглашённые делегаты формируют рабочие группы (WG, Working Group).

Работа в FAANG (аббревиатура из названий крупнейших компаний Facebook, Amazon, Apple, Netflix, Google — прим. редактора) — не единственный способ попасть в рабочую группу W3C. Группа может включать и приглашённых экспертов (Invited Expert), которые никак не аффилированы с бизнесом, но являются крутанами в своей области. Все рабочие группы собираются на ежегодной сходке TPAC (Technical Plenary), которая проходит осенью.

Рабочая группа CSS в W3C

Как устроена рабочая группа, на примере CSS Working Group.

В ней есть председатели, штатные сотрудники W3C, делегаты из внешних компаний (FAANG и другие) и приглашённые эксперты, например: Рэйчел Эндрю, Элика Этемад, Лия Веру, Джонатан Нил. Внешние эксперты приглашаются по предложению участников рабочей группы.

Среди всех участников выделяется три роли:

Редакторы спецификаций — отвечают за модули спецификаций, следят за ишью, получают фидбек, пишут спеку и тащат прогресс по своим модулям спек (иногда у спеки только один редактор, иногда — несколько);
Остальные члены рабочей группы (не редакторы) — участвуют в дискуссии, брейнштормят, принимают коллективные решения;
Сообщество сочувствующих www-style — это как непосредственно участники группы, так и в целом все заинтересованные в CSS люди: они комментируют и критикуют предложения, запрашивают фичи и объясняют юзкейсы, поднимают вопросы, участвуют в обсуждениях и дают фидбек редакторам спек.

Контент CSS-спецификаций живёт в репозитории github.com/w3c/csswg-drafts. Там же заводятся ишью и проводятся публичные дикуссии по контенту. Вот, например, увлекательное обсуждение CSS-нестинга.

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

Спецификации в W3C

Все спецификации W3C опубликованы в одном месте по адресу w3.org/TR.

Спеки проходят такие формальные стадии развития (некоторые промежуточные технические стадии упростил):

Working Draft (WD) — зафиксированная версия черновика спеки для ревью сообществом.
Candidate Recommendation (CR) — сигнал для финального ревью сообществом, сбор опыта реализации спеки в браузерах.
W3C Recommendation (REC) — все довольны, спека доделана, опубликована финальная версия.

Текущая версия черновика называется Editor’s Draft (ED) и может быть достаточно сырой, но она самая живая из всех — над ней работает редактор спеки.

Спецификации по CSS

Если отфильтровать все спеки по тегу CSS, то получится больше сотни. Большая часть из них — черновики WD, меньшая — рекомендации REC и CR.

После публикации единой монолитной спецификации CSS 2.1, рабочая группа решила распилить её и дальше развивать отдельные независимые модули. Также появилась идея собрать из отдельных модулей общий сборник «CSS 3» и дальше развивать отдельные модули и двигать их по уровням независимо друг от друга.

К примеру, в CSS 2.1 был раздел Color. Поэтому в рамках CSS 3 появился отдельный модуль — CSS Color Level 3. Дальше он будет двигаться к Level 4, потом к 5 и так далее.

Если в спеке CSS 2.1 изначально какой-то фичи не было, например, кастомных свойств или флексов, то новые спецификации начинают нумероваться с первого уровня: например, CSS Custom Properties for Cascading Variables Module Level 1 или CSS Flexible Box Module Level 1.

Чтобы не потеряться в обилии спек, рабочая группа CSS время от времени публикует «срез» состояния CSS — Snapshot. Последний из опубликованных — CSS Snapshot 2020. Это список всех спек, про которые в 2020 году можно сказать, что это и есть весь современный стабильный CSS.

Процесс работы над спеками CSS

Как показала практика, работа над CSS-спеками не всегда укладывается в формальную линейную однонаправленную схему WD → CR → REC. Иногда развитие спеки в ответ на полученный фидбек двигается назад, а не вперёд. Поэтому есть более неформальное и близкое к жизни описание стадий работы над спеками, которое показывает стабильность спецификации:

Exploring (ранний WD): нестабильная версия, где всё ещё устаканивается и меняется. Нужен для совместной работы редактора спеки и рабочей группы.
Revising (средний WD): модуль в основном готов, но спека ещё нуждается в нескольких циклах публикации и ревью. В конце этой стадии рабочая группа фиксирует контент спеки перед переходом на формальный CR.
Refining (поздний WD): спека уже в основном стабильна и готова для перехода на CR, но ещё нуждается в шлифовке и полировке.
Testing (ранний CR): на этом этапе рабочая группа уверена, что спека достаточно полна и точна, чтобы её начинать имплементировать и писать тесты, так как для дальнейшего развития спеки нужен уже опыт имплементации в браузерах и тест-кейсы.
Stable (поздний CR): на этой стадии у рабочей группы есть достаточно полученного опыта тестирования и имплементации спеки, сама спека стабильна и надёжна, минорные ишью появляются нечасто. Такая версия спеки может быть включена в Snapshot.
Completed (PR, REC): тесты и отчёты об имплементации готовы, изменений больше не предвидится (кроме листинга опечаток).

Все CSS-спеки, сгруппированные по таким стадиям, опубликованы на странице CSS current work.

WHATWG

Но не W3C единым жива веб-платформа. В 2004 году от W3C из-за разногласий по поводу будущего HTML откололась группа разработчиков стандартов. Эта группа назвалась WHATWG — Web Hypertext Application Technology Working Group. В W3C собирались остановить работу над HTML в угоду XHTML 2 — новой версии XHTML, обратно не совместимой с HTML 4 и XHTML 1. В WHATWG считали, что нужно продолжать развивать HTML и стандарты для создания веб-приложений. Они форкнули HTML и развили его до того самого HTML 5, тем самым выиграв у W3C.

До 2019 существовало две разные параллельные спецификации HTML, но потом W3C и WHATWG помирились и договорились работать вместе над «вечнозелёной» спекой HTML.

Помимо HTML в WHATWG работают над такими фичами: Compatibility, Console Object, DOM, Encoding, Fetch, Fullscreen, URL и XHR. Все спецификации опубликованы на сайте spec.whatwg.org.

Спеки WHATWG живут в репозитории github.com/whatwg.

Процесс работы WHATWG

В отличие от W3C, WHATWG — открытое и бесплатное сообщество. Любой желающий может участвовать в развитии спек. Работа ведётся на Гитхабе.

Все стандарты WHATWG — «вечнозелёные», то есть не имеют версий, а всегда «доделаны». В WHATWG сравнивают разработку спек с разработкой ПО — софт тоже постоянно разрабатывается и меняется.

У каждого стандарта в идеале есть:

редактор или несколько;
активное сообщество контрибьюторов;
лог изменений;
ишью-трекер;
тесты.

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

Всего в организации на Гитхабе в июне 2021 состоит 81 человек.

Тесты веб-платформы

Когда рассказывают о веб-спецификациях, мало говорят про тесты. Вот есть текст спеки, вот её внедрили в браузере, это ок. А как узнать, что ничего старого при этом не поломалось? Как оценить, что внедрение корректное и спеку поняли правильно?

Тесты нужны, чтобы помочь мейнтейнерам софта (браузеров) проверить корректность своей работы: найти баги, проблемы совместимости с другими браузерами. Также они помогают приоритизировать работу над определённой группой более критичных багов. У веб-платформы есть свой набор тестов, который открыто пишется сообществом. Они удобно разделены по названиям фич и внутри структурированы по разделам спецификаций.

Реалии таковы, что браузеры не проходят все тесты на 100% и вряд ли будут когда-то их проходить. Новые фичи появляются в браузерах, а за ними приходят баги, спеки и внедрения допиливаются — всё это нормально. К примеру, в июне 2021 из 41761 тестов в Chrome не проходят 510 тестов, в Firefox — 1377, а в Safari — 3859.

Графики результатов тестов, сгруппированные по фичам, есть на сайте wpt.fyi. Вот такая, к примеру, ситуация с поддержкой гридов в браузерах.

Тесты, помимо пользы для разработчиков браузеров, дают и обычным разработчикам возможность оценивать фичи перед использованием. Обычно разработчики смотрят на статистику внедрения фич на сайте Can I Use. Так можно получить ответ на вопрос: есть ли фича в определённом браузере. Но кроме формального внедрения фичи стоит учитывать:

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

Как контрибьютить в веб-платформу

Самый простой вариант, как въехать в тему — подтянуть английский и заняться багами:

сообщать о багах разработчикам браузеров: Mozilla, WebKit, Chromium;
решать баги в тестах или писать новые тесты: ишью в репозитории WPT;
решать баги в спеках: ишью WHATWG, ишью CSSWG.

Ссылка для скачивания

Fri, 18 Jun 2021 00:00:00 GMT

Иногда передо мной стоит задача сделать ссылку, которая должна открывать системный диалог для сохранения файла. Браузеры достаточно умны, чтобы открывать такой диалог при скачивании бинарников вроде архивов или EXE-файлов. Но что делать, если я хочу скачивать картинки или какие-нибудь видео? Именно скачивать, не открывать для просмотра.

Заголовок Content-Disposition

Самый правильный способ попросить браузер скачать файл — добавить на стороне сервера заголовок Content-Disposition к потоку с файлом.

Content-Disposition: attachment; filename=kitten.jpg

Когда браузер видит у заголовка значение attachment, то пытается скачать файл.

Но иногда у вас просто нет возможности настроить сервер под свои нужды и добавить ещё один mod_rewrite. Нужен какой-то более браузерный способ решить задачу.

Атрибут download

Самый простой способ — добавить атрибут download к ссылке.

Если вы добавите его просто так, без значения, браузер постарается получить имя файла либо из заголовка Content-Disposition (опять он, и у него довольно высокий приоритет), либо из пути файла.

Попробуйте: ссылка.

Но вы можете задать значение атрибуту download, и тогда это значение станет именем скачиваемого файла. Это может быть полезно, если у ваших файлов какие-нибудь странные автогенерируемые урлы вроде https://cdn/images/a1H5-st42-Av1f-rUles.


    Скачать

Попробуйте: ссылка.

Важно! Вся эта магия атрибутов не для ссылок с других доменов (cross-origin). Вы не можете управлять чужими ресурсами из соображений безопасности.

И помните, что IE и старые Safari не понимают атрибут download. Проверьте в Can I use….

blob: и data:

Полезный лайфхак, чтобы помочь вашим пользователям сохранять картинки котиков в удобном для них формате. Если вы на своём сайте используете картинки в форматах AVIF или WebP, есть очень высокая вероятность, что ни один пользователь не сможет сохранить их к себе на компьютер или смартфон, чтобы потом пересмотреть. Точнее, сохранить-то смогут, а вот посмотреть вне браузера не смогут. Печаль.

Чтобы помочь пользователям, используйте data: или blob: внутри атрибута href.

Шаг 1. Нарисуйте картинку на Canvas

const canvas = document.getElementById('canvas');
const context = canvas.getContext('2d');
const image = new Image();
image.onload = function () {
    context.drawImage(image, 0, 0);

    // TODO: всю магию намазывать сюда
};
image.src = 'kitten-170.avif';

Шаг 2а. Сохранить картинку как блоб в атрибут `href` ссылки

const blobLink = document.getElementById('blob-link');

canvas.toBlob(blob => {
    const blobUrl = URL.createObjectURL(blob);
    blobLink.href = blobUrl;
}, 'image/jpeg', 0.9);

Да-да, я могу сохранить AVIF как JPEG. Классно, правда? Пользователь скачал всего 4 КБ AVIF с сервера, а получил 13 КБ JPEG на клиенте!

Шаг 2б. Сохранить картинку как data в атрибут `href` ссылки.

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

const dataLink = document.getElementById('data-link');

dataLink.href = canvas.toDataURL('image/jpeg', 0.9);

Так даже проще, но такой подход хуже по производительности.

Можете поиграть с полным демо тут:

Источники

Магия вне Хогвартса: NJS

Thu, 17 Jun 2021 00:00:00 GMT

Наверняка вы слышали про веб-сервер Nginx Игоря Сысоева. Архитектура Nginx построена таким образом, чтобы выдерживать колоссальное количество запросов от несметного количества клиентов. Словом, настоящая магия программирования на чистом Си! Если попробовать разобраться, как это работает, у многих может возникнуть синдром самозванца. И действительно, чтобы написать свой модуль для расширения функциональности Nginx, надо пройти школу чародейства и мастерства. А что делать JS-волшебникам и JS-волшебницам? Можно пройти курс защиты от тёмных сил или просто узнать больше об NJS.

Алохомора: откроем замочек

Nginx поддерживал внедрение скриптов в рантайм практически с самого начала, но это были скрипты на популярном тогда языке Perl. Сегодня мало кто умеет писать на Perl: сначала ему на смену пришёл PHP, а потом был период, когда практически ничего не менялось в самом Nginx. В то же время в разработке набирали популярность другие языки и всё меньше программистов могли поддерживать скрипты на сервере. Именно поэтому возникла необходимость использовать что-то другое.

И вот примерно с 2017 года одна из команд Nginx начала разрабатывать новое решение — использование JavaScript в качестве языка для скриптов. Было разработано два модуля для бесплатной версии Nginx, которые вместе составляют основу инструмента NJS, и много чего ещё для платной версии Nginx Plus.

NJS — очень интересный инструмент. У команды была возможность использовать готовые решения, например, движки V8 или SpiderMonkey, но они пошли другим путём. Эти решения нужны для решения широкого круга задач. О сложностях использования существующих движков JavaScript для работы скриптов в Nginx подробно рассказывает один из авторов NJS в докладах на русском и английском языке и приводит сравнение производительности.

Вместо этого NJS использует прекомпиляцию в байт-код при старте Nginx: виртуальная машина клонируется для каждого запроса, а ещё нет JIT-компиляции и сборщки мусора. Скрипты под NJS иногда вполне могут заменить модули Nginx на языке Си, хотя и с небольшой просадкой по производительности. При внедрении NJS было важно, чтобы Nginx не потерял своих достоинств. И команда разработчиков из Nginx сделала это!

Портус: пора в новый мир

Установка NJS для большинства операционных систем описана в официальной документации. Возможны как установка в качестве готового пакета, так и сборка модулей из исходных файлов. Для работы с NJS используются два основных модуля: ngx_http_js_module и ngx_stream_js_module. Первый используется для обработки данных по протоколу HTTP, второй — по протоколам TCP и UDP.

После установки необходимо подключить модули NJS к Nginx. Модули являются динамическими, поэтому в файле конфигурации необходимо воспользоваться директивой load_module:

load_module modules/ngx_http_js_module.so;
# или
load_module modules/ngx_stream_js_module.so;

Люмос: что-то темно

Для того чтобы реализовать скрипт для Nginx, необходимо прописать определённые директивы в файле конфигурации. Здесь и дальше конфигурацию будем описывать в файле nginx.conf, а скрипт на языке NJS — в файле script.js.

Начнём с классического «Hello world!». Логика работы скрипта заключается в том, чтобы прослушивать заранее заданный порт, например 8080, и при обращении к корневой папке сайта отослать клиенту ответ с кодом 200 и нашим сообщением.

Файл nginx.conf:

http {
    js_import script.js;

    server {
        listen 8080;

        location / {
            js_content script.hello;
        }
    }
}

Файл script.js:

function hello(r) {
    r.return(200, 'Hello world!');
}

export default {
    hello
};

NJS — это подмножество JavaScript. Что можно, а что нельзя, определено дорожной картой. Язык поддерживает стандарт ECMA-262 и имеет ряд специальных методов и свойств.

Среди специальных методов, которые обрабатывают сущности Nginx — HTTP-запрос, Stream-сессия. Можно узнать метод и аргументы запроса, обработать его заголовки и тело HTTP-сообщения, отправить коды ответа, заголовки, тело HTTP-ответа от сервера. Возможно проксирование, авторизация, логирование, доступна обработка ошибок. Создать и организовать поток данных тоже возможно с помощью NJS. Таймеры, кодирование-декодирование строк, информация о процессе, шифрование являются частью ядра, а синтаксический разбор и форматирование URL, доступ к файловой системе через реализацию библиотеки fs — встроенными модулями.

Разработчики привели довольно много примеров кода и вариантов использования NJS. Обязательно зайдите на эту страницу — вдруг ваш вариант уже реализован.

Список всех актуальных директив NJS для версии 0.4.0 и старше, которые могут быть использованы в файлах конфигурации:

js_body_filter — устанавливает функцию из модуля в качестве фильтра тела HTTP-сообщения ответа;
js_content — устанавливает функцию из модуля в качестве обработчика содержимого location;
js_header_filter — устанавливает функцию из модуля в качестве фильтра заголовков HTTP-сообщения ответа;
js_import — импортирует модуль с функциями;
js_path — устанавливает дополнительный путь до модулей;
js_set — устанавливает функцию из модуля, которая вызывается в момент первого обращения к переменной для данного запроса;
js_var — объявляет перезаписываемую переменную.

Вингардиум Левиоса: полетели

Теперь напишем наш собственный модуль, который будет шифровать данные 🙃. Возьмём самый простой способ шифрования и попробуем передавать и принимать данные с помощью него. Будем использовать очень простой шифр Цезаря. Его заключается в том, чтобы каждый символ в сообщении заменяется на другой, сдвинутый циклично на фиксированное число позиций в алфавите. Например, слово JavaScript будет преобразовано в слово OfafXhwnuy при смещении на пять символов.

Напишем сначала код, используя NJS. Шифрование и дешифрование реализуем в функции processMessage() (для примера учтём только символы английского алфавита, для шифрования будем использовать положительное значение сдвига, а для дешифрования — отрицательное).

Попробуем сделать так, чтобы при приёме HTTP-запроса скрипт возвращал расшифрованное-зашифрованное сообщение в зависимости от пути на сервере /encode/ или /decode/. Если мы обратимся к /shift/, то получим сдвиг, который заложен в нашу программу. Для обработки каждого пути напишем отдельные функции в модуле: encode, decode и shift. С помощью функции getMessage() можно будет получить сообщения из переменных, переданных GET- или POST-запросом от клиента.

Модули NJS перед исполнением компилируются и запускаются на сервере как отдельный процесс, а затем уничтожаются после выполнения. В платной версии Nginx Plus есть вариант хранения переменных в общем хранилище. В нашем случае мы могли бы так настраивать величину сдвига. Но у нас версия бесплатная, поэтому мы храним величину сдвига в константе CAESAR_SHIFT. В платной версии Nginx Plus есть даже кэширование результатов работы скриптов, нам бы вряд ли это пригодилось, но интересно.

Основной модуль script.js будет выглядеть так:

const CAESAR_SHIFT = 5;

// Преобразуем сообщение (шифр Цезаря)
function processMessage(inputString, shift) {
    let outputString = '';
    // Бежим по всем символам строки
    for (let i = 0; i < inputString.length; i++) {
        // Получаем символ строки
        let c = inputString[i];
        if (c.match(/[a-z]/i)) {
            // Получаем код символа
            const code = inputString.charCodeAt(i);
            // Обрабатываем прописные буквы
            if (code >= 65 && code <= 90) {
                c = String.fromCharCode(((code - 65 + shift) % 26) + 65);
            }
            // Обрабатываем строчные буквы
            else if (code >= 97 && code <= 122) {
                c = String.fromCharCode(((code - 97 + shift) % 26) + 97);
            }
        }
        // Добавляем символ в конец строки
        outputString += c;
    }
    return outputString;
}

// Получаем данные из переменной
function getMessage(r) {
    return r.args.msg;
}

// Шифруем
function encode(r) {
    r.return(200, processMessage(getMessage(r), CAESAR_SHIFT));
}

// Дешифруем
function decode(r) {
    r.return(200, processMessage(getMessage(r), -CAESAR_SHIFT));
}

// Возвращаем сдвиг
function shift(r) {
    r.return(200, CAESAR_SHIFT);
}

export default {
    encode,
    decode,
    shift
};

Полный список доступных в NJS конструкций языка JavaScript описан на странице «Совместимость».

Команда r.return() — отправляет тело HTTP-сообщения клиенту и статус ответа веб-сервера. r.variables хранит переменные, переданные в запросе клиента. Перед использованием нужно экспортировать необходимые функции в интерфейс, как это делается при работе с модулями в JavaScript.

Первая версия кода готова, теперь настроим веб-сервер.

У Nginx есть официальный образ Docker. Для того чтобы проверить ваш код, вы можете выполнить команду (если у вас установлен и настроен Docker):

docker run -i -t nginx:mainline /usr/bin/njs

Так вы можете проверять корректность вашего кода, вставляя функции отдельно. Если без Docker, то вы можете сделать это напрямую, установив CLI-утилиту на компьютер или сервер. Это по сути тот же интерпретатор, который используется при обработке скриптов в модуле Nginx.

Установим Nginx и NJS. Для того чтобы ставить эксперименты было удобнее, установим окружение внутри Docker-контейнера. Так можно будет работать с контейнером, как с удалённым сервером, а клиентом будет выступать наш компьютер. Вы можете сделать иначе, просто установив всё, что требуется, к себе на компьютер или на сервер. Подробнее о Docker можно почитать в цикле статей «Распаковка Docker».

Создадим папку с проектом и перейдем в неё:

mkdir caesar
cd caesar

Создадим папку для кода и добавим наш скрипт с помощью редактора или командой cat:

mkdir src
cat > ./src/script.js << __EOF__
// Cодержимое файла скрипта
__EOF__

Добавим ещё простейший интерфейс пользователя в файле index.html, который поместим в папку проекта:




    
    
    NJS тест


    
        
            Зашифровать сообщение
            Сообщение

            

            
        
    
    
        
            Расшифровать сообщение
            Сообщение

            

            
        
    
    
        
            Получить сдвиг

Создадим папку, в которой будем хранить настройки образа для Nginx (ссылка на готовый Dockerfile для сборки берём из примера в официальном репозитории):

mkdir nginx
curl -o nginx/Dockerfile https://raw.githubusercontent.com/nginxinc/docker-nginx/master/modules/Dockerfile

Создадим файл конфигурации nginx.conf:

touch ./nginx/nginx.conf

Поместим в файл конфигурацию для Nginx:

load_module modules/ngx_http_js_module.so;

events {}

http {
    js_path /etc/nginx/njs/;
    js_import script.js;

    server {
        listen 8080;

        root /var/www;

        location /encode/ {
            js_content script.encode;
        }

        location /decode/ {
            js_content script.decode;
        }

        location /shift/ {
            js_content script.shift;
        }
    }
}

Создадим файл конфигурации docker-compose.yml:

touch docker-compose.yml

Наполним его:

version: "3.9"
services:
    web:
        build:
            context: ./nginx/
            args:
                ENABLED_MODULES: njs
        image: nginx-with-njs:v1
        volumes:
            - ./nginx/nginx.conf:/etc/nginx/nginx.conf
            - ./src/:/etc/nginx/njs/
            - ./index.html:/var/www/index.html
        ports:
            - "80:8080"

Обратите внимание на пути томов volumes. В конфигурации используются связанные тома binded volumes, то есть прямая ссылка на файловую систему компьютера, на котором запущен Docker. Однако ссылки внутри контейнера очень важны. Конфигурацию и скрипт нужно поместить в /etc/nginx/ и /etc/nginx/njs/, соотвественно. В конфигурации дополнительно используется директива js_path, чтобы точно ничего не потерялось.

Осталось всё запустить:

docker-compose up

Теперь можно посмотреть в браузере результат нашей работы по адресу http://localhost. Для того чтобы остановить веб-сервер, можно использовать сочетание клавиш Ctrl C или соответствующий сигнал в Unix-подобных системах.

Приори Инкантатем: что это было

Для написания кода можно использовать TypeScript, как это описано в документации. В NJS можно использовать модули Node.js. Например, не составит большого труда сделать сервис для работы с протоколом gRPC с помощью библиотеки protobufjs. Чтобы двигаться дальше, посмотрите примеры использования скриптов NJS.

Разработчику не нужно писать код на Си для реализации модуля Nginx, а потом код на JavaScript для клиентского веб-приложения. Можно переиспользовать один и тот же модуль. Вы, конечно, можете писать скрипты на Perl или на PHP, но JavaScript иногда и правда является лучшим решением. А скорость исполнения в случае NJS сравнима с кодом на Си, помните об этом!

Онлайн-обучение: взгляд очевидца

Sun, 23 May 2021 00:00:00 GMT

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

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

Это первая часть серии статей про онлайн-образование. Пока я планирую написать три статьи, но посмотрим как пойдёт =)

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

В этой статье будут встречаться комментарии других авторов. Таким образом я постараюсь дать полную картину, а не только своё личное мнение.

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

Приятного чтения!

TL;DR

Существует целая наука по обучению взрослых — андрагогика.
Если вы хотите сделать хороший онлайн-курс учитывайте особенности обучения взрослых.
Если вы учитесь, то следите за обстановкой, в которой вы учитесь. Температура, влажность, удобная мебель и достаточное освещение — это очень важно.
Если вы преподаёте, то готовьтесь к лекции. Определите для себя несколько комфортных техник переключения внимания, подумайте над хорошими примерами для объяснения сложных вещей. Эффективный вебинар не должен длиться дольше 45 минут.

Андрагогика

Средний возраст взрослого слушателя онлайн-программ — 35 лет в столице и 33 года в регионах.

Исследование EdMarket Research, 2019 год.

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

Кроме того не стоит забывать, что учиться во взрослом возрасте гораздо сложнее, чем в детстве. Мозг с меньшей охотой создаёт новые нейронные связи, тратит на это энергию.

Эти и некоторые другие особенности обучения взрослых учитывает наука — андрагогика. Её суть заключается в понимании психологических и физических особенностей усвоения новой информации взрослым человеком и формировании на основе этого правильного подхода к преподаванию.

Основные особенности, которые должны учитываться при обучении взрослых:

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

Осознанное обучение

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

Поэтому если человек выбирает пойти на курсы, то он делает это исключительно по собственной инициативе, обменивая деньги на различные нематериальные преимущества.

Поскольку решение принято самостоятельно, то и отношение к учёбе совершенно другое. Никто не заставляет учиться из-под палки. Студент самостоятельно выбирает степень своей занятости и погружённость в процесс, вынужден самостоятельно поддерживать уровень мотивации для продолжения обучения.

Самостоятельность

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

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

Связь с реальностью

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

Практическая направленность

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

Поэтому пространные философские лекции вызывают больше недовольства, чем одобрения. Непонятно как это пойти и применить здесь и сейчас. Разве только козырнуть в разговоре.

Жизненный опыт

Обучение детей, в сравнении со взрослыми, гораздо проще. У ребёнка ещё нет собственного представлении о том, как устроен мир. Ребёнок — чистый лист. Всю информацию он будет усваивать как истину.

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

Общество, быт и время

Кто-то из вас в детстве наверняка слышал от родителей фразу «школа — твоя работа». И правда, в детстве мы не занимаемся практически ничем кроме обучения. Нам дано всё доступное время на усвоение новой информации. 11 лет школы, а у кого-то ещё 5 лет университета, день за днём проходят в изучении и усвоении.

У взрослого человека есть работа, семья, друзья, хобби, бытовые заботы. Взрослый всегда вынужден думать о деньгах. Поэтому чем быстрее он окончит курсы, тем быстрее сможет применить знания в жизни. К тому же он не может смотреть вебинары восемь часов в день, а потом ещё столько же тратить на домашние задания или дополнительные материалы. Информация должна выдаваться небольшими порциями и максимально концентрированно.

Зачем нужны онлайн-курсы

Я часто встречаю позицию, что онлайн-курсы в принципе не нужны и в интернете есть всё для самостоятельного обучения.

Действительно, мы живём в уникальное время полной доступности информации. Но для самостоятельного качественного обучения одной только информации недостаточно. К тому же большое количество материалов если уж не ложные, то часто неактуальные. Не имея опыта понять это с первого взгляда практически невозможно.

Доступность знаний

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

+ Комфортно для людей с соц тревожностью

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

+ Живя в мухосрани можешь получить хорошую профессию

+ Можно пересмотреть запись, нет необходимости спешить за лектором

Julish

Экономия времени

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

Записи лекций на онлайн-курсах позволяют самостоятельно выбирать время для обучения и не винить себя из-за пропущенной лекции.

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

+ Не надо тратить время на дорогу и сборы, для меня это кайф

Лера Зелёная

Готовая программа

Основной ресурс человека — это время. У взрослого это время часто в дефиците. Составление плана обучения, ментальной карты знаний, поиск достоверной и актуальной информации, углубление в темы и практика потребуют ощутимого времени. Из этого вытекает первое преимущество курсов — готовая актуальная программа. Студент фактически обменивает деньги на собственное сэкономленное время. За него уже всё придумали, собрали, отсеяли, формализовали и он получает самую квинтэссенцию полезности.

Актуальность

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

Программы обучения тех же программистов, часто углублённые и развесистые, на деле имеют мало прикладной пользы. Я немало встречала студентов последних курсов ведущих университетов, которые параллельно с высшим образованием обучались на онлайн-курсах. Потому что понимали, что после окончания университета они не смогут конкурировать на рынке труда со своими обширными, но оторванными от реальности знаниями. Отсюда второе преимущество онлайн образования — актуальность.

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

Наставник

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

На онлайн-курсах студента сопровождают на всём пути обучения. Преподаватели, наставники, сокурсники, аспиранты готовы объяснять непонятные моменты и подсказывать. Это существенно увеличивает шансы не потерять мотивацию и дойти до конца.

Помощь с трудоустройством

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

При самостоятельном обучении задача поиска работы остаётся целиком на вас. Никто не придёт и не предложит вам помощь в этом непростом деле. Ситуация усугубляется большим количеством начинающих разработчиков на рынке труда. Конкуренция огромная. Поиски могут затянуться.

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

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

Самый простой способ отличить плохие курсы от хороших, на мой взгляд, это внимательно послушать их обещания про трудоустройство. Гарантия сразу после курсов — это враньё. Помощь — совсем другое дело, но не воспринимайте это как гарантию.

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

Вадим Макеев

Минусы онлайн-формата

Физические

Существует большой документ из СанПиНа (санитарных правил и норм), в котором описываются конкретные требования к учебным классам. Там регламентировано всё, вплоть до температуры и влажности воздуха. Эти рекомендации призваны не просто проконтролировать всё на свете, но и создать благоприятную и безопасную обстановку для обучения.

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

Длина уроков в школе и университете тоже взята не с потолка. При благоприятных внешних факторах ребёнок способен сохранять концентрацию и усваивать новый материал примерно 15 минут. У взрослого это время может достигать 25 минут. Средний вебинар на курсах длится час-полтора. Что значительно превышает время эффективности.

Педагогические

При подготовке офлайн-уроков хороший учитель использует большое количество разнообразных учебных инструментов: опросы, работа в командах, викторины, самостоятельная работы, эксперименты и так далее. Хороший урок построен на периодической смене активностей. Это заставляет мозг переключаться и увеличивает эффективное время обучения. Помните про 15 минут? При смене деятельности счётчик сбрасывается, начинают работать другие участки мозга и ребёнок не теряет интерес.

В онлайне набор этих инструментов существенно сокращается. Как правило, вебинар состоит из монотонного повествования теоретического материала. Хорошие преподаватели периодически шевелят аудиторию вопросами или приглашениями к диалогу. Но это не полноценное общение. Преподаватель говорит, а студенты пишут. Это не позволяет развернуть полноценную дискуссию с вовлечением всех участников учебного процесса. Если мы говорим об изучении программирования, то на лекции может присутствовать ещё лайв-кодинг.

В силу скромного набора инструментов лекции в онлайне менее эффективны с точки зрения усвоения знаний.

Кроме того, находясь со студентами в аудитории преподаватель может видеть реакцию. Если студенты заняты своим делом, отвлекаются, не следят за преподавателем глазами — что-то идёт не так. Хороший, заинтересованный преподаватель всегда реагирует на эти невербальные знаки и корректирует лекцию прямо на ходу.

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

Методические

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

Из-за постоянной актуализации материалы онлайн-курсов находятся в процессе постоянной доработки. Периодически к студентам попадает сырой материал. Преподаватели часто знакомятся с новым материалом непосредственно перед лекцией. Отсюда возникают парадоксы «чтения с листа» и неспособности быстро найти удачный пример для объяснения.

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

Elena Saharova

Количество студентов

В школьных классах как правило небольшое количество детей. Это позволяет учителю изучить характер и особенности каждого ученика и учесть их в процессе урока.

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

Недостаток квалификации

Ещё одним существенным минусом является отсутствие педагогического образования или минимальной подготовки у преподавателя. Чаще всего учителя на курс подбираются по степени их успешности в преподаваемой области. Но их опыт преподавания не важен. Поскольку преподавание — полноценная профессия, не все обладают этим навыком с рождения. А успехи в изучаемой области не квалифицируют человека как хорошего учителя.

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

Качество материала

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

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

Сложно во всём этом инфошуме и разнообразии выбрать действительно качественный продукт.

Для меня как для ученика плюс — это время, конечно, которым я могу управлять (если на курсах есть запись).

Минус — очень сложно выбрать из всего дикого разнообразия что-то действительно хорошее (обычно материал — ВОДА). Полагаешься только на репутацию преподов, и то…

Glafira Zhur

Оптимизация метрик Web Vitals с помощью Lighthouse

Tue, 18 May 2021 00:00:00 GMT

В этой статье мы рассмотрим новые возможности инструментов Lighthouse, PageSpeed и DevTools, чтобы помочь разобраться с тем, как улучшить ваш сайт по метрикам Web Vitals.

Коротко вспомним, что это за инструменты. Lighthouse — это автоматический, постоянно обновляемый инструмент с открытым кодом для улучшения качества страниц. Вы можете найти его в инструментах разработчика Chrome DevTools и запустить в нём любые страницы: публичные или скрытые за авторизацией. Вы также можете найти Lighthouse в PageSpeed Insights, CI и WebPageTest.

Lighthouse 7.x включает новые возможности, например, скриншоты элементов интерфейса, влияющих на пользовательские метрики, вроде тех, что вызывают смещение раскладки.

Мы также добавили возможность делать скриншоты элементов страницы в PageSpeed Insights, чтобы легче было найти проблемы, которые возникают при разовой загрузке страницы.

Метрики Core Web Vitals

Lighthouse может синтетически измерять метрики Core Web Vitals, включая Largest Contentful Paint, Cumulative Layout Shift и Total Blocking Time (аналог First Input Delay для измерения в лабораторных условиях). Эти метрики отражают загрузку, стабильность раскладки и готовность страницы к взаимодействию. Также есть и другие метрики, такие как First Contentful Paint, с запасом на будущее Core Web Vitals (CWV).

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

Lighthouse фокусируется на оценке пользовательского опыта при начальной загрузке страницы в лабораторных условиях, эмулируя медленный телефон или десктоп. Если сдвиги макета или длительные JavaScript-таски возникнут на странице уже после её загрузки, лабораторные метрики этого не отразят. Для измерения показателей после загрузки страницы стоит обратиться к вкладке «Performance» инструментов разработчика, Search Console, расширения Web Vitals или RUM.

На панели Web Vitals во вкладке Performance инструментов разработчика можно включить индикаторы, соответствующие метрикам. Например, индикаторы для метрики Layout Shift (LS) показаны на скриншоте выше.

Полевые метрики, которые вы можете найти в отчёте Chrome User Experience (CrUX) или в RUM, не имеют этих ограничений и полезно дополняют лабораторные метрики. С другой стороны, полевые данные не могут предоставить диагностическую информацию, которую вы можете получить от лабораторных метрик, вот так они и сочетаются вместе.

Где можно улучшить метрики Web Vitals

Largest Contentful Paint (LCP)

LCP — характеристика воспринимаемой пользователем загрузки. Она отмечает точку в процессе загрузки страницы, когда главный (или самый большой) контент загрузился и стал видим пользователю.

В Lighthouse есть отчёт «Largest Contentful Paint element», который позволяет выделить такой LCP-элемент. Если навести на элемент в отчёте, он подсветится на странице.

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

Вам может пригодиться LCP-букмарклет Энни Салливан, который поможет быстро найти LCP-элемент и подсветить его красной рамкой в один клик.

Предзагрузка картинок для улучшения LCP

Чтобы улучшить метрику LCP, вы можете предзагрузить хиро-картинки (например, обложки статей — прим. редактора), если браузер находит их слишком поздно. Одна из причин позднего обнаружения картинок — если сначала нужно загрузить JS-бандл, чтобы узнать о картинках, которые нужно загрузить.

Предзагрузкой нужно пользоваться аккуратно. Пропускная способность соединения на первом этапе загрузки страницы невелика и предзагрузка картинок может повлиять на загрузку других важных ресурсов. Для эффективной предзагрузки убедитесь, что ресурсы расположены в правильном порядке, чтобы не привести к ухудшению других метрик, когда другие ресурсы тоже считаются важными (например, критический CSS, JS, шрифты). Читайте подробнее о цене предзагрузки (Google Docs).

Начиная с версии 6.5, Lighthouse предлагает возможности для применения этой оптимизации.

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

Можно ли предварительно загрузить адаптивные картинки? Да, можно. Скажем, у вас есть набор хиро-картинок для разных размеров экрана, которые описаны с помощью srcset и sizes, например:

Благодаря атрибутам imagesrcset и imagesizes, добавленным в , вы можете предзагрузить адаптивные картинки, используя ту же логику из srcset и sizes:

Подсветит ли отчёт возможности предзагрузки, если LCP-картинка задана с помощью CSS-фона? Да, конечно.

Любая картинка, помеченная как LCP (будь то или фоновая картинка в CSS), это кандидат для аудита, если она обнаружена в водопаде на глубине три уровня и больше.

Поиск влияний на CLS

Кумулятивный сдвиг раскладки (Cumulative Layout Shift, CLS) — это оценка визуальной стабильности. Она показывает, насколько контент страницы визуально сдвигается во время загрузки. Lighthouse содержит специальный отчёт «Avoid large layout shifts» для отладки CLS.

Этот отчёт выделяет элементы DOM, которые вносят основной вклад в сдвиги на странице. В колонке «Element» отчёта Lighthouse вы увидите список таких элементов DOM, а справа — их вклад в CLS.

Благодаря новой возможности Lighthouse делать скриншот элемента мы теперь можем видеть превью ключевого элемента из отчёта и увеличивать его для более детального просмотра:

Для CLS после загрузки страницы, бывает полезно обозначить элементы, которые оказали наибольшее влияние на сдвиг раскладки. Это можно найти в сторонних инструментах, например, в панели Core Web Vitals от SpeedCurve или в Layout Shift GIF Generator от Defaced, который мне очень нравится:

Для анализа сдвигов раскладки для всего сайта мне помогает отчёт Core Web Vitals, который создаёт Google Search Console. Этот отчёт позволяет видеть страницы сайта с высоким значением CLS, что помогает понять, на какие файлы шаблонов мне стоит обратить внимание прежде всего:

Чтобы улучшить показатель CLS для веб-шрифтов, обратите внимание на новый дескриптор size-adjust для @font-face. Он позволяет изменять размер базовых шрифтов для уменьшения значения CLS.

Поиск картинок без размеров для улучшения CLS

Чтобы уменьшить сдвиг раскладки, вызванный загрузкой ресурсов без заданных размеров, задайте картинкам и видео атрибуты width и height. Это помогает браузеру выделить достаточное место на странице, пока картинки или видео грузятся.

Читайте статью «Setting Height And Width On Images Is Important Again» для лучшего понимания важности указания размеров и соотношения сторон для картинок.

Поиск влияния на CLS от рекламы

Отчёт «Publisher Ads для Lighthouse» позволит вам найти возможности загрузку рекламы на ваших страницах, включая роль рекламы в сдвиге раскладки и долгих операций, которые могут отложить интерактивность страницы для пользователей. Вы можете включить этот инструмент в Lighthouse с помощью Community Plugins.

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

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

Избегайте раздельных анимаций

Анимации, не объединённые в общий композитный слой рендеринга, могут дёргаться на слабых устройствах, если исполнение сложных JavaScript-тасков занимает главный поток. Такие анимации могут вызывать и сдвиги раскладки.

Если Chrome обнаруживает, что анимация не может быть выделена в отдельный слой, он сообщает об этом в DevTools. Это позволяет составить список всех элементов, для которых анимация не была композитной и выяснить причину. Вы можете найти эту информацию в отчёте «Avoid non-composited animations».

Отладка метрик FID, TBT, LT

Метрика First Input измеряет время от первой попытки взаимодействия со страницей (например, когда они кликают по ссылке, кнопке или использую JS-контрол), до момента, когда браузер действительно начинает обрабатывать события в ответ на это взаимодействие. Долгие JavaScript-таски могут повлиять на эту метрику и на её прокси-метрику Total Blocking Time.

Lighthouse включает отчёт «Avoid long main-thread tasks», которая перечисляет долгие таски в основном потоке. Это помогает отыскать самое большое влияние на задержку первого взаимодействия. В левой колонке вы можете увидеть адрес скрипта, ответственного за долгие таски в главном потоке.

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

Из сторонних сервисов для мониторинга работы основного потока мне понравился Calibre, который отображает на оси времени долгие таски, родительские и дочерние.

Блокировка сетевых запросов в Lighthouse

Инструменты разработчика Chrome поддерживают блокировку сетевых запросов, чтобы увидеть вклад каждого из загружаемых ресурсов, если они доступны или нет. Это может оказаться важным для понимания вклада каждого отдельного скрипта, который может повлиять на такие метрики, как Total Blocking Time (TBT) и Time to Interactive (TTI).

Блокировка сетевых запросов также работает в Lighthouse! Давайте взглянем на отчёт Lighthouse для сайта. Например, «Performance» выдаёт 63 из 100 очков с TBT, равным 400 мс. Покопавшись, мы найдём загрузку полифила Intersection Observer в Chrome, который для этого браузера не нужен. Заблокируем его!

Мы можем кликнуть правой кнопкой на скрипте в инструментах разработчика на панели «Network» и выбрать «Block request URL». Здесь мы сделали это для полифила Intersection Observer.

Затем мы перезапускаем Lighthouse. На этот раз мы видим улучшение показателя Performance (70/100) и Total Blocking Time (с 400 мс до 300 мс).

Замена дорогих сторонних виджетов на заглушки

Использование на странице сторонних ресурсов для видео, постов из социальных сетей или виджетов является обычной практикой. По умолчанию, большинство таких виджетов стараются загрузиться сразу же и могут существенно отразиться на пользовательском опыте. Это очень расточительно, особенно если такие виджеты некритичны — то есть пользователю ещё нужно прокрутить до них.

Один из способов улучшения скорости загрузки таких виджетов — ленивая загрузка во время взаимодействия. Это может быть реализовано с помощью лёгкой заглушки виджета: полная версия загрузится только тогда, когда начнётся взаимодействие. В Lighthouse есть отчёт, который рекомендует сторонние решения для ленивой загрузки с заглушкой, например, для видео с YouTube.

Напомню, что Lighthouse будет подсвечивать сторонний код, который блокирует основной поток более, чем на 250 мс. Это поможет обнаружить все сторонние скрипты (включая собственные Google), которые стоит отложить или загрузить лениво, если результат их рендеринга прячется за прокруткой.

Не только Core Web Vitals

Помимо использования Core Web Vitals, последние версии Lighthouse и PageSpeed Insights также пытаются обеспечить разработчиков конкретными советами для ускорения тяжёлых JS-приложений, если у вас включены карты кода.

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

За подробностями об инструментах Core Web Vitals следите в Твиттере команды Lighthouse, а также в разделе What’s new in DevTools.

Ищем баланс между нативным и кастомным селектом

Thu, 06 May 2021 00:00:00 GMT

Есть план! Мы сделаем стилизованный селект. Стилизуем не просто снаружи, но и внутри. Полный контроль над стилизацией. Вдобавок к этому мы сделаем его доступным. Мы не будем пытаться повторить за браузером всё, что он делает по умолчанию при отрисовке нативного , как только используется любая вспомогательная технология. Но когда будет использоваться мышь, мы отрисуем стилизованную версию и заставим ее функционировать как , и его стилизованная альтернатива.

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

Селект, выпадающий список, навигация, меню… название имеет значение

Во время изучения данной темы я думала обо всех тех названиях, которыми разбрасываются, когда говорят о селектах. Наиболее общие из них — «выпадающий список» и «меню». Есть два типа ошибок при наименовании, которые мы можем допустить: дать одинаковые названия разным элементам или дать разные названия одинаковым элементам.

Перед тем, как мы двинемся дальше, позвольте мне внести ясность касательно использования термина «выпадающий список». Вот как я его понимаю:

Выпадающий список — интерактивный компонент, состоящий из кнопки, которая показывает и прячет список элементов, в основном по наведению мыши, клику или тапу. По умолчанию список невидим до начала взаимодействия. Список обычно показывает блок содержимого (опций) поверх другого контента.

Множество интерфейсов могут выглядеть похоже на выпадающий список. Но просто назвать элемент «выпадающим списком» — всё равно что использовать слово «рыба» для описания животного. Какое семейство рыб? Рыба-клоун не то же самое, что и акула. То же касается и выпадающих списков.

Отличаем рыбу-клоуна от акулы.

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

Меню: список команд или действий, которые пользователь может исполнить на странице.
Навигация: список ссылок, используемых для перемещения по сайту.
Селект: контрол формы .

Давайте поговорим про определенно из области злых.

Про это написано огромное количество статей и даже в 2020 всё еще трудно создать кастомный селект и некоторые пользователи всё ещё предпочитают простые и нативные селекты.

Для разработчиков такое же, как с ARIA: избегайте его использования, если можете.

Я могла бы закончить статью прямо сейчас словами «Не используйте

Приняв решение создать кастомный селект — пусть и самый простой — мы сталкиваемся с требованиями, которые мы должны учесть:

Должна быть кнопка, содержащая текущий выбранный вариант.

Клик по блоку переключает видимость списка опций.

Клик по опции, расположенной в списке, обновляет выбранное значение. Текст кнопки меняется и список закрывается.

Клик по области вне компонента закрывает список.

Переключатель содержит маленький треугольник, направленный вниз, указывающий на то, что есть варианты.

Что-то вроде такого:

Кто-то из вас подумает: «Работает и хорошо». Но постойте… Разве это работает для всех? Не все используют мышку (или тачскрин). К тому же нативный ведет себя по-разному в разных браузерах и скринридерах.

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

Создаём гибридный селект

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

Что если вместо этого мы зададим нативный селект по умолчанию и заменим его более эстетичным, если это возможно? Вот тут и вступает в игру идея о гибридном селекте. Он гибридный, потому что состоит из двух селектов, каждый из которых показывается в нужный для него момент:

Нативный селект, видимый и доступный по умолчанию.

Кастомный селект, скрытый до тех пор, пока не произойдёт взаимодействие посредством мыши.

Начнём с разметки. Вначале, добавим нативный

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

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

.selectNative, .selectCustom { position: relative; width: 22rem; height: 4rem; }

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

.selectCustom { position: absolute; top: 0; left: 0; display: none; }

Вот здесь-то и начинается веселье. Нам нужно определить, использует ли пользователь устройство, в котором наведение — часть основного ввода информации. Например, компьютер с мышью. Хотя мы и думаем о медиавыражениях только как о способе проверки определённых функций или же инструменте адаптивности на брейкпоинтах, их также можно использовать для обнаружения поддержки ховера с помощью hover: hover, который поддерживается всеми основными браузерами. Итак, давайте используем это для отображения кастомного селекта на устройствах, где можно навести курсор.

@media (hover: hover) { .selectCustom { display: block; } }

Отлично. Но что насчёт людей, которые используют клавиатуру для навигации даже на устройствах, поддерживающих ховер? Что делать? Мы будем прятать кастомный селект, когда нативный находится в состоянии фокуса. Мы можем поймать соседний элемент с помощью комбинирующего селектора +. Как только нативный селект в фокусе, прячем кастомный, который следует сразу за ним в DOM. Вот почему кастомный селект должен следовать за нативным.

@media (hover: hover) { .selectNative:focus + .selectCustom { display: none; } }

Вот и всё! Трюк переключения между двумя селектами готов. Есть другие способы сделать это через CSS, но и этот прекрасно работает.

Наконец, нам нужно немного JavaScript. Добавим несколько обработчиков событий:

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

Один, чтобы синхронизировать выбранные варианты. При изменении одного варианта выбора, меняется и второй.

И ещё один для установки навигации через клавиатуру с помощью клавиш Up и Down, выбора варианта с помощью клавиш Enter или Space, и закрытия списка через Esc.

Юзабилити-тест

Я провела небольшое юзабилити-тестирование, в котором я попросила нескольких людей с ограниченными возможностями воспользоваться гибридным селектом. Были протестированы следующие устройства и инструменты с использованием последних версий Chrome 81, Firefox 76, Safari 13:

Компьютер только с мышью.

Компьютер только с клавиатурой.

VoiceOver на macOS с помощью клавиатуры.

NVDA в Windows с помощью клавиатуры.

VoiceOver на iPhone и iPad в Safari

Все эти тесты дали желаемый результат, но я уверена, что можно было бы провести ещё больше юзабилити-тестов с более разнообразными устройствами и широким диапазоном лиц. Если у вас есть возможность протестировать на других устройствах или с другими инструментами — такими как JAWS, Dragon и подобным — пожалуйста, расскажите мне, как прошёл тест.

Во время теста была обнаружена проблема. В частности, проблема связана с настройкой VoiceOver «Использовать виртуальный курсор VoiceOver». Если пользователь откроет селект с помощью этого курсора, вместо нативного покажется кастомный селект.

Больше всего мне нравится в этом подходе то, как он совмещает всё самое лучшее из обоих миров без нанесения ущерба функциональности.

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

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

Вспомогательные технологии спокойно могут взаимодействовать с нативным селектом.

Пользователи мыши получают возможность взаимодействовать с расширенным кастомным селектом.

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

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

Примечание касательно селекта-меню

Давайте вернёмся к третьему сценарию нашего списка селектов. Если вы помните, это выпадающий список, который всегда имеет отмеченный вариант (например, сортировка). Я отнесла его к серой области как и меню или селект.

Идея такая: много лет назад этот тип выпадающего списка реализовывался в основном с помощью нативного — это вид меню. Оба имеют схожую семантику и поведение, особенно в случае, когда один вариант всегда выбран. Теперь позвольте мне упомянуть критерий из WCAG 3.2.2 о полях (уровень A):

Изменение состояния любого пользовательского элемента не должно влечь за собой автоматическое изменение контекста без уведомления об этом пользователя перед самим изменением.

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

Гибридный селект — это всего лишь ещё одна попытка создать красивый селект, сохранив при этом как можно больше изначальных функций. Не расценивайте этот эксперимент как попытку извинения за уменьшение доступности. Скорее это попытка угодить обоим мирам. При наличии ресурсов, времени и необходимых навыков пожалуйста, сделайте всё как надо и не забудьте протестировать всё на разных пользователях перед тем, как публиковать своё творение.

P.S. Не забудьте выбрать правильное название при создании выпадающего списка 😉

Принцип мозаики, или Как мы сделали JavaScript по-настоящему модульным

Mon, 26 Apr 2021 00:00:00 GMT

Идея создания модульной системы родилась и развивалась внутри нашего опенсорсного проекта ScandiPWA — витрины для онлайн-коммерции на React. Нашей главной задачей было разработать расширяемую основу для наших проектов, в которую мы могли бы внедрять расширения, при этом имея возможность менять облик (создавать темы) как самой основы, так и любого из расширений. При этом, важно было предоставить возможность быстрого и удобного их (базы и расширений) обновления.

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

С расширениями дела обстояли ещё хуже. Потребность в них росла, а обычные подходы к этой проблеме заставляли на каждом шагу останавливаться, и оставлять места для внедрения плагинов. В приложении таких набиралось всё больше, и нас это решительно не устраивало, код регистрации точки внедрения дублировался, а следить и документировать каждый становилось просто невозможно. Наш опыт с языками на бэкенде подсказывал, что должен был быть способ внедрять плагины на уровне кода, а не точки выхода, разбросанные по приложению. Однако JavaScript такой возможности из коробки не предоставлял.

Мы долго задавались вопросом: как живут все больше проекты в вебе, искали подходы, технологии… Даже тогда, два года назад, когда мы только начинали, уже были технологии типа DI (dependency injection — прим. редактора). И всё с ними было хорошо, да есть у нас проблема: наш продукт ScandiPWA делался для простых разработчиков. Для закоренелых PHP-разработчиков, которые и React может первый раз в жизни видят. Приходилось прямо в документации рассказывать о преимуществах над jQuery. Представьте как сложно было бы объяснить непонятные реестры.

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

К чему мы пришли: плагины

Как уже сказано выше, чтобы работать с плагинами, обычно приходится писать ещё и кучу кода. Расставлять точки входа, регистрировать, импортировать файлы регистрации. Это всё долго, сложно, затратно и очень плохо масштабируется. Мы решили, что всё это можно убрать. Скрыть и делать плагины сразу к самому коду. Мы очень не хотели менять прототипы, мы хотели чтобы плагины просто перехватывали вызов той или иной функции и позволяли модифицировать процесс и результат её выполнения. При этом было важно работать на уровне стека вызова оригинальной функции, чтобы программу было легко отлаживать.

Итак, что же мы там придумали? Теперь, вы можете делать сущности вашего языка в вашем приложении (функции, классы и методы) точкой входа для плагинов с помощью всего одного комментария! Комментарий — @namespace позволит изменить отмеченную сущность через плагины из любого модуля в приложении. А ещё он прекрасно подсвечивается вашим редактором! Как это в итоге выглядит:

/** @namespace Application/getData */ const getData = () => { return ['Initial data']; } console.log(getData());

И что, это всё? Да, всё. Теперь вы можете расширять эту функцию, например, добавить к результату её выполнения новый элемент, сделать это, достаточно просто, смотрите:

export default { // Тот самый @namespace нашей функции 'Application/getData': { // Тип изменяемой сущности function: (args, callback) => { return [ // Вызов оригинальной функции ...callback(...args), // Наш новый элемент 'Data from the plugin' ]; } } }

А как решить проблему с импортом файлов регистрации? Определить для них одно место, и брать оттуда! Забегая немного вперёд: система ищет плагины по паттерну src/plugin/*.plugin.* во всех отмеченных модулях приложения.

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

К чему мы пришли: темы

А что с темами? Мы бы хотели надстраивать их бесконечное количество (ну или больше двух) друг на друге. Например так:

Голая тема с чистой функциональностью.

Красивая тема № 101.

Кастомизации под клиента.

Для нас ответ крылся в формулировке вопроса «надстраивать друг на друге». Мы решили сделать всё уже давно изведанным во многих бэкенд-фреймворках способом: при сборке предпочитать файлы детей родительским, в случае, если имена их файлов совпадают! Непонятно? Вот как это работает на практике. Спойлер, всё просто!

Этот файл лежит в файле App.js пакета nice-theme:

import { PureComponent } from 'react'; export default class App extends PureComponent { render() { return Это написано в «Красивой теме №101».; } }

Это файл уже более новой темы «Кастомизации под клиента», но имя файла, что важно, совпадает: тоже App.js.

import ParentApp from 'nice-theme/App'; export default class App extends ParentApp { render() { return ( <> { super.render() } А это в «Кастомизации под клиента». ); } }

В результате получаем следующий HTML в результате рендера:

Это написано в «Красивой теме №101». А это в «Кастомизации под клиента».

Обратите внимание, мы использовали классы и наследование в React! Такая практика не рекомендуется. Однако в нашем случае, она решает больше проблем, чем создает:

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

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

Наконец, мы можем на уровне метода или свойства решать, хотим ли мы унаследовать его (через обращение к super).

Что важно, мы не даём возможности обратиться напрямую к классу родительской темы, если он переписан в новой теме. Теперь любое обращение к нему вернёт вам ваш новый, переписанный класс! Поэтому мы считаем такой подход валидным и, несмотря на популярность функциональных компонентов в React, продолжаем использовать классовые!

Как это попробовать?

Всё очень просто. На самом деле, механизм может работать не только с React: как плагины, так и темы можно делать для любых сущностей и файлов. Мы же пока уверенно можем заявить о поддержке самых популярных фреймворков: Create React App и Next.js. Что, плагины в Next.js? Да-да, именно так!

Как выглядит интеграция? Даже слишком просто. Достаточно заменить зависимость с react-scripts на @tilework/mosaic-cra-scripts, а в самих скриптах, аналогично с react-scripts на cra-scripts. И всё! Как это выглядит:

"dependencies": { - "react-scripts": "4.0.3", + "@tilework/mosaic-cra-scripts": "0.0.2", }, "scripts": { - "start": "react-scripts start", - "build": "react-scripts build", + "start": "cra-scripts start", + "build": "cra-scripts build", }

Для Next.js, всё точно также, только ставить надо @tilework/mosaic-nextjs-scripts, а скрипты менять нужно на nextjs-scripts.

Что делать всем остальным? Если ваш стек — это Webpack и Babel, то и для вас есть очень простое решение: ставим @tilework/mosaic-config-injectors и изменяем вашу Webpack-конфигурацию следующим образом:

const webpack = require('webpack'); const ConfigInjectors = require('@tilework/mosaic-config-injectors'); module.exports = ConfigInjectors.injectWebpackConfig({ // Конфигурация }, { webpack });

Готово? Ура! Поделитесь опытом использования, для нас это очень важно!

Почему все-таки mosaic?

Чем картины отличаются от мозаики? Мозаика состоит из отдельных элементов, а картина, хоть и окрашена в разные цвета, является одним, неразделимым целым.

Большинство приложений JavaScript — это картины. Наше изначальное приложение ScandiPWA — тоже. Даже разделив такое приложение на модули, нам всё равно придётся их переплетать, интегрируя один в другой. Модули — как цвета на картине, изначально выходящие из разных тюбиков, оказываются неразрывно связанными в одно целое.

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

Плагины позволят вам сделать это! Мы начали с интеграций в уже готовые приложения, а теперь предлагаем написать всё с нуля? Да, мы сами в шоке!

Но как это вам поможет? Какие проблемы решит? Честно говоря, вы просто напишете приложение изначально думая о том, как его можно будет расширять. И не только сторонними расширениями, но и собственной дополнительной логикой. Это зарядка для мозга, полезная сложность, которая делает наш код немного более качественным!

Наверное, не стоит переписывать уже готовые приложения на этот подход, но вот писать новые… Стоит попробовать! Особенно в случае, если вы хотите в будущем легко заменять одни его части на другие. Подумайте об этом :)

Ссылки

Документация по mosaic

Репозиторий проекта

ScandiPWA, витрина для онлайн-коммерции — если интересно, с чего всё начиналось.

Пример модульного проекта на mosaic

CSS-нестинг — больше, чем сахар

Fri, 23 Apr 2021 00:00:00 GMT

В последнее время всё чаще всплывают обсуждения вокруг черновика CSS Nesting. Кажется всё началось с твита Адама Аргайла, где он, к слову, писал не столько специально про CSS Nesting, сколько среди прочего. В этом усмотрели некоторый шифр, что мол скоро всё будет, ведь не кто-то там твитнул, а сам автор спецификации, над которой в том числе работает маэстро CSS Таб Аткинс. В отличие от основного твита про некоторую технику в будущем, твиты со ссылками на конкретные спеки не получили значительного количества лайков. Кому нужны спеки, верно?

Не знаю, совпало или одно потянуло другое, но Бен Фрейн вскоре написал статью «CSS Nesting — the last piece of the puzzle», где, в частности, сослался на твит Адама. Кстати, Бен не последний человек в мире Sass и даже написал книгу «Sass and Compass for Designers» в 2013. Вероятно его авторитет и воодушевление по поводу черновика спецификации сделали своё дело и будущее модуля CSS Nesting заиграло новыми красками.

Вот и «Веб-стандарты» написали об этом, а потом и в подкасте обсудили. Получилось интересно: вышли за пределы обсуждаемой статьи и подсветили интересные вопросы, хотя упустили пару моментов (но о них я ещё напишу). Чего не сказать про обсуждения вокруг, где всплывают возражения вроде того, что это всего лишь сахар, зачем из CSS пытаются сделать препроцессор, предложенный синтаксис не торт и так далее.

Отдельно стоит выделить цитату из обзора статьи Бена Фрейна на канале Defront:

Недавно Адам Аргайл представил сообществу черновик спецификации, над которым он работает вместе с Табом Аткинсом. В этой спецификации описывается синтаксис вложенности, который похож на аналогичный синтаксис из Sass и Less. Основное отличие — нужно использовать @nest при размещения вкладываемого селектора в качестве потомка…

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

Не такая уж новая спека

Во-первых, какого-то явного «представления» спецификации от Адама не было. Он просто твитнул ссылку на спеку, в которой указан автором. Его имя попало в спеку всего полгода назад, он себя же и добавил. Саму спеку, или как принято называть «модуль», очень долго вынашивал Таб Аткинс и достаточно долгое время это были, как любит говорить Вадим Макеев, «заметки на салфетке». Таб — гениальный инженер, автор большого количества CSS-спецификаций, с фантазией и идеями у него полный порядок. У него даже есть свой отдельный репозиторий с потенциальными спецификациями, которые уже переписаны с «салфеток» во что-то более конкретное. Но нужно понимать, что в такой непростой теме как CSS, от идеи до реализации в браузерах могут пройти годы, если не десятилетия. И Таб делился своими идеями то тут, то там — в том числе, в своих докладах и статьях о возможном будущем CSS.

Так вот, первый черновик CSS Nesting был подготовлен Табом ещё в октябре 2013 года. А в мае 2018 Джонатан Нил начал масштабную дискуссию по этому предложению, версии черновика от 2015 года. По сути это и было первым представлением начальной версии модуля. Если у вас есть вопросы почему всё выглядит так, как выглядит, то вам обязательно стоит прочитать эту дискуссию (я там оказывается даже вставил свои пять копеек, о чём уже и забыл). Там, пожалуй, есть все типовые набросы и ответы к ним, технические нюансы, риски и прочее. После этого, лишь в июле 2018, спека перекочевала в официальные черновики CSSWG.

Не такой уж знакомый синтаксис

Во-вторых, предложенный синтаксис всё-таки отличается от того что есть в Sass и Less. Ключевым является то, что подстановка вышестоящих селекторов вместо & (новый потенциальный житель в синтаксисе CSS) происходит не на уровне конкатенации строк, как в препроцессорах, а на уровне селекторов, точнее, на уровне CSS-токенов. Это принципиально и, пожалуй, вызывает наибольшие нападки на предложенный в модуле синтаксис. Например, следующий код:

.foo { &-bar { /* … */ } }

Будет воспринят препроцессорами и они произведут CSS:

.foo { /* … */ } .foo-bar { /* … */ }

В тоже время CSS Nesting (пока нет имплементаций, мы можем сослаться только на текст спецификации) говорит, что это некорректно. В лучшем случае, такой код в реалиях CSS будет воспринят так, но это неточно:

.foo { /* … */ } -bar.foo { /* … */ }

Это может вызвать недоумение, если не знать как работает синтаксис CSS и что значит подстановка на уровне токенов. Так что для методологий вроде БЭМ, когда механизм вложенности используют для генерации имён классов для элементов и модификаторов, CSS Nesting работать не будет, в отличие от препроцессоров.

В своём докладе «All about the CSS syntax» летом 2018, я рассказывал про механику CSS-синтаксиса и там есть секция про CSS Nesting на 30 слайдов (слайды 83-114). Там я рассматривал новый синтаксис с точки зрения работы CSS-парсера, который работает согласно правилам CSS Syntax Module Level 3, и немного сравнивал с препроцессорами.

Сам Крис Эпштейн, один из авторов Sass, писал в той самой дискуссии про CSS Nesting, что имплементация вложенности, которую они реализовали в Sass, была плохой идеей. Это одна из тех вещей, говорит он, о которых он действительно жалеет. На мой взгляд, это достаточно веский аргумент в пользу того, почему в черновике спецификации всё именно так.

Всё это было почти 3 года назад. Поэтому утверждения «Адам Аргайл представил сообществу черновик спецификации» и «синтаксис вложенности, который похож на аналогичный синтаксис из Sass и Less» кажутся некорректными. Последнее некорректно без уточнения, что механика другая, ведь вся схожесть ограничивается использованием & для подстановки вышестоящих селекторов.

Можно и без @nest

В-третьих, использование директивы @nest не обязательно, если & идёт первым у всех селекторов в списке селекторов. Да, можно использовать директиву всегда, по какой-либо причине, это не возбраняется, но это не всегда необходимо. Использование же директивы обусловлено тем, что если у первого селектора списка в начале идёт не &, то CSS-парсер может свалиться в так называемый unbound lookahead. Это значит, что разбирая блок, парсер не может быстро принять решение: перед ним вложенный блок или же это поломанная декларация property: value, которую он должен проигнорировать. И это ломает предсказуемость и производительность. Это если коротко. Подробнее я разбирал в докладе на примерах, и об этом есть несколько объяснений в дискуссии к CSS Nesting. А для второго и далее селекторов в списке ограничение сохраняется для консистентности правила и устранения WTF при изменении порядка селекторов или удалении первого селектора, когда всё может внезапно сломаться.

В целом, наличие директивы @nest не ключевое отличие, а скорее небольшой нюанс. Субъективно, ситуации когда & идёт не в начале, а значит может потребоваться @nest, случаются куда реже. Поэтому ключевое отличие всё же, что вложенность в целом работает иначе — другие правила.

Также из Defront:

На данный момент черновик ещё не стабилизировался, и синтаксис описания вложенности скорее всего поменяется…

Лично я сомневаюсь, что синтаксис как-то поменяется.

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

Во-вторых, за прошедшие почти три года в спеке произошло не так много изменений, но изменения значимые:

Разобраны многие моменты со специфичностью. Это сложная тема, и тут на руку сыграли недавние нововведения в CSS селекторах :is() и :where().

Добавились вложенные @media (видимо, с подачи Адама) — как по мне, это хорошее дополнение.

Появился запрет на декларации после вложенных блоков. На самом деле, это изменение Таб внёс совсем недавно, и про это были те самые мои пять копеек. Я не думаю, что мой комментарий как-то на это повлиял, но приятно осознавать, что мои умозаключения были в правильном ключе.

Добавились расширения в интерфейсы CSSOM.

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

Defront молодец

Ещё небольшая, но важная ремарка. Не стоит воспринимать разбор тезисов из обзора Defront к статье Бена Фрейна как нападку на автора канала. Я бы сделал комментарий к обзору в самом канале, но, к сожалению, комментарии там не включены (о, это отдельное «шаманство» включить комментарии в Telegram канале, поверьте). Как бы то ни было, Defront отличный канал, где публикуется много ссылок на очень занятные статьи с сопутствующим обзором. Отдельно хочу выразить респект и уважуху автору канала Александру Мышову, который сделал работу над каналом своей основной деятельностью. То есть он живёт на доход от канала и Патреона. Невероятная самоотдача своему делу, в какой-то степени авантюризм, но это очень круто! Поэтому категорически рекомендую канал.

Что касается темы CSS Nesting и CSS в целом, то это непростая история и в ней делают неверные выводы даже те, кто очень тесно с этим связан. Я сам не уверен, что не ошибся в своих тезисах (поправьте меня, если так). Поэтому особого криминала в неточностях обзора не вижу. Если не погружаться в глубину вопроса (а вопрос очень обширный, как можно заметить по тексту выше), то вполне понятно почему так может происходить и можно сделать скидку. У меня получилось всё это разложить лишь потому, что я давно копаю CSS со стороны спек, слежу и в какой-то степени участвую в происходящем. Но это нетипичный фронтенд. Надеюсь мой разбор поможет другим разобраться в вопросе и лучше понять положение вещей.

Но! Это только первая часть истории, есть ещё кое-что…

Сахар и препроцессоры

Если отойти от обсуждения синтаксиса CSS Nesting и остальных вопросов, рассмотренных выше, то остаются неразобранными тезисы «это всего лишь синтаксический сахар» и «из CSS пытаются сделать препроцессор». Давайте разберёмся, что не так с этими тезисами.

Для начала стоит понять, почему такие тезисы формируются. В черновике CSS Nesting приводятся примеры нового синтаксиса, а рядом с ними эквиваленты CSS без вложенности. Такая преемственность является желаемым эффектом, которого добиваются для новых синтаксических конструкций не только в CSS, но и, например, в JavaScript. Польза от этого, как минимум, в двух аспектах. Во-первых, так проще объяснить новое в сравнении с уже знакомым. Во-вторых, это значит, что новый синтаксис потенциально можно использовать уже сегодня и на этапе сборки адаптировать (транспилировать) его под браузеры, которые не поддерживают новый синтаксис. Если остановиться на этом, то CSS Nesting действительно выглядит как синтаксический сахар.

Однако если продолжить углубляться, и внимательнее почитать комментарии и высказывания Таба Аткинса, то всплывает интересная деталь. Например, он между делом пишет о расширении CSSOM. Эти изменения уже получили отражение в черновике CSS Nesting. В частности, вводится новый интерфейс CSSNestingRule, наследуемый от CSSRule, а также расширяется интерфейс CSSStyleRule. Это означает, что браузер должен отражать CSS с использованием вложенности на объектную модель так как задал «автор». Иными словами, вложенность не разворачивается в линейную структуру (как в примерах), а сохраняется. Конечно, браузер может проводить линеаризацию в своих недрах, как, например, браузеры индексируют селекторы для более быстрого матчинга. Но это находится за рамками спецификации и зависит от имплементации.

Таким образом, новый синтаксис не совсем сахар и браузер не превращается в препроцессор, потому что новый синтаксис превращается в иное представление в CSSOM. Но зачем это нужно?

Начну с менее очевидного — комбинаторный взрыв и потенциал для оптимизаций. Рассмотрим такой пример:

ul, ol { & ol, & ul { & ol, & ul { /* ... */ } } }

Здесь указано три блока и шесть сложных селекторов. Если развернуть эту конструкцию в линейную форму, то получится 2 + 4 + 8 = 14 сложных селекторов:

ul, ol, ul ul, ul ol, ol ul, ol ol, ul ul ul, ul ul ol, ul ol ul { /* … */ }

Если использовать :is(), то можно остаться в рамках шести сложных селекторов:

ul, ol, :is(ol, ul) ul, :is(ol, ul) ol, :is(:is(ol, ul) ul, :is(ol, ul) ol) ul, :is(:is(ol, ul) ul, :is(ol, ul) ol) ol { /* … */ }

Можно попробовать оптимизировать в три:

:is(ul, ol), :is(ul, ol) :is(ul, ol), :is(ul, ol) :is(ul, ol) :is(ul, ol) { /* … */ }

От того, что селекторов стало меньше, работы у браузера не уменьшилось. Последний вариант не менее сложный, чем первый (из 14 селекторов). Конечно, плюс в том, что браузер может это представлять внутри себя более оптимально, чем вариант из 14 селекторов. Но чтобы прийти к оптимальному варианту, браузеру нужно делать какие-то оптимизации на этапе анализа CSS по группировке селекторов. Учитывая, что в современных сайтах и приложениях содержатся тысячи правил (селекторов), то их группировка и оптимизация выглядит очень затратной, если вообще возможной, и браузеры могут эту оптимизацию не производить (как, например, не весь JavaScript оптимизируется на этапе разбора). Поэтому, стили организованные с использованием вложенности, имеют больший потенциал для группировки селекторов и внутренних оптимизаций.

Также стоит заметить, что :is() не панацея и этот функциональный псевдокласс применим в данном примере, так как сложные селекторы были одной специфичности. Если же специфичность у селекторов разная, то для всех селекторов внутри :is() назначается специфичность равная максимальной специфичности среди них (сам псевдокласс :is() не делает вклада в специфичность). Таким образом, в случае, если специфичность у селекторов разная, то :is() уже нельзя использовать для уменьшения числа селекторов. Но с вложенностью у браузеров остаётся возможность оптимизации, так как они и не должны будут использовать внутри :is(), а скорее некоторые свои внутренние механизмы, которые будут учитывать специфичность правильно.

Ещё неочевидный момент, возможность подмешать стилевой блок (в том числе, с вложенностью) в другой блок. Техническая возможность динамически менять таблицы стилей и отдельные правила существует уже лет 20. Даже Internet Explorer 6 это мог (хотя у него было нестандартное API для этого, то есть не по спеке, потому что она появилась позже). Другой вопрос, что это почти никак не используется в веб-разработке, да и мало кто об этом знает. Вроде как некоторые CSS-in-JS решения используют, но это неточно.

Так вот теперь будет возможно подмешивать стилевые блоки в другие блоки. Тут мне видится самым сложным это найти нужный блок. Да и хороших примеров пока не знаю. Но была бы возможность, а применение найдётся. Те же кастомные свойства на этапе внедрения тоже считали бесполезными, а потом открыли много крутых техник, среди которых, например, сортировка таблицы на CSS.

Инлайновые селекторы

Ну и ключевое, что вносит CSS Nesting — это возможность стилизации состояний элемента, его псевдоэлементов и дочерних элементов, с использованием атрибута style. Да, содержимое style — такой же блок стилей, но без селектора (если точнее, то CSSStyleDeclaration). На данный момент, этот атрибут позволяет задать стили только для самого элемента. Если необходимо задать стили для состояний наведения :hover или фокуса :focus, то для этого нужно описывать стили отдельно. Либо, что тоже не редкость, прибегают к решениям на JavaScript, чтобы менять стили состояний по событиям. Однако JavaScript пока ещё не может стилизовать псевдоэлементы, поэтому ::before и ::after обычно превращаются в дополнительные вложенные элементы. А для других псевдоэлементов по-прежнему нужны стили сбоку.

В общем, ценность и возможности атрибута style весьма скромные. Это всегда было некоторым камнем преткновения, что style ограничен и не имеет возможности развиваться вместе с CSS. Несмотря на то, что возможно это и к лучшему (к этому ещё вернёмся), случаи бывают разные.

Теперь же, с CSS Nesting станет возможным следующее:

Оставим на потом обсуждение, насколько это хорошо или плохо. Пока речь про возможности. И выглядит так, что с CSS Nesting атрибут style станет наравне с остальными способами задания стилей. Конечно, этим закрываются не все возможности CSS и часть остаётся за бортом, например, директивы @font-face, @keyframes, @supports и подобные.

Уже сейчас CSS Nesting должен заиграть для вас новыми красками. Но и это ещё не финал 😉

Возможны миксины

Сразу предупрежу, что в этой секции будут мои домыслы. Однако они могут быть недалеки от правды, если сложить А + Б. Где «А» это CSS Nesting, а «Б» это давняя мечта многих — примеси или миксины.

Начну с предыстории. Летом 2015 уже знакомый нам Таб Аткинс формализовал первый черновик спецификации CSS @apply Rule. Это было на фоне внедрения CSS Custom Properties. Ключевая идея: раз в значение кастомных свойств можно задать что угодно, почему бы не задавать в значении блок деклараций. Тогда с помощью директивы @apply, такие значения (блоки) можно подмешивать в другие блоки. То есть, как несложно догадаться, получаем те самые миксины.

Выглядело это так:

:root { --toolbar-theme: { background-color: hsl(120, 70%, 95%); border-radius: 4px; border: 1px solid var(--theme-color, late); }; --toolbar-title-theme: { color: green; }; } .toolbar { @apply --toolbar-theme; } .toolbar > .title { @apply --toolbar-title-theme; }

Если не вдаваться в детали, то в целом должно быть знакомо и понятно. Механика кастомных свойств, а именно переопределение значений (блоков) через каскад. Это кстати, первый прецедент, когда внутри блока деклараций появляется директива.

Выглядело многообещающе, но если начать вдаваться в детали, то возникают вопросы. До широкого обсуждения спецификация не дошла, в сентябре 2018 Таб Аткинс её отменил. Хотя это не помешало Angular сообществу подхватить идею и достаточно активно использовать в экосистеме фреймворка, насколько знаю.

Почему эту идею похоронили? Она не решала проблему. Ведь таким образом можно подмешать набор деклараций в конкретный блок, а этого недостаточно. Если, например, мы хотим подмешать стили по принципу миксина, то мы скорее хотим повлиять не только на дефолтное состояние, но и на состояния :hover, :focus и другие, а может и на псевдоэлементы или дочерние элементы. Получалось:

:root { --cool-border: { border: 1px solid gold; }; --cool-border-hover: { border-color: orange; }; --cool-border-focus: { border-color: blue; } } .button { @apply --cool-border; } .button:hover { @apply --cool-border-hover; } .button:focus { @apply --cool-border-focus; }

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

И вот теперь на горизонте появляется модуль CSS Nesting, открывающий новые возможности и в этом вопросе. С новыми вводными, предыдущий пример можно здорово упростить:

:root { --cool-border: { border: 1px solid gold; &:hover { border-color: orange; } &:focus { border-color: blue; } }; } .button { @apply --cool-border; }

Теперь миксин является целостной сущностью, его использование максимально простое и лаконичное, не нужно знать о его устройстве (в теории, естественно). Конечно, остаётся много открытых вопросов. Например, как должен миксин взаимодействовать с содержимым блока (декларациями и блоками), действительно ли миксины должны использовать механизм кастомных свойств для объявления, нужен ли каскад и так далее. С момента появления кастомных свойств в браузерах, появились новые ожидания от них, в частности добавилась новая директива @property. Не исключено, что объявление миксинов будет осуществляться тоже через директиву, например, @mixin.

Поживём — увидим. И хотя это все лишь мои домыслы, кажется CSS Nesting как раз подводит к чему-то такому. Синтаксис же играет второстепенную роль, главное механика, возможности и решается ли проблема.

Когда CSS Nesting появится в браузерах?

На этот вопрос есть два ответа: «никогда» и «не менее чем через два года».

Ответ «никогда» может показаться странным, но это связано с отсутствием сигналов от разработчиков браузеров. Всё, что у нас есть — это черновик спецификации, пусть и официальный и прошедший публичную дискуссию. А вот про мнение производителей браузеров или какие-либо обсуждения пока ничего не известно, по крайней мере мне. В трекерах есть достаточно свежие тикеты (Blink, Firefox, Safari), но подробностей там нет — просто чтобы было. На «Can I Use» тоже пока не добавили.

Сегодня для новых фич такого масштаба необходим консенсус разработчиков ключевых браузеров, что функциональность должна быть в веб-платформе и это будет реализовано в браузерных движках. Разработчики — практики (а пока была только теория), и они потенциально могут найти технические проблемы, которые не позволят внедрить CSS Nesting либо вообще, либо в текущем виде. Поэтому, пока нет официального кивка со стороны разработчиков браузеров, будет сохраняться вероятность, что CSS Nesting не случится никогда.

Но допустим, что вендоры браузеров взяли и договорились, что CSS Nesting быть. Допустим, это случилось сегодня. Это не значит, что все тут же кинутся пилить. CSS Nesting — это мега-эпик, а эпики на этот год уже спланированы, вроде инициативы Compat2021. Так что попасть в планы CSS Nesting сможет только ближе к следующему году, а появляться в релизах начнёт не раньше второй половины 2022 года. И это оптимистичные прогнозы.

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

Изменение парсера CSS

Технически не очень сложно. Если бы CSS Nesting был синтаксическим сахаром, то на этом пункте бы всё и закончилось. Эта часть является критичной, так как влияет на скорость загрузки страниц, поэтому внимание к этим изменениям будет повышенное. Хотя синтаксис CSS Nesting спроектирован так, чтобы иметь как можно меньшее влияние на время разбора. Поэтому тут ожидается меньше всего сложностей.

Матчинг селекторов

По идее, наиболее сложную часть в браузерах уже реализовали — это псевдоклассы :is() и :where(). Конечно, это явно не связанные вещи, но ведь вложенные правила можно развернуть в линейный список используя эти псевдоклассы. Конечно, ещё нужно написать эту конвертацию и могут возникнуть нюансы. Но наличие :is() и :where() явно упрощает внедрение CSS Nesting. И вероятно, как я писал выше, CSS Nesting можно будет использовать для оптимизаций. Но это неточно.

Расширение CSSOM

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

Переработка атрибута style

Именно «переработка», так как сейчас этот атрибут задаёт стили только для самого элемента, которые не влияют на стили дочерних элементов (кроме наследуемых свойств), не создают псевдоэлементы, не определяют состояний и условий (псевдоклассы), не реагируют на изменение окружения (@media). Этим фактом не могли не воспользоваться для оптимизаций. Очевидно, что часть оптимизаций работать перестанет. Возможно только в случае, если в значении атрибута style используются конструкции из CSS Nesting. Но в любом случае, придётся придумывать новую машинерию, чтобы всё заработало. Чего только стоит ситуация, что для вложенных правил (rule) в style корнем будет является некий виртуальный блок без селектора. Вероятно нужно будет мёржить правила из style с правилами из таблиц стилей, причём этот мёрж должен быть для каждого элемента и на лету. И всё это выглядит как угроза для производительности и в целом всё непросто. Пока этот пункт про style кажется самым сложным и рискованным.

Браузерные DevTools

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

Тесты

Для CSS тесты пишут как общие для спеки (пишут всем миром), так и конкретно под браузер, если нужно протестировать некоторые особенности. Тестов пока нет, и это тоже потребует немало времени и усилий. Без полного набора тестов нельзя будет сказать, корректно ли и полностью ли реализована функциональность.

В общем, объём работы выглядит внушительным. Поэтому на быстрое внедрение рассчитывать не приходится.

Влияние CSS Nesting на разработку

Начнём с того, что все инструменты, которые работают с CSS, сломаются в той или иной степени при использовании CSS Nesting:

Редакторы: раскраска, рефакторинг, саджест и другие;

Раскраска кода;

Сборщики и траспайлеры CSS;

Минификаторы CSS;

Инструменты по сбору покрытия, критический CSS и прочие;

И многие другие.

Всё это нужно будет дорабатывать. Доработки разного уровня сложности и требуют разных временных затрат. Поэтому сомнительно ожидать, что все инструменты разом поддержат CSS Nesting.

Также CSS Nesting может повлиять на распределение использования инструментов: слабо развивающиеся или заброшенные проекты (но популярные в прошлом), или те которые будут долго тянуть с поддержкой, могут потерять своих пользователей. CSS Nesting — первая такая функциональность, которая серьёзно влияет на обратную совместимость, а точнее её ломает. Но всё это станет актуальным, только когда производители браузеров решат внедрять CSS Nesting. А пока этого не случилось, нет смысла что-либо внедрять, кроме как ради академического интереса.

Есть также мнение, что CSS Nesting, с учётом потенциального расширения возможностей style, укрепит позиции апологетов CSS-in-JS. Чтобы не было путаницы, стоит уточнить, что речь про тех, кто использует одну из библиотек CSS-in-JS. Так вот, для пользователей таких библиотек скорее всего ничего не поменяется. А вот для их авторов потенциально будет проще реализовать некоторые механизмы. То есть CSS Nesting может повлиять только на техническое исполнение, нежели на идеологический аспект. Кстати, многие решения CSS-in-JS выносят статические части стилей в обычные файлы и используют DOM и CSSOM, наравне с атрибутом style. В таких случаях, используются все возможности CSS (состояния, псевдоэлементы, @media и другие).

Но есть ещё и техника, когда все стили помещают в атрибут style с помощью JavaScript. Такое сегодня часто можно увидеть в React-компонентах и виджетах, так как это позволяет не волноваться за поставку и внедрение в страницу сопутствующего CSS. Это тоже своего рода CSS-in-JS. И в таких случаях обычно используют события (JavaScript), чтобы менять состояние (:hover, :focus и другие) или реагировать на изменение окружения (@media). В таких случаях, с CSS Nesting во многих случаях получится избавиться от необходимости в JavaScript. На мой взгляд, это хорошо. И хотя я не разделяю такой подход (когда все стили в атрибуте style) и считаю его антипаттерном, но ситуации бывают разные и иногда это может быть оправдано.

По моему мнению, диспозицию в подходах к организации стилей CSS Nesting не меняет. Но, да, он поможет подходам CSS-in-JS улучшить техническую реализацию.

Заключение

В завершении, хотелось бы отметить, что помимо потенциального удобства в написании стилей, оптимизаций в браузерах и новых возможностей, CSS Nesting несёт и увеличение сложности. Сложность в изучении, валидации, обработке, сборке, интроспекции, отладке и так далее. И чтобы CSS Nesting стал явью, нужно усилие большого количества людей. Стоят ли эти усилия того, пока не ясно. Но на мой взгляд, с учётом потенциальных миксинов, внедрение CSS Nesting — вопрос времени. Вопрос только в том, насколько долго ждать.

Скомпилировано из публикаций канала «Горшочек варит» Романа Дворнова с разрешения автора — прим. редактора.

Миграция с Vue CLI на Vite

Fri, 09 Apr 2021 00:00:00 GMT

Я недавно переносил свои проекты на Vue 2 со стэка Vue CLI и Webpack на Vite. После того, как я сделал это в третий раз, у меня сложилось представление об этом процессе, которое я излагаю в этой статье.

package.json

devDependencies

Давайте удалим зависимость @vue/cli-service и заменим её на vite 🚀

npm un @vue/cli-service npm i vite -D

"devDependencies": { - "@vue/cli-service": "4.3.1", + "vite": "2.1.3",

Вы можете также удалить все остальные зависимости, которые начинаются с @vue/cli-plugin-xxx, поскольку они всё равно больше не будут работать, например:

npm un vue/cli-plugin-babel vue/cli-plugin-eslint vue/cli-plugin-unit-jest

"devDependencies": { - "@vue/cli-plugin-babel": "4.3.1", - "@vue/cli-plugin-eslint": "4.3.1", - "@vue/cli-plugin-unit-jest": "4.3.1",

Если вы используете Vue 2, нужно будет добавить плагин vite-plugin-vue2, который мы будем использовать в нашем vite.config.js:

npm i vite-plugin-vue2 -D

"devDependencies": { + "vite-plugin-vue2": "1.4.2",

Также, если вы используете Git-хуки, без сомнения нужно будет установить yorkie, чтобы все заработало как раньше (думаю, что этот инструмент был частью Vue CLI, а в Vite его нет).

npm i yorkie -D

scripts

Мы заменим скрипт serve для Vue CLI на соответствующий скрипт для Vite:

"scripts": { - "serve": "vue-cli-service serve", + "dev": "vite",

Если вам ближе использование слова serve вместо dev, можете использовать и его.

Мы еще вернемся к скриптам build, test и lint в конце статьи.

index.html

Давайте посмотрим на наш public/index.html, который мы должны переместить в корневую папку проекта.

Мы также должны добавить скрипт, который является точкой входа приложения и без которого Vite не сможет собрать проект:

И наконец, мы должны заменить путь до фавиконки <%= BASE_URL %>favicon.ico на более простой /favicon.ico (Vite сможет отыскать его сам в папке public).

- + … +

vite.config.js

Мы должны переименовать наш файл с конфигурацией сборки с vue.config.js на vite.config.js.

В начале файла нужно указать следующее:

import { defineConfig } from 'vite' import { createVuePlugin } from 'vite-plugin-vue2' export default defineConfig({ plugins: [ createVuePlugin(), ], })

Чтобы сделать миграцию на Vite максимально прозрачной для вашей команды разработчиков, давайте оставим тот же порт 8080, который и был:

import { defineConfig } from 'vite' import { createVuePlugin } from 'vite-plugin-vue2' export default defineConfig({ server: { port: 8080, } })

Все доступные опции для конфигурации можно посмотреть в документации.

@ alias

Если вы используете псевдонимы Webpack для импортов в файлах вашего проекта, мы должны переопределить их:

import { defineConfig } from 'vite' import { createVuePlugin } from 'vite-plugin-vue2' export default defineConfig({ resolve: { alias: [ { find: '@', replacement: path.resolve(__dirname, 'src') } ] }, })

Для пользователей WebStorm: при использовании Webpack вам достаточно было прописать в настройках IDE путь до файла с конфигурацией Webpack (для Vue CLI это был путь до базового файла Webpack: node_modules/@vue/cli-servive/webpack.config.js) и WebStorm магическим образом подхватывал псевдоним @, что позволяло очень просто обращаться к библиотекам.

Пока WebStorm не умеет парсить vite.config.js, и мы должны помочь ему, прописав настройки псевдонимов вручную в webStorm.config.js:

System.config({ paths: { '@/*': './src/*', }, })

Это всё, что вы должны сделать :)

Расширение .vue и импорты

Для Webpack было совершенно не обязательно указывать расширение .vue для файлов компонентов, но не для Vite. Нужно заменить:

- import DotsLoader from '@/components/DotsLoader' + import DotsLoader from '@/components/DotsLoader.vue'

Не по теме, но из моего опыта: использовать импорты с полными путями — лучшая практика.

Очистка маршрутов для ленивой загрузки

Вы со спокойной душой можете удалить комментарии webpackChunkName для генерации чанков для определенных маршрутов:

{ path: '/links', name: 'linksPage', component: () => import(/* webpackChunkName: "links" */ './views/LinksPage.vue'), },

Используя Vite можно писать так:

{ path: '/links', name: 'linksPage', component: () => import('./views/LinksPage.vue'), },

Я в этом не эксперт, но если вы действительно хотите изменить имя для вашего чанка, вероятно, вы можете это сделать принудительно с помощью Rollup output.entryFileNames.

Также, можете посмотреть опции для сборщика Vite build.rollupOptionsи перенести часть задач на него.

Переменные окружения

Мы должны заменить все process.env, которые Vite не понимает. Для Vite нужно использовать import.meta.env.

Если ваш роутер использует встроенную переменную окружения BASE_URL, то ее имя надо будет заменить на import.meta.env.BASE_URL:

const router = new Router({ mode: 'history', - base: process.env.BASE_URL, + base: import.meta.env.BASE_URL, routes: [...firstLevelRoutes, ...backOfficeRoutes] })

Другой встроенной переменной окружения является import.meta.env.PROD. Давайте будем использовать её везде, где можем:

- if (process.env.NODE_ENV === 'production') { + if (import.meta.env.PROD) {

Убедитесь, что настройка NODE_ENV=production соответствует настройкам среды в файле .env или в переменных окружения сервера, на котором собирается ваше приложение во время релиза. Подробнее можно посмотреть в документации по переменным окружения и режимах работы Vite.

Что касается ваших собственных переменных окружения, которые вы использовали раньше с префиксом VUE_APP — вам нужно будет заменить его на VITE. Любая переменная окружения, которая будет начинаться с VITE_xxx, будет доступна во всём вашем коде.

Вот пример для моей переменной окружения BACKEND_URL:

export const backendInstance = axios.create({ - baseURL: `${process.env.VUE_APP_BACKEND_URL}/api`, + baseURL: `${import.meta.env.VITE_APP_BACKEND_URL}/api`, timeout: 10000, })

Файл .env.local:

VITE_APP_BACKEND_URL=http://localhost:3001

Тесты

Поскольку мы больше не можем использовать vue-cli-service test:unit, давайте настроим наши тесты.

Для начала надо обновить скрипт для тестов test:

- "test:unit": "vue-cli-service test:init", + "test": "jest",

Затем пройдемся по шагам, описанным в документации.

Если вы использовали файл babel.config.js, то нужно будет сделать что-то вроде:

- presets: ['@vue/cli-plugin-babel/preset'], + presets: ['@babel/preset-env'],

У меня были ошибки для выражения import.meta.env.

К сожалению, простых настроек для модульных тестов в Vite нет, но этот комментарий мне помог.

Мой файл babel.config.js теперь выглядит так:

module.exports = { presets: ['@babel/preset-env'], // Чтобы Jest не нервировали 'import.meta.xxx' plugins: [ function () { return { visitor: { MetaProperty(path) { path.replaceWithSourceString('process') }, }, } }, ], }

Вы можете усилить сборку плагином babel-plugin-transform-import-meta для Babel, который будет исправлять автоматически ошибки в ваших тестах, связанные с import.meta.

Вы можете почитать и обсудить в отдельном ишью на GitHub совместную работу Vite и Jest.

Ошибка regeneratorRuntime

49 | export const actions = { > 50 | init: async ({ commit }, routeContext) => { ReferenceError: **regeneratorRuntime** is not defined

Устанавливая regenerator-runtime и ссылаясь на него в моем setupTests.js, я обнаружил, что эту ошибку уже починили.

npm i regenerator-runtime -D

Файл jest.config.js:

module.exports = { moduleFileExtensions: [ 'js', 'json', // Говорит Jest обрабатывать файлы *.vue 'vue', ], transform: { // Обработай файл *.vue с помощью vue-jest '.*\\.(vue)$': 'vue-jest', // Обработай файлы *.js с помощью babel-jest '.*\\.(js)$': 'babel-jest', }, setupFiles: ['./setupTests'], moduleNameMapper: { '^@/(.*)$': '/src/$1', }, collectCoverage: false, }

Первая строчка файла конфигурации setupTests.js будет такой:

import 'regenerator-runtime/runtime'

Линтер

Я заменил два скрипта для линтинга одним:

- "lint": "vue-cli-service lint src --no-fix", - "lint:fix": "vue-cli-service lint src", + "lint": "eslint src", + "lint:fix": "eslint src --fix",

Развертывание приложений

В этом примере мое приложение крутится в облаке S3 и CloudFront. У меня два окружения для режима продакшена: preprod и prod. Поэтому у меня и два файла для настройки окружения .env:

.env.preprod

.env.prod

Когда мы собираем наше приложение с помощью Rollup, мы указываем режим, и Vite меняет переменные окружения на те, которые соответствуют этому режиму.

Это очень похоже на Vue CLI, поэтому обновление скриптов в package.json очень простое:

- "build-preprod": "vue-cli-service build --mode preprod", - "build-prod": "vue-cli-service build --mode prod", + "build-preprod": "vite build --mode preprod", + "build-prod": "vite build --mode prod",

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

Небольшая ремарка: мне пришлось также поменять максимальный размер для чанка в vite.config.js:

import { defineConfig } from 'vite' import { createVuePlugin } from 'vite-plugin-vue2' export default defineConfig({ build: { // По умолчанию 500 chunkSizeWarningLimit: 700, }, })

Так делать нехорошо, я знаю.

Визуализация сборки

Это последнее упоминание Vue CLI, которое было в моей кодовой базе:

"build:report": "vue-cli-service build --report",

Давайте поищем что-то похожее в мире Rollup. Использование плагина rollup-plugin-visualizer оказалось достаточно хорошим решением для меня.

Я импортировал этот плагин и прописал его в vite.config.js:

import { defineConfig } from 'vite' import { createVuePlugin } from 'vite-plugin-vue2' import visualizer from 'rollup-plugin-visualizer' export default defineConfig({ plugins: [ createVuePlugin(), visualizer(), ], })

Результат теста в сгенерированном файле stats.html:

Несколько метрик

Время старта

Загрузка Vite: около 4 секунд — предполагается, что это время не сильно изменится, даже если проект будет расти 🙌

Загрузка с Vue CLI и Webpack: около 30 секунд — это время постоянно растет при увеличении количества файлов в проекте 😢

Горячая перезагрузка

Vite:

Простые изменения (HTML-файлы, CSS-классы): очень быстро! 🚀

Серьёзные изменения (переименование функций JS, добавление компонентов): не уверен, иногда мне было удобнее перезагрузить страницу самому.

Vue CLI и Webpack:

Простые изменения: около 4 секунд 😕

Серьезные изменения: никогда не жду, сам перезагружаю страницу.

Первая загрузка страницы

Мы запрашиваем страницу в первый раз после запуска Vite. У меня было веб-приложение с большим количеством компонентов. Давайте взглянем на вкладку Network в Chrome DevTools:

Vite: загрузка около 1430 JS-файлов длится примерно 11 секунд 😟

Vue CLI и Webpack: загрузка около 23 JS-файлов длится примерно 6 секунд 👍

Посмотрим, как будет развиваться проект. Пока у меня не было достаточного опыта использования Vite, но начало многообещающее. Надо будет ещё оценить все возможности этого сборщика. Например, заявлено, что в Vite круто реализована ленивая загрузка компонентов!

Заключение

Поработав некоторое время с Vite, могу сказать, что это был очень приятный опыт 🌟 И теперь все тяжелее и тяжелее работать с Webpack на других проектах!

Поддержка веба во Flutter теперь стабильная

Mon, 22 Mar 2021 00:00:00 GMT

Мы позиционируем Flutter как UI-фреймворк для сборки красивых приложений на любой платформе. Сегодня мы анонсируем поддержку сборки веб-приложений во Flutter 2.

Первая версия Flutter поддерживала только мобильные платформы (iOS и Android). И это позволило разработчикам загрузить в магазины App Store и Google Play больше 150 000 приложений. Появление сборки для веба означает не только то, что уже написанные приложения могут быть доступны более широкой аудитории, это означает появление новых способов взаимодействия с пользователем в вебе.

В этом релизе мы сфокусируемся на трех сценариях использования:

Прогрессивные веб-приложения (PWA) — которые можно запустить в браузере и на десктопе как обычные приложения.

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

Веб-версии существующих мобильных приложений на Flutter — с единой кодовой базой для всех платформ.

Эта статья описывает то, что мы успели сделать на настоящий момент. Мы показываем на примерах, какие преимущества вы можете получить, используя поддержку веб-платформы в приложениях Flutter.

iRobot Education разработало приложение iRobot Coding, которое использует Flutter, доступно в вебе, чтобы каждый мог поучиться программировать

Наше путешествие в веб

Сегодня веб-платформа богата как никогда: поддержка графических ускорителей для 2D- и 3D-графики, поддержка работы приложений в офлайне и доступ к API операционной системы и железу устройства, на котором она установлена. Веб-приложения сегодня могут быть написаны на фреймворках вроде React, Angular, Vue, Flask, которые используют эту платформу, чтобы дать разработчикам гибкость в создании веб-приложений.

Поскольку Flutter написан на языке Dart, который из коробки поддерживает трансляцию в JavaScript, следующий шаг — использование Flutter для веба — был совершенно естественным.

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

На уровне архитектуры, Flutter базируется на:

фреймворке, написанном на Dart, который использует общие абстракции, такие как виджеты, анимации и жесты;

движке, написанном на C++, который рендерит код для целевого устройства, используя системные API.

Сам Flutter написан на Dart, и около 700 000 строк кода используются для мобильной платформы, десктопа и веба. Код любого Flutter-приложения также написан на Dart: мы используем компилятор Dart для разработки мобильных приложений (dartdevc) и транслятор Dart (dart2js) для перевода вашего кода в JavaScript, который, в свою очередь, может быть уже перенесен на сервер.

Благодаря поддежке трансляции программ на языке Dart в программы на JavaScript, наша работа сводилась лишь к замене низкоуровневого движка для рендеринга, написанного на C++, который ранее использовался только при рендеринге кода для мобильных приложений, на новый движок с поддержкой API веб-платформы. Теперь движок Flutter для веба предлагает использовать два варианта: рендеринг в оптимизированный HTML и рендеринг с помощью CanvasKit, который использует WebAssembly и WebGL для перевода команд движка Skia в команды рисования на канвасе в браузере. Flutter не умеет напрямую транспилировать виджеты в эквивалент на HTML.

Наша цель — предложить новый путь для веб-платформы, который улучшил бы пользовательский опыт.

Путь к релизу в стабильной ветке

Релиз с поддержкой веба в бета-ветке появился более года назад и мы получили много информации о том, как его используют разработчики. Мы работали с несколькими из них и сегодня их веб-приложения уже в продакшене.

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

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

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

Первоначально мы стартовали с HTML и DOM-модели. В ней веб-движок Flutter переводил сгенерированную сцену в HTML, CSS или Canvas и рендерил каждый кадр на страницу как дерево HTML-элементов. Даже несмотря на очень хорошую браузерную поддержку и малые размеры, которые обеспечивал нам движок для рендеринга HTML, производительность для перерисовки была меньше, чем нужно для приложения с быстро менящейся графикой, наподобие Rive — инструмента для совместного создания анимаций, написанный на Flutter.

Rive, инструмент для создания пользовательских анимаций, перестроил свое приложение с помощью Flutter в Интернете, и теперь оно доступно в бета-версии.

Чтобы эффективно справиться с точностью, которая необходима для отрисовки сложной графики, мы начали экспериментировать с CanvasKit, который позволял рисовать в браузере с помощью команд Skia, используя WebAssembly и WebGL. Мы обнаружили, что CanvasKit может дать большую производительность, качество и точность отрисовки, используя графические ускорители. Вы можете посмотреть демо Феликса Блашке, талантливого участника Flutter-сообщества.

Демо-версия Flutter Plasma, созданная Феликсом Блашке и работающая в Safari, Firefox, Edge и Chrome.

Flutter поддерживает два режима рендеринга, каждый из которых обладает преимуществами или недостатками, в зависимости от сценария использования:

Режим HTML — использует комбинацию HTML-элементов, CSS, элементов на канвасе и SVG-элементов. Этот режим обеспечивает наименьший размер приложения.

Режим CanvasKit — — полностью поддерживает возможности Flutter, доступные на мобильных платформах или десктопе, но добавляет 2 Мб к размеру веб-приложения.

Для оптимизации характеристик вашего веб-приложения на Flutter для всех устройств, режим рендеринга выбирается автоматически. Приложение по умолчанию запускается с помощью движка HTML в мобильных браузерах и с помощью CanvasKit в браузерах на десктопе. Вы можете использовать ключ --web-renderer html или --web-renderer canvaskit для прямого выбора режима рендеринга.

Возможности, специфические для веба

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

Веб-платформа имеет много сильных сторон, одна из них — большое количество пользователей. Одна из многих причин обеспечить поддержку веб-версии существующего Flutter-приложения — охватить пользователей за пределами магазинов мобильных приложений. Мы добавили поддержку роутинга с помощью (URL-стратегий), чтобы ваши пользователи могли получить доступ к вашему приложению, просто кликнув по ссылке.

Демо-страница приложения Flutter Plasma — это пример плагина url_strategy, основанного на кастомных URL-стратегиях Flutter.

Гиперссылки являются критически важным механизмом навигации в вебе. Новый виджет link в пакете url_launcher позволяет использовать возможности навигации по якорям внутри вашего приложения и переходы на внешние сайты. Вы можете использовать link в нужных вам виджетах, включая кнопки, встроенный текст, картинки, чтобы открывать ссылки в той же вкладке браузера или в новой.

Ещё одной неотъемлемой частью приложения является рендеринг текста. Разработка системы верстки текста была одной из самых больших проблем для поддержки Flutter в вебе. Поскольку в вебе отсутствует специальное API для обработки элементов с текстом, Flutter должен измерять размеры абзаца (класс paragraph), обращаясь к методу layout(). Эти измерения могут серьезно повлиять на производительность, поэтому в новый механизм измерения размеров текста на канвасе добавлена поддержка двух вариантов текста: простого и форматированного. Сейчас Flutter позволяет измерять размеры в вебе эффективно чтобы, например, рисовать выделение маркером в тексте.

Взаимодействие с текстом так же важно, как быстрый и точный рендеринг. Текст можно выделить, скопировать и вставить с помощью виджетов SelectableText и EditableText. Кроме того, текстовые поля формы поддерживают автозаполнение с помощью класса AutofillGroup, который обращается к браузеру за пользовательскими данными, доступными для автозаполнения.

Flutter 2 частично поддерживает использование прогрессивных веб-приложений (PWA). PWA — это простой и безопасный способ преодолеть разрыв между мобильными приложениями и веб-приложениями силами проекта Fugu команды Chrome.

Invoice Ninja, приложение для управления счетами, запустило PWA-версию, используя кодовую базу существующего мобильного приложения на Flutter.

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

Поддержка экранов десктопов

Мы хотим, чтобы веб-приложение на Flutter работало правильно, несмотря на форму и размер окна браузера. В мобильных браузерах Flutter-приложения уже имеют великолепную поддержку жестов и скроллов, независимо от того, поддерживается ли это в мобильном приложении. Браузеры на десктопе предлагают другие способы взаимодействия пользователя с элементами интерфейса, и Flutter должен поддерживать их на уровне фреймворка.

Например, пользователь, при просмотре контента на десктопе ожидает отображение полос прокрутки, которыми можно управлять с помощью мышки и клавиатуры. Поэтому новые интерактивные полосы прокрутки поддерживают темизацию ScrollbarTheme и возможность прокручивать перетаскиванием ползунка. Класс контроллера PrimaryScrollController теперь поддерживает использование сочетания клавиш для навигации сразу из коробки.

Решение по управлению недвижимостью для Zurich Insurance, созданное компанией Spica Technologies, является отличным примером веб-поддержки бизнес-приложений Flutter, которую можно включить в десктопных браузерах.

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

Наконец, чтобы поддерживать всех пользователей, мы расширили используемую семантику для поддержки доступности на Windows, macOS и ChromeOS. В вебе дополнительное DOM-дерево, которое называется SemanticsNode генерируется параллельно с DOM-деревом для объекта рендеринга RenderObject. Дерево SemanticsNode переводит флаги, действия, подписи и другие семантические свойства в ARIA-атрибуты. Сейчас вы можете использовать Narrator, VoiceOver, TalkBack или ChromeVox для навигации веб-приложений на Flutter.

Экосистема плагинов

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

С начала бета-тестирования мы с помощью сообщества обеспечили поддержку веб-платформы в следующих плагинах:

image_picker;

google_maps;

firebase_analytics;

firebase_storage;

connectivity;

cloud_firestore;

cloud_functions;

cross_file.

Что дальше

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

Многое в этом релизе стало возможным, благодаря предложениям и замечаниям со стороны пользователей фреймворка для веба на этапе бета-тестирования. И поэтому мы благодарим вас! Продвигаясь вперед, мы видим нашу главную цель в том, чтобы как можно быстрее разрешать все проблемы, что позволит нам оставаться сфокусированными на возможностях реализации высококачественных приложений на Flutter для всех целевых платформ.

Moi Mobiili, современный оператор мобильной виртуальной сети, недавно запустил свое веб-приложение с помощью Flutter.

Вероятно, производительность будет всегда областью, в которую мы будем вкладываться. Наша цель — уменьшить размер кода и увеличить скорость отображения кадров (fps). Сегодня каждое веб-приложение на Flutter скачивает необходимый код движка для рендеринга. Мы ищем возможности закэшировать часть кода, чтобы увеличить скорость загрузки и уменьшить размер скачиваемого бандла. Недавно мы сделали демо-приложение Flutter Gallery, в котором уменьшили размер, используя отложенную загрузку библиотек, и планируем скоро рассказать о том, чему мы научились.

В течение следующих нескольких месяцев мы продолжим улучшать то, что было сделано:

CanvasKit уже в стабильной ветке, но проблемы еще остались. Например, пока нет фолбэков для спецсимволов или поддержки CORS картинок.

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

Рендеринг текста и поддержка различных функций, например, полноценной стилизации, остается очень сложной задачей, над которой мы продолжаем работать.

Экосистема плагинов — это то, над чем мы также продолжаем работать, чтобы пакеты, опубликованные Google, имели лучший паритет между мобильными устройствами и вебом.

Simplebet использовала веб-поддержку Flutter для создания высокоинтерактивных встраиваемых ставок на НФЛ и НБА в рамках существующего набора мобильных приложений Fanduel.

Начните использовать Flutter для веба

С переносимостью Dart, мощью веб-платформы и гибкостью фреймворка Flutter теперь вы можете собрать приложения под iOS, Android и браузер с той же кодовой базой.

Для тех из вас, кто уже имеет готовое веб-приложение на Flutter, можно собрать его, используя стабильную ветку. Если вы только начинаете, почитайте flutter.dev/web, посмотрите наш пример и сессию на Flutter Engage, посвященную веб-платформе.

С нетерпением ждем ваших успехов в применении Flutter для веба!

Удобный доступ к буферу обмена с Clipboard API

Tue, 16 Mar 2021 00:00:00 GMT

Возможность скопировать что-то в буфер обмена существует в браузерах достаточно давно. Но синхронный запуск команд copy или write через функцию document.execCommand() всегда был не самым лучшим API, а сейчас считается устаревшим. Его неудобство сподвигло разработчиков к написанию множества библиотек, которые помогали пользоваться копированием с помощью более удобного интерфейса. К счастью, W3C задумался над разработкой нового, более удобного способа взаимодействия с Clipboard API, и уже в декабре 2016 года был опубликован первый черновик современного API. В 2021 году эта возможность уже есть во всех браузерах, хотя и с некоторыми отличиями в поддержке.

Как это было раньше

Почему же всё-таки старая реализация была не самой удачной? Давайте рассмотрим на примере копирования произвольной строки. Для копирования мы должны вызвать document.execCommand('copy'). В случае команды copy функция execCommand принимает только один аргумент. Но что же будет помещено в буфер обмена? Правильный ответ — то, что в данный момент выделено на странице пользователем.

Но что делать, если нам нужно скопировать что-то произвольное, неужели просить пользователя это выделить?

Можно имитировать эту ситуацию с помощью трюка: поместить текст в поле ввода, убрать у него все стили, чтобы строка выглядела как текст, и поставить этому полю readonly. В этом случае мы можем ставить фокус на это поле, выделять в нем текст и вызывать команду копирования. Когда нам нужно скопировать текст, который не отображается на странице, все становится сложнее. Для того, чтобы наглядно увидеть, сколько всего нужно предусмотреть, я сделал небольшой пример.

const isRTL = document.documentElement.getAttribute('dir') === 'rtl'; const button = document.querySelector('button'); button.addEventListener('click', (evt) => { const input = document.createElement('input'); const text = 'https://web-standards.ru/articles/clipboard-api/'; const yPosition = window.pageYOffset || document.documentElement.scrollTop; // Скрываем поле за краями экрана // в зависимости от направления // текста в текущей локали input.style.position = 'absolute'; input.style[isRTL ? 'right' : 'left'] = '-9999px'; // Предотвращаем срабатывание зума на iOS input.style.fontSize = '16px'; // Предотвращаем скролл к элементу input.style.top = `${yPosition}px`; // Не допускаем появления // клавиатуры на мобильных девайсах input.setAttribute('readonly', ''); // Вставляем элемент в DOM document.body.appendChild(input); input.value = text; // Помещаем поле в фокус input.focus(); // Выделяем текст в поле input.select(); // Копируем текст в поле обмена document.execCommand('copy'); // Удаляем фейковый элемент document.body.removeChild(input); });

Теперь кажется должно стать понятно, почему никто не будет скучать по execCommand.

Почему работа с буфером обмена важна для сайтов

Кажется, что такие знакомые сочетания клавиш как Ctrl C и Ctrl V, ну или Cmd C и Cmd V в macOS, знакомы каждому. Но пользователю иногда всё-таки легче кликнуть по кнопке и получить содержимое из буфера обмена. Например, если пользователь хочет скопировать ссылку, то сочетания клавиш не помогают и нужно совершить больше действий. Прямо как на этом сайте: вы можете скопировать ссылку на конкретное место в статье, обозначенное заголовком, если кликнете на иконку справа от заголовка. Попробуйте, получилось?

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

Применение Clipboard API для копирования ссылок.

Удобное копирование сниппетов кода.

Копирование важной информации, которая нужна пользователю.

Возможности современных браузеров

Современный API позволяет работать не только с текстом, но и с картинками, а также копировать смешанный контент или исключать какие-то элементы при попытке копирования или вставки. Например, если скопирововать контент из MS Word и вставить в WYSIWIG, то мы можем отфильтровать все ненужное и привести содержимое в порядок перед тем, как поместим его в форму для редактирования.

Есть несколько способов работы с Clipboard API, один из самых главных — это API для чтения и записи буфера обмена. Методы в window.navigator.clipboard дают прямой доступ к чтению или записи данных в буфер обмена. Также есть и другие возможности, которые мы рассмотрим дальше.

Запись в буфер обмена

Для сохранения данных в буфер можно использовать универсальный метод window.navigator.clipboard.write() или специальный window.navigator.clipboard.writeText(), если мы собираемся помещать в буфер только текст. Оба метода асинхронные и возвращают Promise.

Рассмотрим простой пример с копированием ссылки:

Скопировать ссылку

document.querySelector('.tooltip').addEventListener('click', () => { const tooltip = this.nextSibling; const hash = this.getAttribute('data-href'); navigator.clipboard .writeText(`${window.location.href}${hash}`) .then(() => { // Успех! }) .catch(() => { // Неудача :( }); });

Полный пример кода на GitHub.

Метод window.navigator.clipboard.writeText возвращает Promise, что позволяет обрабатывать исключения, если они возникнут. Одним из таких случаев может быть запрет на запись в буфер. Ниже мы рассмотрим, как запросить необходимые права для чтения и записи в буфер.

Если мы используем функцию window.navigator.clipboard.write, то к копируемым данным можно добавить, например, картинку:

const blob = await fetch('picture.png').then((req) => req.blob(); ); const clipboardItem = new ClipboardItem({ [blob.type]: blob }); window.navigator.clipboard .write([clipboardItem]) .then(() => console.log('Картинка скопирована!')) .catch((err) => console.error(err));

Также можно изменять данные перед записью в буфер обмена, когда пользователь пытается скопировать контент на странице, например, добавлять дополнительную информацию:

document.addEventListener('copy', (evt) => { const source = `Источник: ${window.location.href}`; // Нужно заблокировать стандартное поведение evt.preventDefault(); // И поместить дополнительные данные в Clipboard evt.clipboardData.setData( 'text', `${document.getSelection()}\n\n${source}` ); });

Чтение из буфера обмена

По аналогии с записью, мы также можем читать данные из буфера обмена. Для этого есть аналогичные методы read и readText:

window.navigator.clipboard .readText() .then((data) => console.log('Скопировано', data)) .catch((err) => console.error('Не удалось скопировать', err));

Важная особенность чтения из буфера в том, что оно работает не напрямую. Например, в Google Chrome во время попытки прочитать данные из буфера пользователя уведомят о попытке чтения и предложат разрешить или запретить действие. А Safari, например, покажет контекстное меню с пунктом «Paste».

Попап запрашивает разрешение на чтение буфера обмена в Google Chrome при попытке вставки.

Контекстное меню в Safari при попытке вставки из буфера обмена.

Также можно запросить разрешение на чтение буфера заранее с помощью Permissions API — хотя стоит заметить, что не все браузеры его поддерживают.

window.navigator.permissions.query({ name: 'clipboard-read' }) .then((result) => { if (result.state == 'granted' || result.state == 'prompt') { // Можно записывать данные в буфер } });

Для запроса на запись в буфер используется аналогичная конструкция, но с аргументом { name: 'clipboard-write' }.

Другой вариант чтения данных из буфера — реагировать на вставку данных на сайте. Такое событие можно слушать как на всём document, так и, например, в поле ввода </code>. С помощью этого метода можно перехватить и обработать событие.</p> <pre><code tabindex="0" class="language-js">document.querySelector('textarea').addEventListener('paste', (evt) => { if (evt.clipboardData.files.lenght === 0) { return; } const files = Array.from(evt.clipboardData.files); evt.preventDefault(); uploadFiles(files) .then(() => console.log('Загружено!')) .catch((err) => console.error('Произошла ошибка', err)); }); </code></pre> <h2>Заключение</h2> <p>Правильное использование современных API может значительно повысить удобство ваших интерфейсов. Clipboard API — один из таких случаев, когда вы можете упростить решение задач даже для самых неопытных пользователей.</p> </article> <article> <h1>Я совсем забыл про стили для печати</h1> <p>Tue, 09 Mar 2021 00:00:00 GMT</p> <p>Небольшая коллекция полезных CSS-техник и короткое напоминание, что стили для печати всё ещё актуальны.</p> <p><a href="https://twitter.com/AaronGustafson">Аарон Густафсон</a> опубликовал <a href="https://twitter.com/AaronGustafson/status/788073583528538112">твит</a> про <a href="http://indiegogo.com">Indiegogo</a>, в котором он указал на то, что их страницы с деталями заказа невозможно использовать в печатном виде.</p> <blockquote> <p>Уважаемые <a href="https://twitter.com/Indiegogo">@Indiegogo</a>, пожалуйста, обратите внимание, как выглядит печатная версия вашей страницы с деталями заказа. Прямо сейчас она отстойная. <a href="https://twitter.com/AaronGustafson/status/788073583528538112">Аарон Густафсон</a></p> </blockquote> <p></p> <p>Когда я увидел этот твит, он меня поразил: я осознал, что прошло уже много времени с тех пор, как я оптимизировал страницу для печати или хотя бы думал её проверить. Может быть, это из-за постоянного изменения размеров наших браузеров и уверенности в безупречной работе наших сайтов во всех формах и размерах, или, может быть, просто потому, что я сам редко печатаю веб-страницы. Как бы то ни было, я совершенно забыл о стилях для печати, и это плохо.</p> <p>Оптимизация веб-страниц для печати важна, потому что мы хотим, чтобы наши сайты были максимально доступными, на любом носителе. Мы <a href="https://adactio.com/journal/11409">не должны делать предположения</a> о наших пользователях и их поведении. Люди по-прежнему печатают веб-страницы. Просто задумайтесь о статьях или постах в блогах, рецептах, контактной информации, картах или сайтах недвижимости. Кто-нибудь где-нибудь в конце концов попытается распечатать одну из ваших страниц.</p> <blockquote> <p>Я давно отказался от домашних принтеров, потому что они постоянно ломаются после десяти минут использования. Но не все такие как я, … <a href="https://shop.smashingmagazine.com/products/inclusive-design-patterns">Хейдон Пикеринг (Инклюзивные дизайн-паттерны)</a></p> </blockquote> <p>Если вы такой же, как я, то надеюсь, этот пост освежит вашу память. Если вы ещё не оптимизировали страницы для печати с помощью CSS, советы ниже помогут вам начать.</p> <h2>1. Подключение стилей для печати</h2> <p>Лучший способ подключить стили для печати — объявить <code>@media</code>-выражение в вашем CSS.</p> <pre><code tabindex="0" class="language-css">body { font-size: 18px; } @media print { /* стили для печати */ body { font-size: 28px; } } </code></pre> <p>Также вы можете подключать свои стили печати в HTML, но это создаст дополнительный запрос.</p> <pre><code tabindex="0" class="language-html"><link media="print" href="print.css"> </code></pre> <h2>2. Тестирование</h2> <p>Вам не нужно распечатывать страницу каждый раз, когда вы вносите небольшие изменения. В зависимости от вашего браузера вы можете экспортировать страницу как PDF, открыть предварительный просмотр печати или даже отлаживать прямо в браузере.</p> <p><strong>Обновление от 6 ноября 2019:</strong> Вот <a href="https://css-tricks.com/can-you-view-print-stylesheets-applied-directly-in-the-browser/">подробная статья</a> Криса Койера о том, как эмулировать стили для печати в 2019 году.</p> <p>Для отладки стилей для печати в Firefox откройте <em>Developer Toolbar</em> (<kbd>Shift F2</kbd> или Tools > Web Developer > Developer Toolbar) и введите <em>media emulate print</em> в поле внизу окна браузера и нажмите <kbd>Enter</kbd>. Активная вкладка будет вести себя так, как будто для неё задан медиа-тип <code>print</code>, пока вы не закроете её или не обновите страницу.</p> <p><strong>Обновление от 20 октября 2018:</strong> начиная с Firefox 63+ этот способ не работает, так как Developer Toolbar был удалён.</p> <p></p> <p>В Chrome откройте инструменты разработчика (<kbd>Cmd Opt I</kbd> (macOS) или <kbd>Ctrl Shift I</kbd> (Windows) или View > Developer > Developer Tools, включите группу вкладок с консолью (<kbd>Esc</kbd>), откройте панель рендеринга, поставьте галочку возле <em>Emulate CSS Media</em> и выберите <em>Print</em>.</p> <p></p> <h2>3. Абсолютные единицы измерения</h2> <p>Абсолютные единицы измерения не подходят для экранов, но отлично подходят для печати. В стилях для печати абсолютно безопасно и даже рекомендуется использовать такие абсолютные <a href="https://developer.mozilla.org/en/docs/Web/CSS/length">единицы измерения</a>, как <code>cm</code>, <code>mm</code>, <code>in</code>, <code>pt</code> или <code>pc</code>.</p> <pre><code tabindex="0" class="language-css">section { margin-bottom: 2cm; } </code></pre> <h2>4. Специфичные для страницы правила</h2> <p>Можно определять свойства, характерные для страницы, такие как размеры, ориентация и отступы, с помощью правила <code>@page</code>. Это очень удобно, если вы хотите, чтобы у всех страниц были определенные поля.</p> <pre><code tabindex="0" class="language-css">@media print { @page { margin: 1cm; } } </code></pre> <p>Правило <code>@page</code> — часть спецификации <a href="https://drafts.csswg.org/css-page-3/">Paged Media Module</a>, которая предлагает всевозможные крутые вещи, например, выбор первой печатаемой страницы или пустых страниц, позиционирование элементов в углах страницы и <a href="https://www.smashingmagazine.com/2015/01/designing-for-print-with-css/">многое другое</a>. Вы даже можете применять его для <a href="https://alistapart.com/article/building-books-with-css3">создания книг</a>.</p> <h2>5. Контроль разрывов страниц</h2> <p>Поскольку печатные страницы в отличие от веб-страниц не бесконечны, контент в конечном итоге прерывается на одной странице и продолжается на следующей странице. У нас есть пять свойств для контроля над тем, что происходит в этом случае.</p> <h3>Разрыв страницы перед элементом</h3> <p>Если мы хотим, чтобы элемент всегда находился в начале страницы, мы можем форсировать разрыв страницы при помощи <code>page-break-before</code>.</p> <pre><code tabindex="0" class="language-css">section { page-break-before: always; } </code></pre> <p><a href="https://developer.mozilla.org/en/docs/Web/CSS/page-break-before">Свойство <code>page-break-before</code> на MDN</a>.</p> <h3>Разрыв страницы после элемента</h3> <p><code>page-break-after</code> позволяет нам форсировать или избегать разрывов страницы после элемента.</p> <pre><code tabindex="0" class="language-css">h2 { page-break-after: always; } </code></pre> <p><a href="https://developer.mozilla.org/en/docs/Web/CSS/page-break-after">Свойство <code>page-break-after</code> на MDN</a>.</p> <h3>Разрыв страницы внутри элемента</h3> <p>Это свойство отлично подходит, если вы хотите избежать ситуации, когда элемент разрывается на две страницы.</p> <pre><code tabindex="0" class="language-css">ul { page-break-inside: avoid; } </code></pre> <p><a href="https://developer.mozilla.org/en/docs/Web/CSS/page-break-inside">Свойство <code>page-break-inside</code> на MDN</a>.</p> <h3>Вдовы и сироты</h3> <p>Иногда вы не хотите принудительно разрывать страницу, но, по крайней мере, хотите контролировать количество строк, отображаемых на текущей или следующей странице. Например, если последняя строка абзаца не помещается на текущей странице, последние две строки этого абзаца будут напечатаны на следующей странице, даже если не поместилась только последняя. Так происходит потому, что свойство, которое этим управляет, <code>widows</code> <em>(англ. «вдова» — прим. редактора),</em> имеет значение по умолчанию <code>2</code>. Мы можем это изменить.</p> <pre><code tabindex="0" class="language-css">p { widows: 4; } </code></pre> <p>Если всё наоборот и на текущей странице помещается только одна строка, весь абзац будет напечатан на следующей странице. За такое поведение отвечает свойство <code>orphans</code> <em>(англ. «сирота» — прим. редактора),</em> и его значение по умолчанию также равно <code>2</code>.</p> <pre><code tabindex="0" class="language-css">p { orphans: 3; } </code></pre> <p>Код выше означает, что на текущей странице должно поместиться как минимум 3 строки, чтобы абзац не переехал на следующую страницу целиком.</p> <p>Вот готовый <a href="http://codepen.io/matuzo/pen/oYvBjN">CodePen</a> с некоторыми примерами (<a href="http://s.codepen.io/matuzo/debug/oYvBjN">дебаг-версия</a> для более лёгкого тестирования).</p> <p><a href="http://caniuse.com/#feat=css-page-break">Не все свойства и значения работают во всех браузерах</a>, вам нужно проверять ваши стили для печати в разных браузерах.</p> <h2>6. Сброс стилей</h2> <p>Имеет смысл сбрасывать некоторые стили, вроде <code>background-color</code>, <code>box-shadow</code> или <code>color</code> для печати.</p> <p>Вот отрывок из <a href="https://github.com/h5bp/html5-boilerplate/blob/master/dist/css/style.css">стилей для печати HTML5 Boilerplate</a>:</p> <pre><code tabindex="0" class="language-css">*, *::before, *::after { color: #000000 !important; text-shadow: none !important; background: #ffffff !important; box-shadow: none !important; } </code></pre> <p>Стили для печати — одно из немногих исключений, где нормально использовать <code>!important</code> ;)</p> <h2>7. Удаление ненужного контента</h2> <p>Чтобы избегать бесполезной траты чернил, вам стоит прятать всякое нерелеватное, вроде презентанционных материалов, рекламы, навигации и прочего, при помощи <code>display: none</code>.</p> <p>Возможно, вы даже захотите просто показать основной контент и спрятать всё остальное.</p> <pre><code tabindex="0" class="language-css">body > *:not(main) { display: none; } </code></pre> <h2>8. Раскрытие ссылок</h2> <p>Напечатанные ссылки абсолютно бесполезны, если вы не знаете, куда они ведут.</p> <p>Довольно легко показывать ссылки рядом с их содержимым.</p> <pre><code tabindex="0" class="language-css">a[href]::after { content: ' (' attr(href) ')'; } </code></pre> <p>Конечно, такой код также покажет относительные ссылки, абсолютные ссылки на ваш сайт, якоря и т. д. Что-то вроде этого подойдёт лучше:</p> <pre><code tabindex="0" class="language-css">a[href^='http']:not([href*='mywebsite.com'])::after { content: ' (' attr(href) ')'; } </code></pre> <p>Выглядит <em>интересно,</em> я знаю. Эти строчки означают: покажи значение атрибута <code>href</code> рядом с каждой ссылкой, у которой есть атрибут <code>href</code>, который начинается с <code>http</code>, но не содержит <code>mywebsite.com</code> внутри.</p> <h2>9. Раскрытие аббревиатур</h2> <p>Аббревиатуры следует оборачивать в <code><abbr></code>, а их расшифровки следует добавлять в атрибут <code>title</code>. Имеет смысл показывать их на печатных страницах.</p> <pre><code tabindex="0" class="language-css">abbr[title]::after { content: ' (' attr(title) ')'; } </code></pre> <h2>10. Принудительная печать фона</h2> <p>Обычно браузеры не печатают фоновые цвета и фоновые изображения, если вы не попросите их это сделать, но иногда вы можете захотеть распечатать фон принудительно. Нестандартное <a href="https://developer.mozilla.org/de/docs/Web/CSS/-webkit-print-color-adjust">свойство <code>print-color-adjust</code></a> позволяет вам переопределить настройки по умолчанию для некоторых браузеров.</p> <pre><code tabindex="0" class="language-css">header { -webkit-print-color-adjust: exact; print-color-adjust: exact; } </code></pre> <h2>11. Медиа-выражения</h2> <p>Если вы пишете свои медиавыражения так, как в примере ниже, имейте в виду, что CSS-правила в этом случае не будут применяться к стилям для печати.</p> <pre><code tabindex="0" class="language-css">@media screen and (min-width: 48em) { /* только экран */ } </code></pre> <p>Вы спросите: «почему?» Потому что CSS-правила применяются только тогда, когда <code>min-width</code> равно <code>48em</code>, а тип носителя — <code>screen</code>. Без ключевого слова <code>screen</code> медиавыражение ограничивается только <code>min-width</code>.</p> <pre><code tabindex="0" class="language-css">@media (min-width: 48em) { /* все типы носителей */ } </code></pre> <h2>12. Печать карт</h2> <p>Текущие версии Firefox и Chrome могут печатать карты, а Safari, например, нет. Некоторые сервисы предоставляют <a href="http://staticmapmaker.com/">статические карты</a>, которые вы можете использовать вместо динамических.</p> <pre><code tabindex="0" class="language-css">.map { width: 400px; height: 300px; background-image: url('http://maps.googleapis.com/maps/api/staticmap?center=Wien+Floridsdorf&zoom=13&scale=false&size=400x300&maptype=roadmap&format=png&visual_refresh=true'); -webkit-print-color-adjust: exact; print-color-adjust: exact; } </code></pre> <h2>13. QR-коды</h2> <p><a href="https://www.smashingmagazine.com/2013/03/tips-and-tricks-for-print-style-sheets/#print-qr-codes-for-easy-url-references">В этой статье на Smashing Magazine</a> есть несколько хороших советов. Один из них — показывать QR-код на печатных страницах, чтобы пользователям не приходилось вводить полный адрес страницы для перехода к веб-версии.</p> <h2>Бонус: Печать неоптимизированных страниц</h2> <p>Во время своего исследования я нашел отличный инструмент, который помогает печатать неоптимизированные страницы. С помощью <a href="https://css-tricks.github.io/The-Printliminator/">Printliminator</a> вы можете удалять элементы, просто кликая по ним.</p> <p><a href="https://www.youtube.com/watch?v=Dt8hpqEIL1c">Демо на YouTube</a> и сам проект на <a href="https://github.com/CSS-Tricks/The-Printliminator">Github</a>.</p> <h2>Бонус 2: Gutenberg</h2> <p>Если вы фанат фреймворков, вам может понравиться <a href="https://github.com/BafS/Gutenberg">Gutenberg</a>, который немного упрощает подготовку страницы для печати.</p> <h2>Бонус 3: Hartija</h2> <p>Есть ещё один фреймворк со стилями для печати от <a href="http://www.vcarrer.com/">Владимира Каррера</a>, который называется <a href="https://github.com/vladocar/Hartija---CSS-Print-Framework">Hartija</a>.</p> <p>Вот и всё! Вот ссылка на мой <a href="http://codepen.io/matuzo/pen/oYvBjN?editors=1100">CodePen</a> (<a href="http://s.codepen.io/matuzo/debug/oYvBjN">дебаг-версия</a>), если вы хотите увидеть некоторые из этих вещей в действии. Надеюсь, вам понравилась эта статья.</p> <p>P.S. Спасибо <a href="https://twitter.com/eva_trostlos">Еве</a> за редактирование статьи и Марио за совет про Gutenberg.</p> <h3>Источники</h3> <ul> <li><a href="https://www.youtube.com/watch?v=jF-OQ-BrIAM">CSS Tips and Tricks: Add External URLs to Print Stylesheets</a></li> <li><a href="https://github.com/h5bp/html5-boilerplate/blob/master/dist/css/style.css#L195">Стили для печати в HTML5 Boilerplate</a></li> <li><a href="https://www.smashingmagazine.com/2013/03/tips-and-tricks-for-print-style-sheets/">5 Powerful Tips And Tricks For Print Style Sheets</a></li> <li><a href="http://stackoverflow.com/questions/9519556/faster-way-to-develop-and-test-print-stylesheets-avoid-print-preview-every-time">Faster way to develop and test print stylesheets (avoid print preview every time)?</a></li> <li><a href="https://www.smashingmagazine.com/2015/01/designing-for-print-with-css/">Designing For Print With CSS</a></li> <li><a href="https://github.com/BafS/Gutenberg">Gutenberg</a></li> <li><a href="https://helloanselm.com/writings/unified-media-queries">Quick Trick: Responsive Print Media Queries</a></li> </ul> </article> <article> <h1>Распаковка Docker, часть 3</h1> <p>Wed, 10 Feb 2021 00:00:00 GMT</p> <p><a href="https://web-standards.ru/articles/docker-unboxing-2/">Во второй части</a> мы рассмотрели практические примеры упаковки приложений. В этой заключительной части мы рассмотрим способы использования Docker в процессе самой разработки.</p> <h2>Навигация</h2> <ul> <li><a href="https://web-standards.ru/articles/docker-unboxing-3/#section-2">Код внутри контейнера</a></li> <li><a href="https://web-standards.ru/articles/docker-unboxing-3/#section-3">Тестирование приложений в GUI</a></li> <li><a href="https://web-standards.ru/articles/docker-unboxing-3/#section-4">Безопасность Docker</a> <ul> <li><a href="https://web-standards.ru/articles/docker-unboxing-3/#section-5">Безопасность вашей ОС</a></li> <li><a href="https://web-standards.ru/articles/docker-unboxing-3/#section-6">Доступ при запуске приложения</a></li> <li><a href="https://web-standards.ru/articles/docker-unboxing-3/#section-7">Безопасные образы</a></li> <li><a href="https://web-standards.ru/articles/docker-unboxing-3/#section-8">Хранение секретной информации</a></li> </ul> </li> <li><a href="https://web-standards.ru/articles/docker-unboxing-3/#section-9">Заключение</a></li> <li><a href="https://web-standards.ru/articles/docker-unboxing-3/#section-10">Материалы по теме</a></li> </ul> <h2>Код внутри контейнера</h2> <p>До сих пор, мы не говорили о написании кода внутри контейнера. Вы можете использовать классическую связку vim с плагинами + tmux. Вы можете подключится к контейнеру по SSH почти из любой популярной среды разработки. Но не использовать или хотя бы не попробовать использовать возможности Visual Studio Code (VS Code) будет преступлением.</p> <p>Для того, чтобы работать с кодом красиво, можно и даже нужно использовать Visual Studio Code Remote, что позволяет подключиться к созданному контейнеру и работать с ним в терминальном режиме.</p> <p>Это делается довольно просто. Достаточно установить расширение <a href="https://marketplace.visualstudio.com/items?itemName=ms-vscode-remote.vscode-remote-extensionpack">Remote Development</a> и создать файл <code>.devcontainer.json</code> в папке из которой собирается ваш контейнер. Часто эта папка является папкой проекта. Можно собрать контейнер и на ходу с помощью мастера, но это трудно воспроизвести впоследствии. Например, содержимое <code>.devcontainer.json</code> может быть таким:</p> <pre><code tabindex="0" class="language-json">{ "name": "server", "dockerComposeFile": ["../docker-compose.yaml"], "service": "test", "workspaceFolder": "/app" } </code></pre> <p>Это заставит VS Code собрать все контейнеры, указанные в файле для Docker Compose и открыть папку /app, которая находится внутри контейнера server.</p> <p>В VS Code можно попытаться открыть папку проекта, и среда сама предложит открыть снова ее, но уже внутри контейнера. А можно сделать это вручную, нажав клавишу F1 или сочетание клавиш Ctrl + P (Cmd + P для macOS) и выбрав команду:</p> <pre><code tabindex="0" class="language-bash">> Remote-Containers: Open Workspace in Container. </code></pre> <p>Вы также можете указать те расширения, которые нужно поставить для данной рабочей сессии VS Code. После работы все эти расширения удаляться из редактора. Это очень удобно. Мне это позволяет держать в VS Code всего десять (!) расширений, которые будут востребованы в любом проекте, и никаких расширений для конкретного языка или фреймворка. Чистота и порядок!</p> <p>В списке литературы вы сможете познакомится с <a href="https://github.com/igsekor/docker-seeds">репозиторием</a> конфигурационных файлов для разных языков и фреймворков, на которых я в основном и работаю. Этот репозиторий обновляется по мере необходимости.</p> <h2>Тестирование приложений в GUI</h2> <p>В Docker можно запускать не только консольные приложения, но и приложения с графическим интерфейсом (GUI). Единственное ограничение — они будут работать на сервере системы X Windows для рендеринга графических приложений и взаимодействия с ними. Воспользоваться можно интересным свойством приложений с графическим интерфейсом Linux. Приложения запускаются как клиенты, которые обращаются к серверу X Windows. При этом не важно, где этот сервер расположен. Он вполне может быть на удаленном хосте. А нам это и надо!</p> <p>Если вы работаете на любом дистрибутиве ОС Linux, такой сервер у вас уже запущен. Чтобы поставить его на macOS, можете воспользоваться <a href="https://www.xquartz.org/">XQuartz</a>. На ОС Windows можно попробовать использовать <a href="https://sourceforge.net/projects/vcxsrv/">VcXsrv</a>. В первую очередь вы должны разрешить удаленное подключение к X Windows серверу и добавить переменные среды для контейнера. Универсального решения для всех ОС не существует, но я приведу флаги для команды <code>docker run</code>, учитывая ОС:</p> <pre><code tabindex="0" class="language-bash">-e DISPLAY=docker.for.mac.host.internal:0 # macOS -e DISPLAY=host.docker.internal:0 # Windows --net=host -e DISPLAY=:0 # Linux </code></pre> <p>Цифра в конце строки обозначает номер монитора, на который будет выведен графический интерфейс приложения (0 используется для обозначения главного монитора). Для macOS и Windows вы можете воспользоваться графическим интерфейсом вашего сервера. Удаленное подключение для LInux можно разрешить с помощью команды:</p> <pre><code tabindex="0" class="language-bash">xhosts + </code></pre> <p>Например, вы так можете запустить Gimp одной командой:</p> <ul> <li><strong>macOS:</strong> <code>docker run --rm -ti -e DISPLAY=docker.for.mac.host.internal:0 jamesnetherton/gimp</code></li> <li><strong>Windows:</strong> <code>docker run --rm -ti -e DISPLAY=host.docker.internal:0 jamesnetherton/gimp</code></li> <li><strong>Linux:</strong> <code>docker run --rm -ti --net=host -e DISPLAY=:0 jamesnetherton/gimp</code></li> </ul> <p>Для запуска Eclipse нужно в конце дописать <code>psharkey/eclipse</code> вместо <code>jamesnetherton/gimp</code>, а чтобы запустить Firefox — <code>jess/firefox</code>. В конце строки вы указываете имя нужного образа, который будет скачан с Docker Hub? Посмотрите, как был собран один из них, и вы будете точно знать, как запустить необходимое вам приложение с графическим интерфейсом.</p> <h2>Безопасность Docker</h2> <p>Предлагаю обсудить еще одну важную тему — безопасность. Рассмотрим четыре аспекта:</p> <ol> <li>Безопасность вашей ОС во время разработки;</li> <li>Управление доступом на этапе запуска приложения в контейнере;</li> <li>Безопасные образы;</li> <li>Хранение секретной информации.</li> </ol> <h3>Безопасность вашей ОС</h3> <p>Что мешает ОС быть в безопасности? Конечно то, что вы вынуждены устанавливать кучу разнообразного софта, в том числе и экспериментального. Это могут быть приложения с графическим интерфейсом или сугубо консольные приложения. Часто вам нужно устанавливать JVM или что-то подобное. Каждая новая программа несет в себе дырки, через которые можно что-нибудь, да сделать. Docker позволяет практически избавить вас от необходимости установки этого груза. Да и работать с коллегами будет намного проще.</p> <h3>Доступ при запуске приложения</h3> <p>Запуск контейнера происходит в отельном окружении, изолированном от ОС и других контейнеров. Но есть определенные трюки, которые позволят обеспечить вам еще большую изоляцию. В документации к Docker есть замечательное <a href="https://docs.docker.com/engine/security/userns-remap/">руководство</a>, которое точно стоит почитать. Перечислю самые важные советы, с моей точки зрения.</p> <p>Во-первых, необходимо запуск приложений внутри контейнера осуществлять от имени какого-то пользователя. По умолчанию, приложение запускается от имени root. Осуществить это довольно просто, достаточно добавить параметр -u:</p> <pre><code tabindex="0" class="language-bash">docker run -u user image </code></pre> <p>Вы также можете добавить эту настройку в Dockerfile:</p> <pre><code tabindex="0" class="language-docker">FROM alpine:latest RUN apk update && apk add --no-cache git USER 1000 </code></pre> <p>Во-вторых, необходимо поддерживать только те возможности, которые вам нужны. Полный функционал для вашего приложения внутри контейнера зачастую совершенно не обязателен. Управление возможностями осуществляется через командную строку с помощью параметров <code>--cap-drop</code> и <code>--cap-add</code>. Лучшей практикой будет запуск контейнера с одним параметром <code>--cap-drop all</code> и разрешающими флагами для необходимых возможностей, обеспечивающих работу вашего приложения. Вы можете ознакомиться подробнее со всеми поддерживаемыми флагами в <a href="https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities">документации</a>. С помощью Docker Compose вы также можете управлять поддержкой той или иной возможности контейнера с помощью параметров <code>cap_drop</code> и <code>cap_add</code>. В документации к Linux есть <a href="https://man7.org/linux/man-pages/man7/capabilities.7.html">исчерпывающий список</a>.</p> <p>В-третьих, необходимо управлять ресурсами вашей ОС, которые будут доступны для запуска контейнеров. Если вы не будете ограничивать эти ресурсы, Docker просто забьет всю оперативную память, что очень смахивает на DDOS атаку прямо у вас на компьютере. Необходимо также ограничивать и использование процессора. В Windows и macOS вы можете посмотреть потребление ресурсов системы с помощью Docker Desktop. Это можно сделать и через консоль командой, доступной уже на всех ОС:</p> <pre><code tabindex="0" class="language-bash">docker stats </code></pre> <p>Об оптимальных настройках вы можете подробнее почитать в официальной <a href="https://docs.docker.com/config/containers/resource_constraints/">документации</a>.</p> <h3>Безопасные образы</h3> <p>Во время работы вы часто будете использовать образы из разных реестров. Будьте бдительны! Использовать образы необходимо с большим количеством скачиваний, высоким рейтингом при большом количестве отзывов, рекомендованные компанией (официальные образы) или группой, которой вы доверяете. Загружая неизвестный образ, вы получаете кота в мешке. В любом случае внимательно смотрите на конфигурационные файлы и базовые образы. Желательно также использовать подписанные образы. Для того чтобы уберечь себя от загрузки «неправильных» образов, необходимо выполнить команду в терминале:</p> <pre><code tabindex="0" class="language-bash">export DOCKER_CONTENT_TRUST=1 </code></pre> <p>Прочитать подробнее про эту систему можно <a href="https://docs.docker.com/engine/security/trust/">в документации</a>.</p> <h3>Хранение секретной информации</h3> <p>Чтобы учетные данные аккаунтов, сертификаты, секретные ключи доступа, имена ресурсов и любая другая конфиденциальная информация оставались в тайне от других, необходимо следовать двум правилам:</p> <ol> <li>Не помещайте секреты внутрь образа;</li> <li>Не используйте для секретов переменные среды.</li> </ol> <p>В документации Docker есть <a href="https://docs.docker.com/engine/swarm/secrets/">специальный раздел</a>, посвящённый сохранности подобной чувствительной информации. Там предлагаются различные варианты. Но Джеф Хэйл (Jeff Hale) <a href="https://towardsdatascience.com/top-20-docker-security-tips-81c41dd06f57">советует</a> хранить секретные данные в томах (Docker volumes), создание и использование которых были описаны выше.</p> <h2>Заключение</h2> <p>Нам приходится устанавливать на свою любимую технику всякую дребедень, экспериментировать с новыми технологиями, прикручивать на этапе внедрения продукта то, что не должно быть в нем. Фраза «у меня все работает» по понятным причинам совершенно не устраивает заказчика. Эти неприятные моменты приводят к прокрастинации или даже эмоциональному выгоранию разработчика, который часто работает больше положенных восьми часов в день. Ночные посиделки на кануне сдачи этапа проекта скорее обыденность, чем исключение.</p> <p>Все вышесказанное является не чем иным, как попыткой помочь узнать основы без чтения документации. Как и всегда, попытка сделать что-либо подобное обречена на провал. Однако надеюсь, что время, проведенное за чтением, не будет бесполезным. Для меня процесс разработки совершенно точно разделился на «До» и «После». Надеюсь, опыт и умозаключения, изложенные выше, вам пригодятся, позволят попробовать различные технологии самостоятельно, поэкспериментировать, и, может быть, обеспечат преимущества при устройстве на следующую работу!</p> <p>Если вы поработаете с Docker, вас, скорее всего, от него уже не спасти. Есть надежда, что вы будете писать уже следующее приложение внутри контейнера. В заключение, вот вам ещё несколько ссылок:</p> <ul> <li><a href="https://habr.com/p/440660/">Команды Docker</a></li> <li><a href="https://medium.com/hackernoon/docker-commands-the-ultimate-cheat-sheet-994ac78e2888">Справочник по командам</a></li> <li><a href="https://github.com/igsekor/docker-seeds">Мой репозиторий наборов конфигурационных файлов для работы в VS Code</a></li> <li><a href="https://blog.maddevs.io/docker-for-beginners-a2c9c73e7d3d">Docker для начинающего разработчика</a></li> </ul> <h2>Материалы по теме</h2> <ol> <li><a href="https://www.piter.com/collection/A20865/product/sovremennye-operatsionnye-sistemy-4-e-izd">Современные операционные системы</a></li> <li><a href="https://medium.com/sysf/getting-started-with-docker-1-b4dc83e64389">Anatomy of Docker</a></li> <li><a href="https://www.upguard.com/blog/docker-vs-lxc">LXC vs Docker: Why Docker is Better</a></li> <li><a href="https://www.freecodecamp.org/news/a-beginner-friendly-introduction-to-containers-vms-and-docker-79a9e3e119b/">A Beginner-Friendly Introduction to Containers, VMs and Docker</a></li> <li><a href="https://habr.com/p/438796/">Изучаем Docker, часть 1: основы</a></li> <li><a href="https://habr.com/p/439978/">Изучаем Docker, часть 2: термины и концепции</a></li> <li><a href="https://ru.wikipedia.org/wiki/%D0%A1%D1%82%D0%B0%D0%BD%D0%B4%D0%B0%D1%80%D1%82%D0%BD%D1%8B%D0%B5_%D0%BF%D0%BE%D1%82%D0%BE%D0%BA%D0%B8">Википедия: Стандартные потоки</a></li> <li><a href="https://ru.wikipedia.org/wiki/TTY-%D0%B0%D0%B1%D1%81%D1%82%D1%80%D0%B0%D0%BA%D1%86%D0%B8%D1%8F">Википедия: TTY-абстракция</a></li> <li><a href="https://docs.docker.com/storage/">Manage data in Docker</a></li> <li><a href="https://habr.com/p/441574/">Изучаем Docker, часть 6: работа с данными</a></li> <li><a href="https://docs.docker.com/engine/reference/builder/">Dockerfile reference</a></li> <li><a href="https://habr.com/p/439980/">Изучаем Docker, часть 3: файлы Dockerfile</a></li> <li><a href="https://github.com/docker-library/postgres/blob/master/12/Dockerfile">Postgres: Dockerfile</a></li> <li><a href="https://www.postgresql.org/download/linux/redhat/">Linux downloads (Red Hat family)</a></li> <li><a href="https://docs.docker.com/engine/reference/run/">Docker run reference</a></li> <li><a href="https://www.cloudways.com/blog/best-php-cms/">Top 14 Best PHP CMS In Market For Developers in 2020</a></li> <li><a href="https://docs.docker.com/compose/install/">Install Docker Compose</a></li> <li><a href="https://docs.docker.com/compose/compose-file/">Compose file version 3 reference</a></li> <li><a href="https://ru.vuejs.org/v2/cookbook/dockerize-vuejs-app.html">Интегрируем Docker в приложение Vue.js</a></li> <li><a href="https://hub.docker.com/_/node">Официальный репозиторий Node.js от команды Docker</a></li> <li><a href="https://habr.com/p/440658/">Изучаем Docker, часть 4: уменьшение размеров образов и ускорение их сборки</a></li> <li><a href="https://docs.docker.com/develop/develop-images/multistage-build/">Use multi-stage builds</a></li> <li><a href="https://dev.to/sujaykundu777/utilizing-the-power-of-docker-while-building-mern-apps-using-mern-docker-4olb">Utilizing the power of Docker while building MERN Apps using mern-docker</a></li> <li><a href="https://www.digitalocean.com/community/tutorials/how-to-set-up-flask-with-mongodb-and-docker">How To Set Up Flask with MongoDB and Docker</a></li> <li><a href="https://habr.com/p/440660/">Изучаем Docker, часть 5: команды</a></li> <li><a href="https://medium.com/hackernoon/docker-commands-the-ultimate-cheat-sheet-994ac78e2888">Docker Commands — The Ultimate Cheat Sheet</a></li> <li><a href="https://github.com/igsekor/docker-seeds">Docker Seeds</a></li> <li><a href="https://blog.maddevs.io/docker-for-beginners-a2c9c73e7d3d">Docker для начинающего разработчика</a></li> </ol> <h2>Видео по теме</h2> <ol> <li><a href="https://youtu.be/wW9CAH9nSLs">The future of Linux Containers</a></li> <li><a href="https://youtu.be/QF4ZF857m44">Основы Docker. Большой практический выпуск</a></li> </ol> </article> <article> <h1>Распаковка Docker, часть 2</h1> <p>Tue, 09 Feb 2021 00:00:00 GMT</p> <p><a href="https://web-standards.ru/articles/docker-unboxing-1/">В первой части</a> мы обсудили технологии виртуализации, основную терминологию Docker и рассмотрели базовые примеры использования. В этой части мы рассмотрим примеры использования Docker на практике.</p> <h2>Навигация</h2> <ul> <li><a href="https://web-standards.ru/articles/docker-unboxing-2/#section-2">Использование Docker</a> <ul> <li><a href="https://web-standards.ru/articles/docker-unboxing-2/#section-3">Работа с базами данных</a></li> <li><a href="https://web-standards.ru/articles/docker-unboxing-2/#section-4">Движок сайта на PHP</a></li> <li><a href="https://web-standards.ru/articles/docker-unboxing-2/#section-5">Фронтенд-приложение</a></li> <li><a href="https://web-standards.ru/articles/docker-unboxing-2/#section-6">Фулстек-приложение</a></li> </ul> </li> </ul> <h2>Использование Docker</h2> <p>Начнем, пожалуй, с самого простого. Определим задачи, для которых Docker может понадобиться веб-программисту, разбив примеры типовых задачи на группы:</p> <ol> <li>Эксперименты и обучение: <ul> <li>Исследование системы команд конкретной ОС Linux (на примере CentOS 8);</li> <li>Работа с базами данных (на примере PostgreSQL);</li> <li>Движок сайта на PHP (на примере CMS Drupal).</li> </ul> </li> <li>Разработка приложений: <ul> <li>Фронтенд приложение (на примере настройки базового репозитория для разработки на Node.js);</li> <li>Фулстек-приложение (на примере MERN и связки Flask с MongoDB);</li> <li>Работа с кодом внутри контейнера;</li> <li>Тестирование приложений в графическом интерфейсе.</li> </ul> </li> </ol> <p>Необходимо помнить, что основной целью Docker является запуск приложения в воспроизводимом окружении. Запуск в контейнере означает гарантированную работу приложения на любой платформе. Но использовать Docker можно и другим способом. Для разработчика существует несколько таких способов. Они рассматриваются в первой и второй группе задач.</p> <h3>Работа с базами данных</h3> <p>Можно поступить по-старому: скачать образ нужной ОС и установить на ней интересующую вас СУБД. Но это противоречит философии Docker. Понятно, что подобрать готовый образ вы сможете и сами на Docker Hub. Однако, давайте создадим свой собственный образ, чтобы потренироваться.</p> <p>Нам необходимо приготовить свой «слоеный пирог», как иногда метафорически называют образ в официальной документации. Мы уже знаем, что существует конфигурационный файл Dockerfile, в котором описываются все нужные нам слои с помощью специальных команд (инструкций). <a href="https://docs.docker.com/engine/reference/builder/">В официальной документации</a> подробно описаны все инструкции. Можно также обратиться <a href="https://habr.com/p/439980/">к руководству по Dockerfile</a>. Инструкция в Dockerfile формируется по следующему принципу:</p> <pre><code tabindex="0" class="language-docker"># Comment INSTRUCTION arguments </code></pre> <p>Строка начинается с имени инструкции, а дальше указываются значения ее аргументов. <a href="https://github.com/docker-library/postgres/blob/master/12/Dockerfile">Посмотрите на Dockerfile</a> из официального образа с установленной СУБД PostgreSQL от команды Docker. Вы увидите достаточно большой файл конфигурации (больше двух сотен строк!). Можно ли проще? Можно, если вы не претендуете на универсальность вашего решения. Давайте постепенно будем формировать файл конфигурации. В первую очередь нам необходимо определить базовый образ. Нам, например, понадобился образ CentOS 8, последней стабильной версии. В Dockerfile достаточно написать для этого всего лишь строчку:</p> <pre><code tabindex="0" class="language-docker">FROM centos:latest </code></pre> <p>Давайте попробуем сформировать и запустить его? Используем команду <a href="https://docs.docker.com/engine/reference/commandline/build/">docker build</a>. Если запустить ее в каталоге с Dockerfile с точкой после слова build, Docker CLI должен собрать новый образ. Переходим в отдельный каталог, создаем файл Dockerfile, записываем в него строчку и запускаем сборку. Достаточно выполнить следующие две команды в терминале:</p> <pre><code tabindex="0" class="language-bash">touch ./Dockerfile && echo "FROM centos:latest" > ./Dockerfile && cat ./Dockerfile docker build . </code></pre> <p>Если посмотрим список доступных образов, то увидим новую строчку списка:</p> <pre><code tabindex="0" class="language-bash">docker image ls > REPOSITORY TAG IMAGE ID CREATED SIZE > <none> <none> 183420543a45 3 months ago 215MB > centos latest 0d120b6ccaa8 3 months ago 215MB > hello-world latest bf756fb1ae65 11 months ago 13.3kB </code></pre> <p>Давайте двигаться дальше. Сначала запустим контейнер в режиме доступа к консоли, указав в качестве имени контейнера Image ID:</p> <pre><code tabindex="0" class="language-bash">docker run -it --entrypoint bash 183420543a45 </code></pre> <p>Имя контейнера можно было указать при его создании, и мы это обязательно сделаем, но чуть позже.</p> <p>Разумеется, для сборки все команды нужно попробовать сначала в терминале ОС, а только потом в Docker. Надо помнить также, что настройки ОС и установленные приложения не сохранятся и будут утеряны после завершения работы контейнера. Нам необходимо установить PostgreSQL в ОС, что мы и сделаем <a href="https://www.postgresql.org/download/linux/redhat/">в соответствии с официальной документацией</a>. Используем команды для CentOS 8, поскольку в последней версии образа устанавливается именно эта версия ОС:</p> <pre><code tabindex="0" class="language-bash">rpm -Uvh https://download.postgresql.org/pub/repos/yum/reporpms/EL-8-x86_64/pgdg-redhat-repo-latest.noarch.rpm dnf install -y postgresql12-server --disablerepo=AppStream </code></pre> <p>Кажется, все успешно. Эти команды можно превратить в инструкции для Dockerfile следующим образом:</p> <pre><code tabindex="0" class="language-docker">RUN rpm -Uvh https://download.postgresql.org/pub/repos/yum/reporpms/EL-8-x86_64/pgdg-redhat-repo-latest.noarch.rpm; dnf install -y postgresql12-server --disablerepo=AppStream </code></pre> <p>При сборке контейнера рекомендуется использовать наименьшее количество слоев. Это нужно как для сборки контейнера, так и для быстродействия работы его файловой системы. Поэтому мы выполняем команды друг за другом на одном слое (в одной инструкции), перечисляя их через точку с запятой.</p> <p>Теперь надо запустить установленную СУБД при старте уже собранного контейнера. Попробуем сделать через консоль контейнера. Для этого можно снова <a href="https://www.postgresql.org/download/linux/redhat/">воспользоваться инструкцией</a>:</p> <pre><code tabindex="0" class="language-bash">systemctl start postgresql-12.service > System has not been booted with systemd as init system (PID 1). Can’t operate. > Failed to connect to bus: Host is down </code></pre> <p>Ошибка! Но почему? Мы имеем дело не с полноценной ОС, а с контейнером, который существует только как абстракция. В нашем случае проблема связана с двумя вещами: доступом к системным службам и журналу поведения этих служб базовой ОС.</p> <p>Поскольку Docker является надстройкой над ядром ОС, доступ контейнера к службе systemd означает доступ к ней в базовой ОС, что не является безопасным действием и по умолчанию запрещено.</p> <p>Можно запустить контейнер в специальном привилегированном режиме, но на свой страх и риск. Мы будем использовать указанный флаг, <a href="https://docs.docker.com/engine/reference/run/">учитывая документацию Docker</a>, поскольку мы это делаем исключительно в исследовательских целях, используя официальный образ ОС.</p> <p>Давайте отвлечемся на минуту, и еще добавим красивые имена для образа и контейнера. Чтобы каждый раз не смотреть значение Image ID (оно будет меняться при каждой сборке) установим имя образа и тег:</p> <pre><code tabindex="0" class="language-bash">docker image rm -f 183420543a45 docker build -t psql:centos . </code></pre> <p>Первая команда используется для того, чтобы удалить собранный на предыдущем шаге образ. Ключ <code>-f</code> мы используем, поскольку Docker без него не будет удалять образы, которые были запущены раньше. Попробуем запустить:</p> <pre><code tabindex="0" class="language-bash">docker run -it psql:centos bash </code></pre> <p>Все работает. Вы можете посмотреть на список всех запущенных контейнеров в другом окне терминала, если выполните следующую команду:</p> <pre><code tabindex="0" class="language-bash">docker ps > CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES > f53b4f7223c2 psql:centos "bash" 9 seconds ago Up 8 seconds cool_curie </code></pre> <p>Значение <code>CONTAINER ID</code> не очень говорящее. Каждый раз смотреть его не удобно. Давайте добавим ключ с указанием имени контейнера, чтобы можно было легче им управлять. Для этого остановим наш контейнер и запустим его снова с именем:</p> <pre><code tabindex="0" class="language-bash">docker stop f53b4f7223c2 docker run -it --name psql-centos-1 psql:centos bash </code></pre> <p>Теперь намного лучше:</p> <pre><code tabindex="0" class="language-bash">docker ps > CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES > 39954a216f6b psql:centos "bash" 8 seconds ago Up 8 seconds psql-centos-1 </code></pre> <p>Если вы уже запускали контейнер с определенным именем, то в будущем Docker CLI под тем же именем вам не даст его запустить, даже если он уже был остановлен. Предварительно имя нужно удалить из списка с помощью команды:</p> <pre><code tabindex="0" class="language-bash">docker rm psql-centos-1 > psql-centos-1 </code></pre> <p>Посмотреть весь список, в котором будут отображены запущенные и остановленные контейнеры, можно с помощью команды:</p> <pre><code tabindex="0" class="language-bash">docker ps -a </code></pre> <p>Теперь вернемся к нашей задаче. Для запуска менеджера служб systemd необходимо запустить сначала специальную службу:</p> <pre><code tabindex="0" class="language-bash">docker run -it --privileged --name psql-centos-1 psql:centos /sbin/init </code></pre> <p>В другом окне терминала вы можете обратится к уже запущенному контейнеру и попасть в него с помощью команды:</p> <pre><code tabindex="0" class="language-bash">docker exec -it psql-centos-1 /bin/bash </code></pre> <p>Теперь можно управлять запуском служб. Выполнения команды <code>exit</code> для остановки контейнера вам теперь будет не достаточно. Чтобы остановить контейнер, вам нужно выполнить команду:</p> <pre><code tabindex="0" class="language-bash">docker stop psql-centos-1 </code></pre> <p>Попробуем запустить нашу службу сейчас:</p> <pre><code tabindex="0" class="language-bash">systemctl enable postgresql-12.service # Успешно systemctl start postgresql-12.service > Job for postgresql-12.service failed because the control process exited with error code. > See "systemctl status postgresql-12.service" and "journalctl -xe" for details. </code></pre> <p>Снова неудача. В этот раз нет принципиальных ошибок, чтобы запустить нашу СУБД, осталось только настроить язык (local). Для этого нужно подправить Dockerfile следующим образом:</p> <pre><code tabindex="0" class="language-docker">FROM centos:latest RUN rpm -Uvh https://download.postgresql.org/pub/repos/yum/reporpms/EL-8-x86_64/pgdg-redhat-repo-latest.noarch.rpm && dnf install -y postgresql12-server --disablerepo=AppStream; dnf install -y glibc-locale-source glibc-langpack-en; dnf clean all RUN localedef -i en_US -f UTF-8 en_US.UTF-8 </code></pre> <p>Теперь нам нужно инициализировать СУБД и запустить ее как службу. Хотя с помощью Dockerfile сделать это можно, мы для простоты будем делать это вручную в терминале. Если выполнить команду внутри контейнера, то все получится:</p> <pre><code tabindex="0" class="language-bash">/usr/pgsql-12/bin/postgresql-12-setup initdb && systemctl start postgresql-12 && su postgres </code></pre> <p>Вы сможете теперь работать с СУБД, если наберете команду:</p> <pre><code tabindex="0" class="language-bash">psql </code></pre> <p>Если добавить команду запуска сервера СУБД в качестве инструкции типа RUN в Dockerfile, то вы получите ошибку при сборке образа на этапе инициализации СУБД. Есть пути решения этой проблемы, но говорить о них в рамках данной статьи будет несколько преждевременно.</p> <p>Не забывайте, что в рабочих задачах установка привилегированного доступа к службе <code>systemd</code> базовой ОС очень опасна! Если ваша задача является широко распространенной, то вы должны озаботиться поиском готового решения.</p> <h3>Движок сайта на PHP</h3> <p>Мы уже научились создавать базовые конфигурации для контейнеров и использовать контейнеры в двух режимах. Давайте теперь поработаем со стандартной задачей для веб-программиста или контент-менеджера — создание сайта на популярном PHP-движке. <a href="https://www.cloudways.com/blog/best-php-cms/">Тройка наиболее популярных движков в мире на лето 2020 года</a>: Wordpress, Magento, Drupal. Наиболее универсальным, мощным и относительно безопасным движком с хорошим тулингом (системой инструментов для разработчиков) является Drupal, он близок моему сердцу. Остановимся на нем, хотя чаще всего задача стоит в том, чтобы поставить и использовать Wordpress (Вы легко это сможете сделать в качестве упражнения по аналогии).</p> <p>Попробуем найти подходящий образ на Docker Hub. Вы, скорее всего, наткнетесь <a href="https://hub.docker.com/_/drupal">на официальный репозиторий</a>. Отмечу только, что достаточно хорошими образами для Wordpress и Magento, на мой взгляд, являются соответственно <a href="https://hub.docker.com/_/wordpress">wordpress</a> и <a href="https://hub.docker.com/r/magento/magento-cloud-docker-php">magento-cloud-docker-php</a>.</p> <p>В образе, который вы сможете загрузить к себе и запустить будет установлена определенная версия Drupal (ее можно выбрать с помощью тегов), но не будет установлена СУБД, без которой ничего не заработает. С точки зрения философии Docker запускать контейнер с СУБД нужно отдельно, а потом сопрягать его с контейнером, в котором установлен Drupal.</p> <p>Давайте, в рамках поставленной задачи, познакомимся с Docker Compose. Если вы устанавливали Docker Desktop, то Docker Compose у вас уже установлен, беспокоиться не о чем. Если вы счастливый обладатель ОС Linux, то Docker Compose необходимо будет установить. Для этого вам необходимо перейти на вкладку Linux <a href="https://docs.docker.com/compose/install/">на странице документации</a>.</p> <p>Что такое Docker Compose? Это инструмент, который позволяет управлять списком связанных контейнеров путем установки параметров запуска. Все управление осуществляется в специальном файле конфигурации в формате YAML, который в последнее время очень часто используется. Файл имеет не только заданный формат, но и имя — «docker-compose.yml».</p> <p>Нам необходимо определенным образом сконфигурировать и запустить два образа Docker совместно: в одном будет находиться CMS Drupal, а в другом — СУБД MySQL. Если перейти на страницу образа drupal, то вы сможете в описании увидеть, какой именно репозиторий рекомендуется использовать для работы Drupal с СУБД MySQL:</p> <pre><code tabindex="0" class="language-bash">docker run -d --name some-mysql --network some-network \ -e MYSQL_DATABASE=drupal \ -e MYSQL_USER=user \ -e MYSQL_PASSWORD=password \ -e MYSQL_ROOT_PASSWORD=password \ mysql:5.7 </code></pre> <p>У нас нет оснований использовать что-то другое, поэтому доверимся разработчикам репозитория. Для облегчения работы с несколькими контейнерами и был придумал Docker Compose.</p> <p>Не буду уделять много внимания описанию инструмента и системы его команд. Давайте посмотрим на готовый конфигурационный файл и попробуем разобраться с тем, как он устроен. Ниже на странице образа drupal есть готовый YAML файл.</p> <p>Файл конфигурации устроен следующим образом. Сначала описывается требуемая для сборки контейнеров версия Docker Compose. Затем перечисляются те сервисы, которые вы планируете запускать. Под сервисами подразумеваются приложения, для каждого из которых создаётся отдельный контейнер. Для сервисов вы можете указать настройки, с которыми контейнер должен запускаться. Все тонкости можно найти <a href="https://docs.docker.com/compose/compose-file/">в документации</a>. Приведу конфигурационный файл для Drupal последней версии, работающего на базе Apache и MySQL. Благодаря формату, конфигурация довольно проста для понимания:</p> <pre><code tabindex="0" class="language-yaml">version: '3.8' services: drupal: image: drupal:latest ports: - 8080:80 volumes: - /var/www/html/modules - /var/www/html/profiles - /var/www/html/themes - /var/www/html/sites restart: always mysql: image: mysql:5.7 environment: MYSQL_DATABASE: drupal MYSQL_USER: user MYSQL_PASSWORD: passwod MYSQL_ROOT_PASSWORD: password restart: always </code></pre> <p>Если файл docker-compose.yml уже создан и вы находитесь в этой же папке, для запуска контейнеров достаточно выполнить команду:</p> <pre><code tabindex="0" class="language-bash">docker-compose up -d </code></pre> <p>Ключ -d нужен для установки режима работы контейнеров в фоновом режиме. Если вы теперь перейдете на ссылке <code>http://localhost:8080</code> в браузере базовой ОС, вы сможете работать с сайтом. При настройке Drupal не забудьте, что СУБД работает на хосте mysql (имя сервиса в docker-compose.yaml). После остановки контейнеров все данные сайта потеряются, если предварительно не создать тома для хранения данных. Приведу также две важные команды для работы с Docker Compose:</p> <ul> <li>Просмотр списка запущенных контейнеров: <code>docker-compose ps</code></li> <li>Остановка всех контейнеров, которые были подняты: <code>docker-compose down</code></li> </ul> <p>Вы только что запустили рабочий сайт на последней версии Drupal. Перейдем теперь к следующей группе задач.</p> <h3>Фронтенд-приложение</h3> <p>Как мы можем использовать Docker для работы с фреймворками Angular, React, Vue и подобными? Чтобы ответить на этот вопрос, нужно разделить этапы разработки и внедрения. На первом этапе с помощью Docker вы сможете обеспечить комфорт для себя (DX, developer experience), на втором — для администраторов или специалистов в области CI/CD.</p> <p>Выполнить одну команду поднятия сервера гораздо проще, чем обеспечить поддержку необходимых библиотек и следить за их версиями, которые используются в коде. Сборка и развертывание проекта станет простым делом и для всех участников этого непростого процесса.</p> <p>Давайте потренируемся в создании репозитория образов для фронтенда, заодно научимся работать с Docker Hub не только как потребители. Для желающих есть также <a href="https://ru.vuejs.org/v2/cookbook/dockerize-vuejs-app.html">хорошее руководство</a>.</p> <p>Для этого вам необходимо <a href="https://hub.docker.com/signup">зарегистрироваться</a> на платформе Docker Hub. После регистрации вы сможете <a href="https://hub.docker.com/repository/create">создать свой репозиторий</a>.</p> <p>Репозиторий может быть либо публичным, либо частным (в базовом бесплатном пакете услуг допускается только один частный репозиторий). Кстати, вы также можете найти и другие реестры от крупных компаний:</p> <ul> <li><a href="https://cloud.google.com/container-registry/">Google Container Registry</a></li> <li><a href="https://aws.amazon.com/ru/ecr/">Amazon Elastic Container Registry</a></li> <li><a href="https://cloud.yandex.ru/services/container-registry">Yandex Container Registry</a></li> <li><a href="https://www.digitalocean.com/products/container-registry/">DigitalOcean Container Registry</a></li> <li><a href="https://www.ibm.com/cloud/container-registry">IBM Cloud Container Registry</a></li> </ul> <p>Я подготовил <a href="https://hub.docker.com/repository/docker/igsekor/node">простой репозиторий в реестре</a> для разработки на Node.js. Я также связал этот репозиторий <a href="https://github.com/igsekor/docker-node">с репозиторием на GitHub</a>, чтобы процесс сборки новых образов происходил в автоматическом режиме после отправки очередного коммита.</p> <p>Платформа Docker Hub позволяет использовать триггеры двух типов, которые служат основанием для начала сборки новой версии образа: коммиты с заданными тегами и коммиты в заранее определенных ветках. Я выбрал для простоты понимания второй вариант — на основе веток. Отправка коммита в определенной ветке означает автоматическую сборку образа в репозитории. Настраиваются связи между GitHub и Docker Hub на вкладке Builds репозитория на Docker Hub.</p> <p>Чтобы загрузка и установка образов не занимали много времени, а сами образы не занимали много места на диске, в качестве базовой ОС на этот раз мы будем использовать Linux Alpine — довольно популярное решение. Опишу процесс создания четырех образов. В дальнейшем я буду развивать репозиторий, поэтому вы можете увидеть уже больше образов в нем.</p> <p>Первый образ будет базовым, в нем будет только Node.js и пакетный менеджер npm. Второй образ будет являться базовым проектом с системой сборки Webpack, третий будет содержать vue-cli для разработки сайтов на VueJS, а четвертый позволит собирать любые проекты на Node.js и запускать их в изолированном окружении на веб-сервере nginx. В этот раз я не буду проводить вас по всей процедуре. Думаю, что достаточно будет только привести соответствующий образу Dockerfile.</p> <p>Первый образ будет содержать только <a href="https://hub.docker.com/_/node">базовый образ Node.js</a>. В дальнейшем вы сможете его приспособить под свои задачи, например, добавить утилиты для тестирования веб-приложений, системы мониторинга и тому подобные инструменты. Итак, вот самый базовый Dockerfile:</p> <pre><code tabindex="0" class="language-docker">FROM node:lts-alpine </code></pre> <p>Одной инструкции вполне достаточно для поставленной задачи. Теперь попробуем решить более сложную задачу — установить базовый проект Node.js. Создаем новую ветку в репозитории, создаем новый проект Node.js и собираем его:</p> <pre><code tabindex="0" class="language-bash">git branch webpack git checkout webpack npm init npm install vi Dockerfile </code></pre> <p>После того, как мы добавили webpack, Dockerfile будет содержать дополнительные инструкции:</p> <pre><code tabindex="0" class="language-docker">FROM node:lts-alpine WORKDIR /app COPY package*.json ./ RUN npm install; npm install webpack webpack-cli --save-dev </code></pre> <p>Пробуем собрать образ. Если все успешно, то добавляем нужные файлы, делаем коммит и отправляем на GitHub (новый образ соберется в репозитории на Docker Hub автоматически, если вы все предварительно настроили):</p> <pre><code tabindex="0" class="language-bash">docker build . git add . git commit -m 'Add basic image for webpack project' git push origin webpack </code></pre> <p>Перейдем к следующей задаче:</p> <pre><code tabindex="0" class="language-bash">git branch vue git checkout vue </code></pre> <p>Чтобы создать проект на Vue, можно было бы просто добавить его в package.json. Но мы пойдем другим путем, уберем webpack и заменим его утилитой vue-cli, удалив предварительно все лишние файлы:</p> <pre><code tabindex="0" class="language-bash">rm *.json vue create . rm -r node_modules git add . git commit -m 'Install Vue 3' git push origin vue </code></pre> <p>Необходимо также поправить Dockerfile:</p> <pre><code tabindex="0" class="language-docker">FROM node:lts-alpine WORKDIR /app COPY package*.json ./ COPY babel.config.js ./ COPY README.md ./ COPY src/ ./src COPY public/ ./public </code></pre> <p>Мы сделали не оптимальный Dockerfile, но зато очень понятный. Для повышения оптимальности можно скопировать все содержимое папки в папку проекта внутри контейнера одной строчкой <code>COPY . .</code>, но тогда вам нужно будет создать файл.dockerignore с единственной строкой <code>node_modules</code> (по аналогии с. gitignore). Если у вас уже настроено правило на Docker Hub, то после коммита и отправки на GitHub все опять автоматически соберется.</p> <p>Перейдем к последнему образу, который будет отвечать за сборку готового сайта на Vue и запуск на веб-сервере nginx. Предлагаю использовать веб-сервер nginx для статических файлов готовой сборки. Снова создаем соответствующую ветку в репозитории и, перейдя к ней, редактируем Dockerfile:</p> <pre><code tabindex="0" class="language-bash">git branch vue-prod git checkout vue-prod vi Dockerfile </code></pre> <p>Я возьму <a href="https://ru.vuejs.org/v2/cookbook/dockerize-vuejs-app.html">готовый Dockerfile из руководства Vue</a>, в нем все более или менее удачно с точки зрения универсального решения:</p> <pre><code tabindex="0" class="language-docker"># build stage FROM node:lts-alpine as build-stage WORKDIR /app COPY package*.json ./ RUN npm install COPY . . RUN npm run build # production-stage FROM nginx:stable-alpine as production-stage COPY --from=build-stage /app/dist /usr/share/nginx/html EXPOSE 80 CMD ["nginx", "-g", "daemon off;"] </code></pre> <p>Здесь происходит пока что-то непонятное, поскольку используется механизм многоступенчатых сборок Docker, которые доступны с версии 17.05. Если вы хотите разобраться с этим механизмом подробнее, то можно воспользоваться <a href="https://habr.com/p/440658/">статьей</a> или <a href="https://docs.docker.com/develop/develop-images/multistage-build/">официальной документацией</a>.</p> <p>Многоступенчатая сборка используется тогда, когда мы хотим часть файлов из одной сборки скопировать в другую сборку, что сильно уменьшает размер конечного образа. На нашем примере мы собираем сайт с помощью Node.js, а потом копируем его целиком в другую сборку, где работает nginx. Мы получаем готовое веб-приложение, которое можно смело использовать в рамках реальной разработки.</p> <p>Пробуем собрать образ, и, если все успешно, заливаем его на GitHub:</p> <pre><code tabindex="0" class="language-bash">git add . git commit -m 'Add production building for VueJS app' git push origin vue-prod </code></pre> <h3>Фулстек-приложение</h3> <p>Приведу пару полезных примеров для фулстек-приложений, в которых используется несколько контейнеров, работающих совместно. Сначала посмотрим работу с MERN-приложением (MongoDB, Express, React, Node), которое у вас, предположим, уже написано — <a href="https://dev.to/sujaykundu777/utilizing-the-power-of-docker-while-building-mern-apps-using-mern-docker-4olb">подробнее об этом</a>.</p> <p>Схема работы приложения описана и проиллюстрирована в том же репозитории. Предлагаю пройтись по стандартным конфигурационным файлам.env, Dockerfile, docker-compose.yml, которые нужно будет добавить в проект:</p> <p>.env:</p> <pre><code tabindex="0" class="language-bash">MONGO_HOSTNAME=mongo MONGO_DB=myapp_db MONGO_PORT=27017 </code></pre> <p>Dockerfile:</p> <pre><code tabindex="0" class="language-docker"># Dockerfile for Node Express Backend api (development) FROM node:lts-alpine # ARG NODE_ENV=development # Create App Directory RUN mkdir -p /usr/src/app WORKDIR /usr/src/app # Install Dependencies COPY package*.json ./ RUN npm ci # Copy app source code COPY . . # Exports EXPOSE 8080 CMD ["npm", "start"] </code></pre> <p>docker-compose.yml:</p> <pre><code tabindex="0" class="language-yaml">version: '3.7' services: webapp-server: build: context: . dockerfile: Dockerfile image: myapp-server-img container_name: myapp-node-express volumes: - .:/usr/src/app - /usr/src/app/node_modules ports: - "8080:8080" depends_on: - mongo env_file: .env environment: - MONGO_HOSTNAME=$MONGO_HOSTNAME - MONGO_PORT=$MONGO_PORT - MONGO_DB=$MONGO_DB mongo: image: mongo container_name: myapp-mongodb ports: - "27017:27017" </code></pre> <p>В docker-compose.yml используется несколько другой подход с подключением отдельного файла для описания контейнера и загрузки переменных среды из файла.env. Такое решение, как вы наверняка знаете, довольно распространено. В репозиторий не попадают пароли, ключи и прочие секретные данные.</p> <p>В Dockerfile описан процесс копирования файлов проекта внутрь контейнера и запуск приложения в режиме разработки на порте 8080. Режим выбран не случайно, поскольку эта сборка предназначена для разработки. При этом на ваш компьютер не нужно будет устанавливать ничего кроме Docker. Это очень полезно как для вас, так и для вашей ОС.</p> <p>Другим распространенным примером является использование Flask в качестве бэкенда, отдельного веб-сервера для производительности и MongoDB в качестве СУБД. Такой пример <a href="https://www.digitalocean.com/community/tutorials/how-to-set-up-flask-with-mongodb-and-docker">приведен в руководстве</a>. Вот файл docker-compose.yml из него:</p> <pre><code tabindex="0" class="language-yaml">version: '3' services: flask: build: context: app dockerfile: Dockerfile container_name: flask image: digitalocean.com/flask-python:3.6 restart: unless-stopped environment: APP_ENV: "prod" APP_DEBUG: "False" APP_PORT: 5000 MONGODB_DATABASE: flaskdb MONGODB_USERNAME: flaskuser MONGODB_PASSWORD: your_mongodb_password MONGODB_HOSTNAME: mongodb volumes: - appdata:/var/www depends_on: - mongodb networks: - frontend - backend mongodb: image: mongo:4.0.8 container_name: mongodb restart: unless-stopped command: mongod --auth environment: MONGO_INITDB_ROOT_USERNAME: mongodbuser MONGO_INITDB_ROOT_PASSWORD: your_mongodb_root_password MONGO_INITDB_DATABASE: flaskdb MONGODB_DATA_DIR: /data/db MONDODB_LOG_DIR: /dev/null volumes: - mongodbdata:/data/db networks: - backend webserver: build: context: nginx dockerfile: Dockerfile image: digitalocean.com/webserver:latest container_name: webserver restart: unless-stopped environment: APP_ENV: "prod" APP_NAME: "webserver" APP_DEBUG: "true" SERVICE_NAME: "webserver" ports: - "80:80" - "443:443" volumes: - nginxdata:/var/log/nginx depends_on: - flask networks: - frontend networks: frontend: driver: bridge backend: driver: bridge volumes: mongodbdata: driver: local appdata: driver: local nginxdata: driver: local </code></pre> <p>Автор предлагает создать три контейнера: для веб-сервера, для СУБД и для Flask. Обратите внимание на создание внутренней сети. Думаю, вы вполне разберетесь с конфигурацией.</p> <hr> <p>Мы можем использовать Docker и для организации собственных рабочих процессов, <a href="https://web-standards.ru/articles/docker-unboxing-3/">поговорим об этом в третьей части</a>.</p> </article> <article> <h1>Распаковка Docker, часть 1</h1> <p>Mon, 08 Feb 2021 00:00:00 GMT</p> <p>Труд наш в основном творческий, интеллектуальный, и мы посвящаем довольно много времени размышлениям о том, что и как делаем. В условиях быстро развивающейся платформы веб-разработчикам приходится принимать сложные, часто компромиссные, решения. Хороший программист всегда стремится к совершенству, и такое положение вещей раздражает. Однако мы можем существенно облегчить свою участь с помощью Docker, который в худшем случае сократит время работы перед релизом, а в лучшем — добавит оснований нам быть счастливыми.</p> <p>Есть и другая сторона. Какое впечатление создает ваш продукт у заказчика и его клиентов? В Docker вы создаете упаковку, создаете, если хотите, свой «дизайнерский язык», уникальный первичный пользовательский опыт. Отношение к вам часто формируется через него. Представьте продукт в физическом, а не в виртуальном мире. Пользователь снимает пленку, открывает крышку коробки, внимательно изучает макулатуру, достает провода и зарядку, вдыхает неповторимый аромат новой техники… Скачивая программу, пользователь ожидает нечто подобное. Восхищается ли он простотой, удобством и лаконичностью?</p> <p>Материал, в начале которого вы находитесь, накладывает определенные требования и к упаковке самого себя. Из соображений удобства весь текст разделен на три части:</p> <ol> <li><strong>Первая часть</strong> описывает терминологию и основные инструменты Docker — <em>вы находитесь здесь.</em></li> <li><a href="https://web-standards.ru/articles/docker-unboxing-2/">Вторая часть</a> посвящена практическим примерам, которые могут быть полезны веб-разработчикам.</li> <li><a href="https://web-standards.ru/articles/docker-unboxing-3/">Третья часть</a> содержит интересности для организации процесса разработки.</li> </ol> <h2>Навигация</h2> <ul> <li><a href="https://web-standards.ru/articles/docker-unboxing-1/#section-2">Технология виртуализации</a></li> <li><a href="https://web-standards.ru/articles/docker-unboxing-1/#section-3">Основные понятия Docker</a> <ul> <li><a href="https://web-standards.ru/articles/docker-unboxing-1/#section-4">Docker container (контейнер)</a></li> <li><a href="https://web-standards.ru/articles/docker-unboxing-1/#section-5">Docker image (образ)</a></li> <li><a href="https://web-standards.ru/articles/docker-unboxing-1/#section-6">Union File Systems</a></li> </ul> </li> <li><a href="https://web-standards.ru/articles/docker-unboxing-1/#section-7">Cистема команд Linux</a></li> </ul> <h2>Технология виртуализации</h2> <p>В 7 главе <a href="https://www.piter.com/collection/A20865/product/sovremennye-operatsionnye-sistemy-4-e-izd">знаменитой книги Эндрю Таненбаума</a>, ставшей хрестоматией для современного поколения инженеров в области Computer Science, понятие виртуализации рассматривается достаточно подробно. Вся концепция сводится к существованию менеджера виртуальных машин (Virtual Machine Manager), или, по-другому, гипервизора (hypervisor), который позволяет запускать ОС так, как будто она существует сама по себе и запущена на отдельном компьютере. Гипервизоры бывают двух типов: функционирующие на уровне «железа» и программные, работающие уже как слой в базовой ОС (host OS).</p> <p>Применение виртуализации связано как с развитием самой вычислительной техники и программ, так и с построением сложных инфраструктурных решений для обеспечения работы компаний разного уровня. Выделенный сервер у хостинг-провайдера, к примеру, будет запускаться на «железном» гипервизоре, а у вас, скорее всего — на программном типа VMWare или VirtualBox.</p> <p>Эти технологии не новые и существуют уже более 50 лет. Однако после небольшого периода забвения они получили в последнее десятилетие новую жизнь. Почему мы говорим про виртуализацию в случае Docker?</p> <p>На ОС, которые не относятся к семейству Linux, служба Docker запускается как отдельная, хоть и очень быстрая, виртуальная машина. Потери ресурсов ОС, хоть и небольших, не избежать. Об этом лучше знать заранее. Подробнее об архитектуре Docker можно почитать в <a href="https://medium.com/sysf/getting-started-with-docker-1-b4dc83e64389">Anatomy of Docker</a>, мы же рассмотрим лишь основные моменты.</p> <h2>Основные понятия Docker</h2> <p>В основе Docker лежит понятие контейнера, которое появилось в Linux довольно давно. <a href="https://linuxcontainers.org/">Linux containers</a> (LXC) в основном использовались и продолжают использоваться для разделения прав пользователей и создания изолированных окружений для разработки, сборки и запуска программ. Простого разграничения прав пользователей не хватало, поскольку требовались наборы разного софта с иногда противоположными значениями в настройках для того или иного случая. Все это существенно приводило к нестабильности базовой ОС, дырам в безопасности и багам в программах.</p> <p>Технология LXC позволяла использовать единое ядро ОС и поверх запускать изолированные экземпляры набора служб со своими настройками, пользователями, подключенными (доступными) внешними устройствами (в понимании архитектуры фон Неймана), с собственным пространством процессов и собственным сетевым стеком. Понятное дело, что все это вынесли в отдельную абстракцию, которая стала называться контейнером.</p> <p>LXC сейчас применяются, например, у хостинг-провайдеров, позволяя клиентам арендовать часть ресурсов какого-то сервера для размещения своего сайта (услуга виртуального хостинга). При этом на одной физической или виртуальной машине могут работать одновременно очень много контейнеров.</p> <p>Какие шаги нужно выполнить для того, чтобы создать и запустить контейнер (независимое окружение, «песочницу») с точки зрения администратора? Вот примерный список действий:</p> <ol> <li>Сгенерировать LXC;</li> <li>Выделить специальную файловую систему;</li> <li>Примонтировать новый слой ОС;</li> <li>Создать виртуальный интерфейс для работы с сетью;</li> <li>Настроить таблицы маршрутизации;</li> <li>Настроить туннелирование сетевых пакетов через протокол NAT;</li> <li>Запустить нужный процесс и перенаправить вывод на вывод родительской ОС.</li> </ol> <p>Реализация каждого из семи шагов занимает довольно много времени. Вы же понимаете, что с первого раза редко удаётся что-то хорошо настроить для большого количества пользователей? Словом, настройка и поддержание такой системы в рабочем состоянии — не простая задача.</p> <p>В день рождения Docker, 21 марта 2013 года, Соломон Хайкс (Solomon Hykes) довольно изящно <a href="https://www.youtube.com/watch?v=wW9CAH9nSLs">представил</a> совершенно новое решение, достоинства которого легко продемонстрировать в терминале. Он загрузил из Интернета вариант сборки контейнера, собрал, запустил внутри контейнера приложение и получил его результаты единственной командой:</p> <pre><code tabindex="0" class="language-bash">docker run -dp 80:80 docker/getting-started </code></pre> <p>Естественно, перед тем, как использовать команду docker, необходимо установить кое-какие специальные службы (пара-тройка команд, которые выполняются один раз при настройке ОС сервера). А сейчас уже существуют готовые сборки серверов с Docker, когда ничего вообще не надо настраивать. К тому же, Docker теперь отлично работает на всех популярных и на некоторых не очень популярных ОС, обеспечивая полную совместимость. Программисты могут свободно разрабатывать программы на базе своей ОС и быть уверенными, что все запустится с первого раза на любом компьютере, на любом сервере, где установлены службы Docker.</p> <p>Таким образом, написав программу один раз и поместив ее внутрь контейнера, можно запускать ее на большинстве ОС. Я описал лишь основной сценарий использования Docker. Для программиста существует еще несколько сценариев, которые мы разберем по ходу. Однако сейчас немного остановимся на терминологии.</p> <h3>Docker container (контейнер)</h3> <p>В статье <a href="https://www.upguard.com/blog/docker-vs-lxc">LXC vs Docker: Why Docker is Better</a> приводится сравнение возможностей технологий Docker и LXC, которое оказывается явно не в пользу последней. В LXC под контейнером подразумевается изолированное окружение пользователя, которое формируется за счет выставления прав (ограничения доступа) для пользователя. Используется установленная на компьютере ОС, но для программ и пользователей контейнер оказывается полностью изолированным. Складывается ощущение, что он совершенно независим, но это не так. Например, LXC-контейнер не может использовать ОС, отличную от базовой. Технология LXC решает задачу изоляции окружения, для которой и была создана, но иногда нужно немного больше.</p> <p>Под контейнером в Docker (Docker container) подразумевается эмуляция ОС на основе специальной службы Docker daemon, которая устанавливается на родительскую ОС и является сервером. Она использует не только механизм LXC, но и включает cgroups, прослойку для коммуникации со службами ОС и ядро Linux.</p> <p>Docker daemon осуществляет управление объектами (Docker objects) и позволяет установить и запустить на Linux, macOS или Windows виртуальную копию окружения большого списка разных дистрибутивов Linux. На Linux используется ядро базовой ОС. На macOS и Windows — ядро оптимизированной виртуальной машины с ОС Linux.</p> <p>С точки зрения пользователя контейнер становится аналогом отдельной ОС, на которой установлено нужное окружение и запускаемое приложение. С точки зрения родительской ОС, запуская контейнер, вы запускаете просто отдельное приложение.</p> <p>Получается, что ОС работает в обычном режиме, а пользователь получает все преимущества отдельной виртуальной машины и ОС контейнера. При этом ресурсы компьютера на обеспечение механизма работы Docker практически не тратятся и идут на обеспечение работы целевого приложения.</p> <h3>Docker engine (движок)</h3> <p><a href="https://docs.docker.com/get-started/overview/#docker-engine">Движок Docker</a> состоит из Docker daemon, выступающего в роли сервера, прослойки REST API и клиента (Docker CLI), на котором осуществляется управление образами (Docker image) и томами (Docker volumes), управление жизненным циклом контейнеров, обеспечивается эмуляция локальной сети для связи запущенных контейнеров друг с другом.</p> <h3>Docker image (образ)</h3> <p>Это образ (прототип) контейнера, который в конечном итоге будет запущен с помощью Docker CLI. Образ представляет собой конфигурационный файл, который содержит набор инструкций для сборки контейнера. Каждую новую инструкцию можно сравнить с новым слоем. Например, на первом слое описывается, какой должен использоваться дистрибутив ОС, на втором слое устанавливаются какие-нибудь специфические для контейнера службы или сервисы, а на последнем слое собирается или просто устанавливается целевое приложение (система управления базами данных (СУБД) / сайт / веб-сервис).</p> <h3>Union File Systems</h3> <p>В контейнерах используется особая стековая файловая система (Union File Systems), в которой файлы и каталоги одного слоя представляют собой отдельную файловую систему (ветвь). Каждая новая ветвь может быть наложена на предыдущую, образуя единую файловую систему собранного контейнера. Содержимое каталогов, имеющих одинаковый путь внутри наложенных ветвей, рассматривается как единый объединенный каталог, что позволяет избежать необходимости создавать отдельные копии каждого слоя. За подробностями можно обратиться к статьям и видео:</p> <ul> <li><a href="https://www.freecodecamp.org/news/a-beginner-friendly-introduction-to-containers-vms-and-docker-79a9e3e119b/">A Beginner-Friendly Introduction to Containers, VMs and Docker</a></li> <li><a href="https://habr.com/p/438796/">Изучаем Docker, часть 1: основы</a></li> <li><a href="https://habr.com/p/439978/">Изучаем Docker, часть 2: термины и концепции</a></li> <li><a href="https://youtu.be/wW9CAH9nSLs">The future of Linux Containers</a></li> <li><a href="https://youtu.be/QF4ZF857m44">Основы Docker. Большой практический выпуск</a></li> </ul> <h3>Система команд Linux</h3> <p>Итак, задача стоит перед нами исследовательская. Например, вы хотите попробовать разобраться с новой для вас системой команд конкретной версии ОС Linux или с настройкой какой-то определенной службы.</p> <p>Чтобы воспользоваться Docker для этой цели, нам необходимо в первую очередь его установить. <a href="https://docs.docker.com/get-docker/">На официальном сайте</a> найдите дистрибутив Docker Desktop для macOS и Windows или инструкции для установки Docker для вашей версии ОС Linux. В результате установки вы получите Docker engine, Docker daemon и Docker CLI, то есть все самое необходимое для использования Docker.</p> <p>Следующий этап представляется намного более творческим. Для работы контейнера с «установленной» внутри него версией ОС Linux, необходимо его из чего-то собрать. Для этого используется базовый образ (Docker image). Необходимо найти такой образ, на который вы потом будете «наслаивать» специфическое окружение. Для выполнения поставленной задачи необходимо выбрать образ ОС Linux и получить доступ к терминалу.</p> <p>Сначала проверим, что после установки и запуска все работает корректно:</p> <pre><code tabindex="0" class="language-bash">docker --version > Docker version 19.03.13, build 4484c46d9d </code></pre> <p>Командой выше можно протестировать, что Docker готов, может скачивать, устанавливать и запускать образы (Docker image). Образы должны где-то храниться, и Docker предлагает хранить их с помощью удаленной платформы <a href="https://docs.docker.com/registry/">Docker Registry</a> или в общедоступном хранилище <a href="https://hub.docker.com/">Docker Hub</a> (бесплатный общедоступный реестр образов).</p> <p>Кроме простых образов существует понятие репозиториев <a href="https://docs.docker.com/docker-hub/repos/">Docker repository</a>, которые представляют собой набор образов с одинаковым именем, но с разными тегами (идентификаторами образов). Обычно с помощью тегов организуется хранение образов с разными версиями программного обеспечения и/или ОС.</p> <p>Попробуем запустить образ. Для этого у команды Docker есть специальный тестовый образ, который можно скачать, установить и запустить следующим образом:</p> <pre><code tabindex="0" class="language-bash">docker run hello-world > Unable to find image 'hello-world:latest' locally > latest: Pulling from library/hello-world > 0e03bdcc26d7: Pull complete > Digest: sha256:e7c70bb24b462baa86c102610182e3efcb12a04854e8c582838d92970a09f323 > Status: Downloaded newer image for hello-world:latest > > Hello from Docker! </code></pre> <p>Сначала Docker CLI попытался найти указанный образ hello-world среди уже скачанных и не нашел его («Unable to find … locally»). Затем он обратился к реестру Docker Hub, который установлен по умолчанию, нашел, скачал и установил последнюю версию: «latest: Pulling from…». В итоге мы получили вывод в терминале сообщения «Hello from Docker!»</p> <p>Если сейчас посмотреть список запущенных контейнеров с помощью команды:</p> <pre><code tabindex="0" class="language-bash">docker ps > CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES </code></pre> <p>Вы увидите, что список пуст (присутствуют только заголовки таблицы). Если запустить эту команду с определенным ключом <code>--all</code>, то мы получим список всех запущенных контейнеров и контейнеров, которые уже отработали, но не были удалены из списка (операция удаления производится вручную или при остановки службы Docker daemon):</p> <pre><code tabindex="0">docker ps --all > CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES > 93cb27f68163 hello-world "/hello" 3 minutes ago Exited (0) 3 minutes ago happy_goldberg </code></pre> <p>Приведу список основных команд со ссылками на оригинальную документацию, которыми вы будете пользоваться большую часть времени при использовании Docker:</p> <ul> <li><a href="https://docs.docker.com/engine/reference/commandline/ps/">docker ps</a></li> <li><a href="https://docs.docker.com/engine/reference/commandline/run/">docker run</a>;</li> <li><a href="https://docs.docker.com/engine/reference/commandline/image/">docker image</a>;</li> <li><a href="https://docs.docker.com/engine/reference/commandline/container/">docker container</a>;</li> <li><a href="https://docs.docker.com/storage/volumes/">docker volume</a>.</li> </ul> <p>Вернемся к нашей задаче. Самый простой способ воплотить ее в жизнь, найти готовый образ желаемой ОС в реестре и запустить. Для этого переходим на страницу <a href="https://hub.docker.com">Docker Hub</a> и ищем необходимый нам образ (пусть это будет <a href="https://hub.docker.com/_/centos">образ с CentOS 8</a>). Вы наверняка увидите подсказку с командой для установки данного образа, после выполнения которой вам будет выведена следующая информация:</p> <pre><code tabindex="0" class="language-bash">docker pull centos > Using default tag: latest > latest: Pulling from library/centos > 3c72a8ed6814: Pull complete > Digest: sha256:76d24f3ba3317fa945743bb3746fbaf3a0b752f10b10376960de01da70685fbd > Status: Downloaded newer image for centos:latest > docker.io/library/centos:latest </code></pre> <p>Любопытно, что образ чистой ОС занимает всего около 70 Мб, гораздо меньше, чем полноценная ОС Linux. Удивляться не надо, ведь в образе нет, например, ядра ОС.</p> <p>В интерфейсе Docker Hub есть три вкладки с полезной информацией: Description, Reviews, Tags. Наличие вкладки Tags свидетельствует о том, что перед нами не образ, а репозиторий образов. На вкладке Reviews есть полезные комментарии от пользователей, на которые стоит обратить внимание при выборе образа или версии образа. Также вы можете заметить справа над строкой, которую мы с вами скопировали, селектор с выбором платформы (ОС и архитектура процессора).</p> <p>Надо понимать, что под архитектурой процессора подразумевается архитектура процессора, для которой собран образ ОС. По умолчанию используется amd64 (синоним x86-64). В первой строке вывода мы также видим, что по умолчанию присваивается тег latest. Это означает, что версию ОС, которая будет установлена в контейнере нужно смотреть в реестре под этим тегом.</p> <p>Информация о том, какие слои должны присутствовать в образе (другими словами — «какое окружение»), хранится в специальном файле Dockerfile. На главной странице репозитория ссылка <a href="https://github.com/CentOS/sig-cloud-instance-images/blob/12a4f1c0d78e257ce3d33fe89092eee07e6574da/docker/Dockerfile">latest, centos8, 8</a> в списке тегов (Supported tags and respective Dockerfile links) ведет на содержимое файла Dockerfile с указанием четырех слоев контейнера, чуть позже мы рассмотрим эти конфигурационные файлы подробнее. Для используемого нами образа это всего три слоя (базовый слой, слой операционный системы, запуск терминала), которые устанавливаются командами:</p> <pre><code tabindex="0" class="language-docker">FROM scratch ADD centos-8-x86_64.tar.xz / LABEL org.label-schema.schema-version="1.0" org.label-schema.name="CentOS Base Image" org.label-schema.vendor="CentOS" org.label-schema.license="GPLv2" org.label-schema.build-date="20200809" CMD ["/bin/bash"] </code></pre> <p>Используется базовая ОС для Docker. С помощью команды <code>ADD</code> добавляются файловая система образа интересующей нас ОС, затем устанавливаются именованные константы для контейнера командой <code>LABEL</code> (важный шаг для управления контейнерами), а на последнем шаге запускается терминал командой <code>CMD</code>. Кажется, пора запустить контейнер.</p> <p>Давайте посмотрим список загруженных образов с помощью команды:</p> <pre><code tabindex="0" class="language-bash">docker image ls > REPOSITORY TAG IMAGE ID CREATED SIZE > centos latest 0d120b6ccaa8 3 months ago 215MB > hello-world latest bf756fb1ae65 11 months ago 13.3kB </code></pre> <p>Обратите внимание на то, что при распаковке размер образа увеличился почти в три раза (215MB против ~ 70MB). Запуск контейнера осуществляется командой:</p> <pre><code tabindex="0" class="language-bash">docker run centos </code></pre> <p>Если вы выполните эту команду, то увидите, что на консоль ничего не вывелось. Почему? Вроде бы вы скачали правильный образ, вроде бы запустили… Помните, что вы запускаете какое-то приложение. После окончания работы этого приложения контейнер автоматически останавливается и выгружается из памяти. Так и получилось.</p> <p>Как же быть, если нам нужно запустить терминал для работы с консолью контейнера? Необходимо выполнить команду со специальными ключами:</p> <pre><code tabindex="0" class="language-bash">docker run -it --entrypoint bash centos </code></pre> <p>Ключ <code>--entrypoint</code> перезаписывает значение точки вхождения по умолчанию. Это приложение, которое запускается внутри контейнера после его сборки. Два ключа <code>-i</code> и <code>-t</code> служат для открытия стандартного потока ввода и использования одного терминала соответственно. С подробностями вы можете ознакомиться в <a href="https://docs.docker.com/engine/reference/commandline/run/">разделе документации</a>, относящейся к команде, <a href="https://habr.com/p/439978/">в статье на Хабре</a>, в Википедии: <a href="https://ru.wikipedia.org/wiki/%D0%A1%D1%82%D0%B0%D0%BD%D0%B4%D0%B0%D1%80%D1%82%D0%BD%D1%8B%D0%B5_%D0%BF%D0%BE%D1%82%D0%BE%D0%BA%D0%B8">Стандартные потоки</a> и <a href="https://ru.wikipedia.org/wiki/TTY-%D0%B0%D0%B1%D1%81%D1%82%D1%80%D0%B0%D0%BA%D1%86%D0%B8%D1%8F">TTY-абстракция</a>.</p> <p>Чтобы выйти из терминала bash, как обычно, необходимо выполнить команду <code>exit</code>. Это приведет к остановке контейнера, поскольку программа терминала будет завершена.</p> <p>Взаимодействие с внешними хранилищами — папками базовой ОС, на которой запущен Docker, или с содержимым других контейнерами — обеспечивается путем использование томов <a href="https://docs.docker.com/storage/volumes/">Docker volumes</a>. Тома монтируются в папки контейнера, которые можно задавать с помощью конфигурационных файлов или напрямую в терминале установкой определенных флагов.</p> <p>Тома могут быть как самостоятельными ресурсами, недоступными для базовой ОС (обычный тип), так и связанными с папками базовой ОС (тип bind). Если используется независимый том, его необходимо предварительно создать и подключить к контейнеру. Для работы с томами используются следующие команды:</p> <ul> <li><strong>Создание тома:</strong> <code>docker volume create my_volume</code></li> <li><strong>Список всех томов:</strong> <code>docker volume ls</code></li> <li><strong>Информация о томе:</strong> <code>docker volume inspect my_volume</code></li> <li><strong>Удаление тома:</strong> <code>docker volume rm my_volume</code></li> </ul> <p>Когда вы создадите обычный том и просмотрите информацию о нем, вы увидите, в какой именно папке будет содержаться файл с содержимым тома в базовой ОС. Чтобы подключить том при запуске контейнера и иметь доступ к содержимому этого тома в определенной папке контейнера (например, /tmp/volume), достаточно выполнить команду <code>run</code> с параметром <code>--mount</code>:</p> <pre><code tabindex="0" class="language-bash">docker run --mount 'source=my_volume,target=/tmp/volume' -it --entrypoint bash centos </code></pre> <p>Если к контейнеру необходимо подключить папку из базовой ОС, необходимо выполнить команду со следующими ключами:</p> <pre><code tabindex="0" class="language-bash">docker run --mount 'type=bind,source=/tmp,target=/tmp/volume' -it --entrypoint bash centos </code></pre> <p>Связывать подобным образом папки базовой ОС оказывается довольно удобно для работы приложений внутри контейнера. Вы можете разобраться с использованием томов подробнее <a href="https://docs.docker.com/storage/">в документации</a> или кратко <a href="https://habr.com/p/441574/">в руководстве по работе с данными</a>.</p> <p>Имея доступ к терминалу ОС контейнера, вы можете изучить интересный для вас дистрибутив ОС Linux, не устанавливая его к себе на компьютер и не арендуя сервер. Например, теперь вы можете экспериментировать со специфичным пакетным менеджером или создать файлы настроек нужных вам служб. И все это после выполнения одной команды в терминале!</p> <hr> <p>Кажется, теперь мы прошлись по всему самому необходимому и готовы попробовать использовать технологию на практике. <a href="https://web-standards.ru/articles/docker-unboxing-2/">Поговорим об этом во второй части</a>.</p> </article> <article> <h1>Что нового в WCAG 3.0</h1> <p>Thu, 28 Jan 2021 00:00:00 GMT</p> <p>Руководство по обеспечению доступности веб-контента (<a href="https://www.w3.org/TR/wcag-3.0/">Web Content Accessibility Guidelines</a>, сокращённо WCAG) — это самый важный стандарт в области веб-доступности. Он содержит рекомендации о том, как сделать контент более удобным для пользователей в целом и доступным для людей с особыми потребностями.</p> <p>WCAG является одним из ключевых документов по веб-доступности и определяет, как она развивается. Поэтому полезно знать об изменениях, которые с ним происходят.</p> <p>21 января 2021 Рабочая группа руководства по доступности (Accessibility Guidelines Working Group) опубликовала <a href="https://www.w3.org/TR/wcag-3.0/">первую рабочую версию черновика Руководства по доступности 3.0</a> (WCAG 3.0). Дальше буду называть его просто WCAG 3.</p> <p>Важно отметить, что WCAG 3 — наследник предыдущих версий руководств. Он не отменяет и не заменяет их.</p> <p>Также WCAG 3 находится пока в статусе первой рабочей версии черновика. Это значит, что W3C всё ещё рекомендует руководствоваться версией 2.1.</p> <p>Кроме основных требований доступности, которые перекочевали в WCAG 3 из предыдущих версий, новые рекомендации частично включают и расширяют два других документа:</p> <ul> <li><a href="https://www.w3.org/WAI/standards-guidelines/uaag/">Руководство по доступности агентов пользователя</a> (User Agent Accessibility Guidelines 2.0 или коротко UAAG 2.0);</li> <li><a href="https://www.w3.org/WAI/standards-guidelines/atag/">Руководство по доступности инструментов разработки</a> (Authoring Tool Accessibility Guidelines 2.0 или ATAG 2.0).</li> </ul> <p>WCAG 3 также их не заменяет и не отменяет.</p> <p>Давайте теперь разберёмся с конкретными изменениями в WCAG 3.</p> <h2>Зачем изменять WCAG</h2> <p>Первая версия WCAG появилась в 2008 году, и с тех пор принятые подходы к доступности не сильно изменились. А технологии и нужды пользователей с особыми потребностями, напротив, эволюционировали.</p> <p>Новая версия документа — это более комплексный и универсальный ответ на новые запросы пользователей и появление новых технологий.</p> <h2>Цели WCAG 3</h2> <p>Новые рекомендации, как и предыдущие, стремятся сделать цифровые продукты более доступными и удобными для людей с особыми потребностями. Это, например, интернет в целом, сайты, ePub, PDF, приложения и многие другие технологии.</p> <p>Однако у WCAG 3 есть и новые цели.</p> <ul> <li>Доходчивым языком описать требования к доступности, которые будут понятны широкой аудитории.</li> <li>Лучше отразить нужды пользователей с особыми потребностями.</li> <li>Дать гибкую систему оценки, которая эффективно ответит на потребности большего числа организаций.</li> <li>Мотивировать улучшать доступность продуктов с помощью новой модели оценки доступности.</li> <li>Разработать удобную модель соответствия требованиям доступности (Conformance Model), которая поможет лучше определять доступность продуктов.</li> <li>Дать возможность людям, создающим цифровые продукты, совершать некритичные ошибки, если они не влияют на пользователей с особыми потребностями.</li> </ul> <h2>Работа над черновиком WCAG 3</h2> <p>Из рабочей группы руководства по доступности W3C были выделены две команды: <a href="https://www.w3.org/WAI/GL/task-forces/silver/">Silver Task Force</a> и <a href="https://www.w3.org/community/silver/">Silver Community Group</a>. Их задача — проведение исследований и улучшение WCAG.</p> <p>В течение 2019 и 2020 годов группы проводили интервью с пользователями с особыми потребностями, дизайнерами, разработчиками, тестировщиками и чиновниками, занимающимися доступностью и изучали литературу и исследования по доступности.</p> <p>В итоге они опубликовали <a href="https://docs.google.com/presentation/d/1POs7orJ4ALB0bq5_vyo4v8RxDcr-5ctwD1noVgpXuJc/view">отчёт</a> (Google Slides) о проблемах с юзабилити, структурой, требованиями и поддержкой WCAG 2. Их выводы и легли в основу черновика WCAG 3.</p> <h2>WCAG 2 vs WCAG 3</h2> <p>Первое, что можно заметить — название документа. Из него убрали слово «веб-контент» и оно превратилось в «W3C Accessibility Guidelines 3.0». Это связано с тем, что рекомендации охватывают больше цифровых продуктов и технологий, например, интернет вещей, виртуальную реальность, приложения и другие.</p> <p>Ещё больше изменилась структура и модель соответствия требованиям.</p> <h3>Новая структура WCAG</h3> <p>Из документа убрали пять основных принципов. Теперь он имеет только три уровня содержимого:</p> <ul> <li>Руководства (Guidelines), как и раньше;</li> <li>Результаты (Outcomes) вместо Критериев успешности (Success Criteria);</li> <li>Методы (Methods) вместо Техник (Techniques).</li> </ul> <p><strong>Руководство</strong> — это высокоуровневая, упрощённая версия содержания. Оно нужно людям, которые пока плохо знакомы с доступностью и не готовы углубляться в технические детали. У руководств есть названия и упрощённые краткие описания (Plain Language Summary). Каждое из них касается отдельной темы: текстовых альтернатив, понятности слов, субтитров, контраста текста и так далее.</p> <p>Пока что в WCAG 3 есть шесть руководств, но их число будет расти. Если вам интересно, что ещё планируется добавить, можете почитать про <a href="https://docs.google.com/document/d/1aCRXrtmnSSTso-6S_IO9GQ3AKTB4FYt9k92eT_1PWX4/view">планы W3C по миграции руководств из WCAG 2</a>.</p> <p>Внутри руководств есть <strong>результаты</strong>. Это проверяемые критерии. Они состоят из критических ошибок (Critical Errors) и оценки результата (Outcome Scoring).</p> <p><strong>Критические ошибки</strong> — это ошибки, из-за которых пользователь не может совершить нужное действие. К таким ошибкам относятся:</p> <ul> <li>Ошибки, которые мешают с чем-то взаимодействовать. Например, нельзя поставить звук на паузу.</li> <li>Ошибки, из-за которых невозможно завершить процесс. Например, нельзя отправить данные, так как кнопка не в порядке табуляции.</li> <li>Ошибки, которые приводят к затруднениям у пользователей. К примеру, непонятные и неоднозначные формулировки в тексте.</li> </ul> <p>Не любой результат содержит ошибки. Но если содержит, то это значит, что продукт не соответствует требованиям WCAG 3 ни на каком уровне.</p> <p>Все результаты оцениваются по шкале от 0 до 4. Оценки результата гибкие и не зависят от технологий.</p> <p>Результаты могут включать <strong>методы</strong>. В них содержится описание, примеры кода, тесты и их результаты.</p> <p>Методы бывают нескольких типов:</p> <ul> <li>Общие (All): подходят для всех технологий.</li> <li>Специфические (Technology Specific): подходят для одной технологии. Например, HTML, PDF или VR.</li> <li>Фолбэк (Fallback): подходят для новых или проприетарных технологий, для которых пока нет отдельных методов.</li> </ul> <p><strong>Тесты</strong> нужны для оценки реализации методов. Они состоят из пошаговых инструкций по оценке метода в зависимости от технологии и информацию о том, как считать баллы. Так как результаты оформлены как проверяемые критерии, то тестирование доступности значительно упрощается.</p> <p>Пока что все тесты разделяются на две категории:</p> <ol> <li>Атомарные (Atomic Tests), которые бывают ручными и автоматическими. Нужны для тестирования отдельных объектов и процессов.</li> <li>Холистические (Holistic Tests). Необходимы для тестирования доступности в целом. Они охватывают тестирование вспомогательных технологий, юзабилити и дизайна в целом.</li> </ol> <p>Также в руководствах есть несколько видов дополнительных материалов:</p> <ul> <li>Как реализовывать принципы (How To);</li> <li>Функциональные потребности (Functional Needs);</li> <li>Функциональные категории (Functional Categories).</li> </ul> <p>В материалах «Как реализовывать принципы» рассказано простым языком о применении принципов доступности на практике. Например, <a href="https://www.w3.org/WAI/GL/WCAG3/2020/how-tos/captions/">как правильно добавить субтитры</a>. Рекомендации сгруппированы по отдельным вкладкам с общим описанием принципа, категориями пользователей, для которых мы это внедряем, что нужно делать разработчикам и дизайнерам, а также ссылками на примеры хороших реализаций и на ресурсы.</p> <p><strong>Функциональные потребности</strong> — это описание ограничений в возможностях пользователей или несоответствие между их возможностями и средой или контекстом. Например, не все пользователи умеют читать или писать.</p> <p>Пока функциональные потребности вынесены в <a href="https://www.w3.org/WAI/GL/WCAG3/2020/functional-needs/">отдельный черновик</a>.</p> <p><strong>Функциональные категории</strong> — объединённые в большие группы функциональные потребности пользователей. Пока что их список предварительный и включает, например, мобильные категории потребностей, моторные, зрительные и визуальные, речевые, ментальное здоровье и так далее.</p> <h3>Новая модель соответствия требованиям и оценка доступности</h3> <p>Раньше соответствие критериям успешности указывало только на то, доступна страница или нет. Теперь мы определяем доступность этой страницы с помощью <strong>оценки результата</strong> (Outcome Scoring). Результаты бывают в диапазоне от 0 до 4:</p> <ul> <li>0 — очень плохо (Very Poor);</li> <li>1 — плохо (Poor);</li> <li>2 — удовлетворительно (Fair);</li> <li>3 — хорошо (Good).</li> <li>4 — отлично (Excellent).</li> </ul> <p>Эти баллы объединяются с другими, чтобы определить общий уровень доступности.</p> <p>Общая оценка (Overall Score) складывается из средней оценки всех результатов по функциональным категориям.</p> <p>Из общей оценки складывается уровень соответствия требованиям доступности (Conformance Level). В WCAG 3 уровни A, AA и AAA заменены на Бронзовый, Серебряный и Золотой. Пока что подробно описан только Бронзовый. Остальные уровни будут проработаны в следующих черновиках.</p> <p><strong>Бронза (Bronze)</strong> — минимальный уровень. Он эквивалентен AA. Контент, который не соответствует требованиям этого уровня, не соответствует WCAG 3. Он присваивается, если:</p> <ul> <li>проведены успешные атомарные тесты, общий балл и балл в каждой функциональной категории составляют не менее 3,5;</li> <li>отсутствуют критические ошибки.</li> </ul> <p><strong>Серебро (Silver)</strong> — это более высокий уровень соответствия требованиям доступности, который эквивалентен AAA. Он складывается из:</p> <ul> <li>наличия Бронзового уровня;</li> <li>успешного проведения холистических тестов.</li> </ul> <p><strong>Золото (Gold)</strong> — самый высокий уровень соответствия. Он складывается из тех же составляющих, что у серебряного.</p> <p>Получается, что уровня A в новом документе нет. Можно предположить, что сайты, которые соответствуют уровню A из WCAG 2.1, не будут считаться доступными с точки зрения WCAG 3.</p> <h2>Что дальше</h2> <p>Пока опубликована только первая рабочая версия черновика и уже ведутся обсуждения по её улучшению.</p> <p>W3C опубликует кандидата в рекомендации WCAG 3.0 примерно в 2022 году. Затем потребуется около года на проведение всех тестов и проверок. Так что окончательную версию документа следует ждать не раньше конца 2023.</p> <p>Так как в новом стандарте будет другая модель соответствия, то рабочая группа даст всем организациям время на переход на новый стандарт. Также она планирует подготовить вспомогательные материалы с советами по переходу.</p> <p>Надо помнить, что принятие новых рекомендаций — это долгий и сложный процесс. Многое за это время изменится: что-то будет убрано, что-то добавлено. Поэтому пока рано внедрять что-то из предложенного в черновике в практику как в своих рабочих проектах, так и в инструментах для тестирования доступности.</p> <h2>Полезные ссылки</h2> <ul> <li><a href="https://www.w3.org/TR/wcag-3.0/">Черновик WCAG 3</a>.</li> <li><a href="https://www.w3.org/WAI/standards-guidelines/wcag/wcag3-intro/">Введение WCAG 3</a>.</li> <li><a href="https://www.deque.com/blog/first-public-working-draft-wcag-3/">What to Expect From The First Public Working Draft of WCAG 3.0</a>, Вилко Фирс.</li> <li><a href="https://www.deque.com/blog/public-working-draft-wcag-3-history/">First Public Working Draft of WCAG 3.0, A Brief History</a>, Вилко Фирс.</li> <li><a href="https://myaccessible.website/accessibility-expert/ag-3.0">Accessibility Guidelines 3.0</a>, Фиона Холдер.</li> </ul> </article> <article> <h1>Водитель или механик?</h1> <p>Thu, 07 Jan 2021 00:00:00 GMT</p> <p>Спор «инструменты против знаний» обычно идёт примерно так:</p> <p><strong>Случайный разработчик:</strong> Не нужно знать CSS. Или даже базовый JavaScript. Ну то есть, наши классные инструменты обо всём позаботятся, так ведь?</p> <p><strong>Я:</strong> Если ты разработчик, ты должен знать что-нибудь про CSS и JavaScript. Что, если твой инструмент не решает твою задачу? Что, если он ужасен с точки зрения производительности?</p> <p><strong>Случайный разработчик:</strong> Глупости. С моими надёжными инструментами я гораздо более продуктивен.</p> <p><strong>Я:</strong> Но ведь иметь какие-то базовые знания — это часть того, чтобы быть профессиональным веб-разработчиком.</p> <p><strong>Случайный разработчик:</strong> Ну вот если ты едешь на машине, ты не должен знать, как она работает, так? Ты просто рулишь.</p> <p>И не упомнишь, сколько раз за последние десять лет я слышал эту аналогию. На первый взгляд она интересная, но я понял, что не согласен с ней.</p> <p>Я считаю, мы не водители машины под названием «Всемирный веб», а скорее механики. И механики совершенно точно должны знать что-нибудь об устройстве, которое они создают и обслуживают, так ведь?</p> <p>На самом деле, чем больше я думаю об этом, тем больше я вижу в этом фундаментальный вопрос.</p> <p><strong>Кем бы вы предпочли быть: водителем машины или механиком?</strong></p> <p>Я уверен, что такая постановка вопроса вызовет у некоторых интерес. Всё же лучше не заходить слишком далеко в таких аналогиях. Вместо того чтобы прояснить, они могут с легкостью запутать.</p> <p>Проблема в том, что люди начинают добавлять подробности, которые не подходят к этой аналогии. Что именно мы имеем в виду под машиной? Веб, сайт или целый процесс его создания? Что значит «вести машину»? Сёрфить по вебу, создавать сайты или что-то другое? Кого именно символизирует механик? Чем являются инструменты?</p> <p>Такая дискуссия может легко деградировать в крикливый спор о значении аналогии, когда все уже забыли о вопросе «знания против инструментов», который аналогия должна была прояснить.</p> <p>За последние двадцать лет я заметил ещё кое-что: люди прибегают к обыденным сравнениям, только если у них кончаются реальные аргументы или если они не до конца понимают всю суть проблемы. Поэтому они создают образ чего-то, с чем все готовы согласиться, и делают вид, что это ставит точку в дискуссии.</p> <p>Вопрос о том, действительно ли достаточно инструментов для создания сайтов, или лежащие в основе технологии также необходимы, не решается обыденным сравнением про машины. Только реальные аргументы про инструменты и знания смогут ответить на него.</p> <p>Несмотря на все вышесказанное, мне нравится вопрос, который я задал выше, поскольку он заставляет вас принять фундаментальное решение. Так что пусть будет, даже если это <em>подбросит</em> нас до потенциально запутывающей аналогии с машинами.</p> <p>Как разработчик, вы бы предпочли быть водителем машины или механиком?</p> </article> <article> <h1>Опрос MDN, Igalia, npm 7, React vs WordPress, уже Webpack 5, Rome — инструмент будущего</h1> <p>Wed, 28 Oct 2020 00:00:00 GMT</p> <p>Перед вами расшифровка 252 выпуска подкаста «Веб-стандарты», который вышел 19 октября 2020. Если вы хотите его именно послушать, то вы можете сделать это на <a href="https://youtu.be/v1RzZEYJmBk">Ютубе</a>, <a href="https://podcasts.google.com/feed/aHR0cHM6Ly93ZWItc3RhbmRhcmRzLnJ1L3BvZGNhc3QvZmVlZC8/episode/aHR0cHM6Ly93ZWItc3RhbmRhcmRzLnJ1L3BvZGNhc3QvZXBpc29kZXMvMjUyLm1wMw?sa=X&ved=0CAUQkfYCahcKEwjA59Du-dXsAhUAAAAAHQAAAAAQAQ">Google Podcasts</a>, <a href="https://podcasts.apple.com/podcast/id1080500016?i=1000495250597">Apple Podcasts</a>, <a href="https://music.yandex.ru/album/6245956/track/72546462">Яндекс.Музыке</a> или на любой другой платформе, где можно слушать подкасты. Но если вам приятнее будет почитать — пожалуйста! А если вы вдруг найдёте опечатки или неточности, то да — <a href="https://github.com/web-standards/web-standards.ru/blob/master/src/articles/episode-252/index.md">мы будем рады пулреквесту</a>.</p> <h2>Темы</h2> <ul> <li><a href="https://web-standards.ru/articles/episode-252/#section-3">События</a></li> <li><a href="https://web-standards.ru/articles/episode-252/#section-4">Опрос MDN</a></li> <li><a href="https://web-standards.ru/articles/episode-252/#section-5">Открытые приоритеты Igalia</a></li> <li><a href="https://web-standards.ru/articles/episode-252/#section-6">Новинки Npm 7</a></li> <li><a href="https://web-standards.ru/articles/episode-252/#section-7">React vs WordPress</a></li> <li><a href="https://web-standards.ru/articles/episode-252/#section-8">Уже Webpack 5</a></li> <li><a href="https://web-standards.ru/articles/episode-252/#section-9">Что такое Rome</a></li> <li><a href="https://web-standards.ru/articles/episode-252/#section-10">Инструмент будущего</a></li> </ul> <h2>Интро</h2> <p><strong>Никита Дубко:</strong> Привет. С вами 252-й выпуск подкаста «Веб-стандарты» и его постоянные ведущие Никита Дубко из «Яндекса»…</p> <p><strong>Вадим Макеев:</strong> И Вадим Макеев из HTML Academy.</p> <p><strong>Никита Дубко:</strong> В этом подкасте мы обсуждаем главные новости фронтенда за прошедшую неделю. Читайте новости в Твиттере, во ВКонтакте, в Фейсбуке или в Телеграме. Если вам нравится, что мы делаем, поддержите нас на Patreon, все ссылки в описании. Сегодня у нас в гостях Антон Кастрицкий. Антон, привет. Расскажи немножко про себя.</p> <p><strong>Антон Кастрицкий:</strong> Всем привет. Да, меня зовут Антон, я работаю в партнерских интерфейсах Яндекс.Маркет, иногда даже выступаю с докладами, имея нездоровую любовь к инструментам разработки, бывает даже в Твиттер пишу микропакеты в npm без зависимостей, всячески топлю за веб и энтузиирую в Vim.</p> <ul> <li><a href="https://twitter.com/antonk52">Антон в Твиттере</a></li> <li><a href="https://www.twitch.tv/antonk52">Антон на Твитче</a></li> </ul> <p><strong>Вадим Макеев:</strong> На самом деле, этот выпуск родился, и Антон с нами сегодня, потому что я как-то прочитал его тредик про Rome в Твиттере, англоязычный, причем, и не так много разработчиков по-английски Твиттер ведут, можем об этом, кстати, поговорить потом, плюс еще тема свежая и интересная. Опять же, мало разработчиков интересуются вещами, которые в практике ежедневной пока еще не вошли. Может, у тебя уже во весь рост Rome используется. Тем не менее, мы сегодня поговорим про этот новый тулчейн, как они себя называют, немножко про вебпяку… Про вебпяку, господи…</p> <p><strong>Никита Дубко:</strong> Это мое любимое новое слово, спасибо, Вадим.</p> <p><strong>Антон Кастрицкий:</strong> Это очень мило.</p> <p><strong>Вадим Макеев:</strong> Немножко про Webpack, спасибо, ребят, за поддержку. Всякие новости недели и статьи. Давайте начнем с событий, как обычно.</p> <h2>События</h2> <ul> <li><a href="https://nextjs.org/conf">Next.js Conf онлайн 27 октября</a></li> <li><a href="https://developer.chrome.com/devsummit/">Chrome Dev Summit 9–10 декабря</a></li> </ul> <p><strong>Вадим Макеев:</strong> В прошлом выпуске мы коротко говорили про Next.js, мол, такая штука, все дела, и они неожиданно анонсировали конференцию, сегодня нам в календарь принесли, спасибо вам большое за это. Не думаю, что сами ребята, тем не менее. Next.js global user conference. Я подумал, что 27 октября размазано по нашей планете довольно-таки тонким слоем, потому что у кого-то еще 26-е, у кого-то уже 27-е, и он шагает по планете, и непонятно вообще, в какой момент эта конференция начнется. И планировать что-то… или просто в календарь добавить, к нам принесли в календарь, и нет города привязки конференции, и нет времени начала. Ты сидишь такой и думаешь — когда она будет? Вечером, утром, днем или круглые сутки будет идти?</p> <p>Я написал об этом письмо, говорю: «Ребят, все, конечно, классно, но у вас глобальная конференция, вы не могли бы хотя бы намекнуть, когда она начинается?» Мне ответили, хохотнули, сказали: «Да, тайм-зоны, все дела». Короче, в 9 утра по PST, кажется, это Калифорния, кажется, это очень американская конференция, поэтому ожидайте, что она начнется, не знаю, вечером по российскому времени где-то.</p> <p>Что еще? Ребята из Google анонсировали Chrome Dev Summit, он пройдет 9–10 декабря, и, к сожалению, к счастью, так вышло, опять же, в формате онлайн. Два дня конференция, которая посвящена исключительно тому, что делает Google Chrome, и это все около веба. Я на паре Chrome Dev Summit бывал, мероприятие крутейшее, там не только гуглеры, но еще и приглашают всяких ребят из компаний дружественных, чтобы они рассказали про собственные успехи, про собственные технологии, даже иногда про собственные браузеры. Поэтому я ожидаю там увидеть и Microsoft, может быть, даже Mozilla среди спикеров или, по крайней мере, где-нибудь рядышком.</p> <p>Одна из фишек на этой конференции, что они устраивают office hours так называемые, я не знаю, есть ли по-русски адекватный перевод, офисные часы. Короче, это время, когда кто-то из команды, которая разрабатывает какие-то части Chrome, может с вами посидеть, поговорить и объяснить, что, как, ответить на ваши вопросы и все остальное.</p> <p>В общем, ребята говорят, что конференции открыта для всех, она будет просто транслироваться на YouTube, но также можно спросить приглашение на то, что вы можете попасть на какие-то воркшопы, эти office hours и прочие всякие штуки дополнительные, в которых можно пообщаться с кем-то, а не просто молча посмотреть. Так что если вам интересно, если у вас какой-то минимальный уровень английского и возможность задавать вопросы, или интерес, или потребность задавать вопросы, регистрируйтесь, вот именно что регистрируйтесь, подавайте заявки, и радостно все посмотрим 9–10 декабря большую Google-конференцию.</p> <p>Я не ожидаю там адских анонсов. Chrome разрабатывается сравнительно открыто, и все анонсы у них в этих шестинедельных релизах заранее известны, но какой-то набор интересных докладов и, может быть, каких-нибудь статей вокруг него обязательно будет, и мы, конечно же, будем обсуждать во время подкаста. В начале декабря, 9-10 числа.</p> <h2>Опрос MDN</h2> <ul> <li><a href="https://www.surveygizmo.com/s3/5897636/Mozilla?sglocale=ru">MDN DNA Survey</a></li> </ul> <p><strong>Вадим Макеев:</strong> К новостям. MDN DNA survey. Какие потребности у разработчиков, решила спросить Mozilla у разработчиков, и спросила. На мой взгляд, не очень удачно. Mozilla, точнее, не Mozilla, а MDN как таковой, организация, в которую входят многие участники, не только Mozilla, спросил у разработчиков уже во второй раз, как им вообще веб, что им мешает, что им помогает, что хорошего, что плохого, и куда дальше двигаться MDN как сайту с документацией и совместимости веба и браузером и около того организациям, библиотекам, фреймворкам и всему остальному.</p> <p>Такая попытка сделать срез актуальный на 2020 год. Они одновременно с этим, рядышком с этим, опубликовали предыдущий репорт 2019 года, в PDF, я не видел ни одного человека, который прочитал этот PDF в живую, честно говоря. Ребят, вы прочитали PDF-репорт?</p> <p><strong>Никита Дубко:</strong> Я его открыл.</p> <p><strong>Вадим Макеев:</strong> А я его скачал, это близко к тому, чтобы его открыть, да. Он лежит у меня близко, я на него смотрю и думаю — ну, почему, почему?</p> <p>В общем, там много вопросов, мне удалось чуть-чуть улучшить перевод официальный этого опросника, мне Крис Милс написал по старой памяти, он помнит, что я по-русски умею, и говорит: «Слушай, у нас выходит, два дня до выпуска, помоги». Я прочитал, у меня волосы дыбом встали, я сказал: «Крис, там все очень плохо». Он говорит: «Поздно». Я говорю: «Окей». Я поправил какие-то самые очевидные ужасные вещи, но, тем не менее, у нас в чате «Веб-стандартов», в Telegram, заходите, кстати, есть дискуссия на тему того, чего получилось, и практически все говорят: «Прошел десять шагов, прошел девять шагов, не понял этого вопроса вообще». Опрос такой, очень печальный.</p> <p>Мне повезло, ребята, мне повезло, что буквально в утро, когда мы опубликовали эту новость, вечером этого же дня я поучаствовал в звонке GDE, Google Developer Experts очередном, на котором представили результаты репорта за предыдущий год и рассказали про новый репорт. Первым вопросом после этой презентации вышел я и сказал: «Ребята, почему же PDF, почему такое плохое качество перевода, почему такое плохое качество вопросов? Даже англоязычные вопросы, они очень сложные, «по шкале от 1 до 15 оцените, насколько вам нравятся свойства, не знаю, aspect ratio». У меня нет эмоций на эту тему вообще никаких. Они бы еще это, не знаю, пятна Роршаха показывали и спрашивали: «Что вы об этом думаете?» Вопросы такого типа. К сожалению, очень сложные и очень такие нерелевантные для типичного разработчика, сквозь них нужно продираться. В общем, я задал все эти неудобные вопросы, мне немножко неловко, но все-таки ответили на них. Мне кажется, я больше никогда не попаду на этот созвон, потому что я снова прихожу и критикую всех.</p> <p>Тем не менее, ребята объяснили, что это все все-таки делается силами Mozilla, они нанимают какое-то агентство, которое не всегда адекватно и переводит, и результаты комбинирует потом в пэдээфник, такой типичный корпоративный вариант, который всех устроит. Блин, но мы же веб, я даже не знаю, что тут еще добавить.</p> <p>Печально, что так получилось, я сказал ребятам, трижды повторил громко, чтобы все точно поняли, что «пожалуйста, в следующем году обращайтесь к сообществам, сообщества готовы участвовать, готовы помогать».</p> <p>Буквально тоже на днях, скоро выходит опрос The State of CSS, меня тоже позвали повычитывать русскоязычный перевод, и там тоже есть сложности, но хотя бы чуть заранее позвали. Я предложил помощь русскоязычного сообщества для следующего года и собственную помощь для того, чтобы все это сделать, более адекватно вопросы подготовить, более адекватный перевод подготовить.</p> <p>А пока, ребята, если вы реально хотите повлиять каким-то образом на то, как развивается браузер, платформа, документация MDN и всего около того, вам придется выстрадать этот опрос. Я пока его еще и сам не прошел, но я планирую, чего его и вам желаю. Какие у вас впечатления, ребята, от этого опроса, я даже не знаю, может быть, я просто пессимист?</p> <p><strong>Никита Дубко:</strong> Мне кажется, ты справедливо все, я начал его проходить и не закончил, потому что действительно продираешься сквозь некоторые вопросы, и уже такое впечатление сложилось в голове, что этот опрос составляли не технические люди по ТЗ от технических людей, оно прям чувствуется. Это, знаешь, как в книгах Лии Веру на русском, «забивка» которая padding, то есть что-то пошло не так. Так вот, тут такая же ситуация, эти вопросы, действительно, «оцените свои ощущения по непонятный шкале», это вообще из области психологии, не очень понятно, зачем. Действительно, есть тот же самый The State of CSS, этих ребяток обожаю, потому что они делают это красиво, эмоционально, «оцените с эмодзи это все», мне хочется в этом участвовать.</p> <p>В общем, на самом деле, посыл хороший, что они это делают, потому что это важно, это действительно какое-то направление, когда ты не просто делаешь продукт в вакууме, и никого не спрашиваешь. Но действительно, нужно над чем-то поработать. У меня не было мотивации завершить этот опрос, там сразу пугают, что целых 25 минут это займет, и ты такой: «О, то есть мне надо где-то сейчас полчаса из жизни найти». Такие вещи уже умеют делать, посмотрите в сторону The State of JS, The State of CSS, они это делают весело, задорно опенсорсно к тому же, то есть им помогать можно это все делать хорошо. Тот же самый Web Almanac очень красиво все… У Web Almanac тоже же PDF, но у них в том числе есть и веб-версия, в которой можно удобно искать, и клевые статейки, и вообще. Моя любовь просто Web Almanac, за прошлый год это самое лучшее, по-моему, что случилось.</p> <p>Но там не опросы, там про исследования.</p> <p><strong>Антон Кастрицкий:</strong> Мне очень понравилась сама идея, я даже… Раз уж мы пойдем по нарастающей, то есть Вадим еще, как я понял, не открывал, Никита попробовал, но не дошел до конца, а я все-таки закончил его вчера. Но это мне далось практически болью, потому что я это делал на телефоне.</p> <p>Никита уже может догадываться, в какую сторону я клоню. У ребят есть такая очень практическая любовь к нативным селектам.</p> <p><strong>Вадим Макеев:</strong> Я видел, я видел, они не помещаются в длину.</p> <p><strong>Антон Кастрицкий:</strong> При этом каждый раз, когда ты что-то выбираешь, ты поворачиваешь этот телефон, чтобы попробовать прочитать — ну, хорошо, еще на два слова больше, я попробую догадаться, что же они хотели от меня узнать! Было сложно, честно. Там были странные вопросы, были места, где я прям задавался сам вопросами о том, что же они хотели здесь спросить, потому что это был очень креативный перевод, особенно что касалось accessibility, потому что это было очевидно не с первого раза. Но кажется, что основную идею моей боли в вебе мне довелось внести.</p> <p><strong>Вадим Макеев:</strong> В общем, главной моей проблемой с этим опросом было то, что на некоторые вопросы… Вы знаете, когда хочется отвечать на какой-то вопрос, но ты читаешь, и не понимаешь, зачем им нужен ответ, то есть ты не понимаешь, зачем они задают этот вопрос, и как им мой ответ может пригодиться. Если ты этого не понимаешь, ты не понимаешь, как на вопрос ответить, ты не понимаешь, зачем на него отвечать в принципе, и это мотивацию очень сильно понижает. Поэтому плохие формулировки, неудобный интерфейс и PDF-экспорт в итоге — это как сделать так, чтобы никто его не прошел и никто его не прочитал. В похожих выражениях я вчера ребятам все это рассказал. Я надеюсь, они сделают выводы из этого, не только исключив меня из программы GDE, но и, не знаю, пригласив в следующем году поучаствовать меня и сообщество, и кого угодно.</p> <p>В общем, опрос важный, не проходите его с телефона, попробуйте пройти с десктопа, вдруг получится?</p> <h2>Открытые приоритеты Igalia</h2> <ul> <li><a href="https://www.igalia.com/2020/10/09/Open-Prioritization-Finalists.html">Two projects remain</a></li> <li><a href="https://blog.amp.dev/2020/10/13/open-prioritization/">AMP: $10k matching campaign</a></li> </ul> <p><strong>Вадим Макеев:</strong> Продолжая про сообщества. Есть такая штука, «Открытые приоритеты», Igalia запустила проект, мы уже про него говорили как-то, и есть отдельный большой выпуск подкаста The F-Word, в котором мы подробнее обсуждаем это с Брайаном Карделлом. Программа, в которой предлагает вам заплатить за то, чтобы Igalia внедрила какие-то фичи в WebKit. Я помню, как разработчики отреагировали: «Я должен платить за то, чтобы…» Нет, вы не должны платить. Если вы реально хотите, чтобы какие-то фичи появились, вы можете повлиять на это.</p> <p>9 ноября, написала Igalia, проект подводит черту, и кажется, нужные деньги собирают две фичи: inert и focus-visible. Это очень круто, потому что это все про доступность, это все важно, это все появится в WebKitе благодаря усилиям Igalia. Но вы все еще можете успеть докинуть свои деньги и, что интересно, если вы докинете доллар, то придет AMP и скажет: «О, кто-то докинул доллар, мы тоже докинем доллар». Если вы покинете 10 долларов, придет AMP и скажет… Ну, в общем, вы поняли. У них есть бюджет 10 тысяч долларов, чтобы сматчить вашу попытку поддержать все это. Так что до 9 ноября у вас есть шанс вкинуть в два раза больше денег, чем вы сами готовы дать. Обязательно присоединяйтесь. У меня там по 100 баксов на каждой фиче есть. Я настолько их ценю и настолько их жду, что мне очень хочется, чтобы они стали кроссбраузерными, и поэтому вам тоже рекомендую.</p> <p><strong>Никита Дубко:</strong> У меня сразу вопрос такой меркантильный. Есть фичи, которые они соберут, судя по всему, и будут те, которые собрали, но не полностью. Куда эта денежка денется? Она же переведена уже.</p> <p><strong>Вадим Макеев:</strong> Нет, эти деньги не переведены. Написав 100 баксов, ты сказал… Я, написав 100 баксов, сказал: «Я готов заплатить». Они не заморозили деньги, они не сняли деньги, ничего, просто это было такое обещание поддержать. Еще нужно будет потом прийти и снять эти деньги. Это такая ставка, скорее, чем непосредственная оплата. Поэтому, когда какой-то проект собрал определенную ставку, их начинают снимать. Это как…</p> <p><strong>Антон Кастрицкий:</strong> Kickstarter.</p> <p><strong>Вадим Макеев:</strong> Да, Kickstarter, на самом деле, с тебя не снимают деньги до последнего момента.</p> <p><strong>Никита Дубко:</strong> Я сразу с этим не разобрался, просто если бы я знал, я бы, наверное, даже… Но я и задоначу, знаешь, что уж тут? Просто ситуация какая? Когда они это начинали, ты такой: «Ага, мне сходу нужно денежку отдать, и сейчас у меня, допустим, нет такой возможности». А оказывается, что это было бы в ноябре, и я в принципе мог бы… Как здорово, что еще есть время.</p> <p><strong>Вадим Макеев:</strong> На самом деле, это все можно было прочитать на сайте opencollective, на основе которого все это происходит, но туда еще нужно было добраться. Неважно, главное, что теперь все знают, бегите, голосуйте вашими деньгами, даже один доллар станет двумя долларами и поможет ребятам это все профинансировать. И не разориться, кстати, потому что если они недособерут, они наверняка махнут рукой и скажут: «А, окей», кому-то зарплату не заплатят, еще что-нибудь такое. Идеалисты там в Igalia работают, я пообщался с некоторыми людьми оттуда, они, конечно, прямо опенсорсеры, линуксоиды, все такие открытые и… В общем, хиппи 21-го века. Удивительный проект. У них там плоская структура, все получат одинаковое количество денег в компании. В общем, такая коммуна практически, удивительно, удивительно. Они помогают доставлять новые фичи в браузер: MathML в Chromium, accessibility фичи, WebKit и так далее. Классно.</p> <h2>Новинки Npm 7</h2> <ul> <li><a href="https://github.blog/2020-10-13-presenting-v7-0-0-of-the-npm-cli/">Presenting v7.0.0 of the npm CLI</a></li> </ul> <p><strong>Никита Дубко:</strong> Тут это, npm 7 вышел, и он вроде как вкусный, да? Можно так говорить про инструменты, «вкусный»? Я слышал, что некоторые бесятся.</p> <p><strong>Вадим Макеев:</strong> Я пропущу вопрос.</p> <p><strong>Никита Дубко:</strong> Ладно. В общем, npm 7, что в нем появилось? На самом деле, кажется, у них такой анонс, он такой коротенький, но со ссылочками, они хитро сделали, они сделали такой, вроде быстренько, а когда проваливаешься в explainer, и ты такой — о-о, какая тут глубина.</p> <p><strong>Вадим Макеев:</strong> Это вам не релиз Webpack, но об этом еще поговорим.</p> <p><strong>Никита Дубко:</strong> Это правда. Так вот, они сделали три по факту фичи, и эти фичи, они такие, каждая заслуживает отдельного эксплейнера, что они и сделали. Первое — это то, чего, наверное, прям ждали, это клево, это workspace, это возможность тебе взять и объединить, действительно, под какое-то рабочее окружение объединить, условно, папочку или по маске как-то выделить. Ты можешь действительно какой-то уровень этого огромного развесистого дерева выделить в отдельное рабочее окружение, и там по-своему крутить чего хотеть, package lock свой настраивать и это все.</p> <p>Почему это действительно сейчас такая штука актуальная? Потому что есть спрос на монорепозитории, и, причем, он растет, в том числе, и в больших, и в малых компаниях, и те же самые всякие open source проекты потихоньку на это переходят. Когда у тебя есть монорепозиторий, там действительно есть проблема это все разруливать, зависимости внутри, внутренние сборки, когда у тебя кусок монорепозитория является зависимостью второго куска монорепозитория. Это все — это огромная боль. Есть, конечно, специальные инструменты для этого, кто-то пишет свои костыли, кто-то лёрну, лерну, я ее «лёрна» называю почему-то, не знаю, кто-то ее эксплуатирует.</p> <p><strong>Антон Кастрицкий:</strong> Приведем еще пару примеров, чтобы, возможно, кому-то было это более очевидно. Например, если пойти на GitHub и, например, зайти на тот же самый Babel, можно заметить, что у них есть папочка packages, внутри которого есть очень много отдельных пакетов, и это собственно и представляет собой монорепозиторий, в котором уже хранится большое количество npm-пакетов. Так исторически сложилось, что npm этой фичей не владел, и сообщество стало пилить свои инструменты для того, чтобы как-то разруливать подобные ситуации. Есть Lerna, которую изначально делал Джейми Кайл, потом он также сделал Bolt, что уже больше относят к проджект-менеджменту, но, тем не менее. Я могу ошибаться, но, по-моему, в какой-то момент даже yarn начал поддерживать workspace, этой фичей я не пользовался, поэтому тут я прокомментировать не могу.</p> <p><strong>Вадим Макеев:</strong> Получается, что workspace делают Lerna ненужной, или дополняют, или как?</p> <p><strong>Антон Кастрицкий:</strong> Кажется, что от Lerna можно будет отказаться. Но я еще не игрался с этой фичей, но мне очень интересно.</p> <p><strong>Никита Дубко:</strong> Кажется, еще пока нет, потому что это только началось, и так сходу все это переписать… Плюс, у Lerna есть еще кое-какие особенности и свои… В общем, проект не просто так создавался. Но действительно, спрос есть, у yarn действительно есть работа с workspace, это мы как раз обсуждали в одном из выпусков, и это такая фича, которая тогда… «О, классно, надо на yarn переходить». А вот не надо, npm тоже теперь так умеет. Я помню, мы обсуждали, чем ответит npm, чем ответит node, это все. Ответили, пожалуйста.</p> <p><strong>Антон Кастрицкий:</strong> Самое смешное то, что здесь еще третьим пунктом есть еще одна причина, почему можно больше не переходить на yarn.</p> <p><strong>Никита Дубко:</strong> Именно, это поддержка yarn.lock. Если вы живете на два мира… Я просто видел даже репозитории, где для того, чтобы и тем, и тем пользоваться, люди синхронизирует yarn.lock и package-lock.json этот вот. Это может быть полезно как раз таки, когда ты хочешь фичи из обоих миров использовать. Но синхронизировать это все — это тоже отдельная боль. Теперь не надо, теперь… Если yarn изначально делался так, что он в принципе может работать с package.json, как, он с ним работает, но создает свое какое-то такое дополнительное описание, чего ему там нужно, в этом yarn.lock, теперь npm тоже умеет смотреть в yarn.lock, и тут непонятно, это такая интересная конкуренция, минивойна, не знаю, за аудиторию. Но вы теперь можете при помощи npm работать с теми репозиториями, в которых вы работали раньше yarn. Не знаю, как на это реагировать, но, скорее всего, этого позитивная новость в плане того, что действительно стала совместимость, то есть те фичи, которые были в yarn, видимо, npm теперь их понимает, он умеет парсить и у себя тоже их обрабатывать. Кажется, оба инструмента в итоге выиграли от этого.</p> <p><strong>Вадим Макеев:</strong> Круто, а вторая фича? Я периодически сталкивался… Я не профессиональный пользователь npm, я бы так сказал, то есть я всячески, много его используют для разных задач, понятное дело, но прям чего-то сложного и тем более монорепозиториев в руках держать и поиспользовать, настраивать не приходилось. Я помню, что какое-то время для меня периодически болью становятся эти peer dependencies, которые нужно как-то отдельно ставить, управлять и вообще врубаться, что случилось с моим репозиторием, почему ничего не работает. Кажется, проблема сейчас решается, и я правильно понял эту новую фичу?</p> <p><strong>Антон Кастрицкий:</strong> Да, про фичу заключается в том, что теперь автоматически будут стамбливаться пир-зависимости. Как многие знают, в npm в package.json есть четыре зависимости, это dependencies, dev dependencies, peer dependencies, и есть еще optional dependencies, которыми по моим ощущениям вообще никто не пользуется. Первые будут всегда устанавливаться, обычные dependencies, вторые будут устанавливаться только когда вы прогоняете npm install внутри вашего пакета, то есть если ваш пакет кто-то устанавливает, вместе с ним приедут только его основные dependencies, и peer dependencies — это пакеты, которые должны будут предоставить потребители вашего пакета. Давайте приведем пример. Я написал какую-то библиотеку для React, для потребителей, которые живут в экосистеме React, и я не хочу в своей библиотеке хардкодить версию React, потому что к потребителям тогда приедет две версии React, и вместе с ними разруливать это не очень весело. Я указываю React в peer dependencies, и люди, которые будут уже пользоваться моим пакетом, должны будут убедиться, что внутри их пакета у них в зависимостях есть React, и он будет использоваться. Но в целом так сложилось, что такие общие пакеты должны жить в пирах, но эти пиры, peer dependencies, они автоматом не устанавливаются, поэтому в большинстве таких пакетов, когда вы пытаетесь первый раз их развернуть, можно ставить такой скрипт, как npm rank bootstrap, внутри которого устанавливаются эти пиры и еще несколько полезных утилит. Если когда-то вы пытались развернуть чужой проект, и спотыкались о то, что, блин, здесь же есть еще какой-то скрипт, который нужно прогнать для того, чтобы можно было начать развернуть примеры уже в нем, покопаться и исправить это багу, скорее всего, это было именно это. Я очень рад, что эту вещь наконец-то решили.</p> <p><strong>Вадим Макеев:</strong> Это было решение, которое не сработало, именно такой механизм работы с пирами, и теперь они его немножко меняют для того, чтобы проблем было меньше, скриптов, и не нужно было костыли писать.</p> <p><strong>Антон Кастрицкий:</strong> Именно так, да.</p> <p><strong>Вадим Макеев:</strong> Хороший набор изменений, когда я смогу начать их использовать?</p> <p><strong>Антон Кастрицкий:</strong> Как я понял, эта штука уже включена в 15-ю Node, но обновиться на нее можно и находясь на 14-й или более ранних версиях.</p> <p><strong>Вадим Макеев:</strong> Вопрос, грубо говоря, я сейчас сижу, условно, у меня 14-я Node стоит, и я захочу использовать фичи npm 7, я просто обновляю свой npm, и у меня все работает или нет? Я видел, люди постили скриншоты, потому что у них далеко не все работает.</p> <p><strong>Антон Кастрицкий:</strong> Так происходит всегда, когда пытаешься жить на gliding edge, то есть нужно быть готовым стать первопроходцем. Мне кажется, в этом нет ничего страшного, если вдруг есть опасения, то можно немножко подождать до 16-й Node, поскольку 15-я — это не… Как сказать? Я боюсь использовать слово «стабильный релиз», это не «стабильный», есть какое-то другое слово, я надеюсь, вы поняли, что я имею в виду. Это не тот релиз, который уйдет в LTS, то есть в поддержку на долгое время, поэтому за время существования 15-й Node его полноценно обкатают, и уже к 16-й, я думаю, можно будет спокойно считать это production ready решением.</p> <p><strong>Вадим Макеев:</strong> Я для себя это называю так. 15-я Node –это следующая версия, а 16-я Node — это следующий релиз.</p> <p><strong>Никита Дубко:</strong> На самом деле, у них же написано в документации, что по умолчанию тебе нужно четенько указать, вместе с latest у тебя npm не приедет 7-й, у тебя будет приезжать предыдущая все еще версия, а если ты ставишь себе 15-ю, тогда приедет уже 7-й. это они, видимо, тоже понимают, что там есть какие-то нюансы, и четко про это даже предупреждают в релизе.</p> <p><strong>Антон Кастрицкий:</strong> Нет, на самом деле, я думаю, можно ведь, грубо говоря, если какой-то команде страшно нужно жить на 14-й Node, потому что с 15-й пакеты несовместимы, например, но хочется использовать фичи 7-го npm, можно же как-то разрулить на уровне конфигов, на уровне package.json версия npm прописывается. Хотя, будет ли она автоматически переключаться? Тоже вряд ли. NVM, по-моему, не умеет переключать версию npm, он только версию Node умеет переключать, да?</p> <p><strong>Вадим Макеев:</strong> Просто интересно, что обычно же в package.json не указывается npm как зависимость и версия npm как зависимость.</p> <p><strong>Антон Кастрицкий:</strong> В package.json можно указать vengeance-версию Node или range этих версий.</p> <p><strong>Вадим Макеев:</strong> Да.</p> <p><strong>Антон Кастрицкий:</strong> А про npm, мне кажется, там тоже есть поле для npm, но я им ни разу не пользовался.</p> <p><strong>Никита Дубко:</strong> Мне казалось, там же vengeance пишется прям, то есть там же.</p> <p><strong>Вадим Макеев:</strong> Круто, потому что иногда бывает, что нужно Node постарее, npm поновее. Надо разобраться, действительно, если кто-то хочет с воркспейсами начать работать именно в npm, кажется, вариант.</p> <p><strong>Антон Кастрицкий:</strong> Тут есть еще один пункт, про который я хочу сказать пару слов. Тут ребята помечают то, что они не то, чтобы помечают npx как деприкейтнутую версию, но они его полностью переписали, чтобы он работал поверх npm-exec команды, и он теперь будет кидать ворнинг, если вы пытаетесь прогнать какой-то пакет, который не был установлен. Раньше, до того, как у нас был npx, мы писали путь node_modules/.bin и команду, которую мы хотим выполнить, а теперь мы уже можем просто запускать его как npx-команда. Но у этой штуки также была дополнительная фича, то, что мы могли с ее помощью прогонять команды, которые вообще не были установлены ни в рамках нашего проекта, ни на нашей операционной системе, вообще. Если у вас не установлен JS, но вы находитесь в проекте, в котором написаны JS-тесты, вы можете сделать npx jest, и у вас начнут прогоняться ваши тесты, то есть он скачает этот пакет, локально его установит ради этого одного прогона, и затем быстренько спрячет куда-нибудь в кэше обратно. Я не очень понял пока, как они будут разруливать такие моменты, но это что-то, с чем нужно поиграться. Звучит интересно.</p> <p><strong>Вадим Макеев:</strong> Я слышал, что там есть большая проблема с безопасностью, потому что любая фигня, ты опечатался, ты написал не jst, а jsst, и там какой-то левый пакет с npm тебе тут же скачался и исполнился. Это, конечно, так, нервно немножко. В общем, npm, дивный новый мир, что-то нам такое новое несет, если у вас есть причины прям бежать и включать себе, разберитесь, как, чтобы у вас все остальное не поломалось тоже.</p> <h2>React vs WordPress</h2> <ul> <li><a href="https://hankchizljaw.com/wrote/the-(extremely)-loud-minority/">The (extremely) loud minority</a></li> </ul> <p><strong>Вадим Макеев:</strong> Я перестал считать Энди Белла, хотя он мне симпатичен, но перестал. Он такой немножко… Он немножко интернет-тролль, он любит шитпостить в Твиттере, факт, неоспоримый факт, я думаю, он не обидится, если вдруг ему кто-нибудь переведет. Просто удалось встретиться в прошлом году на фронтенд-конфе в Москве, пообщаться, он смешной чувак. Есть с ним отдельная запись «Веб-стандартов», так что послушайте, если интересно.</p> <p>Он написал пост про ужасно громкое меньшинство, и ужасно громким меньшинством он называет JS-разработчиков, точнее, не совсем JS-разработчиков, а разработчиков, которые пишут на каком-нибудь single page стейке. В чем проблема? А проблема в том, что когда вы идете в Твиттер, вы слышите: каскад — это плохо, CSS уже не работает для веба, HTML — это глупый язык, давайте что-нибудь переизобретем, переделаем, еще что-то такое. И вы думаете — в Твиттере ерунды не скажут. Нет, даже по-другому, вы слышите эту реплику один раз, второй раз, третий раз, четвертый, пятый раз и думаете — блин, все так говорят, все так думают. Ты идешь с друзьями пообщаться о чем-нибудь таком, и плюс-минус фронтендерские темы всплывают, и ты понимаешь, что все мои друзья пишут на React, все мои друзья пишут на MacBook, все мои друзья, не знаю, у всех в кармане дорогой телефон, все-все-все… И ты понимаешь, что весь мир, ты экстраполируешь свой ближайший круг, естественно, на весь мир, на весь город, на всю страну, и в конечном счете на все фронтендерское сообщество, и думаешь — ну, все же так делают, все, кого я знаю, пишут на Single Page, все, кого я знаю, не любят cascade CSS и так далее.</p> <p>А если посмотреть на статистику, получается совсем другое. У статистики, естественно, есть свои проблемы, и Энди Белл пытается нащупать вообще, а кому это не нравится, тем, кто громче кричит, тем кто пишет 1% веба, как он посчитал, тем не нравится современный веб, те хотят все переизобрести и писать на условных Single Page. Получается очень такая неловкая ситуация, в которой люди, которые громче всего говорят, убеждают нас в том, что они правы, и мы начинаем на основе этого принимать собственные решения и выставлять собственные приоритеты. Как вам такой вброс, ребят?</p> <p><strong>Никита Дубко:</strong> Забавно, но, кстати я хочу Энди назвать как раз таки таким громким человеком, потому что у этой статистики есть один подвох — все сайты в интернете, это не значит, что это все активные сайты, которые прямо сейчас разрабатываются, это сайты, которые, черт побери, с 1993 года существуют, WordPress позже появился. Их много, и их много тех, которые работают просто… как они, летят, потому что когда-то их сделали более-менее стабильными, и они работают. Там не нужен React, все отлично работает.</p> <p>Есть современные требования у разработчиков, есть необходимость, бизнес-необходимость делать быстро, делать хорошо, делать качественно за счет переиспользования компонентов.</p> <p>Здесь, скорее, мне кажется, это extremely loud minority — это спикеры, которые ездят по конференциям, а не люди, которые любят рассказывать про хорошие практики, и про Vanilla, и все такое. Чего уж тут, я сам такой, не знаю, в этом чатике есть еще такие люди. Это люди, которые рассказывают best practices, но по факту, чтобы делать это широко, они рассказывают это про такие технологии как Cube CSS, который придумал Энди. Скорее всего, у меня подозрение, что его бомбит из-за того, что на этот Cube CSS точно прибежали люди, которые… «Да что вы там в своем CSS постоянно придумываете, как изолировать ваши стили? Столько лет прошло, а вы все придумываете и придумываете. Вот, смотрите, в React, и вот тебе два пакета, которые решают одну проблему, три пакета — четвертую проблему». Это все… Да, оно как-то разделяет сообщество, потому что есть люди, которые: «Я хочу быстро и в принципе неплохо», а есть люди которые: «Я хочу разбираться в вебе, и ваш React не вечен, он когда-нибудь закончится». Очень сложно объективно эту статью комментировать, потому что, да, есть статистика, но мне кажется, если разбить ее по годам, и если еще MDN этот опрос проанализировать… Статистика The State of JS как раз таки говорит о том, что React популярен.</p> <p><strong>Вадим Макеев:</strong> Но проблема в том, что те, кто прошел опрос, они уже крутятся в сообществе, они уже трендовые, они уже интересуются технологиями, и тут, естественно, есть перекос в сторону… Как сказать? То, что какой-нибудь The State of JS — 98% мужчин и 2% женщин, это не говорит о том, что такова система, что таково соотношение, допустим, полов внутри разработки, нет. Просто прикол в том, что именно активная часть сообщества, те, кто хотят рассказать, поинтересоваться или, не знаю, высказать свое мнение погромче, там такой перекос. Я просто что в случае с Энди, что в случае со The State of JS не вижу нормальной репрезентативной картины. Но Энди дает повод усомниться, Энди дает повод посмотреть по-другому на эту картину. Мне именно этим его вброс нравится, он по-прежнему немножко тролльский, он по-прежнему некорректный во многих смыслах, но он говорит: «Ребята, посмотрите чуть-чуть шире, чем ваш ближайший круг, посмотрите на то, чем занимаются люди». Опять же, в наш чатик «Веб-стандартов» в Telegram периодически приходят люди и говорят: «Я не могу использовать эти технологии, потому что у меня такая браузерная совместимость». А другие говорят: «А у меня на проекте, я пришел на проект, новый, клевый, а там jQuery». Или «я пришел на проект, а там такая-то CMS». Какой там React, туда даже Vue не воткнуть адекватно, если уж хочется чего-то подобного. А проекты живут, работают, приносят деньги, я не знаю, все интерфейсы, все сайты «Академии» не переписаны на React, потому что мы можем. К нас только, не знаю, чаты, дээмки и какие-то еще прямо совсем интерактивные интерфейсы, которые прям совсем веб-приложения стопроцентном смысле, они написаны на React, все остальное… Да нет, работает и без этого всего развесистого. Не потому, что это новый дефолт, а потому что это решает для нас какие-то конкретные задачи, и мы живем с этим прекрасно. Для всех остальных задач они и не нужны.</p> <p><strong>Антон Кастрицкий:</strong> Примерно года три своей карьеры потратил именно на работу с WordPress. Мне кажется, я тут могу поделиться. А именно, у меня сложилось такое впечатление, что в этом островке индустрии… Я полностью вообще согласен с автором, что это уже не minority, это очень большое количество людей, но при этом я также согласен с Никитой про то, что это сайты, которые могли сделать 10 лет назад, они все еще работают. Ну и что, что на них заходит два человека в год? Это же сайт, его может точно так же сравнить, например, с Яндекс.Маркетом, в котором я работаю, куда заходит значительно больше людей. Это совсем не громкие люди, это не те, кто будут ходить по митапам и рассказывать: «Ой, представляете, я такой плагин себе установил». Большинство, с кем я сталкивался, кто работал или до сих пор работает в этой индустрии, это люди кто может вообще даже не думать, что значит система сборки в проекте.</p> <p>Я написал, и оно уже все, по ftp залилось, и работает. Я ни в коем случае не пытаюсь как-то принизить эту часть индустрии. Я встречал большое количество людей, кто, имея по пять лет опыта, совсем не пользуется системами контроля версий, использует какие-то внутренние тулзы этой WordPress-индустрии, который за вас просто раз в день будет делать бэкапик, и вы сами в любой момент можете откатиться.</p> <p>Мне кажется, это две такие довольно разные парадигмы. В целом это, наверное, нормально, то, что кто-то из них громкие, потому что они тусуются в Твиттере, и Твиттер сам располагает к тому, чтобы быть более вызывающим, оттащить людей на диалог.</p> <p><strong>Вадим Макеев:</strong> Это проклятие современных соцсетей, они, пытаясь доставить тебе интересный для тебя контент, в итоге изолируют тебя в таком ecochamber, ты слышишь то, что ты хочешь слышать.</p> <p><strong>Антон Кастрицкий:</strong> Bubble.</p> <p><strong>Вадим Макеев:</strong> Да, да, да.</p> <h2>Уже Webpack 5</h2> <ul> <li><a href="https://webpack.js.org/blog/2020-10-10-webpack-5-release/">Webpack 5 release</a></li> </ul> <p><strong>Никита Дубко:</strong> Тут релизы короче за релизами. Webpack 5. Представляете? У меня так такая же реакция была, как в чатике «Веб-стандартов», типа, мы тут на 4-й переехать не успели, остановитесь, какой 5-й, что происходит, мы еще на втором сидим, как так-то? А вот, все, раньше надо было… Вебпяка, мне понравилось слово, простите. Webpack 5, короче, зарелизился, и этот тот случай, когда релиз-ноуты очень подробны, и это даже, наверное, в минус, потому что я очень долго читал, чего они сделали, и пока дочитал, забыл что они делали в начале.</p> <p>Но если коротко, у них там есть как и breaking changes, так и по большей части оптимизация производительности, то, что я увидел. Они покопали в сторону, во-первых, tree shaking, который все развивается и развивается, и прямо уже как стандарт уже, что ли, во всех этих сборочках, без него никуда. Улучшили всякие алгоритмы, начали использовать более крутые для кодогенерации. В общем-то, да, все идет к тому, что работают про перформанс, то есть это перформанс самой сборки, они его тоже подтюнили нормально, то есть ваша сборка будет не пять минут, а четыре минуты, вы сможете заварить меньше кофе. Tree shaking — это меньше на клиент приходит ненужного, как раз они очень много расписали, каким образом это все ненужное убирается, то есть это, в том числе, поддержка того, что уже можно не поддерживать. Они выпилили No JS полифилы, где эти No JS полифилы, например, не нужны. Они сейчас взяли ориентирование на клиент. А дело в том, что, я думаю, те, кто работает с Webpack, понимают, что можно как и на клиент, так и на сервер это все, это просто инструмент, который одни файлики в другие превращает, а где вы их запускаете, это уже ваши трудности. Но у них ориентирование теперь идет на фронтенд, на веб-платформу, то есть больше поддержка реалий, я бы так сказал, есть браузеры, в браузерах уже, например, работают динамические импорты больше, чем раньше, значит, можно с этим поиграться. Можно этот самый tree shaking как-то так сделать хитро, чтобы еще меньше приходило на клиент ненужного, можно прямо на ходу какие-то вещи анализировать, что нужно прямо сейчас, что не нужно. Опять же, есть фреймворки, популярные сейчас у фронтенд фреймворкм, например, React, и можно сделать какие-то штуки, которые именно под этот React заточены, потому что есть спрос.</p> <p>В общем, я не знаю, через весь этот список продраться — это прям сложно. Антон, я понимаю, что ты в Webpack ковырялся. Что ты можешь выделить здесь такого прям сочного?</p> <p><strong>Антон Кастрицкий:</strong> Мои, пожалуй, три самые любимые, и они в начале этого списка, поэтому мне легко их вынести, первое — это изменение, как ребята начали работать с кэшами, это такая небольшая боль моя, в том числе, была, что очень влияло на скорость сборки, что особенно критично в момент самой работы над проектом. То, что у ребят появился long term cashing, это также ранее анонсировалось как улучшенный persistent cache, то есть что-то, ради чего вы раньше могли использовать AutoDllPlugin, HardSourcePlugin, то есть что-то, что в момент сборки кэшировало все, что у вас едет в ваши бандлы из node_modules, чтобы повторно не обрабатывать эти файлы. Теперь это уже должно работать из коробки, то есть вы сможете выкинуть эти самые плагины, оно у вас должно работать автоматом уже, гораздо быстрее.</p> <p>Также ребята выкинули очень много всего, что было в четвертом Webpack, то есть если вдруг вы сейчас живете с 4 Webpack, и у вас есть какие-то в консоли вординги, есть деприкейтнутые штуки, скорее всего, вам нужно будет сначала пофиксить их до того, как обновляться.</p> <p>Последняя и самая большая фича, которая прям, мне кажется, киллер-фича вообще этой версии, это мой modules federation, это что-то, что может позволить вам в рамках своего проекта начать обращаться к чужому чанку, который был сделан из чужой сборки, то есть переиспользовать какие-то виджеты между сборками с разными проектами. Такая фича, с которой нам пришлось поиграться внутри партнерских интерфейсов, они у нас не единственные из В2В-кабинетов в Яндекс.Маркете, но у нас была необходимость показывать переиспользуемые виджеты между несколькими кабинетами.</p> <p>Для этого мы пробовали тыкаться еще в пятую альфу, нам понравилось, то есть все работает. Я ранее уже сегодня приводил пример с React, то есть если у вас две версии React на одной странице, не всегда их можно подружить между собой, можно наступить на разные костылики. Мне самому очень нравится эта фича. Мне кажется, у нее есть очень большой потенциал, который еще совсем не раскрыт. Тут же можно докинуть несколько базвордов, как микрофронтенды и подобное.</p> <p><strong>Вадим Макеев:</strong> Слушай, а можешь еще раз объяснить про этот федерейшн?</p> <p><strong>Антон Кастрицкий:</strong> Давай представим, что ты сидишь в одной команде, я не знаю, вообще в другом здании, работаешь над своим продуктом, я в другом офисе работаю над своим продуктом, и внезапно я понимаю, что мне нужен этот кусочек, один конкретный кусочек твоего приложения отрисовать на своей странице, чтобы он умел ходить в твои эндпойнты. Я могу только лишь сославшись на него, вообще не зная про то, как собралось, когда последний раз собиралось твое приложение, загрузить его на свою страницу, он уже будет использовать мою версию React, которая у меня используется, и он правильно отрисуется, и может быть, будет какая-то формочка, человек может ее засабмитить. Он, как сказать, окажется first class citizen внутри моей страницы.</p> <p><strong>Вадим Макеев:</strong> А это требует каких-то дополнительных телодвижений от разработчика, подготовить все к этому, или оно все само?</p> <p><strong>Антон Кастрицкий:</strong> Оно все не само, определенно, документацию придется почитать. Но мне кажется, это того стоит. Я почти уверен, что за ближайший год выйдет отнюдь не одна статья про то, как правильно это готовить, что значительно понизит порог входа, и это будет здорово.</p> <p><strong>Вадим Макеев:</strong> У нас кто-то в соцсетях сказал, что главная фича — это modules federation, но никто не попытался объяснить, почему это важно и почему это хорошо. Сейчас я услышал эту версию. Она звучит интересно, но опять же, фича, кажется, узкая, в смысле, она нужна, когда у тебя что-то совсем уж развесистое, но она звучит очень ценно для такой ситуации, конечно.</p> <p><strong>Антон Кастрицкий:</strong> В целом, пока мы находимся на этой странице, про Webpack, я хотел бы еще пару вещей отметить. Никита начал с того, что кто-то еще не успел переехать даже на 4-й. 4-й Webpack вышел уже два с половиной года назад, то етсь это отнюдь не то, что они клепают мажорные версии, первая альфа вышла еще полтора года назад, я помню, я тогда как раз читал свой доклад про Webpack, как настроить энтерпрайз-сборку так, чтобы она не тормозила. Эти полтора года мы ждали этого мажорного релиза, и наконец-то он случился, уже, мне кажется, даже 5.1, с патчами, тоже вышел. Можно начинать играться.</p> <p>Самая последняя основная идея, в целом я не считаю, что Webpack нужен всем. Мне кажется, это довольно сложная штука, которая подходит в тех местах, когда вам действительно нужна эта гибкость сборки. Гораздо чаще и большему количеству людей может подойти тот же Parcel.</p> <p><strong>Никита Дубко:</strong> Я думал, ты скажешь Gulp, и я тебе поаплодирую</p> <p><strong>Вадим Макеев:</strong> А я надеялся, что это Rollup, потому что если вам просто JS собирать.</p> <p><strong>Антон Кастрицкий:</strong> А мне кажется, Rollup все равно нужно уметь настраивать, а Parcel за тебя уже может попробовать увидеть: «О, я у тебя нашел.babelrc, дай-ка я тебе еще Babel сейчас установлю, и кажется, у тебя здесь sas-файлы, ты их импортируешь, я тебе SAS тоже притащу». Он прямо совсем beginner friendly.</p> <p><strong>Вадим Макеев:</strong> Я не люблю слишком магические пакеты. Я просто к тому, что если нужно, допустим, как-то JS пособирать, то Rollup более чем достаточно, а если уж нужно что-то прямо совсем сложное делать… Хотя и для Rollup можно плагинов насобирать, у них в последнее время развивается хорошо. Но я к тому, что есть альтернативы. Да, это не единственный, если вам больно пользоваться Webpack, возможно, вам он не нужен.</p> <h2>Что такое Rome</h2> <ul> <li><a href="https://github.com/romefrontend/rome">Репозиторий Rome</a></li> <li><a href="https://romefrontend.dev">Сайт Rome</a></li> <li><a href="https://twitter.com/AntonK52/status/1300142257497088007">I’ve been looking at the Rode source code…</a></li> </ul> <p><strong>Вадим Макеев:</strong> Антон, ты тут тредик написал, я тебя позвал по его мотивам сюда. Можешь как-то коротко запичить, что это такое, и почему это может стать для кого-то интересным, этот Rome Frontend Toolchain?</p> <p><strong>Антон Кастрицкий:</strong> Rome собой представляет такой очень большой инструмент, в котором есть очень много всего. Бо́льшая часть этого уже работает с собственными внутренностями, наружу торчит только линтер, если мы говорим про сегодня, но в обозримом будущем у него есть очень такие большие планы, он хочет захватить весь мир, а именно, он хочет собой, одним только собой, Rome, заменить и Babel, и ESLint, и Webpack, и Prettier и Jest, много-много всего другого. Та же Lerna, про которую мы ранее говорили, у них есть и на это планы.</p> <p>Я могу больше рассказать про то, как он работает изнутри, почему меня он так сильно заинтересовал. Мне кажется, нужно обязательно рассказать про самого автора, поскольку он был написан очень известным человеком, Себастьяном Маккензи, это автор Babel, он долгое время работал в Facebook, в инфре он также приложил руку над самим yarn, про который мы тоже уже сегодня говорили.</p> <p>Тут можно сделать такой gist, это не кто-то, кто только что пришел, а кто-то, у кого уже есть большая экспертиза в таких инструментах, которые должны будут работать на комьюнити очень разносторонние.</p> <p><strong>Вадим Макеев:</strong> И большая экспертиза в open source, потому что мало написать код, нужно и заставить его не просто понравится всем остальным, а еще и чтобы люди приходили, помогали, развивали и заинтересовывались. Я гляжу на проект Rome на GitHub, и там уже open governance, там уже и сайт, и логотип, и одно, другое, третье, это, по-моему, все достаточно рано появилось. Он с самого начала появился не просто как проект выходного дня, а как как проект с заявкой на что-то большое. Судя по тем целям, которые ты описал, амбиции у него не фиговые, и для этих амбиции у него соответствующий фундамент уже есть.</p> <p><strong>Антон Кастрицкий:</strong> Я думаю, тут даже можно рассказать немножко про историю. Те, кто подписан на Себастьяна в Твиттере, последние несколько лет могли наблюдать, он любил тизить разработчиков разными скриншотами о фичах, которые будут использованы в Rome, как это выглядит, как это удобно, как это здорово и просто даже задумавшийся о контрасте, как сегодня работает ESLint, как сегодня работает Babel или какие-то схожие инструменты, уже, не знаю, чесались руки, блин, когда же это можно будет потрогать уже, очень-очень хочется.</p> <p>Примерно полгода назад Rome вышел полностью в open source, то есть раньше он разрабатывался исключительно под нужды Facebook, потому что Себастьян-то работал в Facebook, сейчас он уже там не работает, он ушел в Discord вместе с еще несколькими очень известными людьми, и также внутри самого Rome произошло несколько интересных изменений. Он внезапно был переписан с Flow на TypeScript.</p> <p><strong>Вадим Макеев:</strong> Видимо, если ты работаешь ли уже не в Facebook, то нет смысла писать на Flow, да?</p> <p><strong>Антон Кастрицкий:</strong> Да. На сегодняшний день TypeScript определенно победил со своим комьюнити. Вместе с этим также появился открытый вебсайт, на котором превосходная документация, мне очень нравится правильный фундамент, который был вложен в Rome. Ребята отлично расписали, какие у них есть цели, как они хотят их добиваться, что они делают в первую очередь, чем они будут заниматься далее. Об этом мы тоже уже поговорим. В Rome уже внутри есть и свой линтер, чем они сам Rome и винтят, это что-то, чем вы уже можете пользоваться сегодня. Последняя версия, которая доступна в npm, она сейчас вам позволит это сделать только с помощью табов, но следующая версия, которую опубликуют, там уже будут пробелы.</p> <p>В целом, Rome, его можно назвать такой, как opinionated tool, он очень хочет за вас сразу предоставить все дефолтные настройки, и в каком-то плане он очень похож на Prettier в том плане, что очень мало чего вам получится настроить, по крайней мере, сегодня. Как мне кажется, это большой плюс. Rome также уже умеет парсить, у него есть разные парсеры, не только для JavaScript, для TypeScript, Markdown, TOML, PCSS…</p> <p><strong>Вадим Макеев:</strong> HTML даже. Я тут читаю issue, тут написано 8 августа: «Я внедрил довольно ужасный HTML Parcer, который не то, что несовместим со спекой, даже близко несовместим, но мы будем его потихонечку итерировать на основе этого».</p> <p><strong>Антон Кастрицкий:</strong> Эти вещи еще не торчат наружу, то есть они могут использоваться внутри для генерации документации, поэтому не стоит пугаться. Также, мне кажется, можно сказать, что если вы будете слушать этот подкаст, как он выйдет, а сегодня у нас октябрь 2020 года, и если вы откроете GitHub и увидите, что последние пару месяцев очень мало чего произошло в Rome, то не пугайтесь, пожалуйста. Себастьян переезжал, и поэтому у него меньше времени хватало на Rome, но помимо GitHub, кстати, есть сервер в Discord, где тоже ребята общаются, бывает, я там могу задавать какие-то вопросы. Не знаю, мне кажется, у меня приняли на сегодняшний день, может, всего парочку pull requests туда, но у меня есть еще идеи, что там можно исправить и сделать лучше, о чем мы еще поговорим.</p> <p>Могу рассказать про несколько вещей, которые меня, например, удивили. Rome написал свой собственный компилятор для того же TypeScript, сам Rome полностью написан на TypeScript. Давай еще сделаем шаг назад, в первую очередь, у Rome нет никаких зависимостей. Если ты откроешь GitHub, откроешь их package.json, посмотришь на dependencies, они будут пустые, а сверху будет комментарий о том, «смотри, как круто, можешь так же?»</p> <p><strong>Вадим Макеев:</strong> Это какой-то спорт, или в этом есть ценность?</p> <p><strong>Антон Кастрицкий:</strong> Мне кажется, в этом есть ценность, поскольку ты можешь полностью управлять всем, что ты используешь.</p> <p><strong>Никита Дубко:</strong> Как сейчас Вадим на спортсменов-то набросил.</p> <p><strong>Вадим Макеев:</strong> В смысле, спорт ради того, чтобы показать, что ты можешь, в этом смысле.</p> <p><strong>Антон Кастрицкий:</strong> Мне кажется, это не странный флекс, а именно нарочно принятое решение, когда ты можешь полностью управлять всеми движущимися частями, на которых ты стоишь, ты можешь стоять с гораздо большей уверенностью.</p> <p><strong>Вадим Макеев:</strong> Если сможешь встать, потому что тебе нужно сначала написать весь скелет, все мышцы и всю обвязку.</p> <p><strong>Антон Кастрицкий:</strong> Да, то есть тут уже у нас, конечно, получится эта знаменитая проблема про бананы, гориллу и джунгли. Но, по моим ощущениям, у Rome это уже получилось, и бо́льшая часть джунглей уже выросла.</p> <p><strong>Никита Дубко:</strong> Можно, я все-таки понабрасываю? Ты сказал, что большой плюс — это то, что он все делает сам из коробки. Меня корежит это все. Мы в свое время тут с Вадимом холиварили про Prettier, и в целом мне Prettier норм, но при этом я четко понимаю, что для каких-то проектов Prettier абсолютно не подходит, потому что, условно, тебе нужно в команде по-другому немножко, у вас есть какие-то особенности, проект большой, проект с legacy, еще что-то, и его ты не можешь взять его, на него натянуть это свежее, клевое. Я так понимаю, что Rome, он для старта каких-то проектов, наверное, норм. Но ведь новый проект — это не такая частая история. Не знаю, убеди меня, пожалуйста, почему это хорошо, и почему все говорят, что это клево, когда всего за тебя решают.</p> <p><strong>Антон Кастрицкий:</strong> Хорошо, давай, тут есть два пункта. Первое, я не считаю, что Rome сегодня production ready, и тебе нужно завтра уже бежать переписывать и выкидывать весь свой…</p> <p><strong>Вадим Макеев:</strong> Нет, подожди завтра мы перепишем все на Webpack, послезавтра мы перепишем на Rome.</p> <p><strong>Антон Кастрицкий:</strong> Черт побери, ты прав. А второй пункт — это про Prettier, если ты помнишь, когда он впервые вышел, у него вообще не было никаких опций, и эти опции долго спорами, с кровью и потом доказывались, что «ребята, пока не появится такой опции, мы совсем никак не можем его использовать», и только после того, как там, не знаю, десятки, если не сотни людей отписали то, что «нам очень нравится этот инструмент, пожалуйста, пожалуйста, добавьте этот флажок, чтобы мы могли стащить его себе». Таким же подходом, мне кажется, будет все работать и с Rome. Сегодня и в Discord, и в issues ребята жаловались, что «как же так, у вас только пабы, и все, как мне жить? Я пробелы люблю, да еще и не 2, а 4». И было принято решение — да, хорошо, давайте поддержим такую штуку. Кстати, для такого рода настроек не нужно будет лезть в сам файл Rome, он при инициализации добавит вам EditorConfig, который уже очень распространен в индустрии, мне кажется, это стандарт, который используется не только в фронтенде, но и в других сферах.</p> <p>А основная фича того, что Rome все делает сам, это отнюдь не про линтинг, как мне кажется, а, скорее, про то, как эти разные инструменты, то есть и компилятор, и бандлер, и линтер, и test runner могут взаимодействовать.</p> <p>А расскажи мне, пожалуйста, какие проблемы у тебя были, Никита, с Prettier, чтобы я мог еще немножко раскрыть эту тему.</p> <p><strong>Никита Дубко:</strong> Нет, давай ты лучше у Вадима спроси, у меня как раз таки с Prettier… Мы с ним подружились в итоге.</p> <p><strong>Вадим Макеев:</strong> Я могу рассказать про свои проблемы с Prettier. Я хочу, чтобы вся эта связка — линтинг, тестирование, автофикс, еще и плагины мои в моем редакторе были, во-первых, адекватно интегрированы, а во-вторых, чтобы я мог себе накидать EditorConfig, чтобы я мог накидать себе какой-нибудь Stylelint какой-нибудь config, .stylelintrc, и чтобы инструмент по умолчанию работал, как он работает, со своими внутренними дефолтами, но как только он увидит в моем окружении конфиги, которые я для себя написал, то он, не задавая вопросов, начинал работать по моим настройками. Это как EditorConfig работает — ты кидаешь его в корень проекта, и редактор не говорит: «У меня здесь другие правила», нет, он просто видит config, говорит: «А, окей, все, меняю свои настройки». Какой-то подобной, во-первых, интеграции нескольких решений — HTML, JS, CSS, линтинг, автофикс и все остальное на основе моих настроек. Чего-то подобного я не видел, и мои попытки настроить в VS Code какую-то интеграцию, чтобы Prettier работал по ESLint-конфигу, они приводили к какой-то катастрофе, мне приходилось сносить все эти плагины, и выключать, и говорить: «Господи, нет, никогда больше». Чего-то подобного не хватает, и, как ты уже, наверное, понял, мне некомфортно в дефолтах Prettier. Для меня это тоже абсолютный стоппер. Если у меня нет возможности настроить, вкинуть свои конфиги, то я не могу пользоваться этим инструментом. Такой вот я старомодный, или такой вот я сам, человек с мнениями. Rome совсем идет по пути Prettier, или все-таки брезжит надежда на то, что конфиги будет уважать?</p> <p><strong>Антон Кастрицкий:</strong> На сегодняшний день это прям совсем Prettier, то есть там есть даже некоторые вещи, которые ты можешь указать в EditorConfig, но они будут успешно проигнорированы Rome, что меня очень смутило, когда я его первый раз попробовал развернуть в одном из своих пет-проджектов. Но, тем не менее, я уверен, что в ближайшие те же полгодика там добавится разных флажков, которые он начнет поддерживать, как я уже говорил, уже есть смердженный pull request от Себастьяна, где поддержались те же самые пробелы, которые… конечно, комьюнити не может договориться о том, что же использовать.</p> <p><strong>Вадим Макеев:</strong> Rome не поддерживал пробелы, только табы?</p> <p><strong>Антон Кастрицкий:</strong> Да.</p> <p><strong>Вадим Макеев:</strong> Вау, я уже люблю Rome. Я был любителем табов, пока не столкнулся с open source, и мне пришлось сломать свои привычки об колено.</p> <p><strong>Антон Кастрицкий:</strong> Мы сейчас не будем об этом спорить, потому что нам тогда еще несколько выпусков придется выпустить.</p> <p><strong>Никита Дубко:</strong> Тогда давай про точку с запятой, надо ее вставить в конце строчки или нет.</p> <p><strong>Вадим Макеев:</strong> Что Rome думает? Ставит?</p> <p><strong>Антон Кастрицкий:</strong> Да. Rome ставит точку с запятой.</p> <p><strong>Никита Дубко:</strong> О, тогда мне тоже Rome нравится.</p> <p><strong>Вадим Макеев:</strong> Все, переписываю все на Rome.</p> <h2>Инструмент будущего</h2> <p><strong>Антон Кастрицкий:</strong> Теперь, я думаю, можно даже попробовать рассказать, как все эти инструменты дружат между собой. Вадим, как ты сказал, подружить тот же Prettier с ESLint, по сути, элементарно, но почему-то этого не происходит. Prettier отвечает за formatting и совсем не отлавливает никакие ошибки, ESLint пытается сесть на, простите, два стула, и как форматировать ваш код с автофиксами, так и находить ошибки, неиспользуемые переменные и тому подобные вещи, что звучит почти идеально, но когда они оказываются вместе, ты добавляешь плагин от Prettier в свой и ESLint config, и он начинает уже использовать и его, но порой какие-то правила начинают коллизить между собой, и становится грустно. Ты начинаешь вспоминать, как правильно игнорить Prettier-правила для ESLint, как игнорить какие-то ESLint-правила, расстраиваешься, закрываешь ноутбук, и это.</p> <p><strong>Вадим Макеев:</strong> Пишешь заявление, и уходишь к чертовой матери из этой профессии, потому что невозможно.</p> <p><strong>Антон Кастрицкий:</strong> С Rome такого быть не может, потому что все эти… На самом деле, один минус, который я сегодня в нем вижу, я понимаю, что это будет пофикшено, но в нем нету флагельной системы, то есть если мне очень нравится линтер, но у меня в компании есть какие-то общие договоренности, которые сегодня зафиксированы парой десятков кастомных ESLint-правил, я не могу то же самое сегодня применить к Rome, что чуть-чуть обидно.</p> <p><strong>Вадим Макеев:</strong> Если тебя послушать, получается, что у них на roadmap есть все.</p> <p><strong>Антон Кастрицкий:</strong> Да. Как я уже говорил, ребята хотят захватить мир, и я искренне верю, что это прям инструмент будущего. Я еще даже не попробовал раскрыть эту тему.</p> <p><strong>Вадим Макеев:</strong> Хорошо, давай теперь про будущее. Что мы выкинем из нашего нынешнего тулчейна, и что заменит Rome. У нас зависимости наши, dev-зависимости, что оттуда исчезнет, и что станет Rome, даже если не сегодня, а, допустим, через несколько лет, когда весь этот roadmap или большая его часть исполнится?</p> <p><strong>Антон Кастрицкий:</strong> Мне искренне хочется верить, что мы сможем полностью забыть про линтинг, то есть мы просто сможем отдать это Rome, и все. Следующими шагами будут компиляторы и бандлеры, поскольку на них уже будут построены остальные части Rome, если я не ошибаюсь, следующее, что должно выйти после линтера, это бандлер, поскольку без него не получится запустить тот же test runner, потому что если сравнить с тем, как работает Jest, который может индивидуально все тесты запускать, Rome сначала их бандлит, а потом уже запускает балком, то есть это не значит, что они все будут синхронно выполняться, они все равно параллелятся, но ему все равно сначала нужно их сбандлить.</p> <p>Почему я считаю, что это можно назвать так громко, как «инструменты будущего»? Мне очень нравится, что ты никогда не столкнешься с такой проблемой, что «ой, а у Rome это линт-правило не работает с этим». Rome очень красиво, когда ты пытаешься линтить, покажет тебе, где ты ошибся, как это починить, «если хочешь, я починю это за тебя», и это приятно.</p> <p><strong>Вадим Макеев:</strong> Там хороший DX, получается или даже UI как таковой, этого, ошибки, он хороший.</p> <p><strong>Вадим Макеев:</strong> Да, при этом эти все инструменты… Сегодня я могу говорить о том, как это устроено с самим Rome, потому что последние пару месяцев по воскресеньям два-три часа я мог в этом поковыряться, и мне было интересно. Поэтому я могу представить то, что вот, наверное, через годик, а может, через полтора примерно такого же DX можно будет ожидать в своем проекте, внедрив туда Rome. О чем я говорю? Если сравнить с тем же с ESLint, Jest плюс Webpack, или вставь сюда любой другой бандлер, есть одна прямо такая фундаментальная разница того, как это устроено.</p> <p>Инструменты, которыми мы пользуемся сейчас, они живут сами по себе, и развиваются довольно-таки отдельно друг от друга. Тот же из ESLint использует свой собственный парсер для JS, если вы пользуетесь Webpack, он использует Acorn, но, скорее всего, вы туда все равно подключите Babel. Есть какие-то такие, как слои работы, которые не дружат между собой, для этих инструментов, не говоря уже о том, что какой-то из них может обновиться, а теперь он будет использовать что-то другое, что будет уже не совсем полностью совместимо с соседним инструментом, с которым… с ним придется работать. Когда я, например, у нас на работе обновлял Webpack с третьей на четвертую версию, я потратил довольно-таки большое количество времени, чтобы подружить все эти плагины между собой, и там были определенного рода дорогие сложности, связанные с этим.</p> <p><strong>Вадим Макеев:</strong> Получается, что каждый из этих инструментов отдельно парсит, отдельно свое дерево создает, отдельно… Кроме того, что это неэффективно, в смысле, они это делают каждый раз заново, они не шарят это это дерево между собой, они еще это делают по-разному, соответственно, могут всякие артефакты вылезать.</p> <p><strong>Антон Кастрицкий:</strong> Да. У меня есть некоторая проблема с тем, что они это делают отдельно друг от друга. Давай представим, что я в своем проекте что-то поделал, внес какие-то изменения, и теперь хочу их закомитить. У нас есть несколько прекомит-хуков, которые проверяют типы, которые проверяют то, что измененные файлы были написаны по нашему стайлгайду, которые проверяют то, что измененные файлы и тесты для них, а также тесты для других файлов, которые могли быть задеты моими измененными, проходят. Довольно-таки стандартный набор. Я нажимаю git commit, и мне нужно подождать какое-то время, скажем, 10 секунд, пока JS задетектит, а что же все-таки поменялось, потому что пока я был в своем редакторе, и изменял эти файлы, на лету я мог видеть ошибки от ESLint и от типов, я уже заранее мог применить автофикс или поправить что-то руками, если это не автофиксится, и все хорошо. А в случае с Jest я… Я очень ленивый человек, я не буду, конечно же, руками прогонять эти юнит-тесты, поэтому я подожду, пока JS сам все это за детектит, прогонит эти юнит-тесты, и скажет мне, что не так. Но эти 10 секунд, которые я буду ждать, пока Jest поймет, «изменились эти файлы, значит, на эти файлы есть здесь юнит-тесты, а также эти файлы еще затрагивают еще с десяток других файлов, на которые есть здесь юнит-тесты, а теперь нам нужно их всех поднять, нам нужно поднять наш пул воркеров для Jest, теперь мы можем распараллелить прогон этих юнит-тестов, давайте их запустим, теперь они гоняются»… Я хочу сделать git commit, и сразу увидеть: «Друг, у тебя здесь есть ошибка».</p> <p><strong>Вадим Макеев:</strong> И как Rome здесь поможет?</p> <p><strong>Антон Кастрицкий:</strong> А вот я хочу рассказать. У него есть фундаментальное отличие, это то, что у него есть свой собственный сервер. Тот пример, который я привел, если ты будешь прогонять юнит-тесты или ESLint, смотря в своем редакторе, или из консоли, это два несвязанных между собой процесса, то есть там равно есть какая-то цена на boot up этой программы, тот же ESLint, это все равно нод-процесс, его нужно поднять, нужно запарсить все эти javascript-файлики.</p> <p>В случае с Rome это работает иначе. Тот же плагин для VS Code, тот же плагин… для Vim есть плагин, но мне он не понравился, поэтому, может быть, придется написать свой, или SLA API, на самом деле, любое API, которое будет работать с Rome, первый раз, когда ты его запустишь, у тебя потратится примерно 4-5 секунд на то, чтобы поднять сервер, LSP-сервер. Language Server Protocol — технология, которая изначально развивалась Microsoft для VS Code, но потом вышла как общий стандарт общения между серверами конкретных языков программирования под редакторы или IDE. У вас в самом начале поднимается этот сервер, и тут неважно, как именно вы его поднимите. Допустим, вы придете утром на работу, вы просто откроете свой редактор, и у вас автоматом он поднимется, когда вы самый первый файл откроете в своем проекте или вы запустите что-то из консоли. На всем протяжении вашей работы у вас в фоне будет работать этот сервер. Вы что-то меняете, каждый раз это общение с этим сервером, он уже знает про весь ваш проект, он уже знает, как что распарсить, он уже шарит кэши между кэшами, обычными файлами, банддером и так далее. Это прям значительно сокращает работу.</p> <p>Я приведу пример. У меня есть мой pet project, Swagger Lint, это линьер для Swagger и Open API схем. Он довольно-таки маленький, и мне кажется, там тысяча строк кода, можно его измерить. Но если я в нем прогоню ESLint сегодня, то это занимает порядка 10 плюс секунд, на весь проект. Если я в нем попробую прогнать Rome с уже запущенным сервером, это занимает менее одной секунды.</p> <p>Это великолепно. У меня просто, я не знаю, бабочки в животе, когда я вижу что-то подобное. Я очень люблю хороший DX, я всячески стараюсь прилагать усилия к тому, чтобы сделать жизнь разработчиков легче, будь это у нас в работе или в каком-то open source, поэтому, мне кажется, я был предрасположен к тому, чтобы полюбить Rome.</p> <p><strong>Вадим Макеев:</strong> У меня есть вопрос, которым я хочу немножко закруглить уже нас. Представим, что у меня pet project, представим, что я страшно рисковый, и я хочу прямо сейчас взять, и начать использовать Rome. Это имеет хоть какой-либо смысл? Если я не энтузиаст, который хочет репортить баги и присылать pull requests, который хочет просто, чтобы заработало. Имеет смысл вообще использовать, кроме как в исследовательских целях?</p> <p><strong>Антон Кастрицкий:</strong> Мне кажется, в этом году в этом еще нет большого смысла, за исключением тех случаев, как ты сказал, если ты энтузиаст, и хочешь просто поэкспериментировать с этим.</p> <p><strong>Вадим Макеев:</strong> Можно ли себе на roadmap своего проекта на 2021 год добавить — поисследовать, вдруг Rome уже готов?</p> <p><strong>Антон Кастрицкий:</strong> Я уверен, что в 2021 году уже линтер будет полностью готов прям к широкому использованию, для него наконец-то появятся открытые API для внешних плагинов, что было бы очень, очень и очень здорово. А про остальные части я еще не могу говорить, поскольку я пока даже не могу представить, в каком обозримом будущем планируется выпустить бандлер, после которого уже смогут приходить все остальные инструменты.</p> <p><strong>Вадим Макеев:</strong> Мне кажется, линтер в этом плане — это отличная отправная точка, это что-то, что позволит тебе так опустить ножки в воду, а там, глядишь, уже и самому спрыгнуть хочется.</p> <p><strong>Никита Дубко:</strong> С вами был 252-й выпуск подкаста «Веб-стандарты» и его постоянные ведущие Никита Дубко из «Яндекса»…</p> <p><strong>Вадим Макеев:</strong> И Вадим Макеев из HTML Academy.</p> <p><strong>Никита Дубко:</strong> Сегодня у нас в гостях был Антон Кастрицкий. Антон, спасибо, что просветил нас, что такое Rome, и с чем его едят.</p> <p><strong>Антон Кастрицкий:</strong> Ребят, спасибо большое, что пригласили. Мне было очень интересно. Если вдруг у кого-то еще остались вопросы ко мне, меня можно найти в Твиттере, antonk52, а если вдруг вам по воскресеньям нечего делать, так бывает, что часиков в пять вечера я начинаю стримить на Twitch такой же хэндлер, поэтому заходите, будем ковыряться в Rome вместе.</p> <p><strong>Никита Дубко:</strong> Все, теперь придется на тебя подписаться.</p> <p>Слушайте нас в любом приложении для подкастов — на YouTube, во «ВКонтакте», и не забывайте ставить оценки и писать отзывы. Это помогает нам продолжать.</p> <p>Если вам нравится, что мы делаем, поддержите нас на Patreon, все ссылки в описании. Услышимся на следующей неделе. Пока.</p> <p><strong>Вадим Макеев:</strong> Пока.</p> <p><strong>Антон Кастрицкий:</strong> Пока.</p> </article> <article> <h1>Управление фокусом и атрибут inert</h1> <p>Mon, 19 Oct 2020 00:00:00 GMT</p> <p>Множество вспомогательных технологий используют навигацию с клавиатуры для помощи в восприятии и взаимодействии с контентом. Один из способов подобной навигации — клавиша Tab. Возможно, вы знакомы с ним, если используете Tab для быстрого перемещения между полями формы, не дотягиваясь до мышки или трекпада.</p> <p>Tab будет перемещаться по интерактивным элементам в том порядке, в котором они отображаются в DOM. Вот почему так важно, чтобы порядок исходного кода соответствовал визуальной иерархии вашего дизайна.</p> <p>Список <a href="https://www.w3.org/TR/html52/dom.html%23interactive-content">интерактивных элементов</a>, по которым можно пройтись клавишей Tab:</p> <ul> <li><a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a">Ссылки</a> с заполненным атрибутом <code>href</code>;</li> <li><a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/button"><code><button></code></a>;</li> <li><a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input"><code><input></code></a> и <a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/textarea"><code><textarea></code></a> с сопутствующим им <a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/label"><code><label></code></a>;</li> <li><a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/select"><code><select></code></a>;</li> <li><a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details"><code><details></code></a>;</li> <li><a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/audio"><code></code></a> и <a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/video"><code></code></a> при наличии контролов;</li> <li><a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/object"><code></code></a>, в зависимости от того, как он используется;</li> <li>любой элемент с <code>overflow: scroll</code> в Firefox;</li> <li>любой элемент с атрибутом <a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/contenteditable"><code>contenteditable</code></a>;</li> <li>любой элемент с установленным атрибутом <a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes/tabindex"><code>tabindex</code></a> (о нём чуть позже).</li> </ul> <p>Интерактивный элемент получает состояние фокуса, когда:</p> <ul> <li>На него переходят с помощью клавиши Tab,</li> <li>Он является ссылкой и на него кликают,</li> <li>Фокус программно задан с помощью <a href="https://developer.mozilla.org/en-US/docs/Web/API/HTMLOrForeignElement/focus"><code>element.focus()</code></a> в JavaScript.</li> </ul> <p>Фокус похож на ховер, поскольку так мы определяем элемент, с которым хотим провзаимодействовать. Вот почему <a href="https://css-tricks.com/focusing-on-focus-styles/">визуально очевидные стили для фокуса</a> имеют огромное значение.</p> <figure> </video> <figcaption> Фокус следует по домашней странице. Начиная с логотипа, затем к товарам, услугам, вакансиям, блогу, контактам и останавливается на кнопке «Learn more». </figcaption> </figure> <h2>Управление фокусом</h2> <p>Управлять фокусом — значит определять, какие элементы могут его получать, а какие нет. Это один из самых сложных аспектов при разработке веб-интерфейсов, но он важен для доступности сайтов и приложений.</p> <h3>Полезные практики управления фокусом</h3> <p><strong>В 99% случаев вам стоит оставить порядок фокуса в покое.</strong> Не устану это повторять.</p> <p>Состояние фокуса будет работать без дополнительных усилий, если вы используете <code><button></code> для кнопок, <code><a></code> для ссылок, <code><input></code> для полей форм и т. д.</p> <p>В редких случаях вам может понадобиться добавить фокус к элементам, к которым обычно событие <code>focus</code> не применимо. Вот некоторые рекомендации относительно того, как реализовать это доступно и интуитивно понятно для пользователя.</p> <h4>✅ Следует: узнать побольше про атрибут <code>tabindex</code></h4> <p><code>tabindex</code> делает элементы фокусируемыми. В качестве значения он принимает число, в зависимости от которого меняется поведение фокуса.</p> <h4>❌ Не следует: устанавливать <code>tabindex="0"</code> там, где это не надо</h4> <p>Нет необходимости устанавливать <code>tabindex</code> для интерактивных элементов, которые могут получать фокус с клавиатуры (например, <code><button></code>). Кроме того, вам не нужно прописывать <code>tabindex</code> неинтерактивным элементам, чтобы их могли прочесть вспомогательные устройства (на самом деле, отсутствие роли и доступного имени является ошибкой с точки зрения WCAG). На самом деле, это даже <a href="https://adrianroselli.com/2019/02/uncanny-a11y.html#Tabindex">усложняет навигацию</a> для тех, кто использует вспомогательные устройства. У таких пользователей уже есть другие, ожидаемые ими способы чтения контента.</p> <h4>✅ Следует: устанавливать <code>tabindex="-1"</code> для фокуса с помощью JavaScript</h4> <p>Атрибут <code>tabindex="-1"</code> используется для создания доступных интерактивных виджетов посредством JS. Прописав <code>tabindex="-1"</code>, вы сделаете элемент фокусируемым для JS, а также по клику или тапу, но недоступным через клавишу Tab.</p> <h4>❌ Не следует: использовать положительное значение <code>tabindex</code></h4> <p>Это антипаттерн. Установив положительное значение <code>tabindex</code>, вы переопределите ожидаемый порядок элементов для фокуса через Tab и запутаете пользователя. Сделать так один раз — уже плохо, несколько — полный кошмар. Серьёзно, не надо так.</p> <h4>❌ Не следует: создавать собственный порядок фокусировки</h4> <p>Пройтись по интерактивным элементам можно только в том порядке, в котором они следуют друг за другом. Не следует создавать множество <code>tabindex</code> со значением, которое увеличивается для каждого последующего элемента, в соответствии с вашим представлением о том, как пользователь должен читать ваш сайт. Позвольте DOM сделать это за вас.</p> <h2>Ловушка фокуса</h2> <p>Иногда есть необходимость запретить состояние фокуса. Хороший пример запрета — это <a href="https://hiddedevries.nl/en/blog/2017-01-29-using-javascript-to-trap-focus-in-an-element">ловушка фокуса</a>, которая временно ограничивает событие фокуса у родительского элемента и у его дочерних элементов.</p> <p>Ловушку фокуса не стоит путать с <a href="https://www.w3.org/TR/UNDERSTANDING-WCAG20/keyboard-operation-trapping.html">ловушкой клавиатуры</a>. Ловушки клавиатуры — это ситуации, когда невозможно закрыть виджет или перейти к другому компоненту из-за вложенного цикла плохо прописанной логики.</p> <p>Практический пример того, как вы могли бы использовать ловушку фокуса — это модальное окно:</p> <figure> </video> <figcaption> Фокус проходит по странице и открывает модальное окно, чтобы продемонстрировать отмену фокуса. Далее фокус двигается в рамках контента модального окна, на кнопку «Play», кнопку «Cancel», кнопку «Purchase» и кнопку закрытия (всё это время фокус на странице заблокирован). После закрытия модального окна он возвращается к исходному положению на странице до его открытия. </figcaption> </figure> <h3>Почему это важно?</h3> <p>Удержание фокуса в пределах модального окна помогает понять, что является его контентом, а что нет. Это аналогично тому, как зрячий человек может видеть, как окно всплывает поверх контента сайта или приложения. Это важная информация, если:</p> <ul> <li>У вас <a href="https://adrianroselli.com/2017/02/not-all-screen-reader-users-are-blind.html">плохое зрение или слепота</a> и вы полагаетесь на скринридер, чтобы узнать об изменениях после взаимодействия со страницей;</li> <li>У вас плохое зрение и интерфейс увеличен с помощью экранной лупы, при которой фокусировка за пределами модального окна может сбить с толку и дезориентировать;</li> <li>Вы перемещаетесь исключительно с помощью клавиатуры и, в случае закрытия модального окна, можете потеряться на странице при попытке вернуться обратно к нему.</li> </ul> <h3>Как это сделать?</h3> <p>Надёжно управлять фокусом — дело сложное. Нужно прибегнуть к JavaScript, чтобы:</p> <ol> <li>Определить родительский блок для всех фокусируемых элементов на странице;</li> <li>Определить границы содержимого ловушки фокуса (например, модального окна), включая первый и последний фокусируемый элемент;</li> <li>Убрать как интерактивность, так и видимость всего, что может иметь фокус и находится вне рамок содержимого ловушки фокуса;</li> <li>Переместить фокус на содержимое ловушки фокуса;</li> <li>Обрабатывать события, сигнализирующие об уходе с выделенной области (сохранение, отмена, нажатие Esc и так далее);</li> <li>Выйти из содержимого ловушки фокуса, когда сработает нужное событие;</li> <li>Вернуть раннее отменённую интерактивность;</li> <li>Переместить фокус обратно на интерактивный элемент, который вызвал ловушку фокуса.</li> </ol> <h3>Зачем нам это?</h3> <p>Не стану врать: все эти действия отнимают много времени. Но всё же, управление фокусом и удобный порядок фокусировки являются частью <a href="https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-order.html">WCAG (руководства по обеспечению доступности веб-контента)</a>. Тема достаточна важна, чтобы считать её частью <a href="https://www.w3.org/WAI/policies/">международного правового стандарта о юзабилити</a>.</p> <h3>Видимость</h3> <p>Существует небольшой трюк, с помощью которого можно легко ограничить видимость и интерактивность элемента.</p> <p><a href="https://tink.uk/understanding-screen-reader-interaction-modes/">У скринридеров есть режим взаимодействия</a>, который позволяет им проходить по странице или просматривать её с помощью виртуального курсора. А ещё виртуальный курсор позволяет пользователю скринридера обнаруживать неинтерактивные части страницы (заголовки, списки и т. д.). В отличие от использования Tab, виртуальный курсор доступен только пользователям скринридера.</p> <p>При управлении фокусом может потребоваться ограничить возможность обнаружения содержимого виртуальным курсором. В нашем примере с модальным окном это значит предотвратить случайный выход пользователя за рамки окна при чтении контента.</p> <p>Видимость может быть заблокирована с помощью правильного применения атрибута <a href="https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_aria-hidden_attribute"><code>aria-hidden="true"</code></a>. А вот с интерактивностью есть один тонкий нюанс.</p> <h2>Знакомство с <code>inert</code></h2> <p><a href="https://whatpr.org/html/4288/interaction.html#the-inert-attribute">Атрибут <code>inert</code></a> — <a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Global_attributes">глобальный атрибут в HTML</a>, позволяющий легко убирать и восстанавливать видимость интерактивных элементов, а также их возможность получать состояние фокуса. Вот пример:</p> <pre><code tabindex="0" class="language-html"><body> <div aria-labelledby="modal-title" class="c-modal" id="modal" role="dialog" tabindex="-1"> <div role="document"> <h2 id="modal-title">Save changes?</h2> <p>The changes you have made will be lost if you do not save them.<p> <button type="button">Save</button> <button type="button">Discard</button> </div> </div> <main inert>  </main> </body> </code></pre> <p>Я намеренно избегаю использования <code><dialog></code> для модального окна из-за <a href="https://www.scottohara.me/blog/2019/03/05/open-dialog.html">многочисленных проблем с поддержкой</a>.</p> <p>Атрибут <code>inert</code> задан элементу <code><main></code>, следующему сразу после модального окна сохранения изменений. Теперь всё содержимое <code><main></code> не может попасть в фокус и по нему нельзя кликнуть.</p> <p>Фокус ограничен рамками модального окна. Когда мы закрываем его, то убираем <code>inert</code> из <code><main></code>. Этот способ управления ловушкой фокуса проще, чем другие методы.</p> <p><strong>Помните:</strong> событие закрытия модального окна может быть вызвано не только нажатием на кнопки внутри нашего модального окна из примера, но и при нажатии на Esc. А ещё некоторые модальные окна могут быть закрыты по клику на оверлей.</p> <h3>Поддержка <code>inert</code></h3> <p>Все последние версии <a href="https://caniuse.com/#feat=mdn-api_htmlelement_inert">Edge, Chrome и Opera поддерживают <code>inert</code></a>, если <a href="https://css-irl.info/how-to-enable-experimental-web-platform-features/">включены экспериментальные функции веб-платформ</a>. Также <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1655722">скоро появится</a> его поддержка в Firefox! Единственное исключение — Safari, как мобильный, так и десктопный.</p> <p>Мне бы очень хотелось, чтобы Apple реализовала встроенную поддержку <code>inert</code>. Хоть <a href="https://github.com/WICG/inert">полифил и существует</a>, но у него <a href="https://www.scottohara.me/blog/2019/03/05/open-dialog.html#does-the-polyfill-help">серьёзные проблемы с поддержкой скринридерами</a>. Нехорошо!</p> <p>Вдобавок хочется обратить внимание на <a href="https://github.com/WICG/inert#performance-and-gotchas">пометку в README полифила</a>:</p> <blockquote> <p>Полифил обойдётся вам дорого с точки зрения производительности, в отличие от нативного <code>inert</code>, т. к. он требует изрядного количества перемещений по DOM.</p> </blockquote> <p>Перемещение по DOM подразумевает, что JavaScript в полифиле требует высокой вычислительной мощности и, следовательно, в конечном итоге замедлит использование.</p> <p>Для устройств с низким энергопотреблением, таких как <a href="https://www.pewresearch.org/fact-tank/2019/05/07/digital-divide-persists-even-as-lower-income-americans-make-gains-in-tech-adoption/ft_17-03-21_low-incometech_smartphone/">бюджетные Android-смартфоны и устаревшие ноутбуки</a>, а также тех, что выполняют сложные задачи (например, запуск нескольких приложений сразу), это может привести к зависанию или сбоям. Нативная браузерная поддержка делает такие процессы менее затратными в этом плане, так как у браузера есть доступ ко всем частям DOM, в отличие от JS.</p> <h4>Safari</h4> <p>Лично я разочарован тем, что Apple не поддерживает <code>inert</code>. Хотя понимаю, что добавление новых функций в браузер — невероятно сложная и трудная работа. <code>inert</code> кажется функцией, которую Apple стоило бы начать поддерживать гораздо раньше.</p> <p>macOS и iOS всегда имели хорошую поддержку доступности, а поддержка вспомогательных технологий — важная часть <a href="https://www.apple.com/accessibility/">их маркетинговой кампании</a>. Поддержка <code>inert</code> представляется как естественное продолжение миссии Apple ввиду того, что сама эта функция смогла бы облегчить разработку доступных веб-интерфейсов в разы.</p> <p>К сожалению, Apple держит в тайне, когда появится поддержка этого атрибута. Поэтому поддержка <code>inert</code> — всё ещё открытый вопрос.</p> <h4>Igalia</h4> <p><a href="https://www.igalia.com/">Igalia</a> — компания, работающая над функциями браузеров. Сейчас они проводят эксперимент, в котором каждый может проголосовать за те возможности браузеров, которые ему хотелось бы видеть. Конечно, моя статья совсем не про это, но вы можете <a href="https://www.smashingmagazine.com/2020/07/crowdfunding-web-platform-features-open-prioritization/">узнать больше в Smashing Magazine</a>.</p> <p>Одно из предложений Igalia — это <a href="https://www.igalia.com/open-prioritization/#inertwebkit">добавление поддержки <code>inert</code> в WebKit</a>. Если вы искали возможность принять участие в улучшении доступности веба, но не знали с чего начать, я могу вам <a href="https://opencollective.com/html-inert-in-webkit-safari">её предоставить</a>. 5 $, 10 $, 25 $ — совсем необязательно жертвовать большие суммы, даже маленький вклад ценен.</p> <p><a href="https://opencollective.com/html-inert-in-webkit-safari">Пожертвовать</a></p> <h2>Итог</h2> <p>Управление фокусом требует некоторых навыков и осторожности, но это того стоит. Атрибут <code>inert</code> значительно облегчит эту задачу.</p> <p>Такие техники, как <code>inert</code>, являются примером одной из самых сильных сторон веба: <a href="https://www.w3.org/TR/html-design-principles/#pave-the-cowpaths">способности кодифицировать неожиданное поведение</a> в нечто простое и эффективное.</p> <h3>Что почитать</h3> <ul> <li><a href="https://youtu.be/Pe0Ce1WtnUM">Controlling focus with tabindex</a> (A11ycasts, эпизод 4).</li> <li><a href="https://developer.paciellogroup.com/blog/2014/08/using-the-tabindex-attribute/">Using the tabindex attribute</a> (The Paciello Group).</li> <li><a href="https://hiddedevries.nl/en/blog/2017-01-29-using-javascript-to-trap-focus-in-an-element">Using JavaScript to trap focus in an element</a> (Хидде де Врис).</li> </ul> <p>Спасибо <a href="https://adrianroselli.com/">Адриану Розелли</a> и <a href="https://sarahmhigley.com/">Саре Хайли</a> за их отзывы.</p> </article> <article> <h1>Доступный для кого-то</h1> <p>Thu, 30 Jul 2020 00:00:00 GMT</p> <p>Согласно <a href="https://webaim.org/projects/million/">ежегодному исследованию доступности от WebAims</a>, 98,1% сайтов из топ-1 000 000 содержат явные ошибки WCAG 2.0. У некоторых из этих сайтов лишь незначительные проблемы с контрастностью или, может, есть один пропущенный <code>id</code>, в то время как другие крайне недоступны. Тем не менее, это чертовски большое число, учитывая тот факт, что инструменты автоматического тестирования сообщают только <a href="https://accessibility.blog.gov.uk/2017/02/24/what-we-found-when-we-tested-tools-on-the-worlds-least-accessible-webpage/">о явных проблемах доступности</a>.</p> <p>Только 1,9% протестированных страниц проходят автоматическое тестирование, что нормально, но это не значит, что на этих сайтах <a href="https://www.matuzo.at/blog/building-the-most-inaccessible-site-possible-with-a-perfect-lighthouse-score/">нет никаких барьеров</a>. Настоящая доступность выходит за рамки автоматических тестов и правил <a href="https://www.w3.org/WAI/standards-guidelines/wcag/">WCAG</a>.</p> <p>Справедливо сказать, что большинство сайтов <strong>доступны только для кого-то.</strong></p> <p>98,1% звучит плохо, но для большинства из нас это просто число, не так ли? Мне, как человеку, чья работа — помогать другим создавать доступные сайты, легче представить, какими могут быть реальные последствия этих ошибок. Чтобы помочь вам лучше понять, что значит этот высокий процент для пользователей и их повседневного опыта в интернете, я провел небольшой эксперимент.</p> <p>Мой партнёр — архитектор, и она разожгла во мне интерес к современной архитектуре. Поэтому я создал страницу об архитектурном движении в Европе, и в рамках моего эксперимента я хотел бы, чтобы вы открыли эту страницу и прочитали её. Когда закончите, попробуйте обобщить то, что вы только что узнали, оцените свой опыт, а затем, пожалуйста, вернитесь к статье.</p> <p><a href="https://cdpn.io/matuzo/debug/LYGxLLJ">Эксперимент.</a></p> <p>Впечатляет, правда? Я надеюсь, что вы можете получить доступ к большей части информации, не используя DevTools. Я сделал всё возможное, чтобы сделать её максимально доступной. Если у вас возникли проблемы с пониманием того, о чём эта страница, обратите внимание на следующее:</p> <ol> <li> <p>Наши разработчики (я) провели бесчисленные часы, оптимизируя доступность, и мы гордимся тем, что <a href="https://web.dev/measure/">Lighthouse</a>, <a href="https://wave.webaim.org/">Wave</a> и <a href="https://www.deque.com/axe/">Axe</a> не выдают никаких ошибок. Страница <strong>на 100% доступна.</strong></p> </li> <li> <p><strong>Вы сами выбираете, как работать со страницей,</strong> но она оптимизирована для десктопных скринридеров. Вы получите лучший опыт, если не будете использовать мышь. Вы можете <a href="https://www.nvaccess.org/download/">бесплатно скачать NVDA</a>.</p> </li> <li> <p><a href="https://twitter.com/TwitterSupport/status/1273332642113617921">Это ранняя версия страницы</a>, и мы изучаем способы сделать такие типы страниц доступными для всех.</p> </li> <li> <p>К сожалению, <strong>мы не заложили бюджет,</strong> чтобы оптимизировать её не для скринридеров. Нет выгоды вкладывать деньги в эту часть рынка.</p> </li> <li> <p><strong>Зачем вообще люди, пользующиеся мышью, хотят посетить сайт,</strong> посвящённый архитектуре экспрессионизма?!</p> </li> <li> <p>Мы ориентируемся на нашу целевую аудиторию: пользователей VoiceOver на macOS, NVDA и JAWS. Но мы также рассматриваем <strong>виджеты доступности,</strong> которые мы могли бы добавить на сайт для других пользователей. Такое улучшение позволит вам кликать столько раз, сколько хотите, и оптимизировать сайт под ваши нужды. Это сделает сайт <a href="https://adrianroselli.com/2015/11/be-wary-of-add-on-accessibility.html">доступным на 120%</a>.</p> </li> <li> <p>Мы известны первоклассными сайтами и постоянно исследуем новые технологии. Мы рассматриваем возможность использования <abbr title="Искусственный интеллект">ИИ</abbr> для рисования изображений по информации в атрибуте <code>alt</code>.</p> </li> </ol> <p>На основании альтернативного текста <em>«Длинное прямоугольное здание. Het Schip не только выглядит как корабль — он ещё и напоминает причудливое произведение искусства. Его облик нетрадиционен, с какой стороны ни посмотри. Внешний вид отличает ярко-оранжевый кирпич, башни и архитектурные элементы необычной формы»</em> наши супер-алгоритмы <abbr title="Искусственный интеллект">ИИ</abbr> сгенерировали следующее изображение:</p> <figure> <figcaption> Сравнение исходного здания (вверху) и сгенерированного нашим ИИ изображения (внизу). Мы уже близко. </figcaption> </figure> <p>Думаю, что большинство из вас не смогли получить доступ ко всей информации. Как ощущения? Особенно с моими дурацкими оправданиями. Довольно паршиво, правда? А теперь представьте, что вы получаете похожий опыт на большинстве посещаемых вами сайтов. Это не просто раздражает и приносит неудобства, но и заставляет злиться и грустить.</p> <p>Пожалуйста, вспоминайте эти свои ощущения каждый раз, когда вы работаете над новым сайтом, страницей или компонентом. Делайте свои сайты <strong>доступными для всех,</strong> а не только для кого-то.</p> <h2>За кулисами</h2> <p>Вы, наверное, хотите знать, как я создал этот <em>эксклюзивный</em> сайт. Имейте в виду, что большинство следующих примеров кода (я выделил те, которые не являются плохими) иллюстрируют плохие и опасные практики. Я написал их просто для того, чтобы подчеркнуть: не используйте этот код на реальных проектах.</p> <h3>Лейблы</h3> <p>Трудно понять, о чём страница, если на ней нет <code><h1></code> или она не размечена должным образом.</p> <pre><code tabindex="0" class="language-html"><h1 aria-label="Архитектура экспрессионизма">Заголовок документа</h1> </code></pre> <p>Показано «Заголовок документа», но скринридер произносит «Архитектура экспрессионизма».</p> <p>Примечание: <code>aria-label</code> не должен использоваться таким образом. Вам это не нужно, если уже есть текстовое содержимое.</p> <p><strong>Читать дальше:</strong></p> <ul> <li><a href="https://webaim.org/techniques/semanticstructure/#headings">Semantic structure: regions, headings, and lists</a></li> </ul> <h3>Управляющие подсказки</h3> <p>Скринридеры предоставляют пользователям инструкции, как взаимодействовать с такими элементами, как ссылки. Дополнительные подсказки, вроде «нажмите на эту ссылку, чтобы…» или «нажмите эту кнопку», излишни.</p> <pre><code tabindex="0" class="language-html"><a href="https://en.wikipedia.org/wiki/Expressionism"> экспрессионизм <span aria-hidden="true">(Кликните мышкой, чтобы открыть ссылку)</span> </a> </code></pre> <p>Некоторые ссылки в моём эксперименте показывают дополнительную инструкцию <em>«(Кликните мышкой, чтобы открыть ссылку)»</em> рядом с текстом ссылки.</p> <p><strong>Читать дальше:</strong></p> <ul> <li><a href="https://adrianroselli.com/2019/10/stop-giving-control-hints-to-screen-readers.html">Stop giving control hints to screen readers</a></li> </ul> <h3>Другой язык</h3> <p>Атрибут <code>lang</code> — важный. Будучи применен к элементу <code><html></code>, он сообщает скринридеру естественный язык страницы. Скринридер может не определить язык автоматически; атрибут <code>lang</code> помогает ему выбрать правильный профиль голоса.</p> <p>Если вы меняете язык в предложении, вы можете использовать атрибут <code>lang</code>, чтобы пометить слово или фразу. (Это хорошая практика).</p> <pre><code tabindex="0" class="language-html"><p> В воздухе витает конкретное <span lang="fr">je ne sais quoi</span>. </p> </code></pre> <p>Если вы так не сделаете, это может привести к тому, что русский голосовой профиль будет произносить немецкое предложение с русским акцентом. Это может быть трудным для понимания и путать, как переключение языка в середине абзаца.</p> <pre><code tabindex="0" class="language-html"><p class="visually-hidden"> Архитектура экспрессионизма — один из трёх доминирующих стилей Модерна… </p> <p aria-hidden="true"> Expressionismus in einer der drei dominanten Stile der modernen Architektur… </p> </code></pre> <p>Одно предложение на немецком, но оно спрятано от скринридеров.</p> <p><strong>Читать дальше:</strong></p> <ul> <li><a href="https://adrianroselli.com/2015/01/on-use-of-lang-attribute.html">On use of the <code>lang</code> attribute</a></li> </ul> <h3>Изображения</h3> <p>Отсутствующий <code>alt</code> — плохо, но <code>alt</code> с неверной или бесполезной информацией не намного лучше. Пожалуйста, не раздражайте пользователей скринридера длинной, скучной или нерелевантной информацией.</p> <p>Атрибут <code>alt</code> часто используется как место для хранения ключевых слов SEO или информации об авторских правах. Здесь я перевернул это и поместил всю бесполезную информацию в изображение.</p> <pre><code tabindex="0" class="language-html"><figure> <figcaption>Голландский экспрессионизм (Амстердамская школа), жилой дом Het Schip в Амстердаме, 1917–20 (Мишель де Клерк)</figcaption> </figure> </code></pre> <p><strong>Читать дальше:</strong></p> <ul> <li><a href="https://www.smashingmagazine.com/2020/05/accessible-images/">Accessible images for when they matter most</a></li> </ul> <h3>Пустые ссылки</h3> <p>Пользователи скринридеров часто сталкиваются с пустыми ссылками и кнопками. Скринридер может озвучить им, что у них есть ссылка, но если она без текста, они не знают, куда она их приведёт.</p> <p>Используя <code>aria-label</code>, я сделал лейбл доступным только для скринридеров.</p> <pre><code tabindex="0" class="language-html"><a href="https://" class="btn" aria-label="Het Schip в Википедии"></a> </code></pre> <p><code>aria-label</code> часто используют, чтобы задать обозначения иконкам. Я не поклонник передачи информации только с помощью значков, потому что отсутствие текста повышает мою когнитивную нагрузку, требуя умственной обработки для выведения смысла.</p> <p><strong>Читать дальше:</strong></p> <ul> <li><a href="https://www.nngroup.com/articles/icon-usability/">Icon usability</a></li> <li><a href="https://jonyablonski.com/articles/2015/design-principles-for-reducing-cognitive-load/">Design principles for reducing cognitive load</a></li> </ul> <h3>Неправильный порядок</h3> <p>Скринридеры произносят контент в порядке его появления в <abbr title="Document Object Model" lang="en">DOM</abbr>, сверху вниз. Изменение порядка при помощи CSS не влияет на порядок в документе. Трудно перемещаться и понимать отношения между элементами, если они появляются в непонятном порядке.</p> <pre><code tabindex="0" class="language-html"><p aria-hidden="true"> Кирпичный экспрессионизм — особый вариант северной Германии этого движения и в западной и Нидерландах в. </p> <p class="visually-hidden"> Кирпичный экспрессионизм — особый вариант этого движения в западной и северной Германии и в Нидерландах. </p> </code></pre> <p><strong>Читать дальше:</strong></p> <ul> <li><a href="https://tink.uk/flexbox-the-keyboard-navigation-disconnect/">Flexbox & the keyboard navigation disconnect</a></li> <li><a href="https://adrianroselli.com/2015/10/html-source-order-vs-css-display-order.html">HTML source order vs CSS display order</a></li> </ul> <h3>Скрытый контент</h3> <p>Разработчики нашли хороший костыль для ситуаций, когда слишком сложно сделать части страницы доступными: они просто добавляют <code>aria-hidden="true"</code> к элементу и скрывают его от скринридеров. Если его нет, его не нужно делать доступным. 🤙 *</p> <pre><code tabindex="0" class="language-html"><p style="filter: invert(1)"> Термин «Архитектура экспрессионизма… </p> </code></pre> <p>Примечание: я пробовал использовать <code>color: #ffffff</code> и <code>opacity: 0</code>, чтобы скрыть текст визуально, но Axe слишком умный. У меня получилось обмануть этот инструмент с помощью <code>filter: invert(1)</code>.</p> <p>* Это был сарказм. Знаете, на всякий случай…</p> <p><strong>Читать дальше:</strong></p> <ul> <li><a href="https://developer.paciellogroup.com/blog/2012/05/html5-accessibility-chops-hidden-and-aria-hidden/">HTML5 accessibility chops: hidden and aria-hidden</a></li> </ul> <h3>Нажмите здесь</h3> <p>Скринридеры могут делать гораздо больше, чем просто зачитывать контент на странице. Они предоставляют различные способы навигации. Вы можете переходить от ориентира к ориентиру или от заголовка к заголовку, или вы можете перечислить все элементы формы или ссылки на странице. Если у этих элементов нет осмысленной метки, трудно, а иногда даже невозможно сказать, для чего они — как в параграфе, где каждая ссылка имеет одинаковую метку.</p> <pre><code tabindex="0" class="language-html"><p> Среди важных событий в архитектуре экспрессионизма есть <a href="/wiki/Werkbund_Exhibition_(1914)" aria-label="Выставка в Веркбунде (1914)"> нажмите здесь </a> , которая… </p> </code></pre> <p><strong>Читать дальше:</strong></p> <ul> <li><a href="https://webaim.org/techniques/hypertext/">Links and hypertext</a></li> </ul> <h3>Чрезмерная вложенность</h3> <p>Структура страницы должна быть чистой и простой. Нет никакой пользы от 8 вложенных <code><article></code> или <code><ul></code>.</p> <pre><code tabindex="0" class="language-html"><ul aria-hidden="true"> <li>Стиль <ul> <li>характеризовался <ul> <li>ранним модернистским принятием <ul> <li>новых материалов, <ul> <li>формальными инновациями, <ul> <li>и очень необычным <ul> <li>подходом <ul> <li>.</li> </ul> </li> </ul> </li> </ul> </li> </ul> </li> </ul> </li> </ul> </li> </ul> </li> </ul> </code></pre> <p><strong>Читать дальше:</strong></p> <ul> <li><a href="https://www.htmhell.dev/10-section-is-no-replacement-for-div/">#10 <code><section></code> is no replacement for <code><div></code></a></li> </ul> <h3>Формы</h3> <p>Создавать доступные и удобные для использования формы сложно, но есть несколько основ, которые просто необходимо соблюдать.</p> <ul> <li>Каждый элемент формы нуждается в лейбле.</li> <li>Лейблы должны содержать текст, а не только картинки или иконки.</li> <li>Лейблы и элементы формы должны быть сгруппированы так, чтобы и машины, и пользователи понимали связь между ними.</li> </ul> <p>Я сделал правильный лейбл «плохо» доступным только пользователям скринридеров, скрыв его визуально, и отключил клик по нему, добавив <code>pointer-events: none</code> лейблу.</p> <pre><code tabindex="0" class="language-html"><p> <input type="radio" id="rating2" name="rating"> <label for="rating2" style="pointer-events: none"> <span class="vh">плохо</span> <span aria-hidden="true">Скруглённая белая звезда Скруглённая белая звезда</span> </label> </p> </code></pre> <p>И не только. Я могу порекомендовать <a href="https://www.smashingmagazine.com/printed-books/form-design-patterns/">Шаблоны проектирования форм</a> Адама Сильвера, если вы хотите научиться создавать инклюзивные формы.</p> <h3>«Кнопки»</h3> <p>Распространённая проблема доступности — наличие на странице элементов, которые выглядят как кнопки, но на самом деле они не являются <code><button></code>. Это обычно делает их менее доступными или недоступными для некоторых пользователей. Здесь я перевернул ситуацию: это настоящая кнопка, она выглядит как кнопка, но вы не можете нажать на неё.</p> <pre><code tabindex="0" class="language-html"><button style="pointer-events: none" type="submit" class="btn" onclick="alert('Спасибо за вашу оценку')"> Отправить </button> </code></pre> <p><strong>Читать дальше:</strong></p> <ul> <li><a href="https://youtu.be/CZGqnp06DnI">Just use button — A11ycasts #05</a></li> </ul> <h2>Заключение</h2> <p>Это был весёлый эксперимент, и я надеюсь, что вы получили удовольствие от чтения этой статьи. Лежащая в основе проблема, однако, совсем не весёлая. Просто это мой способ работы с серьёзными темами.</p> <p>Ваш сайт, приложение или новая функциональность лишь наполовину хорошие, если только некоторые люди могут получить к ним доступ. Подумайте об инклюзивности и разнообразии в самом начале и тестируйте правильно. Соточка в Lighthouse или отсутствие ошибок в Axe не означают, что вы всё сделали правильно, это означает, что вы готовы приступать к ручному тестированию и тестированию с реальными пользователями, если это возможно. Прежде чем просто что-то создавать и запускать, подумайте о ваших пользователях и о том, как ваши решения могут влиять на них.</p> <p>Вот доступная версия <a href="https://cdpn.io/matuzo/debug/qBbrMgW?editors=1100">страницы про архитектуру экспрессионизма</a>.</p> <p>Спасибо, <a href="https://cariefisher.com/">Кэри Фишер</a>, за помощь со статьёй!</p> </article> <article> <h1>Объяснение ключевых слов initial, inherit, unset и revert в CSS</h1> <p>Tue, 21 Jul 2020 00:00:00 GMT</p> <p>В CSS есть несколько ключевых слов для задания значений свойств. Я собираюсь поговорить о нескольких из них: <code>initial</code>, <code>inherit</code> и об относительно новых — <code>unset</code> и <code>revert</code>.</p> <p><em>В оригинальной статье в заголовке и во вступлении говорится только о трёх ключевых словах, но дальше в тексте идёт обсуждение четвёртого — <code>revert</code>. Мы решили добавить его во вступление для удобства читателя — прим. переводчика.)</em></p> <p>Хотя большинство веб-разработчиков сталкивалось с ними, весьма вероятно, что многие, даже самые опытные, не до конца их понимают.</p> <p>Долгое время я знал об этих ключевых словах только то, что они используются для сброса стилей в CSS. Но если все эти ключевые слова являются своего рода сбросом, то почему их так много? Какие именно различия между ними? Я решил глубже изучить эти ключевые слова, чтобы раз и навсегда разобраться, что отличает их друг от друга.</p> <h2>Базовые стили для веба</h2> <p>Прежде чем мы начнем разбираться с ключевыми словами, важно понять, откуда берутся базовые стили в браузере.</p> <h3>Начальное значение для каждого свойства в CSS</h3> <p>Каждое свойство в CSS имеет начальное (<code>initial</code>) значение. Оно никак не связано с типом HTML-элемента, к которому применяется.</p> <p>Пример начального значения из MDN:</p> <figure> <figcaption>Начальное значение свойства <code>line-height</code> — это <code>normal</code>.</figcaption> </figure> <h3>Браузерные стили</h3> <p>После применения начальных стилей для всех CSS-свойств браузер загружает свои стили. Эти стили не имеют ничего общего с базовыми начальными значениями CSS-свойств.</p> <p>Пример браузерных стилей:</p> <figure> <figcaption>Стили браузера Chrome, применяемые к элементу <code><h1></code>.</figcaption> </figure> <p>У HTML-элементов нет начальных значений для стилей! Базовые стили HTML-элемента, такого как <code><h1></code>, например, предоставляются стилями браузера, а не начальными значениями CSS-свойств.</p> <p>Теперь начнем говорить о ключевых словах.</p> <h2>Ключевое слово <code>inherit</code></h2> <p>Ключевое слово <code>inherit</code> сообщает браузеру, что значение свойства нужно найти у ближайшего родительского элемента и унаследовать его для текущего элемента. Если у ближайшего родителя также задано значение <code>inherit</code>, то браузер продолжит подниматься по DOM, пока не найдет какое-нибудь значение. Если значения нет, то браузер применит свои стили, а если и браузерных стилей нет, то тогда будет применено значение <code>initial</code>.</p> <h2>Ключевое слово <code>initial</code></h2> <p>Чтобы понять ключевое слово <code>initial</code>, мы должны помнить важный факт: у каждого свойства в CSS есть значение по умолчанию, которое не имеет ничего общего со значениями, которые устанавливаются браузером. Браузерные стили — это стили, которые применяются браузером к конкретным HTML-элементам. Мы часто думаем, что они автоматически приходят вместе с HTML, но это не так.</p> <p>Ключевое слово <code>initial</code> говорит браузеру использовать значение по умолчанию для заданного CSS-свойства. Например, для свойства <code>color</code> значение <code>initial</code> всегда будет <code>black</code>.</p> <p>Такое поведение может очень запутывать, потому что, как мы и говорили ранее, значение по умолчанию для CSS-свойства не всегда совпадает со значением, которое браузер задает конкретному элементу. Например, <code>initial</code>-значение для свойства <code>display</code> равно <code>inline</code> для всех элементов. Поэтому, если для элемента <code><div></code> будет задано свойство <code>display</code> со значением <code>initial</code>, то свойство будет вычислено как <code>inline</code>, а не <code>block</code>, как в стилях браузера.</p> <p>Пример:</p> <pre><code tabindex="0" class="language-css">div.box { background-color: red; display: initial; /* примет значение `inline`, а не `block` */ } </code></pre> <p><a href="https://codepen.io/elad2412/pen/KKKqMyZ">Пример на CodePen значения <code>initial</code> для свойства <code>display</code> элемента <code><div></code></a>.</p> <figure> <figcaption> <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/display">Информация об <code>initial</code>-значении свойства <code>display</code> на MDN</a>. </figcaption> </figure> <h2>Ключевое слово <code>unset</code></h2> <p>Ключевое слово <code>unset</code> является уникальным и работает в зависимости от типа свойства. В CSS есть два типа свойств:</p> <h3>1. Наследуемые свойства</h3> <p>Свойства, которые затрагивают дочерние элементы. <strong>Все свойства, которые влияют на текст, имеют такое естественное поведение.</strong> Например, если мы зададим <code>font-size</code> элементу <code><html></code>, то он будет применяться ко всем дочерним элементам, пока вы не зададите другой <code>font-size</code> какому-нибудь из них.</p> <figure> <figcaption> <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/font-size">Информация о наследуемости свойства font-size на MDN</a>. </figcaption> </figure> <h3>2. Ненаследуемые свойства</h3> <p>Все остальные свойства, которые влияют только на элемент, для которого они заданы. <strong>Это все свойства, которые не относятся к оформлению текста</strong>. Например, если вы зададите border на родительском элементе, то он не будет задан на дочернем.</p> <figure> <figcaption> <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/border">Информация о наследуемости свойства <code>border</code> на MDN</a>. </figcaption> </figure> <p>Ключевое слово <code>unset</code> работает так же, как и <code>inherit</code> для наследуемых свойств. Например, для текстового свойства <code>color</code> оно будет работать как значение <code>inherit</code>, то есть будет искать ближайший родительский элемент с заданием нужного свойства, а если он не будет найден, то применится браузерное значение, а если и браузерных стилей нет, то применится значение <code>initial</code>.</p> <p>Для ненаследуемых свойств <code>unset</code> ведет себя как <code>initial</code>, то есть применится значение по умолчанию. Например, для свойства <code>border-color</code> оно будет работать как <code>initial</code>.</p> <pre><code tabindex="0" class="language-css">.some-class { color: unset; /* будет равно `inherit` */ display: unset; /* будет равно `initial` */ } </code></pre> <h3>Зачем использовать <code>unset</code>, если оно работает так же, как <code>inherit</code> и <code>initial</code>?</h3> <p>Если <code>unset</code> ведет себя как <code>inherit</code> и <code>initial</code>, то зачем оно может понадобиться? Если мы сбрасываем только одно свойство, то <code>unset</code> не нужен. Вместо него мы можем просто использовать <code>inherit</code> или <code>initial</code>. Но сейчас у нас есть свойство <code>all</code>, которое дает нам новую возможность — сбросить наследуемые и ненаследуемые свойства одновременно.</p> <p>Таким образом, вам не нужно сбрасывать свойства по отдельности. Применение ключевого слова <code>unset</code> к свойству <code>all</code> приведет к сбросу всех наследуемых свойств к значению <code>inherit</code> и всех ненаследуемых свойств — к значению <code>initial</code>.</p> <p><strong>Это единственная причина существования нового ключевого слова <code>unset</code>! В противном случае мы могли бы вместо этого использовать <code>inherit</code> и <code>initial</code>.</strong></p> <p>Вместо сброса свойств по отдельности, к примеру:</p> <pre><code tabindex="0" class="language-css">/* Плохо */ .common-content { font-size: inherit; font-weight: inherit; border-width: initial; background-color: initial; } </code></pre> <p>Мы можем использовать новое свойство <code>all</code> со значением <code>unset</code>, которое повлияет на все существующие свойства, например:</p> <pre><code tabindex="0" class="language-css">/* Хорошо */ .common-content { all: unset; } </code></pre> <p>Я создал небольшой пример для демонстрации того, как свойства ведут себя, когда используется свойство <code>all</code> со значением <code>unset</code>. Некоторые ведут себя так, как будто к ним применено значение <code>inherit</code>, а некоторые так, как будто к ним применено значение <code>initial</code>. <a href="https://codepen.io/elad2412/pen/QWWgKbB">Пример на Codepen использования <code>all: unset</code></a>.</p> <h2>Ключевое слово <code>revert</code></h2> <p>Но что, если мы хотим сбросить значение свойства до первоначально заданных браузером значений, а не до значений по умолчанию? Например, вернуть значение свойства <code>display</code> элемента <code><div></code> к значению <code>block</code> (это стили браузера), а не к значению <code>inline</code> (это базовые стили CSS).</p> <figure> <figcaption>Браузерные стили для тега div</figcaption> </figure> <p>Для этих целей мы скоро получим новое ключевое слово в CSS: <code>revert</code>. Оно очень похоже на <code>unset</code>, единственное отличие состоит в том, что оно предпочитает стили браузера базовым значениям свойств CSS. Например:</p> <pre><code tabindex="0" class="language-css">div { display: revert; /* = block */ } h1 { font-weight: revert; /* = bold */ font-size: revert; /* = 2em */ } </code></pre> <p>Таким образом, если мы хотим сбросить все стили HTML-элемента до базовых стилей браузера, мы можем сделать это так:</p> <pre><code tabindex="0" class="language-css">/* Хорошо */ .common-content { all: revert; } </code></pre> <p>Соответственно, <code>revert</code> дает гораздо больше возможностей, чем <code>unset</code>. Правда, на данный момент <code>revert</code> работает только в Firefox и Safari. <em>(В Chrome работает с версии 84 — прим. переводчика.)</em></p> <h2>Заключение</h2> <p>На этом всё. Надеюсь, вам понравилась эта статья, и вы чему-то научились из моего опыта.</p> <h2>Видео доклада по теме</h2> <p>Я сделал короткий доклад на эту тему, смотрите видео целиком на YouTube:</p> <figure> <figcaption> Мой доклад <a href="https://youtu.be/8IaKXJHRSXc">«Ключевые слова в CSS, которые никто не понимает»</a>. </figcaption> </figure> </article> <article> <h1>Советы по сложным CSS-иллюстрациям</h1> <p>Thu, 02 Jul 2020 00:00:00 GMT</p> <p>Если бы вы меня спросили, какой вопрос мне чаще всего задают про фронтенд-разработку, я бы ответил: <em>«Как прокачаться в CSS?».</em> Этот вопрос обычно озвучивают после того, как я делюсь сделанными мной CSS-иллюстрациями. Это то, что <a href="https://codepen.io/jh3y/pens/">я люблю делать на CodePen</a>.</p> <p>Для многих CSS — неукротимый мифический зверь. <a href="https://twitter.com/chriscoyier/status/1248088743002677248">Этот твит</a> Криса заставил меня улыбнуться, потому что, несмотря на всю иронию, в нём много правды. Тем не менее, что, если я скажу вам, что вам нужно всего несколько свойств и техник, чтобы создать всё, что вы хотели? Правда в том, что это действительно так.</p> <p>Я давно хотел написать подобную статью, но это сложная тема, потому что существует так много возможностей и так много техник, что, как правило, одно и то же можно сделать несколькими способами. То же самое относится и к CSS-иллюстрациям. Нет правильного или неправильного способа. Мы все рисуем на одном и том же холсте. Просто есть много разных инструментов, чтобы поместить все эти пиксели на страницу.</p> <p>И хотя не существует универсального подхода для CSS-иллюстраций, я могу предложить несколько техник, которые помогут вам в вашем путешествии.</p> <h2>Время и практика</h2> <p>CSS-иллюстрация требует много времени и практики. Чем точнее вы хотите быть и чем сложнее иллюстрация, тем больше времени это займёт. Самая затратная часть — не решение, какие свойства использовать и как, а отшлифовка результата до состояния, чтобы всё выглядело правильно. <strong>Будьте готовы изучить <a href="https://developers.google.com/web/tools/chrome-devtools/css">инспектор стилей</a> в вашем браузере!</strong> Я также рекомендую попробовать <a href="https://chrome.google.com/webstore/detail/visbug/cdockenadnadldjbbgcallicgledbeoc?hl=en">VisBug</a>, если вы этого ещё не сделали.</p> <p>Два фантастических CSS-художника — Бен Эванс и Диана Смит. Оба недавно рассказывали о затратах времени на CSS-иллюстрации.</p> <figure> <figcaption> Создание PureCSS Gaze заняло у Дианы два долгих уикенда. Она рассказывает о некоторых своих техниках <a href="https://www.vice.com/en_us/article/9kgx7p/painting-made-with-code-html-pure-css-browser-art-diana-smith">здесь</a>. «Если у вас есть время, терпение и запал, то это, безусловно, возможно», — говорит она. </figcaption> </figure> <p>Я запостил мем про чашку, и в <a href="https://twitter.com/ivorjetski/status/1259893362129350658">ответе Бена</a> всё было прекрасно:</p> <blockquote> <p>Когда в первый раз увидел твит, мне захотелось сделать это на CSS, но потом подумал, что мой ответ займет около месяца.</p> </blockquote> <p>Это требует времени!</p> <figure> <figcaption> <a href="https://twitter.com/jh3yy/status/1259487385554911233">CSS-иллюстрация</a>. </figcaption> </figure> <h2>Трассировка вполне приемлема</h2> <p>Зачастую мы уже имеем представление о том, что хотим нарисовать. В конце концов, эта статья не о дизайне. Речь идет о том, чтобы взять изображение и отрендерить его с помощью DOM и CSS. Я уверен, что эта техника существует с незапамятных времен. Но это то, чем я делюсь последние несколько месяцев.</p> <ul> <li>Найдите или создайте изображение, которое вы хотите нарисовать.</li> <li>Вставьте его в ваш HTML при помощи <code></code>.</li> <li>Расположите его так, чтобы оно находилось прямо под вашей иллюстрацией.</li> <li>Уменьшите прозрачность изображения, чтобы его было видно, но не слишком.</li> <li>Трассируйте его с помощью DOM.</li> </ul> <p>К моему удивлению, про эту технику <a href="https://twitter.com/therealpaulcook/status/1256283143587405824">не все знают</a>. Но она бесценна для создания точных CSS-иллюстраций.</p> <p>Следите за трюком в действии:</p> <figure> <figcaption> Вот таймлапс создания логотипа <a href="https://twitter.com/eggheadio">@eggheadio</a> на CSS 😎 Поигрался с тенями и применил clip-path поверх 🛠️ <a href="https://twitter.com/jh3yy/status/1256281143244136448">@jh3yy</a> </figcaption> </figure> <p>И попробуйте его здесь:</p> <h2>Обращайте внимание на отзывчивость</h2> <p>Если вы начнёте использовать только две техники из этой статьи, пусть это будут трассировка из раздела выше и эта.</p> <p>Есть немало фантастических примеров CSS-иллюстраций. Но одна из неприятных особенностей некоторых из них в том, что они не стилизованы — или даже не видны — на маленьких экранах. Мы живём в эпоху, когда очень важны первые впечатления от технологий. Рассмотрим на примере клавиатуры, нарисованной на CSS. Кто-то находит вашу работу, открывает её на своём смартфоне, а его встречает только половина иллюстрации или её небольшая часть. Они скорее всего упустили самые крутые части демо!</p> <p><strong>Вот мой приём:</strong> использовать единицы вьюпорта для иллюстраций и создавать свою собственную масштабированную единицу измерения.</p> <p>Для размеров и позиционирования вы можете использовать либо масштабированную единицу измерения, либо проценты. Это особенно полезно, когда вам нужно использовать <code>box-shadow</code>, потому что это свойство работает с единицами вьюпорта, но не работает с процентами.</p> <p>Рассмотрим CSS-логотип <a href="https://egghead.io/">egghead.io</a>, который я создал ранее. Я нашел изображение, которое хотел использовать, и добавил его в DOM тегом <code></code>.</p> <pre><code tabindex="0" class="language-html"> </code></pre> <pre><code tabindex="0" class="language-css">img { height: 50vmin; left: 50%; opacity: 0.25; position: fixed; top: 50%; transform: translate(-50%, -50%); } </code></pre> <p>Высота <code>50vmin</code> — желаемый размер CSS-иллюстрации. Уменьшение прозрачности позволяет нам «трассировать» иллюстрацию по мере прогресса.</p> <p>Теперь создадим нашу масштабированную единицу измерения.</p> <pre><code tabindex="0" class="language-css">/** * размеры изображения 742 x 769 * ширина — 742 * высота — 769 * желаемый размер — 50vmin */ :root { --size: 50; --unit: calc((var(--size) / 769) * 1vmin); } </code></pre> <p>Зная размеры изображения, мы можем создать единицу измерения, которая будет масштабироваться вместе с нашим изображением. Мы знаем, что высота — это самая большая сторона, поэтому используем её как основу для создания дробной единицы.</p> <p>Получим что-то вроде такого:</p> <pre><code tabindex="0" class="language-css">--unit: 0.06501950585vmin; </code></pre> <p>Выглядит так себе, но поверьте, это нормально. Мы можем использовать её для задания размеров контейнера для иллюстации, используя <code>calc()</code>.</p> <pre><code tabindex="0" class="language-css">.egg { height: calc(769 * var(--unit)); position: relative; width: calc(742 * var(--unit)); z-index: 2; } </code></pre> <p>Если мы используем проценты или наше новое кастомное свойство <code>-⁠-⁠unit</code> для стилизации элементов внутри контейнера нашей CSS-иллюстрации, мы получим отзывчивую CSS-иллюстрацию… И всё это требует всего несколько строчек математики с использованием CSS-переменных!</p> <p>Поизменяйте размеры этого демо, чтобы увидеть, что все пропорции сохраняются, ограничиваясь по размеру до <code>50vmin</code>.</p> <h2>Семь раз отмерь, один отрежь</h2> <p>Следующий совет: замеряйте. Чёрт, вы даже можете взять рулетку, если работаете с физическим объектом!</p> <p>Это может показаться немного странным, но я замерял эту сцену. Это телевизор с полками, которые стоят в моей гостиной. Все замеры сделаны в сантиметрах. Я использовал их для получения отзывчивой единицы измерения, основанной на фактической высоте телевизора. Благодаря кастомным свойствам мы можем дать имя этому числу и всем остальным. Это позволит легко запомнить, для чего оно предназначено.</p> <pre><code tabindex="0" class="language-css">:root { --light-switch: 15; --light-switch-border: 10; --light-switch-top: 15; --light-switch-bottom: 25; --tv-bezel: 15; --tv-unit-bezel: 4; --desired-height: 25vmin; --one-cm: calc(var(--desired-height) / var(--tv-height)); --tv-width: 158.1; --tv-height: 89.4; --unit-height: 42; --unit-width: 180; --unit-top: 78.7; --tv-bottom: 114.3; --scaled-tv-width: calc(var(--tv-width) * var(--one-cm)); --scaled-tv-height: calc(var(--tv-height) * var(--one-cm)); --scaled-unit-width: calc(var(--unit-width) * var(--one-cm)); --scaled-unit-height: calc(var(--unit-height) * var(--one-cm)); } </code></pre> <p>Как только мы вычислили переменную, можем использовать её везде. Я знаю, что мой телевизор 158,1 см в ширину и 89,4 см в высоту — подсмотрел в инструкции. Но в моей CSS-иллюстрации он всегда будет ограничен <code>25vmin</code>.</p> <h2>Используйте абсолютное позиционирование для всего</h2> <p>Этот совет позволит сэкономить на нажатиях клавиш. Чаще всего вы будете пытаться позиционировать элементы абсолютно. Помогите себе и положите это правило куда-нибудь.</p> <pre><code tabindex="0" class="language-css">/* Имена классов могут отличаться */ .css-illustration *, .css-illustration *:after, .css-illustration *:before, .css-illustration:after, .css-illustration:before { box-sizing: border-box; position: absolute; } </code></pre> <p>Ваша клавиатура скажет вам спасибо!</p> <p>Или поиграйте в этой песочнице:</p> <h2>Придерживайтесь подхода</h2> <p>Это, безусловно, самая сложная вещь. Какой подход вы используете к CSS-иллюстрации? С чего начинаете? Должны ли вы начать с внешней части и идти внутрь картинки? Это работает не так хорошо, как хотелось бы.</p> <p>Скорее всего, вы попробуете несколько подходов и найдёте лучший способ решить задачу. Вы, конечно, будете переделывать некоторые вещи, но чем больше вы будете практиковаться, тем чаще будете замечать шаблонные вещи и разработаете подход, который лучше всего подходит для вас.</p> <p>Я склонен соотнести свой подход с тем, как если бы вы создавали векторное изображение, в котором иллюстрация состоит из слоёв. Разделите её и нарисуйте на бумаге, если нужно. Но начните снизу и прорабатывайте свой путь наверх. Это обычно означает более крупные фигуры сначала, а более мелкие детали — позже. Вы всегда можете повозиться с контекстом наложения, когда вам нужно подвигать элементы.</p> <h2>Сохраняйте жёсткую структуру ваших стилей</h2> <p>Это приводит нас к структуре. Старайтесь избегать плоской DOM-структуры для вашей иллюстрации. Сохранение вещей атомарными позволяет проще двигать части вашей иллюстрации. А ещё так гораздо проще показывать или прятать части иллюстрации или даже потом анимировать их. Рассмотрим <a href="https://codepen.io/jh3y/pen/yLYXVJa">демо CSS Snorlax</a>. Руки, ноги, голова и прочие части являются отдельными элементами. Это сделало анимирование руки гораздо проще, чем если бы я пытался держать всё вместе, так как я смог просто применить анимацию к классу <code>.snorlax__arm-left</code>.</p> <p>Вот ускоренная запись того, как я делал это демо:</p> <figure> <figcaption> Попытался собрать таймлапс создания CSS Snorlax, которого мы делали вчера ночью. Забавно пересматривать! <a href="https://twitter.com/jh3yy/status/1255207715137339396">@jh3yy</a> </figcaption> </figure> <h2>Работа с неудобными фигурами</h2> <p>Есть <a href="https://css-tricks.com/the-shapes-of-css/">довольно неплохая статья</a> на CSS-Tricks про создание фигур с помощью CSS. Но как насчёт более «неуклюжих» фигур, таких как длинная кривая или даже обводка? В таких случаях нужно мыслить нестандартно. Такие свойства, как <code>overflow</code>, <code>border-radius</code> и <code>clip-path</code> — отличные помощники.</p> <p>Посмотрим на демо CSS Jigglypuff. Нажмите на чекбокс.</p> <p>Вот ключ к созданию искривлённых фигур! У нас есть элемент, который гораздо больше тела с примененным <code>border-radius</code>. Тогда мы задаем <code>overflow: hidden</code> телу, чтобы обрезать этот лишний кусок.</p> <p>Как мы можем сделать обводку? Это уже немного сложнее. Но мне нравится следующий приём: используйте прозрачный элемент с толстой рамкой. Затем примените <code>border-radius</code> и обрежьте лишнее, если нужно.</p> <p>Если вы нажмёте на чекбокс, покажется элемент, который мы используем для обводки этого угла. Другой приём может заключаться в том, чтобы наложить поверх круг, совпадающий по цвету с фоном. Это нормально, пока нам не понадобится изменить цвет фона. Хорошо, если у вас есть переменная или что-то вроде для этого цвета. Но такой подход слегка сложнее поддерживать.</p> <h2><code>clip-path</code> — ваш друг</h2> <p>В последнем демо вы могли заметить парочку интересных CSS-свойств, например, <code>clip-path</code>. Вам почти наверняка понадобится <a href="https://css-tricks.com/almanac/properties/c/clip-path/"><code>clip-path</code></a>, если вы хотите создавать сложные CSS-фигуры. Его особенно удобно использовать для обрезания краёв элементов, когда применение <code>overflow</code> на родителе не помогает.</p> <p>Вот небольшое демо, которое я собрал некоторое время назад, чтобы показать различные возможности <code>clip-path</code>.</p> <p>Есть ещё такое демо, которое берёт идеи из статьи <a href="https://css-tricks.com/the-shapes-of-css/">Shapes of CSS</a> и воссоздаёт фигуры при помощи <code>clip-path</code>.</p> <h2><code>border-radius</code> — ещё один друг</h2> <p>Вам точно понадобится <a href="https://css-tricks.com/almanac/properties/b/border-radius/"><code>border-radius</code></a> для создания кривых. Один необычный приём заключается в использовании синтаксиса с двумя значениями. Это позволяет задавать горизонтальный и вертикальный радиус для каждого угла.</p> <p>Поиграйте с этим демо, чтобы по-настоящему оценить мощь <code>border-radius</code>. Я призываю использовать проценты для значений, чтобы сохранять отзывчивость элементов.</p> <h2>Техники создания теней</h2> <p>У вас уже есть все формы, всё хорошо продумано, правильные цвета везде, где нужно… Но что-то всё ещё выглядит не так. Скорее всего, это отсутствие теней.</p> <p>Тени добавляют глубину и создают реалистичные ощущения. Посмотрим на это воссоздание иллюстрации Галь Шир. Галь великолепно использует тени и градиенты для создания красивой иллюстрации. Я подумал, что было бы интересно воссоздать её и добавить переключатель, который включает и выключает затенение, чтобы оценить разницу, которое оно создаёт.</p> <p>Эффекты затенения часто создаются при помощи комбинации <code>box-shadow</code> и <code>background-image</code>.</p> <p>Ключевая особенность этих свойств в том, что мы можем складывать их в список, разделённый запятой. Например, у котла в этом демо есть список градиентов, которые используются по всему его телу.</p> <pre><code tabindex="0" class="language-css">.cauldron { background: radial-gradient(25% 25% at 25% 55%, var(--rim-color), transparent), radial-gradient(100% 100% at -2% 50%, transparent, transparent 92%, var(--cauldron-color)), radial-gradient(100% 100% at -5% 50%, transparent, transparent 80%, var(--darkness)), linear-gradient(310deg, var(--inner-rim-color) 25%, transparent), var(--cauldron-color); } </code></pre> <p>Обратите внимание, что здесь используются <code>radial-gradient()</code> и <code>linear-gradient()</code>, и они не всегда содержат идеально круглые числовые значения. Опять же, такие числа нормальны. На самом деле вы потратите много времени, настраивая и подкручивая разные значения в инспекторе стилей.</p> <p>То же самое применимо и к <a href="https://css-tricks.com/snippets/css/css-box-shadow/"><code>box-shadow</code></a>. Однако с ним мы также можем использовать значение <code>inset</code>, чтобы создавать хитрые границы и дополнительную глубину.</p> <pre><code tabindex="0" class="language-css">.cauldron__opening { box-shadow: 0 0px calc(var(--size) * 0.05px) calc(var(--size) * 0.005px) var(--rim-color) inset, 0 calc(var(--size) * 0.025px) 0 calc(var(--size) * 0.025px) var(--inner-rim-color) inset, 0 10px 20px 0px var(--darkness), 0 10px 20px -10px var(--inner-rim-color); } </code></pre> <p>Конечно, бывают случаи, когда куда разумнее использовать <a href="https://css-tricks.com/almanac/properties/f/filter/"><code>filter: drop-shadow()</code></a>, чтобы получить желаемый эффект.</p> <p>Сайт Линн Фишер <a href="https://a.singlediv.com/">a.singlediv.com</a> — яркий пример этих свойств в действии. Потыкайте в разные элементы на этом сайте и исследуйте некоторые из иллюстраций, чтобы найти отличные способы применения <code>box-shadow</code> и <code>background-image</code> в иллюстрациях.</p> <p>Свойство <code>box-shadow</code> настолько мощное, что вы можете создать целую иллюстрацию только с ним. <a href="https://twitter.com/jh3yy/status/1252924614281486336">Я однажды пошутил</a> о создании CSS-иллюстрации доллара.</p> <p>Я использовал генератор, чтобы <a href="https://codepen.io/jh3y/details/eYpBwgN">создать иллюстрацию всего из одного <code><div></code></a>. Но Альваро Монторо <a href="https://dev.to/alvaromontoro/drawing-a-single-element-dollar-bill-with-css-and-javascript-3mj4">пошёл дальше</a> и написал генератор, который вместо этого использует <code>box-shadow</code>.</p> <h2>Препроцессоры очень полезны</h2> <p>Хоть это и не необходимо, использование препроцессоров может помочь содержать ваш код в чистоте и порядке. Например, Pug позволяет писать HTML быстрее, особенно когда нужно использовать циклы для работы с группой повторяющихся элементов. А дальше мы можем <a href="https://css-tricks.com/the-power-and-fun-of-scope-with-css-custom-properties/">ограничить кастомные CSS-свойства</a> таким образом, чтобы нужно было определить стили всего один раз, а затем переопределять их при необходимости.</p> <p>Вот другой пример, который демонстрирует структуру по принципу DRY. Цветы свёрстаны с одинаковой разметкой, но каждый имеет свой собственный класс с индексом, который используется для переопределения CSS-свойств.</p> <p>У первого цветка такие свойства:</p> <pre><code tabindex="0" class="language-css">.flower--1 { --hue: 190; --x: 0; --y: 0; --size: 125; --r: 0; } </code></pre> <p>Это первый, все остальные основаны на нём. Обратите внимание, что второй цветок немного смещён вправо и вверх. Всё, что нужно, это дать разные значения тем же кастомным свойствам:</p> <pre><code tabindex="0" class="language-css">.flower--2 { --hue: 320; --x: 140; --y: -75; --size: 75; --r: 40; } </code></pre> <figure> <figcaption> Анимированный отзывчивый CSS Leif попал в последний CodePen Spark! ✨ Для тех, кто не знаком с Animal Crossing, Leif — ленивец с зелеными пальцами, который посещает ваш остров 🌻 Вот таймлапс! 📹 <a href="https://twitter.com/jh3yy/status/1262856791873945601">@jh3yy</a> </figcaption> </figure> <h2>Вот и всё!</h2> <p>Продолжайте, используйте эти советы, придумывайте свои собственные, делитесь ими, а также делитесь своими CSS-шедеврами! И, эй, если у вас есть свои лайфхаки, пожалуйста, делитесь ими тоже! Это определённо то, чему учатся методом проб и ошибок. То, что работает у меня, может отличаться от того, что работает у вас, и мы можем учиться на этих разных подходах.</p> </article> <article> <h1>Взгляд на JavaScript со стороны</h1> <p>Fri, 29 May 2020 00:00:00 GMT</p> <p>Сегодня я пыталась помочь другу, который сам по себе замечательный компьютерный специалист, но не в сфере JavaScript, воспользоваться JavaScript-модулем, который он нашел на GitHub. С учетом того, что последние шесть лет моя работа — исследование юзабилити и преподавание в MIT, меня просто трясет от того, что это было. Куча бесполезных неверных условий, запутанные ошибки и отсутствие правильной обратной связи. И я не чувствую, что хорошо справилась с объяснением той фрустрации, через которую он проходил час, пока не сдался.</p> <p>Всё происходило приблизительно так…</p> <p><em>Замечание: имена пакетов и людей были изменены для защиты их конфиденциальности. Я также опустила несколько проблем, с которыми он столкнулся, так как они слишком специфичны для данного пакета. Некоторые ошибки воссозданы по памяти, так что дайте знать, если я в чём-то ошибаюсь!</em></p> <p><strong>Джон:</strong> Привет, я хочу проверить один алгоритм, который нашёл на GitHub. Он говорит сделать <code>import functionName from packageName</code> и потом вызвать <code>functionName(arguments)</code>. Выглядит достаточно просто! Мне не нужен UI, поэтому я собираюсь использовать Node.js!</p> <p><strong>Лия:</strong> Конечно, кажется, Node.js как раз подходит для этого!</p> <p><em>Джон запускает <code>npm install packageName --save</code>, как написано в README пакета.</em></p> <p><em>Джон запускает <code>node index.js</code>.</em></p> <p><strong>Node:</strong> <code>Внимание: Чтобы загрузить ES модуль, установите "type": "module" в package.json или используйте расширение .mjs. Синтаксическая ошибка: Нельзя использовать выражение import вне модуля.</code></p> <p><strong>Джон:</strong> Но у меня нет package.json…</p> <p><strong>Лия:</strong> Запусти <code>npm init</code>, он его создаст!</p> <p><em>Джон запускает <code>npm init</code>, выполняет инструкции на экране, добавляет руками <code>"type": "module"</code> в сгенерированный package.json.</em></p> <p><em>Джон запускает <code>node index.js</code>.</em></p> <p><strong>Node:</strong> <code>Синтаксическая ошибка: Нельзя использовать выражение import вне модуля</code>.</p> <p>Странно, на этот раз ошибка была проброшена из внутренного модуля в проекте. ШТА?!</p> <p><strong>Лия:</strong> Ладно, к чёрту, просто запусти скрипт в браузере. Это ES6-модуль, просто обычный JS-алгоритм, который не использует никакие Node.js API. Должно сработать.</p> <p><em>Джон создаёт простую index.html с <code><script type="module" src="index.js"></code>.</em></p> <p><em>Джон запускает index.html в браузере.</em></p> <p>В консоли ничего. Тишина. Сверчки. 🦗</p> <p><strong>Лия:</strong> Оу, тебе нужно уточнить путь до модуля, чтобы подключить <code>packageName</code>. Node.js делает всякое специальное, чтобы получить пакет из node_modules. Сейчас ты в браузере, поэтому нужно самому указать точный путь.</p> <p><em>Джон смотрит в файловую систему, но там нет никакой папки node_modules.</em></p> <p><strong>Лия:</strong> Оу, ты запускал <code>npm install</code> до того, как у тебя появился package.json, это скорее всего оно! Попробуй запустить ещё раз!</p> <p><em>Джон запускает <code>npm install packageName --save</code> ещё раз.</em></p> <p><strong>Джон:</strong> Ура, node_modules появилась!</p> <p><em>Джон отчаянно ищет в node_modules точку входа.</em></p> <p><em>Джон редактирует index.js, перезагружает index.html.</em></p> <p><strong>Firefox:</strong> <code>Incorrect MIME type: text/html</code>.</p> <p><strong>Лия:</strong> Оу, ты смотришь через <code>file://</code>! Чувак, как ты живёшь без localhost? JavaScript сейчас сильно ограничен внутри <code>file://</code>.</p> <p><strong>Джон:</strong> Но зачем мне… ладно, я запущу localhost.</p> <p><em>Джон запускает localhost, открывает index.html по пути <code>http://localhost:80</code>.</em></p> <p><strong>Firefox:</strong> <code>Incorrect MIME type: text/html</code>.</p> <p><strong>Джон:</strong> Уф. Мне нужно настроить localhost, чтобы JS-файлы раздавались с MIME-типом <code>text/javascript</code>?</p> <p><strong>Лия:</strong> Что? Нет! Он это умеет. Хм… посмотри во вкладку Networks, я подозреваю, он не может найти твой модуль и возвращает HTML страничку для 404, поэтому оно ругается, так как MIME-тип страницы не <code>text/javascript</code>.</p> <p><em>Смотрит в node_modules снова, исправляет путь. Оказывается, VS Code схлопывает папки, в которых только одна подпапка, поэтому мы и не заметили сразу.</em></p> <p>Если кому интересно: я правда думаю, что это полезное улучшение VS Code, оно увеличивает эффективность. Но им действительно стоит сделать его более явным, чтобы такого не случалось.</p> <p><strong>Firefox:</strong> <code>SyntaxError: missing ) after formal parameters</code>.</p> <p><strong>Лия:</strong> Что? Это приходит из кода пакета, это не твоя ошибка. Я не понимаю… Можем мы посмотреть на эту строчку?</p> <p><em>Джон кликает на строчку, которая бросает ошибку.</em></p> <p><strong>Лия:</strong> Боже мой. Это не JavaScript, это TypeScript! С расширением .js!!</p> <p><strong>Джон:</strong> Я просто хотел запустить одну строчку кода, чтобы протестировать алгоритм… 😭😭😭</p> <p><em>Джон сдаётся. Решает больше никогда не прикасаться к Node.js, npm или ES6-модулям даже длинной палкой.</em></p> <p>Конец.</p> <p>Обратите внимание, что Джон — компьютерный специалист, который знает достаточно много про веб: у него установлены Node.js и npm, он знает, что такое MIME-типы, он может запустить localhost для своих нужд. А как быть тем, кто и правда новичок?</p> </article> <article> <h1>Разработчика, который писал на чистом HTML и CSS в «Блокноте», признали колдуном</h1> <p>Tue, 26 May 2020 00:00:00 GMT</p> <p>Младший веб-разработчик в ООО «Масштабируемые решения для энтерпрайза» Кристофер Эбаут-Бланк привлёк к себе пристальное внимание коллег. Вскоре понадобилось вмешательство топ-менеджмента. Причина произошедшего звучит научно-фантастически: Кристофер умудрился создать сайт на чистом HTML и CSS прямо в «Блокноте».</p> <p>Через неделю Кристофера повысили до старшего веб-разработчика. Не прошло много времени, и команда DevOps была расформирована, поскольку, ко всеобщему удивлению, продукт Кристофера не требовал столько вычислительных мощностей, как предполагалось ранее.</p> <p>Однако впоследствии в трагической череде событий Кристофер был уволен из компании без выходного пособия, а Верховный суд без особых разбирательств официально признал его колдуном.</p> <p>«Казалось, что законы физики не применимы к Кристоферу, — говорит один из его коллег, пожелавший остаться анонимным. — Я посмотрел на его монитор и сначала подумал — как мило! Но потом он открыл браузер, всё заработало, и я почувствовал глубокий экзистенциальный ужас, расползающийся внутри».</p> <p>В настоящее время Кристофер проходит лечение в удалённом буткэмпе для кодеров в Колорадо.</p> </article> <article> <h1>«Мы можем быть не только массажистами». Как люди с нарушениями зрения учатся делать сайты доступными</h1> <p>Tue, 19 May 2020 00:00:00 GMT</p> <p>На протяжении двух месяцев во львовском SoftServe училась группа студентов на новом для их IT Academy направлении. Тут готовили пятерых профессионалов по тестированию доступности (Accessibility Testing).</p> <p>Журналисты <a href="https://dou.ua/">DOU</a> побывали на одном из занятий и узнали, какие именно знания получают будущие тестировщики, в чем особенность тестирования доступности и зачем готовить таких специалистов.</p> <h2>Шахматист</h2> <p>В помещении SoftServe IT Academy с минуты на минуту начнется занятие. По коридору быстро шагает парень и случайно задевает плечом двери. Это Владислав Колпаков, один из студентов курса по тестированию доступности, который стартовал в академии два месяца назад. В руках парень держит трость, а темные очки не снимает даже в помещении.</p> <p>Влад начал терять зрение ещё в детстве. Но это не помешало ему окончить философский факультет Львовского университета им. Франко и добиться успеха в шахматах. Сегодня он — игрок и тренер сборной Украины по шахматам среди людей с нарушением зрения. А ещё в скором времени Влад станет профессиональным тестировщиком сайтов на доступность.</p> <p>Для парня это первые IT-курсы. Ранее с компьютером он был знаком на уровне обычного пользователя. А теперь с помощью скринридера и полученных знаний сможет с лёгкостью отличить доступный сайт от недоступного, на котором человек с нарушением зрения не сможет найти нужный товар или войти в систему.</p> <p>«Я сомневался, стоит ли идти на курсы, ведь последние несколько лет у меня неплохой прогресс в шахматах. А эти занятия требуют большой отдачи, много энергии и времени. Собственно, я понимал, что придётся чем-то пожертвовать, поэтому решение принялось нелегко. Но когда есть возможность, ею нужно воспользоваться», — говорит Владислав Колпаков.</p> <figure> <figcaption>Владислав Колпаков</figcaption> </figure> <h2>Рынок, закон и доступность</h2> <p>Тестирование доступности — это тип тестирования программного обеспечения, которое применяют, чтобы сайт, приложение или что-либо ещё были удобными для использования людьми с нарушением зрения или слуха, поражением опорно-двигательного аппарата, памяти и тому подобного. Специалисты по такому виду тестирования проверяют, соответствует продукт критериям, изложенным в <a href="https://www.w3.org/WAI/standards-guidelines/wcag/">Web Content Accessibility Guidelines</a> (WCAG). Этот документ — часть из серии руководящих принципов о доступности веб-страниц, которые разработали в <a href="https://www.w3.org/">W3C</a>.</p> <p>Контрастность цветов, размер шрифтов, заголовки разделов, аудиосопровождение страницы, анимация от взаимодействий и корректность многих параметров — всё это описано в документе. Задание тестировщика доступности — определить, где существуют проблемы.</p> <p>Толчком для создания курсов по тестированию доступности в SoftServe стали требования рынка и законодательства.</p> <p>Виктория Ширяева, представительница бизнес-подразделения, Senior QA и Project Manager, уже на протяжении двух лет работает с проектами SoftServe, которые внедряют доступность.</p> <p>«В Соединённых Штатах приблизительно у каждого четвёртого есть та или иная форма инвалидности. Так что это гигантский рынок, который потенциально можно потерять. Это бизнес-драйвер. Есть и законодательные драйверы — требования, согласно которым сайты должны быть доступными. Иначе их не допустят к использованию. Особенно строго это регулируется в Америке. В последние годы к этому вопросу более внимательно относится и Европа», — объясняет специалистка.</p> <p>По её словам, сегодня действует директива Европарламента, где прописано, что европейские страны должны принять закон, который требовал бы от всех публичных сайтов быть доступными. А к 2021 году, согласно документу, необходимо сделать такими и мобильные приложения.</p> <p>«Так что мы поняли, что это не только благородная цель — помочь с трудоустройством людям с инвалидностью, но и большая потенциальная возможность для SoftServe предоставлять необходимые услуги уже существующим клиентам, а также новым, которые могут обратиться к нам», — подытоживает Виктория.</p> <h2>Активист</h2> <p>Роману Савке — 34. 15 лет назад он учился во «Львовской политехнике», где осваивал компьютерные науки. 10 лет назад занимался художественным кузнечеством. Два месяца назад впервые познакомился с командой SoftServe и узнал, что такое тестирование доступности.</p> <figure> <figcaption>Роман Савка</figcaption> </figure> <p>Проблемы со зрением у Романа начались во взрослом возрасте. Из-за этого даже пришлось бросить одно из любимых занятий — дзюдо. Врачи сказали, что из-за интенсивных тренировок зрение станет только хуже и есть вероятность его полностью потерять. Сейчас мужчина распознает свет и тени, так что-то, как он ориентируется в пространстве, зависит от времени суток и освещения.</p> <p>Сегодня Роман возглавляет организацию «Равные возможности для всех», которая предоставляет юридические консультации в вопросах защиты прав человека. Со временем её участники планируют разработать рекомендации для правительства, чтобы более эффективно внедрять нормы Конвенции ООН по правам человека на просторах Украины.</p> <p>А ещё Роман отец двоих детей и единственный кормилец в семье, так как жена находится в декретном отпуске. Поэтому решиться на курсы было непросто: вдруг не хватит навыков, времени или знаний?</p> <p>«Я не думал, что дойду именно до обучения, тем более до финального этапа. Дело в том, что я не так давно пользуюсь скринридером и не было опыта интенсивной работы с компьютером», — говорит мужчина.</p> <p>Теперь Роман ощущает себя более уверенным в своих умениях. Курс по тестированию доступности — это три часа занятий в аудитории IT Academy три раза в неделю и регулярные домашние задания. Время, проведённое в аудитории и ночью за домашним ПК, принесло свои результаты. Сегодня Роман разве что шутит, что постоянно ставит кучу вопросов преподавательницам. А они и рады. Говорят, если есть вопросы, значит, человеку действительно интересно, он хочет разобраться в предмете.</p> <h2>Компьютер, английский и мотивация</h2> <p>Найти таких, как Роман и Владислав, было непросто, хоть и требования к потенциальным участникам курса были невысоки:</p> <ul> <li>знать компьютер на уровне уверенного пользователя;</li> <li>владеть английским не ниже уровня Intermediate;</li> <li>быть мотивированным.</li> </ul> <p>«Больше всего людей отсеялось из-за английского. Это не наша прихоть, а реалии рынка, поскольку украинских заказчиков нет. А участникам придётся не только читать литературу, чтобы разобраться в теме, но и общаться с заказчиком или его представителями», — объясняет менторка SoftServe IT Academy Виктория Ряжская.</p> <p>Умений или знаний в тестировании от кандидатов не требовали. Но они должны были уметь элементарные вещи: найти тот или иной сайт, зарегистрироваться на нём и так далее. Всё это — с использованием скринридера, лупы или другой программы, которая помогает людям с нарушением зрения пользоваться компьютером. Это и было одним из тестовых заданий, которое приближало на шаг к месту на курсах.</p> <p>«У нас была девочка со зрением −13. Но мы не смогли её взять, потому что она не использовала никакой вспомогательный инструмент. Она впритык подходила к монитору, чтобы увидеть текст, изображение. Но таким образом девушка ознакамливалась с сайтом как обычный пользователь и не смогла протестировать его на предмет доступности», — уточняет Виктория Ряжская.</p> <p>Мотивация тоже важна для того, чтобы попасть на курс, поскольку программа, как отмечают представители IT Academy, не так проста. Особенность курса в том, что он содержит в себе много информации, которую нужно освоить за короткое время. Студенты постоянно работают, каждую неделю пишут тесты, делают домашние задания, а ещё должны уделять время своим собственным делам. Поэтому, чтобы доучиться до конца и получить знания, нужно действительно этого хотеть.</p> <p>«Мы даже нашим студентам говорим: пойдёте на работу, тогда и отдохнёте. Потому что на работе ты работаешь и выкладываешься на полную 8 часов, а во время учёбы на курсах нужно заниматься постоянно — и в аудитории, и дома. И далеко не все, кто подавал заявку, были уверены в своих силах. А некоторые не были готовы принимать что-то новое», — добавляет Виктория.</p> <p>Всего, говорят организаторы, было около 30 заявок, но желающих — намного больше. Одна из преград — нужно было физически находиться во Львове и посещать каждое занятие, а не все могут самостоятельно передвигаться.</p> <p>«Хоть мы и так старались максимально упростить этот момент. Волонтёры привозили людей. Мы не проводили длительные собеседования тет-а-тет с каждым потенциальным участником. Один раз собрали всех. Рассказали на общей встрече о компании, курсах и о требованиях. Потом — двухминутный разговор на английском, чтение короткого текста, его пересказ своими словами и небольшое тестовое задание», — говорит Виктория Ряжская.</p> <h2>Филолог</h2> <figure> <figcaption>Иван Яцига</figcaption> </figure> <p>Одним из пяти, кого отобрали, стал 24-летний Иван Яцига. Парню даже пришлось отказаться от занятий репетиторством: он готовил учеников к школьным экзаменам по украинскому языку и литературе.</p> <p>Не так давно Иван окончил Львовский национальный университет им. Ивана Франко. Теперь он филолог, а репетиторство — его основной источник дохода.</p> <p>«Но я не раздумывал над тем, стоит ли идти на курсы. Репетиторство хоть и основной, но не постоянный заработок. А найти работу сегодня, тем более человеку с инвалидностью, сложно. Я хорошо учился, окончил университет, получил диплом… Впрочем, оказалось, что в реальной жизни филолог не очень кому-то нужен. Я ходил на собеседования в школы, и мне отказывали», — вспоминает Иван.</p> <p>Иван считает, трудоустройство человека с инвалидностью — проблема на государственном уровне, она глобальна.</p> <p>«Если посмотреть на перечень профессий, то по большей части люди с нарушением зрения могут быть или массажистами, или… массажистами!» — отмечает студент.</p> <p>Так что курсы для него — реальный шанс трудоустроиться.</p> <p>«Мне как филологу, конечно, вначале было смешно от таких слов, как „зашедулить“, „саппортить“. Но потихоньку привык», — с улыбкой добавляет будущий тестировщик.</p> <p>По словам Ивана Яциги, у курса есть существенное преимущество перед классическим университетским образованием. Тут ты учишься чему-то новому за короткий срок и, если у тебя что-то не получается или что-то не нравится, всегда можно поменять направление. И не надо тратить пять лет жизни, а потом не знать, что делать с этим дипломом.</p> <p>Правда, теперь парень шутит: пока не пришёл на курсы, пользовался сайтами нормально. А теперь куда не посмотришь — всё недоступное, ведь в голове держишь критерии оценки веб-ресурсов.</p> <h2>Теория, практика и результаты</h2> <p>Программа курса по тестированию доступности состоит из теории и практики и в целом похожа на ту, по которой в SoftServe обучают обычных тестировщиков.</p> <p>«Наверно, девяносто процентов — это та информация, которую мы даём будущим ручным тестировщикам. А вторая часть — именно тестирование доступности. Естественно, её обычные тестеры не проходят», — уточняет менторка IT Academy Виктория Ряжская. Сначала студентов ознакомили с критериями доступности сайтов и приложений согласно <abbr title="Web Content Accessibility Guidelines">WCAG</abbr>, демонстрировали различные кейсы. Потом перешли к практической работе, как на проекте.</p> <p>«Каждую неделю у нас проходит тест по теории. И интересно, что у студентов этой группы оценка выше, чем у остальных, хоть они выполняют те же задания. Единственное отличие — им дают полтора часа на выполнение, а не час, потому что наш тест не рассчитан на людей с нарушениями зрения и им сложно ориентироваться в навигации», — говорит преподавательница.</p> <p>В конце курса студенты курса сдают финальный тест и должны презентовать собственный проект.</p> <h2>Англоязычный</h2> <p>Олег Шапай — один из тех, кого тестирование по иностранному языку во время отбора точно не испугало, потому что в университете он изучал английский и немецкий.</p> <p>«Мне очень вовремя предложили этот курс, потому что я как раз искал работу и думал, что стоит найти то, что будет связано с компьютерами. Согласился на курсы не в последнюю очередь потому, что в Украине и в мире в общем существует большая проблема с доступностью», — уверен Олег.</p> <figure> <figcaption>Олег Шапай</figcaption> </figure> <p>Ещё до обучения парень давал рекомендации компаниям по поводу того, как сделать сайты более удобными для людей с нарушениями зрения. Однако всё это было на уровне обычного пользователя и базировалось на личном восприятии.</p> <p>«Иногда было тяжело объяснить разработчику, в чём проблема. А теперь у меня есть фундаментальная база и я знаю, в каких именно документах находятся объяснения и требования», — добавляет он.</p> <p>Достаточно большое количество домашних заданий на курсах Олега не останавливает. Говорит, что и так много времени проводил за монитором, а теперь может делать это с пользой. Единственная вещь, которая ему не нравится, — необходимость много писать. Парень признается: не любил этого ещё в университете, но тут уже никуда не денешься.</p> <p>«Что-то протестировать — легко, а вот писать… Пришлось смириться», — с улыбкой отмечает он.</p> <p>Студент говорит, что важно не просто хотеть, чтобы чем-то было удобно пользоваться, а попробовать изменить ситуацию.</p> <p>«Например, мы видим, что сайт недоступен. А хочется, чтобы было иначе. Так давайте сделаем его доступным! Но не только для себя, а для всех. Собственно, это одна из тех вещей, которая мотивирует меня учиться тут и двигаться дальше», — говорит Олег Шапай.</p> <h2>Выпуск и планы</h2> <p>В конце обучения команда взялась тестировать сайт SoftServe. Работают по Agile-методологии, используют Scrum: с митингами для планирования, выполнением заданий и заполнением документации.</p> <p>Виктория Ряжская говорит, что этот выпуск — уже настоящие эксперты в <abbr title="Web Content Accessibility Guidelines">WCAG</abbr>. Она радуется результатам команды и твердит, что у студентов удивительная память.</p> <p>«Есть 50 критериев, по которым можно проверять сайт на доступность. В документе, который мы используем, они сгруппированы и пронумерованы. И если я попрошу кого-то из наших студентов назвать критерий, например, 1.3.2, то человек не только скажет, что это, но и даст детальное описание, нюансы, когда этот критерий может не применяться, и приведет примеры. Я эти цифры не могу запомнить, а у них всё в голове, будто по полочкам разложено», — отмечает менторка.</p> <p>На данный момент основной план компании — трудоустроить выпускников на проекты SoftServe. Говорят, если всё пройдет успешно и будет много запросов по тестированию доступности, то второй набор точно откроют. Но пока что из-за карантина этот процесс затягивается, поскольку нет возможности организовать выпускникам онбординг и надлежаще обустроить рабочие места.</p> <p>«Думаю, если бы мы запускали новый набор, имея такой хороший пример, было бы намного больше желающих и меньше сомнений в том, что такое возможно. Поэтому будем работать на этот результат. Тем более, что у нас уже есть хороший опыт», — говорит Виктория Ширяева.</p> <p>Олег Шапай убеждён: если их группа получит достойную работу, то покажет, что можно и нужно ломать стереотипы.</p> <p>«Люди должны понимать, что мы можем быть не только массажистами и преподавателями. IT открыто для всех. И было бы круто, если как можно больше людей с инвалидностью могли научиться всему, что связано с технологиями. То, что происходит сейчас, это классно и вселяет надежду», — говорит Олег.</p> </article> <article> <h1>Можно ли вложить тег в тег? Об инструменте Can I Include</h1> <p>Tue, 05 May 2020 00:00:00 GMT</p> <p>На создание этого инструмента меня вдохновила <a href="https://htmlacademy.ru/">HTML Academy</a> и их стремление к чистоте вёрстки и строгим стандартам. В их <a href="https://htmlacademy.ru/intensive/htmlcss">курсе по вёрстке</a> вкладывание тегов объясняется примерами <a href="https://html.spec.whatwg.org/">из спецификации</a>, что не очень удобно. И мне пришла в голову идея: упростить доступ к информации о тегах и придумать простой механизм проверки возможности вкладывать теги. Далее — история создания онлайн-инструмента <strong><a href="https://caninclude.glitch.me/">Can I Include</a>.</strong></p> <h2>Технологии</h2> <p>Сразу встал вопрос, какие технологии использовать, а главное на каком хостинге разворачивать проект. Хотелось чего-то лёгкого и незатейливого, без использования бабелей, парселей и вебпаков, в душе зарождался дух свободы и бунтарства.</p> <h3>Про вёрстку</h3> <p>Подумав немного, понял, что старый добрый <a href="https://github.com/preactjs/preact">Preact</a> c его подходом к Server Side Rendering через <a href="https://github.com/developit/htm">Hyperscript Tagged Markup</a> поможет в разделении частей страниц на компоненты. При этом решил, что на первых порах стоит обойтись без клиентского JS, использовать на клиенте только CSS и HTML.</p> <h3>Про стили</h3> <p>Не стал использовать препроцессоры и отдал предпочтение <strong>raw</strong> CSS как есть, в одном файле.</p> <h3>Про серверную часть</h3> <p>Мой любимый <a href="https://expressjs.com/">Express.js</a> и <a href="https://nodejs.org/en/">Node.js</a>.</p> <h3>Хостинг</h3> <p>Выбрал <a href="https://glitch.com/">glitch.com</a>. Он даёт возможность кодить в браузере и открывает доступ к результатам работы любым желающим. Поддерживает Node.js и возможность доступа к контейнеру через веб-консоль прямо из редактора кода. И, что самое главное, он основан на <a href="https://www.docker.com/">Docker</a>. У меня уже был ранее отработанный простой механизм поставки изменений, и это тоже радовало. Вдобавок ко всем удобствам, <a href="https://glitch.com/">glitch.com</a> добавил <a href="https://glitch.com/pricing">тариф с возможностью бустинга 5 приложений</a>, я тут же поспешил им воспользоваться.</p> <h3>Скрейпинг</h3> <p>Ну куда же без скрейпинга! Без него никуда. Данные нужно извлечь из <a href="https://html.spec.whatwg.org/">спецификации HTML</a> и обработать напильником в удобоваримую структуру для доступа к данным. Для скрейпинга использовал свой любимый инструмент — <a href="https://github.com/puppeteer/puppeteer">Puppeteer</a>.</p> <h2>Реализация</h2> <p>Мне понадобилось пара дней на то, чтобы пройти от генерации идеи до её реализации. Я ни разу не дизайнер, так что заимствовавал идеи уже давно существующих веб-сайтов. В итоге получился простой и ёмкий, в плане отображения информации, интерфейс.</p> <p>В ходе скрейпинга увидел дополнительную информацию с сайтов <a href="https://caniuse.com/">Сan I Use</a> и <a href="https://developer.mozilla.org/">MDN</a> по каждому тегу, расположенную на странице <a href="https://html.spec.whatwg.org/">спецификации HTML</a> в виде небольших бейджиков. В итоге решил разместить информацию о поддержке тегов разными браузерами сразу под сравниваемыми тегами. Чтобы, как говорится, всё было под рукой, в развёрнутом виде.</p> <p>Так как не использовал JS на клиенте, то в мобильном представлении сделал переключение табов со сравниваемыми тегами с помощью CSS-селекторов.</p> <h2>Принцип работы</h2> <p>Так как основная цель — удобно показать информацию о двух сравниваемых тегах, то для старта я решил реализовать простой способ проверки. Информация, представленная в спецификации, больше приспособлена для понимания человеком, чем машиной — хотя и человеку нужно приложить усилия, чтобы сопоставить несколько условий и решить, можно ли вкладывать теги.</p> <p>Для принятия решения о возможности вложения одного тега в другой необходимо сопоставить содержание секций сравниваемых тегов.</p> <ul> <li>У вкладываемого тега нужно проверить секцию <strong>Categories,</strong> а у родительского тега — <strong>Content model.</strong></li> <li>В простом случае, наличие одного из пуктов из секции <strong>Categories</strong> в секции <strong>Сontent model,</strong> даёт положительный результат.</li> <li>В случае с контентной моделью <strong>Transparent</strong> в секции <strong>Content model</strong> родительского тега, нужно обратить внимание на <strong>Content model</strong> <strong>родителя</strong> нашего родительского тега. То есть в таком случае вам нужно самостоятельно проверить следующий родительский тег из вашей разметки.</li> <li>Есть и более сложный случай, где есть несколько «но». Порой некторые атрибуты меняют возможность вкладывания.</li> </ul> <p>Теперь про простой алгоритм проверки вложенности тегов:</p> <ol> <li>Во время скрейпинга в секциях каждого тега создаётся множество ключевых слов, в которое входят названия контентной модели, имена атрибутов и тегов.</li> <li>Если в секции есть <strong>Nothing</strong>, то в множество ключевых тегов включается название тега.</li> <li>Если есть модель <strong>Transparent</strong> в секции <strong>Content model</strong> родительского тега, то ситуация с включением тега не определена. В этом случае выдаётся сообщение, что нужно взять из разметки следующий внешний тег и повторить запрос. При этом следующий пункт не выполняется.</li> <li>Далее производится проверка на пересечение множеств: <ul> <li>если найдены общие ключевые слова — <strong>положительный вердикт,</strong> теги можно вкладывать.</li> <li>если нет пересекающихся ключевых слов — <strong>отрицательный вердикт,</strong> теги нельзя вкладывать.</li> </ul> </li> </ol> <h2>Интерфейс</h2> <p>При обращении по адресу <strong>caninclude.glitch.me</strong> открывается следующая страница:</p> <p>Весёлый текстовый логотип и два поля встречают пользователя: в левом нужно ввести название тега, который вы вкладываете, в правом — тега, в который вы вкладываете. После этого, нужно нажать клавишу <kbd>Enter</kbd> или кликнуть по кнопке с вопросом.</p> <p>В результате отправки формы по методу GET рендерится страница с информацией по двум тегам и вердиктом о вложенности.</p> <p>Если определить возможность вкладывания не получилось из-за «прозрачной» контентной модели внешнего тега, то страница будет выглядеть так:</p> <p>В случае, если вкладывать теги нельзя, то страница с вердиктом будет выглядеть так:</p> <h2>Итог</h2> <p>Надеюсь, что онлайн-инструмент <a href="https://caninclude.glitch.me">Сan I Include</a> пригодится вам. Ещё много работы предстоит по улучшению интерфейса и расширению функциональности, а также по совершенствованию механизма определения вложенности. Спасибо коллективу <a href="https://htmlacademy.ru/">HTML Academy</a> за борьбу за грамотность вёрстки и что вдохновили меня на создание этого инструмента. Также в планах организовать обратную связь, чтобы получать замечания и пожелания.</p> </article> <article> <h1>Ускоряемся с помощью Browserslist</h1> <p>Sun, 19 Apr 2020 00:00:00 GMT</p> <p>На сегодняшний день имеется большое количество разных браузеров и ещё большее количество версий каждого из них. Если раньше новые фичи добавлялись в браузеры редко, то сейчас их можно обнаружить практически с каждым новым релизом. Как итог, у разных версий браузера — разная поддержка фич, не говоря уже о разном уровне поддержки среди разных вендоров.</p> <p>Разработчикам хочется использовать новые фичи, так как зачастую это упрощает жизнь. Благодаря инструментам разработки можно использовать фичи до их появления в браузерах путём транспиляции и использования полифилов. Также эти инструменты гарантируют работу сайта в любом браузере независимо от того, имеется ли в нём поддержка той или иной фичи. Из примеров: <a href="https://github.com/postcss/autoprefixer">Autoprefixer</a> и <a href="https://preset-env.cssdb.org">postcss-preset-env</a> для CSS, <a href="https://babeljs.io">Babel</a> для JavaScript. Но нужно понимать, что при этом размер кода увеличивается.</p> <p>В итоге мы имеем сайт, который работает в любом браузере, но из-за этого загружается медленнее, чем мог бы. Напомню, что скорость загрузки и работы сайта напрямую влияет на количество и глубину просмотров. Что с этим можно сделать? На самом деле нам незачем транспилировать и полифилить абсолютно все фичи — достаточно это делать только с теми, которые не поддерживаются актуальными браузерами (или актуальными для аудитории вашего сайта). Например, промисы не поддерживаются только очень старыми версиями браузеров.</p> <h2>Browserslist</h2> <p><a href="https://github.com/browserslist/browserslist">Browserslist</a> — это тот инструмент, с помощью которого можно описать целевые браузеры веб-приложения, используя простые выражения:</p> <pre><code tabindex="0">last 2 years > 1% not dead </code></pre> <p>Этот пример файла <code>.browserslistrc</code> означает, что вам нужны: браузеры за последние два года, плюс браузеры у которых больше 1% пользователей, и все эти браузеры должны быть «живыми». Посмотреть в какие конкретные браузеры это разрезолвится можно на сайте <a href="https://browserl.ist/">browserl.ist</a>, а более подробно узнать про синтаксис выражений можно <a href="https://github.com/browserslist/browserslist">на странице проекта</a>.</p> <p>Уже упомянутые <a href="https://github.com/postcss/autoprefixer">Autoprefixer</a>, <a href="https://preset-env.cssdb.org">postcss-preset-env</a> и <a href="https://babeljs.io/docs/en/babel-preset-env">babel-preset-env</a> под капотом используют Browserslist, и если в вашем проекте есть конфиг Browserslist, то код проекта будет собран под эти браузеры.</p> <p>На этом этапе можно прийти к следующему выводу: чем новее браузеры, в которые мы целимся, тем меньше будет весить итоговый код сайта. При этом нужно не забывать, что в реальном мире не у всех пользователей самый новый браузер, и сайт должен быть доступен если не всем пользователям, то большинству из них. Как можно поступить, учитывая это условие?</p> <h2>Варианты таргетирования браузеров</h2> <h3>1. Более узкое таргетирование</h3> <p>По умолчанию, если в проекте нет конфига, то Browserslist будет использовать <code>defaults</code> браузеры. Это выражение является сокращением для <code>> 0.5%, last 2 versions, Firefox ESR, not dead</code>. В целом, можно остановиться на использовании этого выражения, и со временем браузеры, подходящие под это выражение, станут поддерживать большинство актуальных фич.</p> <p>Но можно целиться в более узкое количество браузеров: исключить старые и непопулярные, учитывать более-менее актуальные версии браузеров. Звучит просто, но на самом деле это не так. Необходимо сбалансировать конфиг Browserslist так, чтобы он, опять же, покрывал большую часть аудитории.</p> <h3>2. Анализ аудитории</h3> <p>Если ваш сайт подразумевает использование только в определенных регионах, то можно попробовать использовать выражение вида <code>> 5% in US</code>, которое вернёт браузеры, подходящие по статистике использования в указанной стране.</p> <p>Семейство Browserslist полно разными дополнительными инструментами, один из них — <a href="https://github.com/browserslist/browserslist-ga">Browserslist-GA</a> (также есть <a href="https://github.com/xeroxinteractive/browserslist-adobe-analytics">browserslist-adobe-analytics</a>), который позволяет выгрузить из сервиса аналитики данные о браузерах, используемые посетителями вашего сайта. После этого становится возможным использовать эти данные в конфиге Browserslist и применять на них выражения:</p> <pre><code tabindex="0">> 0.5% in my stats </code></pre> <p>К примеру, если обновлять эти данные при каждом деплое, то сайт будет всегда собираться под актуальные браузеры, используемые вашей аудиторией.</p> <h3>3. Условная загрузка ресурсов</h3> <p>В марте 2019 <a href="https://twitter.com/mathias">Матиас Байненс</a> из Google <a href="https://github.com/whatwg/html/issues/4432">предложил</a> добавить в браузеры дифференциальную загрузку скриптов (differential script loading, далее DSL):</p> <pre><code tabindex="0" class="language-html"><script type="module" srcset="2018.mjs 2018, 2019.mjs 2019" src="2017.mjs"></script> <script nomodule src="legacy.js"></script> </code></pre> <p>До сих пор его предложение остается лишь предложением, и неизвестно, будет ли это в том или ином виде реализовано в браузерах. Но концепт понятен, и в семействе Browserslist есть инструменты, с помощью которых можно реализовать что-то подобное, один из них — <a href="https://github.com/browserslist/browserslist-useragent">browserslist-useragent</a>. Этот инструмент позволяет проверить User-Agent браузера на соответствие вашему конфигу.</p> <h4>Browserslist-useragent</h4> <p>В интернете уже есть несколько статей на эту тему, вот пример одной из них — <a href="https://www.smashingmagazine.com/2018/10/smart-bundling-legacy-code-browsers/">«Smart Bundling: How To Serve Legacy Code Only To Legacy Browsers»</a>. Коротко пробежимся по реализации. Для начала необходимо настроить ваш процесс сборки для вывода, например, двух версий бандлов для новых и старых браузеров. Здесь вам поможет Browserslist с его <a href="https://github.com/browserslist/browserslist#configuring-for-different-environments">возможностью объявления нескольких сред в конфигурационном файле</a>:</p> <pre><code tabindex="0">[modern] last 2 versions last 1 year not safari 12.1 [legacy] defaults </code></pre> <p>Далее необходимо настроить сервер для отдачи нужного бандла под браузер пользователя:</p> <pre><code tabindex="0" class="language-js">/* … */ import { matchesUA } from 'browserslist-useragent' /* … */ app.get('/', (request, response) => { const userAgent = request.get('User-Agent') const isModernBrowser = matchesUA(userAgent, { env: 'modern', allowHigherVersions: true }) const page = isModernBrowser ? renderModernPage(request) : renderLegacyPage(request) response.send(page) }) </code></pre> <p>Таким образом, сайт будет выдавать легковесный бандл пользователям с новыми браузерами, что приведёт к более быстрой загрузке страниц, сохраняя при этом доступность для остальных пользователей. Но, как можно было заметить, этот способ требует наличия собственного сервера со специальной логикой.</p> <h4>Module/nomodule</h4> <p>С появлением в браузерах поддержки ES-модулей появился другой способ реализовать DSL, но уже на стороне клиента:</p> <pre><code tabindex="0" class="language-html"><script type="module" src="index.modern.js"></script> <script nomodule src="index.legacy.js"></script> </code></pre> <p>Этот паттерн имеет название module/nomodule, и его суть состоит в том, что старые браузеры без поддержки ES-модулей не будут обрабатывать скрипты с типом <code>module</code>, так как этот тип им неизвестен. А браузеры, которые поддерживают ES-модули, будут загружать скрипт с типом <code>module</code> и игнорировать скрипт с атрибутом <code>nomodule</code>. Браузеры с поддержкой ES-модулей, описываются следующим конфигом:</p> <pre><code tabindex="0">[esm] edge >= 16 firefox >= 60 chrome >= 61 safari >= 11 opera >= 48 </code></pre> <p>Главным плюсом паттерна module/nomodule является отсутствие необходимости в собственном сервере — всё работает полностью на клиентской части. Загрузку стилей в зависимости от браузера таким образом не сделать, но можно реализовать загрузку ресурсов с помощью JavaScript, используя проверку вида:</p> <pre><code tabindex="0" class="language-js">if ('noModule' in document.createElement('script')) { // Новые браузеры } else { // Старые браузеры } </code></pre> <p>Из минусов: этот паттерн имеет кое-какие <a href="https://gist.github.com/jakub-g/5fc11af85a061ca29cc84892f1059fec">кроссбраузерные проблемы</a>. Также уже начинают появляться фичи, которые имеют разный уровень поддержки, даже среди браузеров с поддержкой ES-модулей, например, <a href="https://caniuse.com/#feat=mdn-javascript_operators_optional_chaining">optional chaining operator</a>. С появлением новых фич этот вариант DSL потеряет свою актуальность.</p> <p>Прочитать ещё больше про паттерн module/nomodule можно в статье <a href="https://jasonformat.com/modern-script-loading/">«Modern Script Loading»</a>. Если вас заинтересовал этот вариант DSL и хочется попробовать внедрить его в свой проект, то вы можете воспользоваться плагином для Webpack: <a href="https://www.npmjs.com/package/webpack-module-nomodule-plugin">webpack-module-nomodule-plugin</a>.</p> <h4>Browserslist-useragent-regexp</h4> <p>Относительно недавно появился ещё один инструмент для Browserslist: <a href="https://github.com/browserslist/browserslist-useragent-regexp">browserslist-useragent-regexp</a>. Этот инструмент позволяет получить из конфига регулярное выражение для проверки User-Agent браузера. Регулярные выражения работают в любой среде исполнения JavaScript, что даёт возможность проверять User-Agent браузера не только на стороне сервера, но и на стороне клиента. Таким образом, можно реализовать работающий в браузере DSL:</p> <pre><code tabindex="0" class="language-js">// last 2 firefox versions var modernBrowsers = /Firefox\/(73|74)\.0\.\d+/ var script = document.createElement('script') script.src = modernBrowsers.test(navigator.userAgent) ? 'index.modern.js' : 'index.legacy.js' document.all[1].appendChild(script) </code></pre> <p>Можно добавить, что генерируемые регулярные выражения работают быстрее, чем функция <code>matchesUA</code> из browserslist-useragent, так что есть смысл использовать browserslist-useragent-regexp и на стороне сервера:</p> <pre><code tabindex="0" class="language-js">> matchesUA('Mozilla/5.0 (Windows NT 10.0; rv:54.0) Gecko/20100101 Firefox/54.0', { browsers: ['Firefox > 53']}) first time: 21.604ms > matchesUA('Mozilla/5.0 (Windows NT 10.0; rv:54.0) Gecko/20100101 Firefox/54.0', { browsers: ['Firefox > 53']}) warm: 1.742ms > /Firefox\/(5[4-9]|6[0-6])\.0\.\d+/.test('Mozilla/5.0 (Windows NT 10.0; rv:54.0) Gecko/20100101 Firefox/54.0') first time: 0.328ms > /Firefox\/(5[4-9]|6[0-6])\.0\.\d+/.test('Mozilla/5.0 (Windows NT 10.0; rv:54.0) Gecko/20100101 Firefox/54.0') warm: 0.011ms </code></pre> <p>Все это выглядит очень здорово, но хочется иметь удобный способ встроить это в процесс сборки проекта… И такой способ есть!</p> <h4>Browserslist Differential Script Loading</h4> <p><a href="https://github.com/TrigenSoftware/bdsl-webpack-plugin">Bdsl-webpack-plugin</a> это плагин для Webpack, работающий в паре с <a href="https://github.com/jantimon/html-webpack-plugin">html-webpack-plugin</a> и использующий <a href="https://github.com/browserslist/browserslist-useragent-regexp">browserslist-useragent-regexp</a>, который помогает автоматизировать добавление в бандл дифференциальной загрузки. Вот пример конфига для Webpack с применением этого плагина:</p> <pre><code tabindex="0" class="language-js">const { BdslWebpackPlugin, getBrowserslistQueries, getBrowserslistEnvList } = require('bdsl-webpack-plugin') function createWebpackConfig(env) { return { name: env, /* … */ module: { rules: [{ test: /\.js$/, exclude: /node_modules/, loader: 'babel-loader', options: { cacheDirectory: true, presets: [ ['@babel/preset-env', { /* … */ targets: getBrowserslistQueries({ env }) }] ], plugins: [/* … */] } }] }, plugins: [ new HtmlWebpackPlugin(/* … */), new BdslWebpackPlugin({ env }) ] }; } module.exports = getBrowserslistEnvList().map(createWebpackConfig) </code></pre> <p>В этом примере экспортируется <a href="https://webpack.js.org/configuration/configuration-types/#exporting-multiple-configurations">несколько конфигов</a> для вывода бандлов для каждой среды из конфига Browserslist. На выходе мы получим HTML-файл со встроенным DSL-скриптом:</p> <pre><code tabindex="0" class="language-html"><!DOCTYPE html> <html> <head> <title>Example</title> <script>function dsl(a,s,c,l,i){c=dsld.createElement('script');c.async=a[0];c.src=s;l=a.length;for(i=1;i<l;i++)c.setAttribute(a[i][0],a[i][1]);dslf.appendChild(c)}var dsld=document,dslf=dsld.createDocumentFragment(),dslu=navigator.userAgent,dsla=[[]];if(/Firefox\/(73|74)\.0\.\d+/.test(dslu))dsl(dsla[0],"/index.modern.js") else dsl(dsla[0],"/index.legacy.js");dsld.all[1].appendChild(dslf)</script> </head> <body></body> </html> </code></pre> <p>Помимо загрузки скриптов есть поддержка <a href="https://github.com/TrigenSoftware/bdsl-webpack-plugin/tree/master/examples/postcss-preset-env">загрузки стилей</a>. Также имеется возможность использовать этот плагин <a href="https://github.com/TrigenSoftware/bdsl-webpack-plugin/tree/master/examples/SsrBdslWebpackPlugin">на стороне сервера</a>.</p> <p>Но, к сожалению, есть и кое-какие нюансы, о которых нужно знать при использовании bdsl-webpack-plugin: так как загрузка скриптов и стилей инициализируется из JavaScript, то они загружаются асинхронно без блокировки рендеринга и т. д. К примеру, в случае скриптов — это означает невозможность использования атрибута <code>defer</code>, а для стилей — необходимость скрывать контент страницы до момента полной загрузки стилей. Про то, как можно обойти эти нюансы, и про другие возможности данного плагина можно прочитать в <a href="https://github.com/TrigenSoftware/bdsl-webpack-plugin/blob/master/README.md">документации</a> и в <a href="https://github.com/TrigenSoftware/bdsl-webpack-plugin#examples">примерах использования</a>.</p> <h2>Транспиляция зависимостей</h2> <p>Из уже прочитанной части статьи мы узнали несколько способов того, как с помощью Browserslist можно уменьшить размер <em>собственного</em> кода сайта, но остаётся другая часть итогового бандла — зависимости. В веб-приложениях размер зависимостей в итоговом бандле может занимать весомую часть.</p> <p>По умолчанию, процесс сборки должен избегать транспиляцию зависимостей, так как тогда сборка будет занимать много времени, да и сами зависимости, если их исходники используют неподдерживаемый синтаксис, обычно распространяются уже транспилированными. На практике же можно выделить три типа пакетов:</p> <ol> <li>c транспилированным кодом;</li> <li>c транспилированным и исходным кодом;</li> <li>c кодом на актуальном синтаксисе только для новых браузеров.</li> </ol> <p>С первым типом, очевидно, ничего сделать не получится. Второй — нужно настроить бандлер для работы только с исходной версией кода в пакете. Третий тип — для работы кода даже в не очень актуальных браузерах всё равно необходимо транспилировать.</p> <p>Так как общепринятого способа делать пакеты с несколькими версиями бандла нет, то опишу как я делаю такие пакеты: обычная транспилированная версия имеет расширение <code>.js</code>, и главный файл записывается в поле <code>main</code> файла <code>package.json</code>, а версия бандла без транспиляции имеет расширение <code>.babel.js</code>, и главный файл записывается в поле <code>raw</code>. Вот реальный пример — пакет <a href="https://unpkg.com/browse/canvg/">Canvg</a>. Но можно делать и по-другому, например, как это сделано <a href="https://unpkg.com/browse/preact/">в пакете Preact</a> — исходники выделены в отдельную папку, а в <code>package.json</code> есть поле <code>source</code>.</p> <p>Для того, чтобы Webpack мог работать с такими пакетами, нужно модифицировать секцию <code>resolve</code>:</p> <pre><code tabindex="0" class="language-js">{ /* … */ resolve: { mainFields: [ 'raw', 'source', 'browser', 'module', 'main' ], extensions: [ '.babel.js', '.js', '.jsx', '.json' ] } /* … */ } </code></pre> <p>Таким образом мы указываем Webpack как он должен искать файлы в пакетах, которые он должен использовать для сборки. Дальше нам остаётся настроить <a href="https://github.com/babel/babel-loader">babel-loader</a>:</p> <pre><code tabindex="0" class="language-js">{ /* … */ test: /\.js$/, exclude: _ => /node_modules/.test(_) && !/(node_modules\/some-modern-package)|(\.babel\.js$)/.test(_), loader: 'babel-loader' /* … */ } </code></pre> <p>Логика простая: просим игнорировать всё из <code>node_modules</code>, за исключением конкретных пакетов и файлов с определенным расширением.</p> <h2>Результаты</h2> <p>Я замерил размеры бандла и скорости загрузки до и после применения дифференциальной загрузки вместе с транспиляцией зависимостей, на примере сайта <a href="https://github.com/TrigenSoftware/DevFest-Siberia">DevFest Siberia 2019</a>:</p> <div class="content__table-wrapper"> <table> <caption>Размеры бандла</caption> <thead> <tr> <th></th> <th>Без сжатия</th> <th>После сжатия</th> </tr> </thead> <tbody> <tr> <td>Без DSL</td> <td>1,08 Мб</td> <td>292 Кб</td> </tr> <tr> <td>С плагином BDSL для Webpack</td> <td>0,80 Мб</td> <td>218 Кб</td> </tr> </tbody> </table> </div> <div class="content__table-wrapper"> <table> <caption>Среднее время загрузки, мс</caption> <thead> <tr> <th></th> <th>Обычный интернет</th> <th>Обычный 4G</th> <th>Хороший 3G</th> </tr> </thead> <tbody> <tr> <td>Без DSL</td> <td>1,511</td> <td>4,240</td> <td>8,696</td> </tr> <tr> <td>С плагином BDSL для Webpack</td> <td>1,594</td> <td>3,409</td> <td>8,561</td> </tr> </tbody> </table> </div> <div class="content__table-wrapper"> <table> <caption>Лучшее время загрузки, мс</caption> <thead> <tr> <th></th> <th>Обычный интернет</th> <th>Обычный 4G</th> <th>Хороший 3G</th> </tr> </thead> <tbody> <tr> <td>Без DSL</td> <td>1,266</td> <td>3,366</td> <td>8,349</td> </tr> <tr> <td>С плагином BDSL для Webpack</td> <td>1,143</td> <td>3,142</td> <td>6,673</td> </tr> </tbody> </table> </div> <p>В итоге получился прирост скорости загрузки и размер бандла уменьшился на ≈20%, <a href="https://gist.github.com/dangreen/5427c5f2158c357bf0b15d38270508ac">читайте более подробный отчёт</a>. Также вы можете самостоятельно провести подобные замеры — необходимый скрипт есть <a href="https://github.com/TrigenSoftware/bdsl-webpack-plugin#metrics">в репозитории bdsl-webpack-plugin</a>.</p> <h3>Источники</h3> <ul> <li><a href="https://www.smashingmagazine.com/2018/10/smart-bundling-legacy-code-browsers/">Smart Bundling: How To Serve Legacy Code Only To Legacy Browsers</a>, Шабхам Канодия</li> <li><a href="https://jasonformat.com/modern-script-loading/">Modern Script Loading</a>, Джейсон Миллер</li> </ul> </article> <article> <h1>Чему меня научил год изучения и преподавания доступности</h1> <p>Fri, 10 Jan 2020 00:00:00 GMT</p> <p>Ещё несколько лет назад я не знала значения термина «доступность». Я создавала сайты, которые были доступны лишь частично, <strong>так как понятия не имела как сделать лучше.</strong> На сегодняшний день мне известно достаточно, чтобы писать, говорить о доступности и проводить мастер-классы, помогая другим создавать более доступный и инклюзивный веб. Как и многие в нашей сфере, я всё ещё нахожусь в процессе обучения. Но с тех пор, когда я только начинала, я усвоила множество ценных уроков и ключевых ценностей, которым следую в своей работе по сей день. Вот некоторые из них.</p> <h2>Семантический HTML — основа по-настоящему доступного веба</h2> <p>Семантический HTML — это универсальный язык, который понимают все устройства, имеющие доступ к интернету, язык, который вы используете для передачи вашего контента этим устройствам.</p> <p>HTML семантичен или, другими словами, описателен и отвечает за передачу смысла, каждый HTML-элемент описывает тип контента, который он представляет. Таким образом, если перед вами заголовок — вы используете элемент, соответствующий заголовку. Если абзац — тег <code><p></code>. Иными словами, подразумевается использование корректных HTML-элементов по их назначению.</p> <p>Использование корректных элементов гарантирует вашему контенту передаваемую структуру и смысл.</p> <p>Важность структуры заключается в том, что она способствует совместимости. Совместимость — это способность разных систем, устройств, приложений или продуктов взаимодействовать согласованно, без приложения усилий пользователем. Иначе говоря, это позволяет большему количеству устройств интерпретировать и получать доступ к вашему контенту, включая те, что появятся в будущем.</p> <p>Структура помогает приложениям для чтения и режимам чтения (подобным тому, который есть в Safari), а также таким средам, как режим высокой контрастности в Windows, интерпретировать ваш контент и стилизовать его тем способом, который приведёт к улучшению интерфейса. Это возможно только тогда, когда использованы соответствующие семантические HTML-элементы, такие как <code><article></code>, <code><h1></code>, <code><ul></code>, <code><aside></code>, <code><nav></code> и многие другие имеющиеся в HTML. Данные элементы описывают тип своего содержимого. Без них приложения будут неспособны рассказать, что оно из себя представляет и, следовательно, не смогут стилизовать его надлежащим образом. Это повысит риск того, что контент станет менее доступным, если не утратит это свойство вообще.</p> <figure> <figcaption> Cтраница Мэнди Майкл <a href="https://medium.com/@mandy.michael/building-websites-for-safari-reader-mode-and-other-reading-apps-1562913c86c9">демонстрирует</a>, как статья, размеченная несемантично (дивами, слева) и семантично (подходящими элементами, справа) выглядит в Instapaper. </figcaption> </figure> <p>Структура также важна, поскольку позволяет пользователям более эффективно перемещаться по контенту. Пользователи скринридеров полагаются на соответствующую структуру документа, чтобы быстрее попадать на необходимые области страницы, используя различные комбинации клавиш, специальные для скринридеров. Если вы не используете соответствующие ориентиры (или «landmarks», определяемые скринридерами через семантику таких HTML-элементов, как <code><nav></code>, <code><main></code> или <code><header></code>), пользователи скринридеров могут лишиться возможности эффективно перемещаться по странице, а достижение нужных частей сайта станет более утомительным.</p> <figure> <figcaption> Меню VoiceOver показывает все ориентиры, доступные на странице, позволяя пользователю перемещаться в нужные части страницы. </figcaption> </figure> <p>Заголовки также предоставляют схему или некий каркас страницы, по которым пользователи могут перемещаться при помощи комбинаций клавиш и которые соответствуют визуальной структуре вашего контента, доступной зрячим пользователям. Вот почему нужно использовать правильные уровни заголовков, вне зависимости от того, как они выглядят на самом деле. Заметьте, что, хотя мы и можем стилизовать заголовки по-разному, там, где это необходимо, визуальная согласованность по-прежнему очень важна.</p> <figure> <figcaption> Меню VoiceOver показывает все заголовки, доступные на странице, позволяя пользователю ориентироваться на странице более эффективно. </figcaption> </figure> <p>Семантика также выражает назначение. HTML-элементы, как отмечает Джереми Кит в своей книге «<a href="https://resilientwebdesign.com/">Resilient Web Design</a>» — это словарь значений. Использование соответствующих HTML-элементов позволяет различным приложениям и устройствам передавать значение вашего содержимого пользователям таким образом, чтобы им было понятно, что от него ожидать и как с ним взаимодействовать.</p> <p>Например, когда вы используете <code><button></code> для создания кнопки, скринридер отображает кнопку, как она есть, и пользователи знают, что они могут совершить с ней определённое действие (обычно обусловленное наличием у последней доступной подписи), нажав на клавиши Space или Enter. Так, они получат функциональность и доступность элемента <code><button></code>, встроенные в него по умолчанию.</p> <p>Если же вы не используете <code><button></code> для создания кнопки, а выбираете вместо этого, скажем, <code><div></code>, вы теряете всю встроенную семантику, а также возможность доступа с клавиатуры, делая кнопку полностью недоступной для скринридеров.</p> <blockquote> <p>Но ведь можно использовать ARIA атрибуты, чтобы превратить <code><div></code> в <code><button></code>! Так?</p> </blockquote> <p>Ну, и да, и нет…</p> <h2>ARIA — это полифилл для HTML-семантики</h2> <p>ARIA-атрибуты — вероятно, наиболее мощный инструмент в нашем арсенале доступности. Многие ARIA-атрибуты имитируют нативную семантику HTML, в то время как некоторые предоставляют ту, что ещё не представлена в HTML. Однако, они не меняют поведение, не добавляют функциональности, состояния фокуса или возможности управления с клавиатуры. Так что, если вы решили пойти по пути создания кнопки с помощью <code><div></code>, вам придётся добавить эту функциональность при помощи JavaScript. Но зачем создавать столь хрупкую реализацию того, что уже предоставляется вам браузерами?</p> <p><a href="https://www.w3.org/TR/using-aria/#rule1">Первое правило ARIA гласит</a>:</p> <blockquote> <p>Если для того, чтобы сделать элемент доступным, вместо переназначения роли элемента с помощью ARIA вы можете использовать нативный HTML-элемент или семантический атрибут с <strong>уже встроенным</strong>, необходимым поведением, <strong>то так и делайте.</strong></p> </blockquote> <p>Так что пока нам следует полагаться на использование нативных HTML-элементов везде, где это возможно, однако есть некоторые виджеты, которые мы можем создать только при помощи ARIA. Например, не существует нативного эквивалента для табов (например, таких элементов, которые имели бы роли <code>tab</code>, <code>tablist</code> или <code>tabpanel</code>) со всей встроенной в них по умолчанию интерактивностью, поэтому мы можем создавать табы, меняя роли другим элементам с помощью ARIA, предоставляя тем самым комбинированный UI для пользователей скринридеров.</p> <p>Так как ARIA кардинально меняет и доступное отображение элементов, при некорректном использовании это может оказать негативное влияние на то, каким образом ваш контент будет показан людям, использующим вспомогательные технологии. <a href="https://scottohara.me/">Скотт Охара</a>, ссылается на практические рекомендации ARIA:</p> <blockquote> <p>Первый принцип применения ARIA гласит, что «роль — это обещание». Используя ARIA или, раз уж на то пошло, HTML, задумайтесь, что именно вы обещаете людям, которые пользуются вашими интерфейсами или потребляют ваш контент. Сдерживаете ли вы обещания, которые им даёте? <a href="https://scottohara.me/">Скотт Охара</a></p> </blockquote> <p>Прежде чем использовать ARIA-атрибуты, подумайте о том, что именно вы обещаете вашим пользователям. ARIA-атрибуты прямо влияют на то, как элементы будут размещены в дереве доступности и, следовательно, каким образом с ними будут взаимодействовать пользователи. Если вы нуждаетесь в указаниях, как следует и как не следует их использовать, Документация по использованию ARIA — лучший для этого источник.</p> <blockquote> <p>Главный совет от <a href="https://twitter.com/LeonieWatson">@LeonieWatson</a> заключается в том, что существует 147 HTML-элементов и только два из них не имеют встроенных возможностей доступности — <code><div></code> и <code><span></code>. Используйте семантически правильные элементы по максимуму! <a href="https://twitter.com/edinbeth/status/1176161245352927237">Бет Фрейзер</a></p> </blockquote> <blockquote> <p>Простейший #a11y совет, который я когда-либо получала: <code><div></code> — последнее к чему вам следует обращаться. Имеете дело с основным контентом? Для этого есть свой тег. С заголовком? И для него тоже. <code><div></code> — это не плохо; просто он ничего не значит. И это совершенно точно означает, что не стоит использовать его для чего-то, на что можно кликнуть. Смотрите на ваш контент, как на что-то, имеющее предназначение, и пытайтесь подобрать под это подходящий тег. В ином случае <code><div></code> (или <code><span></code>) подойдёт. Для <code><div></code> есть своё место, однако большинство учебников преувеличивают его значение. <a href="https://twitter.com/codeability/status/1162861059822112770">И. Дж. Мейсон</a></p> </blockquote> <h2>JavaScript необходим для по-настоящему доступных кастомных интерактивных компонентов</h2> <p>И хотя вы можете обойтись без него, создавая функциональные интерактивные компоненты, такие, как модальные окна на чистом CSS или раскрывающиеся виджеты с помощью печально известного чекбокс-хака, это почти всегда гарантирует, что такие компоненты не будут по-настоящему доступными.</p> <p>Когда вы создаёте интерактивный виджет, с большей долей вероятности он будет иметь состояние. Раскрывающийся виджет имеет либо открытое состояние, либо закрытое (или развёрнутое и свёрнутое). Это состояние видно пользователям скринридеров посредством ARIA-атрибутов (например, <code>aria-expanded="true"</code> или <code>false</code>) и когда пользователи взаимодействуют с виджетом, состояние меняется и эти изменения передаются пользователю. JavaScript для этого необходим. Я смирилась с этим фактом два года назад, когда мне нужно было создать доступный тултип для одного из моих клиентов.</p> <p>JavaScript также необходим для того, чтобы добавлять кастомным компонентам возможность взаимодействовать с клавиатурой (например, табы должны переключаться с помощью клавиш со стрелками, а раскрывающийся виджет быть управляемым клавишами Space и Enter).</p> <p><strong>Примечание:</strong> даже если JavaScript необходим для создания интерактивных кастомных компонентов, для того чтобы быть уверенным, что ваш контент инклюзивен для всех пользователей вне зависимости от их особенностей, вы можете и, вероятно, должны — везде, где это возможно — убедиться, что они могут воспринимать ваш контент, когда JavaScript недоступен. Фактически, никогда не следует рассчитывать на то, что у ваших пользователей он есть, так как существует <a href="https://kryogenix.org/code/browser/everyonehasjs.html">множество</a> причин, почему его может не быть. Вот почему прогрессивное улучшение является наиболее доступной стратегией для создания веба. Я бы даже пошла ещё дальше и сказала, что в некоторых случаях оно абсолютно необходимо для создания инклюзивных документов и компонентов.</p> <h2>Прогрессивное улучшение — это инклюзивная стратегия для создания веба</h2> <p>Кажется, что среди многих разработчиков сложилось неправильное представление о том, что раз JavaScript необходим для обеспечения доступности интерактивного компонента, вы не сможете создать его, используя подход прогрессивного улучшения. Причина в том, что разработчики рассматривают прогрессивное улучшение как некий анти-JavaScript-паттерн. Это заблуждение.</p> <p>Прогрессивное улучшение можно рассматривать, как своего рода наслоение — всё начинается с гибкой основы — семантического HTML — и лишь затем сверху, при необходимости, наслаиваются стили и функциональность (JavaScript).</p> <p>С первого дня, как я узнала о прогрессивном улучшении, оно стало для меня основной движущей силой в создании интерфейсов. Сейчас я не могу себе представить другого подхода к веб-разработке. И с тех пор, как я начала создавать интерфейсы, держа в уме доступность, я пришла к убеждению, что этот подход наиболее разумный.</p> <p>Давайте в качестве примера снова возьмём компонент табов. В таком компоненте у вас есть серия вкладок, которые управляют блоками с содержимым. Пользователь может переключаться между блоками, активируя ту или иную вкладку. Для того чтобы работать и быть доступными, табам необходим JavaScript. Но что, если JavaScript не работает? Если бы табы были созданы без использования прогрессивного улучшения — то есть в полной уверенности разработчика, что JavaScript у пользователя всегда будет включен, они были бы не в состоянии работать и содержимое скрытых блоков осталось бы полностью недоступным.</p> <p>Но если бы вы подошли к табам с точки зрения прогрессивного улучшения, вы бы рассмотрели вариант создания компонента с помощью одного только HTML — без использования CSS, добавляющего интерфейсу возможность взаимодействия и без JavaScript, запускающего его функциональность.</p> <p>В ситуации, когда JavaScript недоступен, можно предусмотреть отображение вкладок, как последовательность секций с заголовком и содержимым, которую может сопровождать оглавление в начале страницы. В таком виде пользователи будут видеть компонент по умолчанию при выключенном JavaScript.</p> <figure> <figcaption> Табы могут быть прогрессивно улучшены как последовательность секций с заголовком и соответствующим ей содержимым. </figcaption> </figure> <figure> <figcaption> Табы могут быть прогрессивно улучшены как последовательность секций с заголовком и соответствующим ей содержимым, а также с оглавлением, предваряющим эти секции. </figcaption> </figure> <p>Когда JavaScript заработает, вы сможете улучшить эти секции, изменив их раскладку и отображение, а также добавив необходимую интерактивность. Я бы реализовала это, добавив в разметку флаг, по которому определяла бы наличие JavaScript и, в зависимости от этого, необходимость изменения сетки секций и активации функционала табов.</p> <p>Когда вы применяете к доступности <a href="https://www.deque.com/shift-left/">подход «shift left»</a> <em>(привлекаете тестировщиков на ранних этапах разработки — прим. переводчика),</em> использование стратегии прогрессивного улучшения приобретает ещё больший смысл. Почти каждый кастомный интерактивный компонент, созданный мной за последний годы, представлял собой улучшение базового не интерактивного компонента. В первую очередь, начинайте с HTML. Задействуйте всё, что он может вам предложить для обеспечения базовой доступности интерфейса.</p> <blockquote> <p>Прогрессивное улучшение. Потому что однажды ваш JavaScript не сработает. Будьте к этому готовы. <a href="https://www.kryogenix.org/">Стюарт Лэнгридж</a></p> </blockquote> <h2>Дизайн не всегда диктует реализацию</h2> <p>Одним из самых распространённых способов, который, на мой взгляд, способен разрушить семантику является извлечение её из визуального дизайна. Потому что визуальный дизайн не всегда описывает тип контента, который он представляет.</p> <p>Это прекрасно иллюстрирует пример с заголовками. В недавнем докладе я показывала пример из одного моего последнего проекта, где страница была спроектирована таким образом, что главного заголовка, казалось, не существует, хотя это было не так. Он просто-напросто не был стилизован как заголовок первого уровня.</p> <figure> <figcaption> Главный заголовок страницы, который описывает содержимое главного раздела страницы, расположен и стилизован таким образом, что (ненамеренно) маскирует факт того, что он им является. </figcaption> </figure> <p>Размышляя над структурой документа и ожиданиями пользователей скринридеров, я узнала, что главный заголовок странице необходим. До недавних пор я должна была предусматривать заголовок для пользователей скринридеров только на тех страницах, где он визуально отсутствовал. В этом же конкретном случае заголовок уже был там, просто стилизованный таким образом, что выглядел совсем иначе.</p> <p>Глядя на страницу через призму доступности и держа в уме HTML — семантику и структуру — поменялось моё видение страницы, а также кардинально изменился подход к работе над ней.</p> <p>Так что если компонент или элемент выглядят как нечто определённое, это не означает, что они непременно этим являются. И наоборот, если они не выглядят как нечто определённое, это не означает, что они этим не являются.</p> <p>То же самое справедливо и для интерактивных UI-паттернов. Один и тот же паттерн может работать по-разному, в зависимости от того в каком контексте находится. И часто именно контекст определяет поведение паттерна и то, каким должен быть пользовательский опыт, а это, в свою очередь, должно составлять основу семантики, от которой зависит сама реализация.</p> <p>В том же самом проекте, который я упоминала, был простой на вид UI-паттерн, который оказался достаточно интересным испытанием UX и доступности. На следующем изображении скриншот этого компонента:</p> <figure> <figcaption> Компонент из моего недавнего коммерческого проекта состоит из видео слева и плейлиста справа. При клике на любое из названий справа загружается видео слева; однако, это не инициирует его запуск. (Заметьте, что содержимое на скриншоте — просто пример). </figcaption> </figure> <p>Для реализации этого видеоплееера, мне нужно было разобраться, как он работает — чтобы я могла сверстать его таким образом, чтобы передать его семантику и функциональность скринридерам должным образом.</p> <p>И хотя плейлист справа выглядит как список ссылок, <em>в действительности</em> — это не так, потому что предполагается, что ссылка должна вас куда-то вести, чего в этом случае не происходит. При клике на название видео оно загрузится в плеере слева. Значит, это интерактивный элемент, который совершает некое действие и, следовательно, не является ссылкой. И хотя их внешний вид не демонстрирует этого, эти названия на самом деле являются <em>кнопками.</em></p> <p>Затем возник вопрос, что случится, если кликнуть на само название? Сработает ли автозапуск? Если да, то кнопка должна отвечать также и за постановку на паузу, играя тем самым роль кнопки-переключателя. Но если клик на название запускает и ставит видео на паузу вы также захотите ассоциировать эту кнопку и с кнопками запуска и паузы внутри самого видео, что может стать проблемой, учитывая, что видео может быть с YouTube, Vimeo или со своё. И если вы не запускаете видео автоматически, должны ли вы устанавливать фокус на <code></code> после того, как нажали на кнопку?</p> <p>После изучения предполагаемого UX и тестирования скринридерами, я, в конечном счёте, реализовала плеер с помощью табов, где каждая вкладка управляет блоком содержимого.</p> <p>Я никогда прежде не думала об интерфейсе табов, в котором несколько вкладок управляют одним блоком. Но контекст этого компонента и его UX определили ход моих мыслей и соображения, которые привели меня к конечной реализации.</p> <p>Первое, что я усвоила из этого компонента — UX определяет реализацию. ARIA поставляет множество атрибутов, которые позволяют нам создавать разные UI-паттерны в разных контекстах, но иногда нам всем нужна возможность немного модифицировать паттерн для конкретного контекста.</p> <blockquote> <p>Странно, что мы до сих пор извлекаем семантику из визуального дизайна, а не наоборот. Визуальный дизайн может отличаться в зависимости от контекста, в то время, как основная семантика — нет. <a href="https://twitter.com/rikschennink/status/1166771758684356608">Рик Шеннинк</a></p> </blockquote> <h2>Если что-то технически доступно, не значит, что оно инклюзивно</h2> <p>Вы можете создать что-то, что будет технически доступным, но при этом не будет инклюзивным. Такой элемент или компонент может иметь все необходимые кнопки, доступные с клавиатуры, а также видимые скринридерами, но действительно ли вы приняли во внимание потребности и ожидания ваших пользователей, когда принимали решения насчёт отображения того или иного элемента и взаимодействия с ним?</p> <p>В докладе <a href="http://feather.ca/inclusion/aea2019">«Inclusive by Design»</a> Дерек Фэверстон, пропагандист доступности и дизайнер, рассказывает о том, как он и его команда создавали доступный видеоплеер для одной организации.</p> <p>Когда пришло время и компонент понадобился для использования пользователями с разными особенностями здоровья, команда осознала, что, хотя они создали прекрасный и доступный видеоплеер, его нельзя было назвать по-настоящему инклюзивным — в нём была упущена разного рода функциональность, которая упрощала бы его использование для некоторых групп пользователей, такая как, например, перемотка вперёд или назад. Дерек и его команда также пытались предположить, как плеер мог бы использоваться всеми пользователями, и поняли, что не учли публику со старыми версиями скринридеров. Они рисковали пропустить важные объявления — те самые, что должны были помочь в управлении. Так, после нескольких итераций и тестов с разными пользователями, они в конечном счёте добавили в плеер необходимые возможности, приняв в расчёт все его недостатки и ожидания пользователей, что сделало плеер гораздо более инклюзивным и чрезвычайно улучшило его UX.</p> <p>Доклад Дерека полон множества хороших примеров, которые подчёркивают важность <strong>своевременного вовлечения пользователей ещё на этапе проектирования</strong>, а также убеждают вас учитывать возможные различия по умолчанию.</p> <blockquote> <p>Ничего о нас без нас. Майкл Масута</p> </blockquote> <h2>В конце концов, всё это только ради пользователя</h2> <p>Если в процессе разработки вы будете держать в уме реальные потребности пользователей и инклюзивность, то в скором времени осознаете, что реализация спроектированного паттерна может быть достигнута разными способами. А в проектировании доступности предостаточно категоричных моментов.</p> <p>Прекрасный пример — модальные окна. Несмотря на то, что этот UI-паттерн всех раздражает, существует множество дискуссий вокруг того, каким образом он должен быть реализован и как должен себя вести, когда модальное окно открыто: следует ли устанавливать фокус на первом доступном для этого элементе внутри модального окна. Что если таких элементов нет? Что если первый элемент, доступный для фокуса — это кнопка закрытия окна? Хотели бы вы, чтобы модальное окно побуждало вас к его скорейшему закрытию? (Очевидно, нет). Что если первый элемент, доступный для фокуса — это поле, требующее от пользователя адрес его электронной почты? Допустимо ли без какого-либо контекста требовать от пользователя личную информацию? (Очевидно, что так же нет).</p> <p>В конце концов, не важно какое решение вы примете, оно всегда должно быть принято для пользователя. Поэтому вовлечение пользователя или более разнообразной команды в проектирование и процесс разработки — это ключевой момент в построении по-настоящему инклюзивных веб-интерфейсов.</p> <p>Но что если у вас нет такой возможности? Что если у вас нет доступа к такому окружению или команде? Что если вы, как и я — независимый разработчик, который часто работает с командами, не имеющими доступа к пользователям или людям с особенностями здоровья.</p> <h2>Обратитесь за советом, если сомневаетесь</h2> <p>Если вы не в силах сделать это сами, вы можете воспользоваться опытом или советами тех, кто через это прошёл. И, что очень важно, быть готовыми и открытыми для конструктивного фидбека.</p> <p>В нашей сфере есть уйма чудесных (иногда по понятным причинам довольно раздражительных) экспертов по доступности, которые <em>мечтают,</em> чтобы веб был более доступным. Большинство из них бесплатно дают ценные советы и делятся своими ценными знаниями в разной форме — пишут статьи и книги, создают видеокурсы, читают доклады и устраивают воркшопы и так далее. Мы многому могли бы научиться у них. И большинство из них открыты к вопросам любой степени сложности (и платно, и бесплатно).</p> <p>Некоторые из моих авторитетных экспертов (порядок не имеет значения):</p> <ul> <li><a href="https://tink.uk/">Leonie Watson</a></li> <li><a href="http://feather.ca/">Derek Featherstone</a></li> <li><a href="http://scottohara.me/">Scott O’Hara</a></li> <li><a href="https://marcysutton.com/">Marcy Sutton</a></li> <li><a href="https://www.youtube.com/channel/UCJAtIv92EJqzG2EOzo92sdQ">Rob Dodson</a></li> <li><a href="https://twitter.com/sundress">Alice Boxhall</a></li> <li><a href="https://marcozehe.de/">Marco Zehe</a></li> <li><a href="https://ericwbailey.design/">Eric Bailey</a></li> <li><a href="https://twitter.com/stevefaulkner">Steve Faulkner</a></li> <li><a href="https://www.paciellogroup.com/">The Paciello Group</a></li> </ul> <p>Перед тем как обратиться за помощью, вы поступите правильно, уделив время чтению спецификаций и рекомендаций по ARIA, чтобы попытаться самим узнать о доступности как можно больше. В конце концов, эти добрые люди способны помочь, но они не обязаны делать нашу работу за нас — по крайней мере, не бесплатно.</p> <h2>Заключение</h2> <p>Доступность — это непросто. Чаще всего это откровенно тяжело. Но это издержки профессии. Проектирование для человека — вот что, на самом деле, тяжело. А доступность, в конечном счёте, целиком <em>про</em> человека и <em>для</em> человека.</p> <p>Мы можем делать это не до конца правильно, всегда есть место улучшениям — тем более, что всё большее количество пользователей используют наши продукты и потребляют наш контент, но одна вещь, которую я знаю точно, это то, что мы никогда не должны отбивать у них желание к этому. Так или иначе, почти всё можно улучшить. Самое главное — быть открытыми для обратной связи, быть достаточно чуткими, чтобы беспокоиться о своих пользователях и стараться изо всех сил, чтобы сделать их жизнь проще с теми (мощными) инструментами, которые есть в нашем распоряжении.</p> <p>Используйте HTML. Совершенствуйте сделанное при помощи CSS. Добавляйте мощи JavaScript. Вовлекайте ваших пользователей в дизайн-процессы как можно раньше и всегда смотрите на вашу работу сквозь призму инклюзивности. Так, вы достигнете большего. Продолжайте учиться, повторяйте выученное и становитесь лучше. Ну, и не забывайте, что возможности нашего здоровья не всегда будут неограниченными.</p> </article> <article> <h1>Введение в вариативные шрифты</h1> <p>Wed, 25 Dec 2019 00:00:00 GMT</p> <p>Типографика всегда вызывала у меня особый интерес, еще задолго до того, как мы смогли использовать шрифты в вебе. И хотя с тех пор прошло уже около десяти лет, всё это время мы были ограничены в выборе шрифтов, так как увеличение их количества напрямую влияло на количество трафика, которое приходилось загружать пользователю. И хотя грамотное использование типографики может положительно отразиться на дизайне, лёгкости восприятия и удобстве использования в целом, но стоит вам подключить слишком большое количество шрифтов, как тут же это негативно отразится на производительности и следовательно, на удобстве для пользователей. Три года назад был представлен результат развития формата шрифтов OpenType, который вносит удивительные изменения в работу со шрифтами.</p> <h2>Представляем OpenType Font Variations или «вариативные шрифты»</h2> <p>На протяжении всего времени использования шрифтов, мне приходилось устанавливать отдельные файлы для каждой ширины, веса (жирности) или варианта начертания, который хотел использовать. Жирный (bold) в одном файле, светлый (light) в другом, курсив в третьем. Формат вариативных шрифтов является развитием OpenType (формата, используемого нами в течение многих лет), который позволяет содержать в одном файле в оптимизированном виде всё то, что ранее было разделено на отдельные файлы. Дизайнер может решить, какие оси включать, а также определить минимальные и максимальные значения.</p> <p>Если говорить о вебе, это значит, что мы можем загрузить единственный файл и использовать CSS для установки параметров его осей в любое значение из всего допустимого диапазона, без каких-либо искусственных искажений силами браузера. Некоторые шрифты могут иметь только одну ось (weight является наиболее распространённой), а у некоторых можно задавать сразу несколько. Несколько осей являются «зарегистрированными», так как наиболее распространены: <strong>width</strong> (ширина), <strong>weight</strong> (вес), <strong>slant</strong> (наклон), <strong>italic</strong> (курсив) и <strong>optical size</strong> (оптический размер) — но формат является расширяемым, так что дизайнеры могут определить собственные оси и позволить вносить необходимые изменения. Давайте рассмотрим, как это работает</p> <h2>Прямо как раньше, но по-другому</h2> <p>Один из способов, с помощью которого новый формат сохраняет обратную совместимость с другими приложениями, которые еще не поддерживают вариативные шрифты, это так называемые «именованные экземпляры» (named instances) — которые по сути являются псевдонимами для настройки данных, которые раньше помещались в отдельные файлы. Таким образом, независимо от того, что имел в виду дизайнер шрифта, называя его «плотным жирным», эти значения просто будут отражены на соответствующих точках вариативных осей веса и ширины. Если шрифт был создан корректно, его настройки позволят установить и использовать его в последних версиях Windows и macOS, будто они были изначально встроены в систему.</p> <p>Если приложение полностью поддерживает вариативные шрифты, появится возможность манипулировать настройками отдельных осей так, как посчитаете нужным. В настоящее время к таким программам относятся последние версии Adobe Illustrator, Photoshop, InDesign, а также Sketch.</p> <h2>Открытие секретов шрифтов</h2> <p>Чтобы узнать о всех возможностях работы с вариативными шрифтами, необходимо либо воспользоваться упомянутым ниже сайтом, либо загрузить Firefox (или, ещё лучше, сделать и то, и другое).</p> <p>Если у вас есть файл шрифтов и доступ к интернету, можете воспользоваться сайтом <a href="https://wakamaifondue.com/">Wakamai Fondue</a> Роель Нискенс, что расшифровывается как «What Can My Font Do» <em>(англ. «На что способен мой шрифт» — прим. переводчика).</em> Просто перетащите файл шрифта и получите отчёт, показывающий, какие у шрифта есть особенности, размер файла, количество глифов, а также поддерживаемые языки и вариативные оси. Вы получите даже тестировщик типа и несколько ползунков, которые позволят поиграть с изменением разных осей. Обратите внимание на оси, значения и настройки по умолчанию. Эта информация понадобится, когда мы начнём писать CSS.</p> <p>Если же у вас нет доступа к файлу шрифта, всё еще можно получить необходимую информацию, просто используя инструменты разработчика браузера Firefox. По ним есть много обучающих видео, например <a href="https://www.youtube.com/watch?v=UazfLa1O94M">это</a> или <a href="https://www.youtube.com/watch?v=RYP7jKMWkVY">это</a>.</p> <p>Благодаря Джен Симмонс и команде Firefox Devtools, у нас есть несколько потрясающих инструментов для работы с веб-шрифтами прямо в браузере. В инструментах разработчика выберите текстовый элемент, использующий нужный шрифт, а затем перейдите в закладку «Fonts», расположенную справа. Вы попадёте на панель, содержащую в одном месте всю информацию о шрифте, размере, стиле и вариативных осях. Можно изменить любое из представленных значений и сразу увидеть результат в браузере, а перейдя на вкладку «Changes», легко скопировать изменённый CSS-код для переноса к себе.</p> <p>Теперь, когда у вас есть все доступные оси, значения, настройки по умолчанию, давайте посмотрим, как это использовать на практике. Первое, на что следует обратить внимание, это то, что теги пяти зарегистрированных осей пишутся строчными буквами (<code>wght</code>, <code>wdth</code>, <code>ital</code>, <code>slnt</code>, <code>opsz</code>), тогда как кастомные — всегда заглавными. Браузеры учитывают это, и несоответствие верхнего и нижнего регистра в названии может привести к непредсказуемым результатам.</p> <p>Существует два способа задания параметров для зарегистрированных осей: через соответствующие им CSS-свойства, а также с помощью низкоуровневого синтаксиса <code>font-variation-settings</code>. Очень важно использовать стандартные свойства везде, где это возможно, поскольку это единственный способ браузеру узнать, что делать если по какой-то причине вариативный шрифт не загрузится, или любому альтернативному устройству просмотра узнать, что нужно вывести определённый вид семантики из нашего CSS (то есть, большее значение <code>font-weight</code>, означающее более жирный текст). Хотя для кастомных осей (и на данный момент для осей <code>italics</code> и <code>slant</code>) мы должны использовать <code>font-variation-settings</code>, параметры <code>font-weight</code> (<code>wght</code>) и <code>font-stretch</code> (<code>wdth</code>) полностью поддерживаются в каждом браузере, который поддерживает вариативные шрифты. Теперь давайте рассмотрим пять зарегистрированных осей и как их использовать.</p> <h2>Weight (вес)</h2> <p>Вероятно, наиболее очевидной осью является <code>weight</code>, поскольку почти каждый шрифт спроектирован как минимум, под обычное и жирное начертание. С вариативным шрифтом вы можете использовать стандартное свойтво <code>font-weight</code>, но указывать не только ключевые слова или значения, например, <code>normal</code> (<code>400</code>) или <code>bold</code> (<code>700</code>), а любое число в диапазоне между минимальным и максимальным значениями, определёнными для шрифта. Согласно спецификации OpenType, значение <code>400</code> должно соответствовать ключевому слову <code>normal</code> для всех шрифтов, но на практике вы увидите, что на данный момент оно может не совпадать и довольно сильно, в зависимости от шрифта.</p> <pre><code tabindex="0" class="language-css">p { font-weight: 425; } strong { font-weight: 675; } </code></pre> <h3>Почему вам это понравится</h3> <p>Позволяет использовать более широкий диапазон значений. Например, для таких ситуаций, как большие кавычки с очень тонким весом (жирностью). Определение значения «чуть тоньше, чем жирное» для отдельных слов внутри жирного текста может повысить читаемость. Чем текст жирнее, тем более закрытыми выглядят символы, но стоит сделать их немного тоньше, как они станут более открытыми, но всё ещё будут придавать акцент (попробуйте установить <code>font-weight</code> где-то между <code>500</code> и <code>600</code> вместо <code>700</code>).</p> <h2>Width (ширина)</h2> <p>Другим распространённым значением при разработке шрифта является ширина. Этот параметр часто характеризуют терминами «плотный», «сжатый» или «расширенный», хотя то, что значат эти слова, является полностью субъективным. Согласно спецификации, 100 должно равняться ширине <code>normal</code>, а допустимые значения могут варьироваться от 1 до 1000. Как и вес, ширина соответствует существующему (и очень неудачно названному) CSS-свойству <code>font-stretch</code> и задаётся в процентах. На ранних стадиях внедрения технологии многие дизайнеры шрифтов не придерживались стандарта с числовыми диапазонами, так что это может выглядеть немного странно в вашем CSS. Но диапазон ширины в 3% — 5% всё еще является допустимым, даже если в этом случае 5% фактически является нормальной шириной. Надеюсь, со временем этот момент станет более стандартизированным</p> <pre><code tabindex="0" class="language-css">p { font-stretch: 89%; } </code></pre> <h3>Почему вам это понравится</h3> <p>Одна из важных задач при разработке адаптивного дизайна — не допустить ситуацию, в которой текст больших заголовков, после каждого слова переносится на новую строку, не помещаясь в ширину маленьких экранов. Помимо настройки размера шрифта <code>font-size</code>, попробуйте сделать текст заголовка немного уже. Это позволит поместить больше слов на каждой строке без уменьшения размера шрифта, которое визуально может выглядеть как снижение акцента или нарушение иерархии заголовков</p> <h2>Italic (курсив)</h2> <p>Ось <code>italic</code> — это более-менее то, что вы и ожидаете. В большинстве случаев это логическое значение 0 или 1: выключено (вертикальный текст) или включено — обычно значит наклонное начертание и часто замену глифа. Часто строчные буквы «a» и «g» имеют немного отличающиеся формы курсива. Хотя, конечно, и существует возможность для данного свойства вместо строгих 0 или 1 задавать диапазон значений, сценарий с состояниями «включено» или «выключено» более распространён. К сожалению, хоть это и предназначено для соответствия свойству <code>font-style: italic</code>, это одна из тех возможностей, которую браузеры реализовали не полностью, поэтому нам остаётся полагаться на синтаксис более низкого уровня <code>font-variation-settings</code>. Вы уже могли задуматься о его использовании вместе с кастомными свойствами CSS, в этом случае вам не потребуется повторно объявлять всю строку, если нужно просто изменить курсивное или вертикальное начертание.</p> <pre><code tabindex="0" class="language-css">:root { --text-ital: 0; } body { font-variation-settings: 'ital' var(--text-ital); } em { --text-ital: 1; } </code></pre> <h3>Почему вам это понравится</h3> <p>Наличие курсива, вертикального начертания, а также веса и других доступных для настройки осей означает, что у вас появляется возможность использовать только один файл шрифта вместо четырёх. Ведь при наличии широкого диапазона доступных осей, вам может больше ничего и не понадобиться</p> <h2>Slant (наклон)</h2> <p>Ось наклона похожа на курсив, но имеет два ключевых отличия. Во-первых, она принимает значение в градусах, диапазон которых, согласно спецификации OpenType, должен быть «больше −90 и меньше +90». Во-вторых, она не предусматривает замену глифа (как <code>italic</code>). Обычно используется со шрифтом без засечек и допускает любое значение в указанном ранее диапазоне. Если используемый вами шрифт имеет только ось <code>slant</code>, но не имеет <code>italic</code> (я немного расскажу об этом), можно использовать стандартное свойство <code>font-style</code> например:</p> <pre><code tabindex="0" class="language-css">em { font-style: oblique 12deg; } </code></pre> <p>Если доступны обе оси, потребуется использовать <code>font-variation-settings</code>, и в этом случае понадобится просто задать числовое значение без указания единиц измерения <code>deg</code>.</p> <pre><code tabindex="0" class="language-css">:root { --text-slnt: 0; } body { font-variation-settings: 'slnt' var(--text-slnt); } em { --text-slnt: 12; } </code></pre> <h2>Почему вам это понравится</h2> <p>Ось наклона (<code>slant</code>) позволяет задавать любое значение в пределах всего допустимого диапазона, поэтому становится возможным небольшое изменение угла наклона текста. Например, можно добавить анимацию, при которой текст после загрузки страницы постепенно становится курсивным. Это хороший способ привлечь внимание к текстовому элемент на экране таким изящным образом</p> <h2>Optical Size (оптический размер)</h2> <p>Это настоящая жемчужина вариативных шрифтов. Данная практика существует более 400 лет. При её использовании физически меньший шрифт вырезался с немного более толстой обводкой и немного меньшим контрастом, чтобы обеспечить качественную печать и сохранить текст разборчивым даже при мелких размерах. Другие аспекты также могут быть адаптированы. Например, апертуры (отверстия) в буквах могут быть шире, более угловатые выступы или увеличенные скругления. И наоборот, крупные точки будут вырезаны более аккуратно, что позволит добиться большей контрастности и лучше детализации. Хотя этот подход использовался во многом из-за недостаточно качественных чернил, бумаги и шрифта — он всё же позволял использовать один эскиз шрифта в широком диапазоне физических размеров символов. Однако, эта технология перестала использоваться с переходом к цифровым шрифтам.</p> <p>Концепция заключается в том, что числовое значение для этой оси должно соответствовать визуальному размеру шрифта, и именно для этого был введёно новое свойсвто: <code>font-optical-sizing</code>. По умолчанию, оно имеет значение <code>auto</code> и такое поведение поддерживается всеми современными браузерами. Можно либо отключить его — <code>off</code>, либо задать явное значение через <code>font-variation-settings</code>.</p> <pre><code tabindex="0" class="language-css">body { font-optical-sizing: auto; } </code></pre> <p>Или:</p> <pre><code tabindex="0" class="language-css">:root { --text-opsz: 16; } body { font-variation-settings: 'opsz' var(--text-opsz); } h1 { --text-opsz: 48; font-size: 3em; } </code></pre> <h3>Почему вам это понравится</h3> <p>Правильный оптический размер делает шрифт более разборчивым при меньших размерах. Повышенная контрастность обводки (и всего остального, что решил изменить дизайнер шрифта) может означать, что один и тот же шрифт может существенно отличаться при его использовании в заголовке или теле статьи. Убедиться в этом можно на примере шрифта Roslindale от Дэвида Джонатана Росса, который <a href="https://rwt.io/">используется на моём сайте</a>. Я использую один шрифт и для заголовков и для остального текста.</p> <h2>Slant и Italic (наклон и курсив)</h2> <p>Не знаю, задумывались ли над этим создатели спецификации, когда составляли её, но технически вы можете задавать обе оси: и для наклона (то есть, угла) и для курсива (то есть, замены глифа). На самом деле и Дэвид Джонатан Росс и Стивен Никсон уже применили это со шрифтами Roslindale Italic и Roslindale Recursive соответственно. В случае с Roslindale Recursive вы можете увидеть, насколько больше гибкости вы можете получить, отделив угол от глифов. Возможность задать угол наклона без замены глифов может придать блоку текста совершенно другой вид. Учитывая то, что курсив и наклон используют одно и то же свойство <code>font-variation-settings</code>, его можно использовать для определения параметров обоих атрибутов.</p> <pre><code tabindex="0" class="language-css">:root { --text-ital: 0; --text-slnt: 0; } body { font-variation-settings: 'ital' var(--text-ital), 'slnt' var(--text-slnt); } em { --text-ital: 1; --text-slnt: 12; } .slanted { --text-slnt: 12; } .italic-forms-only { --text-ital: 1; } </code></pre> <h2>Почему вам это понравится</h2> <p>Наличие отдельной оси под каждый тип изменения шрифта может дать больше гибкости при создании системы типографики проекта. В одном случае вы можете выбрать только наклон, в другом — и наклон и замену глифов. Может это и не самая важная функция, но всё же она добавляет дополнительное измерение, в котором можно настраивать шрифт.</p> <h2>Кастомные оси</h2> <p>Пока что существует только пять зарегистрированных осей, но дизайнеры могут также создавать собственные. Любая составляющая шрифта потенциально может стать осью. Есть вполне привычные, такие как форма засечек или высота строчных (x-height), так и достаточно изобретательные. Более подробный их разбор я оставлю кому-нибудь другому, но продемонстрирую один, использование которого, как я надеюсь, станет более распространённым в текстовом и UI-дизайне — это Grade.</p> <h2>Grade</h2> <p>Понятие «grade» в типографике впервые было введено для регулирования толщины шрифта на разных типах бумаги и печатных станках. Концепция заключается в изменении веса (жирности) шрифта без изменения межбуквенного интервала и пространства, занимаемого одним символом. Наличие его в качестве переменной оси может быть полезно в нескольких отношениях. Создание участка текста с большей контрастностью, при котором символы становятся немного более жирными без переформатирования, может сделать текст более разборчивым при слабом освещении или при разработке тёмной темы. Либо при наведении на элемент, анимировать его с помощью плавного утолщения шрифта и изменения фона. Обратите внимание, что кастомные оси должны указываться заглавными буквами.</p> <pre><code tabindex="0" class="language-css">:root { --text-GRAD: 0; } body { font-variation-settings: 'GRAD' var(--text-GRAD); } body.dark { --text-GRAD: 0.5; } </code></pre> <h3>Почему вам это понравится</h3> <p>Я думаю, что чаще всего ось <code>GRADE</code> будет использоваться при разработке функционала, связанного с доступностью: тёмными темами или режимом высокой контрастности. Но никто не запрещает её применения при анимировании кнопок или навигации путём утолщения текста без изменения количества пространства, которое он занимает.</p> <h2>Поддержка</h2> <p>К счастью, поддержка вариативных шрифтов достаточно хорошая: последние версии macOS и Windows предлагают поддержку на уровне операционной системы, делая возможной их установку в вашу систему и отображение параметров в меню настройки шрифтов в любом приложении, как если бы это были отдельные шрифты. Если вы используете последние версии приложения Adobe CC такие как Illustrator, Photoshop или InDesign — или последние версии Sketch, вы можете изменять все доступные оси. Согласно <a href="https://caniuse.com/#feat=variable-fonts">Can I use</a>, поддержка находится на уровне 87%, включая наиболее популярные мобильные платформы и браузеры.</p> <p>Единственное исключение — это IE11, но учитывая то, что при подключении вариативных шрифтов вы можете использовать <code>@supports</code>, получается. что вполне безопасно использовать их в продакшн уже сегодня. Этот подход используется на более 40 сайтах новой веб-платформы штата Джоржия в США и успешно поддерживает статические шрифты для госслужащих, использующих IE11 и вариативные шрифты для миллионов граждан по всему штату</p> <pre><code tabindex="0" class="language-css">p { font-family: YourStaticFontFamily; } @supports (font-variation-settings: normal) { p { font-family: YourVariableFontFamily; } } </code></pre> <p>Поскольку CSS всегда полностью анализируется перед выполнением любого другого действия, вы можете быть уверены, что браузеры никогда не загрузят оба шрифта сразу</p> <h2>Добавление шрифтов в проект</h2> <p>Вероятней всего, многим из вас пока что потребуется хранить вариативные шрифты у себя на сервере, так как на данный момент только Google предлагает их через собственные API и то в бета-версии. Существует несколько ключевых отличий в составлении <code>@font-face</code> объявления, давайте рассмотрим их:</p> <pre><code tabindex="0" class="language-css">@font-face { font-family: 'Family Name'; src: url('YourVariableFontName.woff2') format('woff2 supports variations'), url('YourVariableFontName.woff2') format('woff2-variations'); font-weight: [low] [high]; font-stretch: [low]% [high]%; font-style: oblique [low]deg [high]deg; } </code></pre> <p>Первое, что вы могли заметить, это немного отличающаяся строка <code>src</code>. Я добавил два варианта синтаксиса, указывающих на один и тот же файл, потому что спецификация была обновлена, но в браузерах этот момент еще не актуализировали. Так как на горизонте в дополнение к вариативным виднеются еще и разноцветные шрифты (и возможность того, что некоторые будут и вариативными и цветными), синтаксис должен быть более гибким. Таким образом, первая запись указывает <code>woff2 supports variations color</code> для шрифта, который поддерживает и то и другое. Когда браузеры начнут понимать этот синтаксис, они будут останавливать распознавание строки <code>src</code> как только дойдут до него. До тех пор они будут пропускать эту строку и переходить ко второй с форматом <code>woff2-variations</code>, который понимают все современные браузеры, поддерживающие вариативные шрифты.</p> <p>Для веса <code>font-weight</code> и ширины <code>font-stretch</code>, если доступна соответствующая ось, укажите минимальное и максимальное значения (со знаком процента для ширины). Если соответствующей оси нет, просто используйте ключевое слово <code>normal</code>. Стоит отметить, что если также присутствует ось курсива (вместе с осью наклона или без неё), на данный момент лучше всего просто полностью пропустить строку <code>font-style</code>.</p> <p>Задавая эти граничные значения, вы помогаете браузеру понять, что делать, если CSS запросит значение, находящееся за пределами допустимого диапазона. Таким образом, если диапазон веса 300–700, а вы случайно указали <code>font-weight: 100</code>, браузер просто установит значение 300 и не будет пытаться синтезировать меньший вес. Стоит отметить, что это работает только со стандартными CSS-свойствами, такими как <code>font-weight</code> или <code>font-stretch</code>. Если для установки значений вы используете <code>font-variation-settings</code>, браузер предполагает, что вы являетесь экспертом и попытается синтезировать результат, даже если он выходит за пределы нормального диапазона.</p> <h2>Google Fonts тоже подходит</h2> <p>В сентябре 2019 команда Google Fonts анонсировала бета-версию своего API, который поддерживает некоторые вариативные шрифты. Поддержка растёт и впереди еще больше шрифтов. Если вы хотите опробовать это уже сейчас, можете <a href="https://rwt.io/typography-tips/variable-fonts-new-google-fonts-api">ознакомиться с моей статьей</a> о том, как это сделать и <a href="https://codepen.io/jpamental/pen/JjPvBpm">проверить CodePen</a>, в создании которого я применил упомянутый способ.</p> <h2>Где их найти</h2> <p>Место, с которого следует начинать поиски вариативных шрифтов — <a href="https://v-fonts.com/">v-fonts.com</a> Ника Шермана, который является каталогом, содержащим почти все доступные на данный момент вариативные шрифты. Также загляните на GitHub, где дополнительно <a href="https://github.com/search?q=variable+fonts">сможете найти проекты</a> на разных стадиях завершённости. Ник также ведёт Твиттер, где публикует анонсы и ссылки, а я добавляю новости по веб-типографике.</p> <p>Вы также можете посетить сайт <a href="https://axis-praxis.org/">Axis-Praxis</a> Лоуренса Пенни, необычный каталог вариативных шрифтов, который позволяет добавить шрифт на специальную тестовую площадку, которая может сообщить вам дополнительную информацию о возможностях и особенностях выбранного шрифта.</p> <h2>Почему всё это важно</h2> <p>Хотя всё это может быть интересно чисто с академической точки зрения, существуют некоторые значительные преимущества и возможности от использования вариативных шрифтов. С точки зрения производительности, хотя вариативные шрифты могут иметь больший размер, чем отдельные файлы каждого начертания обычных шрифтов, они всё равно намного меньше совокупного размера этих файлов. Что значит, что время загрузки страницы может значительно улучшиться. Это именно та причина, по которой <a href="https://www.nngroup.com/articles/variable-fonts-wide-screen-layout/">Nielson/Norman Group использует шрифт Source Sans Variable</a> на своём сайте в течение последнего года, а <a href="https://rwt.io/typography-tips/what-web-wants">Google тестирует шрифт Oswald Variable</a> в течение последних месяцев. В основном, просто используя их вместо нескольких отдельных файлов для получения выгоды от более быстрой загрузки страниц.</p> <p>Но помимо этого, что меня действительно радует, так это возможности дизайна. Когда в нашем распоряжении оказываются вариативные шрифты, мы можем подходить к вопросу типографики более творчески. Пример, приведённый ниже, не должен оставаться просто примером, а становиться частью всеобщей практики.</p> <p>Надеюсь, эта статья послужила хорошим введением в тему вариативных шрифтов. <a href="https://twitter.com/jpamental">Отправляйте ссылки и вопросы</a> — я не могу дождаться, когда увижу, что у вас получилось сделать. И следите за обновлениями.</p> <p>А пока, если хотите узнать о других способах работы с вариативными шрифтами, загляните на удивительный сайт Mandy Michael — <a href="https://variablefonts.dev/">variablefonts.dev</a></p> </article> <article> <h1>Как русскоязычные пользователи с особыми потребностями пользуются сайтами</h1> <p>Thu, 14 Nov 2019 00:00:00 GMT</p> <p><a href="https://www.sergeikriger.com/">Сергей Кригер</a> и я проводили опрос с апреля по декабрь 2019 года. В нём участвовало 143 человека. Выборка не самая большая, но хотелось бы поделиться с вами результатами.</p> <p>Опросник состоял из 10 вопросов, связанных с тем, как люди с особыми потребностями пользуются сайтами и с какими трудностями сталкиваются.</p> <p>Мы вдохновлялись исследованиями <a href="https://webaim.org/">WebAIM</a>. Эта организация каждый год проводит <a href="https://webaim.org/projects/">подобные исследования</a> среди англоязычных пользователей.</p> <h2>1. Какое у вас ограничение по здоровью</h2> <p>У большей части участников опроса есть слепота или пониженное зрение — 97,9% (140 человек). Когнитивные нарушения у одного человека (0,7%), глухота или тугоухость тоже у одного (0,7%). Наконец, у одного участника опроса сразу несколько нарушений: тотальная слепота, ампутация кистей обеих рук и тугоухость (0,7%).</p> <p>Изначально нашей целью было опросить как можно больше людей с разным спектром нарушений, но это оказалось сложной задачей.</p> <p>Такие результаты связаны с тем, по какому каналу распространялся опросник. Например, Сергей участвовал в одном из <a href="https://tiflo.info/stream/tiflostrim-vypusk-19-veb-dostupnost-2019/">тефлостримов</a>. Тефлострим — еженедельный стрим на русском языке, в котором говорят о том, что интересует незрячих и слабовидящих людей. Кроме слушателей стрима в опросе принимали участие некоторые сотрудники и пользователи Санкт-Петербургской библиотеки для слепых и слабовидящих.</p> <h2>2. Ваш уровень пользования интернетом</h2> <p>Нам было интересно какой уровень владения техникой у участников опроса.</p> <p>Оказалось, что больше всего пользователей со средним уровнем — 59,4% или 85 человек. За ними идут продвинутые пользователи — 38,5% (55 респондентов). Новичков оказалось всего трое — 2,1%.</p> <h2>3. С какого устройства чаще всего выходите в интернет?</h2> <p>Большинство участников пользуется компьютерами или ноутбуками — 88,1% (126 человек). На втором месте по популярности смартфоны. Ими постоянно пользуются 14 человек или 9,8%. Одинаково часто пользуется и компьютером, и смартфоном два человека (0,8%). Планшетом и смартфоном всего один респондент (0,7%).</p> <h2>4. Пользуетесь ли вспомогательными технологиями</h2> <p>Большинство участников пользуется вспомогательными технологиями. Это 140 человек, то есть 97,9%. Трое ими не пользуются — 2,1%.</p> <h2>5. Если пользуетесь вспомогательными технологиями, то какими именно</h2> <p>Программами чтения с экрана (скринридеры, экранные дикторы, VoiceOver) пользуются все 100% участников опроса. На втором месте брайлевский дисплей. Его использует 7,7% (11 респондентов). За программируемую клавиатуру проголосовало 3,5% (5 человек). Экранная лупа набрала 3,2% (3).</p> <p>Специальными мышками (джойстиками, выносными компьютерными кнопками, роллерами) не пользуется никто из опрошенных.</p> <h2>6. Если используете вспомогательные технологии, то как научились ими пользоваться?</h2> <p>Интересно было узнать как люди учатся пользоваться вспомогательными технологиями.</p> <p>Большинство респондентов научились этому самостоятельно. Их оказалось 49,3% (70). 37,1% (45) участников с этим помогли друзья, родственники или знакомые. Частично самостоятельно, частично при поддержке родственников и друзей вспомогательными технологиями научился пользоваться 1 человек — 0,7%. На специальных курсах было 17,6% (25) респондентов. В школе на уроках информатики вспомогательные технологии освоило двое человек — 1,4%.</p> <p>Один человек (0,7%) написал, что научился этому с помощью учебных пособий и дискуссионных листов для незрячих. Ещё один участник (0,7%) указал конкретное пособие — «Пермский учебник». Вероятно, речь идёт про <a href="http://www.tiflocomp.ru/docs/audiotb_perm.php">«Звуковой учебник для начинающих незрячих пользователей компьютера»</a>.</p> <h2>7. Как часто сталкиваетесь с недоступным контентом на сайтах</h2> <p>Большинство респондентов иногда сталкиваются с недоступными сайтами — 75,5% (108 человек). Постоянно — 24,5% (35). За вариант «Никогда» не проголосовал ни один из участников.</p> <p>Из этого можно сделать вывод, что многие сайты недоступны частично, а не полностью.</p> <h2>8. Если вы встречаете недоступный контент на сайтах, то с чем вы сталкиваетесь чаще всего?</h2> <p>Было интересно узнать какие же именно элементы в вебе респонденты считают недоступными. В этом вопросе можно было выбрать несколько ответов.</p> <p>На первом месте по недоступности капча. За неё проголосовало 132 респондента или 92,3%. На втором месте неработающие кнопки и ссылки. Их выбрало 73,4% (105) респондентов. Некоторые участники опроса оставляли более развёрнутые ответы о том, что конкретно не так со ссылками и кнопками.</p> <p>Респондент 1:</p> <blockquote> <p>Ещё очень неудобны пункты, так называемые «onclicable», на которые можно нажать, но они не ссылки и не кнопки.</p> </blockquote> <p>Респондент 2:</p> <blockquote> <p>Вместо ссылки иногда JAWS читает ссылку не как таковую, а просто надпись, и не понятно, что это ссылка или другой элемент управления.</p> </blockquote> <p>Респондент 3:</p> <blockquote> <p>Всё больше сайтов, где элементы управления или навигации вообще не видны для скринридеров, или видны, но их нельзя активировать. У многих страницы перегружены элементами управления или навигации, они путевые, добираться до нужного долго и сложно.</p> </blockquote> <p>Респондент 4:</p> <blockquote> <p>Нет подписи к кнопкам или ссылкам. А может быть и картинка за место подписи.</p> </blockquote> <p>Респондент 5:</p> <blockquote> <p>Неподписанные ссылки (когда скринридер говорит только слово «ссылка»).</p> </blockquote> <p>Респондент 6:</p> <blockquote> <p>Это касается в основном радиостанций, где можно скачать или хотя бы послушать программы, но ссылки на них находятся вне зоны доступа экранного чтеца. Без разницы какой именно скринридер, главное, что полностью отсутствует доступ к нужному мне контенту. Наглядная ссылочка: <a href="https://radio.nv.ua/">https://radio.nv.ua/</a>. И ещё одна: <a href="https://nv.ua/">https://nv.ua/</a>.</p> </blockquote> <p>Отсутствие <code>alt</code> у изображений или их неправильное содержимое вызывает проблемы у 60,8% (87) опрошенных. Неожиданные изменения на странице затрагивают 45,4% (65) участников опроса.</p> <p>С отсутствием заголовков на страницах или плохо составленными заголовками сталкивается 43,4% (62 человека). По сайту не могут перемещаться с помощью клавиатуры 39,2% (56) респондентов.</p> <p>51,7% (74) участников сталкиваются с проблемой отсутствия подписей у полей форм. За слишком большое количество ссылок и других интерактивных элементов проголосовало 30% (43 человека).</p> <p>Один из них отметил:</p> <blockquote> <p>Например, если я читаю новости на ria.ru, то после каждой новости показывается много ссылок с рекламой от Яндекса, которая меня совершенно не интересует. Как можно проскочить через эту область с рекламой и перейти сразу к следующей новости с помощью скринридера я не знаю.</p> </blockquote> <p>28,7% (41) респондентов сталкивается с тем, что на сайтах нет ссылок для перехода к основному содержимому. С отсутствием поля поиска и плохо работающим поиском сталкивается 26,6% (38 человек). За сложные и длинные формы проголосовал 21% (30 респондентов).</p> <p>Один из участников опроса при этом отметил, что:</p> <blockquote> <p>Внутри поля форм клавиатура перестаёт слушаться.</p> </blockquote> <p>Для 14,7% (21 участник) проблемы вызывает отсутствие субтитров в видео. С проблемами с текстом и ошибками в нём сталкивается 7,7% (11 участников).</p> <p>Один из респондентов отметил:</p> <blockquote> <p>Бесит использование схожих по написанию с русскими латинских символов в русских текстах.</p> </blockquote> <p>Низкий контраст текста вызывает проблемы у 2,8% (4 человека). Это может быть связано с тем, что многие из участников опроса незрячие и проблема контраста для них не такая острая. 2,1% (3) участника выделили в отдельную проблему чекбоксы и элементы для выбора дат.</p> <p>Респондент 1:</p> <blockquote> <p>[Есть] трудности выбора даты в календарях. Почему-то иногда сложно вызвать его появление.</p> </blockquote> <p>У 1,4% (2) респондентов есть проблемы с выпадающими списками.</p> <p>Один их участников опроса написал:</p> <blockquote> <p>[Есть] нечитаемые выпадающие списки, из которых кнопками невозможно выбрать нужный пункт.</p> </blockquote> <p>1,4% (2) участников отметил маленький размер шрифта.</p> <p>Недоступные всплывающие элементы выделило для себя 0,7%(1) участников опроса, отсутствие версии для печати — 0,7% (1) и фреймы — 0,7% (1). Участники отмечали и проблемы, которые связаны с конкретными скринридерами.</p> <p>Респондент 1:</p> <blockquote> <p>Скринридеры не все элементы фиксируют. При этом JAWS и NVDA могут не совпадать.</p> </blockquote> <p>Респондент 2:</p> <blockquote> <p>Нельзя пользоваться тачпадом, так как NVDA плохо его озвучивает.</p> </blockquote> <p>Респондент 3:</p> <blockquote> <p>Иногда огромная задержка озвучивания содержимого (машина как бы на время «зависает») в некоторых браузерах.</p> </blockquote> <h2>9. Назовите три сайта, которые считаете наиболее доступными</h2> <p>Нам было интересно какие же сайты из всех, которыми участники опроса пользуются, они считают наиболее доступными. Получились интересные результаты.</p> <ol> <li><a href="http://tiflocomp.ru/">Тифлокомп</a> — 17 голосов.</li> <li>Яндекс.Поиск — 11 голосов.</li> <li><a href="http://av3715.ru/">Онлайн-библиотека «Логос»</a> — 10 голосов.</li> <li>ВКонтакте (скорее всего мобильная версия) — 10 голосов.</li> <li>Поиск Google — 9 голосов.</li> <li>YouTube — 7 голосов.</li> <li>Мобильный Facebook — 5 голосов.</li> <li>Одноклассники (скорее всего мобильная версия) — 4 голоса.</li> <li>Рутрекер — 3 голоса.</li> <li><a href="http://www.radiovos.ru/">Радио ВОС</a> — 3 голоса.</li> </ol> <p>По 2 голоса набрали:</p> <ol> <li>Google Drive.</li> <li>Википедия.</li> <li>Mail.ru.</li> <li><a href="http://tiflo.space/">Тифло-пространство</a>.</li> <li><a href="https://www.elitagroup.ru/">Сайт компании Элита Групп</a>.</li> <li><a href="https://blind.games/">Blind games</a>.</li> <li>Интернет-магазин Rozetka.</li> <li>NNM-club.</li> </ol> <p>По 1 человеку проголосовало за: Gmail (новый интерфейс), Google Календарь, Яндекс.Погода, сайт Сбербанка, Сбербанк-Онлайн, сервис по отслеживанию Почты России, Slack, сайт Skype, сайт NVDA, Livejournal, Стихи.ру, ЛитРес, Консультант, Ozon, tutu.ru, погодный сайт Метеонова, портал для инвалидов Disability.ru, Тифло Хост, сайт ВОС, сайт издательства ВОС «Чтение», сайт с образовательными курсами ВОС, Реакомп, zri-sam.ru, сайт ЭлекЖест, Тифложизнь, LIOBlindSoft, Sinoptik, интернет-магазин Petshop, украинский интернет-магазин Comfy, украинский интернет-магазин Фокстрот, сайт фитомагазина «Зелена крамничка», Кинозал, Флибуста, diakov.net, emu-land.net, Регистр лекарственных средств России, remontka.pro, Brainum, сайт Неизвестный гений, LRepacks.ru, информационный портал «ТифлоГродно», мобильная версия новостного портала tyt.by, новостной портал ИноСМИ, Лента.ру, Укрпресса, информационный канал subscribe.ru, новостной сайт ORF.at, 2ip.ru, персональный сайт markmanson.net.</p> <p>Среди ответов были и развёрнутые.</p> <p>Респондент 1:</p> <blockquote> <p>Мне кажется все сайты доступны, если бы справиться с разного рода мелочами, описанными выше.</p> </blockquote> <p>Респондент 2:</p> <blockquote> <p>Их [сайтов] не так уж и мало. Мобильные версии как правило доступнее основных.</p> </blockquote> <p>Респондент 3:</p> <blockquote> <p>И вообще все службы Google и Microsoft можно брать за эталон за редкими исключениями.</p> </blockquote> <p>Респондент 4:</p> <blockquote> <p>Яндекс самый хороший, а смертельного прям нигде нет.</p> </blockquote> <p>Респондент 5:</p> <blockquote> <p>В основном я в соцсетях. Фейсбук очень даже, как на меня, неплохо устроен, правда с одной оговоркой: автоматическая прокрутка страниц в некоторых местах. И мне приходится жать страницу вверх, дабы вернуться на элемент, с которого я слетел […]. ВКонтакте тоже недурен в последнее время стал, но недоступна ссылка загрузки видео.</p> </blockquote> <p>Респондент 7 объясняет почему выбрал Рутрекер и nnm-club:</p> <blockquote> <p>rutracker.org и nnm-club.me только благодаря табличной вёрстке и некоторым элементам оформления.</p> </blockquote> <h2>10. Назовите три сайта, которые считаете наименее доступными</h2> <p>Интересно было также с какими сайтами участникам опроса пользоваться сложно.</p> <ol> <li>ВКонтакте (возможно, десктопная версия) — 11.</li> <li>Одноклассники (тоже, возможно, десктопная версия) — 8.</li> <li>Фейсбук (десктопная версия) — 7.</li> <li>Яндекс.Деньги — 4.</li> <li>Instagram — 3.</li> <li>Яндекс.Почта — 3.</li> <li>Яндекс.Поиск — 3.</li> <li>Поиск Google — 3.</li> </ol> <p>По 2 голоса набрали:</p> <ol> <li>AIiExpres</li> <li>Ozon</li> <li>Mail.ru</li> <li>Госуслуги</li> <li>Сайт РЖД</li> <li>Сбербанк-онлайн</li> <li>ЛитРес</li> <li>2ГИС</li> <li>Сайт Ростелекома</li> <li>Интернет-магазин Rozetka</li> <li>Рутрекер</li> </ol> <p>По 1 участнику выбрало: Telegram, Twitter, Twitch, YouTube, RuTube, Хабр, Яндекс.Дзен, Яндекс.Диск, Яндекс.Коннект, КиноПоиск, Яндекс.Музыка, Смолкасса Ру, Rambler.ru, Сайт Первого канала, РИА Новости, электронный журнал «Школа жизни», Сайт МТС, Сайт Билайн, Сайт Love Radio, Сайт радио 101.ru, Флибуста, сайт Неизвестный гений, сайт компании Кайтен, сайт сервиса JustClick, сайт TravelPayouts, сервис рассылок Senler, портал Агенство праздник, сайт фитомагазина «Зелена крамничка», онлайн-магазин prom.ua, сайт хостинг-провайдера Reg.ru, панель управления ISP manager, сайт Инсбрукского университета имени.</p> <p>В этом вопросе тоже были подробные ответы и комментарии от опрашиваемых.</p> <p>Респондент 1:</p> <blockquote> <p>Совсем тяжёлых сайтов, к счастью, не так много. Чаще на них всё путано организовано или есть нечитаемые или неактивируемые элементы. ЛитРес становится всё хуже, Фэйсбук написан очень мутно, на сервисах Яндекс есть проблемные страницы, даже с ВКонтакте не всё гладко. Одноклассники очень мутный.</p> </blockquote> <p>Респондент 2:</p> <blockquote> <p>Так сразу и не вспомню прям совсем недоступные сайты. Но попадаются сайты с досадными ошибками, усложняющими жизнь. Например, на <a href="http://www.litres.ru">www.litres.ru</a> можно отложить книгу, а добавить в корзину с помощью клавиатуры не получается. Так же была поломана доступность интернет-магазина Ozon, в котором теперь я не могу совершать покупки.</p> </blockquote> <p>Респондент 3:</p> <blockquote> <p>Сложно сказать. В частности, сайты по заказу билетов в кино / на концерты, полная версия сайта РЖД. А в целом сложно что-то выделить. Практически везде что-то доступно нормально, а что-то не очень. С ходу трудно что-то вспомнить.</p> </blockquote> <p>Респондент 4:</p> <blockquote> <p>[Недоступны] все сайты, где много графики и нет подписанных кнопок или нет ссылок с описанием. Особенно сайты, где есть flash-контент. В этих плеерах, как правило, невозможно работать при помощи клавиатуры. Да и мышей. Для слепого очень затруднительно, потому что кнопки не подписаны.</p> </blockquote> <p>Респондент 5:</p> <blockquote> <p>На данный момент не могу таких сайтов назвать. В случае, если какую-то информацию в Google ищу, они иногда попадаются. Однако я могу маленькое неудобство описать. Например, если я хочу на сайте ria.ru подкаст прослушать, то кнопка play или воспроизведение не озвучивает screen reader. Вместо этого NVDA говорит: «Пусто». Но если на сайте youtube.com какой-нибудь фильм смотреть, то там эти кнопки озвучиваются нормально.</p> </blockquote> <p>Респондент 6:</p> <blockquote> <ol> <li>[Недоступен] <a href="https://nv.ua/">https://nv.ua/</a>. В данном случае это страничка радио, которое в эфире рассыпается своей разнообразностью, но, по факту, лишь лжёт, ибо к сей разнообразности не дотягивается рука. Ну, разве что, кнопочку прямого эфира нажать можно. Попробуйте найти архив передач! Лишь текст, да и тот скудный. А вообще и их облако не сильно балует разнообразием ориентиров для безподглядника [человека со слепотой], большинство нужно шарить стрелами.</li> <li><a href="https://kazky.suspilne.media/online">https://kazky.suspilne.media/online</a>. Здесь я вообще не вшариваюсь как запустить контент. Нужный находится, а слушать нельзя.</li> <li>Радио свобода […] Методом тыка разбираешься средь неозвучиваемых элементов как воспроизвести какое-нибудь видео или аудио. А вообще тут большая проблема большая: запустить прямой эфир нельзя. В целом, такого добра в инете хватает. Я много сайтов подобных видел […].</li> </ol> </blockquote> <p>Респондент 7:</p> <blockquote> <p>Яндекс, Сбербанк-Онлайн, Озон: не оптимально, но приемлемо доступны.</p> </blockquote> <p>Респондент 8:</p> <blockquote> <p>[Недоступны] почта Яндекса, 2gis.ru и любые картографические сервисы. И службы Яндекса в целом.</p> </blockquote> <p>Респондент 9:</p> <blockquote> <p>Плохо доступна основная версия Фэйсбука. Тяжело регистрироваться на почтовых серверах, нужно проходить картинки, которые не описаны, и нужно вставлять капчу. Очень плохо читаются соцсети Twitter, Telegram, Instagram и т. п.</p> </blockquote> <p>Респондент 10:</p> <blockquote> <p>[Плохо доступен] <a href="https://vk.com">https://vk.com</a>. Сейчас уже гораздо лучше, чем раньше, но проблемы до сих пор остаются.</p> </blockquote> <p>Респондент 11:</p> <blockquote> <p>[Недоступны] ВК, собственно, все соцсети, новостные сайты, много чего ещё.</p> </blockquote> <h2>Выводы</h2> <p>Большинство участников опроса считают себя пользователями среднего уровня. Чаще всего они пользуются компьютерами и ноутбуками для выхода в интернет. Подавляющее большинство респондентов пользуется скринридерами и научились этому самостоятельно.</p> <p>Опрошенные обращают внимание на то, что абсолютно недоступных сайтов они не встречали. Чаще всего недоступны отдельные элементы и страницы.</p> <p>Самые проблемные элементы на сайтах — это:</p> <ul> <li>капчи;</li> <li>кнопки и ссылки;</li> <li><code>alt</code> у изображений;</li> <li>поля и подписи к ним в формах;</li> <li>заголовки;</li> <li>недоступные для клавиатуры элементы;</li> <li>слишком большое количество интерактивных элементов на страницах;</li> <li>нет ссылки или другой возможности сразу перейти к основному контенту;</li> <li>проблемы с поиском по сайту.</li> </ul> <p>Респонденты отметили, что многие мобильные версии сайтов (упрощённые) чаще всего более доступные, чем десктопные. Также среди лидеров по доступности контента специальные сайты для людей с нарушениями зрения.</p> <p>Мы благодарны всем участникам опроса и неравнодушным разработчикам. Только объединив вместе усилия мы сможем сделать интернет местом, где будет комфортно находиться каждому из нас.</p> <p>Надеемся, что опрос станет ежегодным и охватит максимальное количество пользователей.</p> </article> <article> <h1>Инклюзивные компоненты: слайдер</h1> <p>Thu, 14 Nov 2019 00:00:00 GMT</p> <p>Слайдеры похожи на мужчин. <em>Буквально не все</em> они плохие. Кто-то из них даже отзывчивый и тактичный. Однако я не доверяю тем, кто не обращает внимание на откровенно ужасный паттерн. Я, как и другие, понимаю, что многие предпочли бы просто избегать каруселей, но часто у нас нет выбора. Отсюда эта статья.</p> <p>Слайдеры не так ужасны, но у нас сложилась культура делать их плохо. Обычно во всём виноваты конкретные реализации, а не концепция сама по себе. Как и со многими инклюзивными вещами, правильное решение заключается не в том, что именно вы делаете, а в том, чего не делаете в композиции компонента.</p> <p>Итак, мы создадим без оглядки на предыдущие реализации то, что выполнит <em>основную задачу</em> слайдера: позволит перемещать контент вдоль горизонтальной оси.</p> <h2>Контрол</h2> <p>Все инклюзивные компоненты, в широком смысле, должны быть:</p> <ul> <li>очевидными и лёгкими в использовании;</li> <li>совместимыми с разными типами ввода и вывода;</li> <li>адаптивными и не зависящими от типа устройства;</li> <li>производительными;</li> <li><strong>управляемыми пользователем.</strong></li> </ul> <p>В последнее время я много размышлял над последним требованием и поэтому добавил в <a href="https://github.com/Heydon/inclusive-design-checklist">чеклист инклюзивного веб-дизайна</a> пункт <em>«Не включайте сторонние компоненты, которые нарушают конфиденциальность пользователей».</em> И пользователи так же должны быть защищены от непредвиденных или нежелательных действий, как и от незаконных. Поэтому WCAG предписывает выполнять критерий <a href="https://www.wuhcag.com/pause-stop-hide/">2.2.2. Пауза, остановка, скрытие</a>. Он запрещает использовать нежелательную анимацию. С точки зрения карусели речь идёт о возможности прекращения с помощью кнопок паузы и остановки автоматической циклической смены слайдов.</p> <figure> <figcaption> Карусель с кнопкой паузы в правом нижнем углу. </figcaption> </figure> <p>Так уже хорошо, но этого всё ещё недостаточно. Вы не дали настоящий <a href="http://inclusivedesignprinciples.org/#give-control">контроль над элементом</a>. Сначала отказали пользователю в этом, а позже всё-таки вернули такую возможность. Людям с вестибулярными нарушениями, у которых анимация может вызвать тошноту, к тому времени, когда появится кнопка паузы, уже будет нанесена травма.</p> <p>Думаю, что настоящая инклюзивная карусель — это та, которая не будет двигаться без разрешения пользователя. По этой причине я предпочитаю термин «контентный слайдер» <em>(дальше будет использовать термин «слайдер» — прим. переводчика).</em> Он подразумевает, что слайдером управляет пользователь, а не скрипт. <a href="https://en.wikipedia.org/wiki/Carousel">Карусели</a> же начинают и прекращают движение тогда, когда захотят.</p> <p>Наш слайдер не будет скользить, кроме момента, когда слайды переключаются. Но как их, собственно, переключить?</p> <h2>Мультимодальное взаимодействие</h2> <p>«Мультимодальность» означает <em>«возможность взаимодействовать разными способами».</em> Поддержка разных режимов взаимодействия звучит как что-то, что требует большого количества работы, но браузеры уже мультимодальны по умолчанию. Если вы не облажались, то всем интерактивным контентом можно управлять мышью, с клавиатуры и (где это поддерживается) тачем.</p> <p>Придерживаясь стандартного поведения браузера, мы без особых усилий можем обеспечить мультимодальность в нашем слайдере.</p> <h3>Горизонтальная прокрутка</h3> <p>Самый простой представимый слайдер — это область, которая содержит контент без переносов. Она расположена вдоль горизонтальной оси, и имеется возможность горизонтальной прокрутки. <code>overflow-x: scroll</code> берёт тяжелую работу на себя.</p> <pre><code tabindex="0" class="language-css">.slider { overflow-x: scroll; } .slider li { display: inline-block; white-space: nowrap; } </code></pre> <p>Добавьте некоторые внешние отступы и границы, чтобы улучшить внешний вид слайдера. Это подходящий MVP <em>(минимально жизнеспособный продукт — прим. переводчика)</em> для пользователей мыши. Они могут прокручивать, потянув за видимую полосу прокрутки либо использовать жесты на трекпаде, если курсор находится поверх слайдера. В этом случае анимация будет плавной, потому что за неё отвечает браузер, а не JavaScript-функция, которая срабатывает каждые пять миллисекунд.</p> <p>Когда скроллбара не видно, то <a href="https://www.interaction-design.org/literature/topics/affordances">возможные действия</a> неочевидны. Не беспокойтесь: чуть позже я с этим разберусь.</p> <h3>Поддержка клавиатуры</h3> <p>Для пользователей мыши на большинстве платформ достаточно навести курсор на слайдер, чтобы появилась возможность его прокручивать. Пользователи мобильных устройств могут совершить этот же трюк, если просто свайпнут влево или вправо. Это не требующая особых усилий мультимодальность, которая делает веб крутым.</p> <p>Те, кто пользуется клавиатурой, могут взаимодействовать со слайдером только тогда, когда на нём сделан фокус.</p> <p>При нормальных обстоятельствах большинство элементов по умолчанию не получают фокус. Его могут получить только определённые интерактивные элементы, например, ссылки и контролы с тегом <code><button></code>. Пользователи не должны иметь возможности сделать фокус на неинтерактивных элементах. Если такое происходит, то это нарушение критерия <a href="https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-order.html">WCAG 2.4.3. Порядок фокуса</a>. Причина в том, что фокус должен предшествовать активации, и если активация невозможна, тогда зачем давать элемент в руки пользователям?</p> <p>Чтобы дать пользователям возможность сделать фокус на слайдере, нам нужно добавить <code>tabindex="0"</code>. Поскольку элемент (на котором сделан фокус) будет теперь объявлен скринридерами, мы должны присвоить ему роль и добавить подпись, которые его идентифицируют. В последующих демо мы будем использовать слайдер для показа произведений искусства, поэтому подпись «Галерея» кажется подходящей.</p> <pre><code tabindex="0" class="language-html"><div role="region" aria-label="Галерея" tabindex="0">  </div> </code></pre> <p>Роль <code>region</code> достаточно общая, но подходит для больших областей контента. Она гарантирует, что атрибут <code>aria-label</code> сработает правильно и его содержимое будет объявлено. Вы не можете просто добавить <code>aria-label</code> для любого неинтерактивного <code><div></code> или <code><span></code>.</p> <p>Теперь, когда есть фокус, стало доступным стандартное поведение для элемента: мы можем его прокручивать клавишами с левой и правой стрелками. Нам нужен только стиль фокуса, чтобы показать зрячим пользователям, что слайдер интерактивен:</p> <pre><code tabindex="0" class="language-css">[aria-label="gallery"]:focus { outline: 4px solid dodgerblue; outline-offset: -6px; /* компенсируем 2px у border */ } </code></pre> <h2>Возможность действия</h2> <p>Уже есть пара вещей, которые сообщают пользователю, что это область слайдера: стиль фокуса и тот факт, что обычно крайнее правое изображение обрезается. Предполагается, что можно увидеть больше.</p> <p>Вы можете решить, что этого достаточно, в зависимости от того, насколько критично для пользователей видеть скрытый контент. Так же в этом случае сохраняется лаконичность кода. Тем не менее, мы могли бы сделать всё более очевидным. Мантра инклюзивного дизайна: <em>если есть сомнения, объясните это более подробно.</em></p> <p>Мы можем сделать это с помощью элемента с «инструкцией» после слайдера. Сообщение будет появляться в зависимости от его состояния. Например, мы могли бы показать при помощи <code>:hover</code> сообщение <em>«Прокрутите, чтобы увидеть больше».</em> Смежный селектор + добавит стиль <code>:hover</code> к элементу <code>.instructions</code>.</p> <pre><code tabindex="0" class="language-css">#hover { display: none; } [aria-label="gallery"]:hover + .instructions #hover { display: block; } </code></pre> <p>Сообщение в состоянии <code>:focus</code> может быть реализовано примерно таким же образом. Однако для пользователей скринридеров нам нужно ещё связать это сообщение с областью слайдера. Не имеет значения представляет эта область интерес для каждого из них или нет. Это даёт больше контекста о том, <em>почему</em> область может быть им интересна. Также пользователи лучше понимают, чего они избегают, когда им не нужен этот элемент.</p> <p>Для этого можем использовать атрибут <code>aria-describedby</code>. Мы указываем его для сообщения с фокусом, используя значение <code>id</code> в качестве содержимого для ARIA-атрибута:</p> <pre><code tabindex="0" class="language-html"><div role="region" aria-label="gallery" tabindex="0" aria-describedby="focus">  </div> <div class="instructions"> <p id="hover">Прокрутите, чтобы увидеть больше.</p> <p id="focus">Используйте клавиши со стрелками для того, чтобы увидеть больше.</p> </div> </code></pre> <p>Теперь, когда фокус устанавливается на галерее слайдера, скринридеры объявят что-то вроде этого: <em>«Галерея изображений, область, используйте клавиши со стрелками для того, чтобы увидеть больше».</em> Как дальше описано в примечании про мультимодальность, убедитесь, что пользователям скринридеров будет просто войти в эту область и пройти через каждое изображение в определённом порядке в «режиме просмотра» (в нём они проходят через каждый элемент). Другими словами, слайдер мультимодален даже для этой группы пользователей.</p> <figure> <figcaption> Путь пользователя скринридера в режиме просмотра во многом похож на путь пользователя клавиатуры при наличии связанных/интерактивных слайдов. В любом случае, браузер или скринридер сдвинет контейнер, чтобы показать элементы, на которые сделан фокус. </figcaption> </figure> <h3>Hover и focus?</h3> <p>Иногда интересно то, что обнаруживаешь при тестировании. В моём случае я заметил, что, когда одновременно и фокусировался, <em>и</em> наводился на слайдер, появлялись оба сообщения. Конечно же.</p> <p>Я обнаружил, что в качестве улучшения могу объединить состояния (<code>:hover:focus</code>) и показать сообщение, в котором описаны обе ситуации.</p> <pre><code tabindex="0" class="language-css">[aria-label='gallery']:hover:focus + .instructions #hover-and-focus { display: block; } </code></pre> <p>Используя селектор следующего элемента <code>~</code>, я могу добиться того, что два других сообщения скрыты, в противном случае увидел бы сразу три!</p> <pre><code tabindex="0" class="language-css">[aria-label='gallery']:hover:focus + .instructions #hover-and-focus ~ * { display: none; } </code></pre> <p>Попробуйте навестись на слайдер в демо, а затем кликнуть по нему:</p> <h2>Обработка тача</h2> <p>Пока что взаимодействие со слайдером при помощи тача не проработано. В инструкции это по умолчанию не предусмотрено. Так что, когда вы начинаете свайпать слайды, некоторые устройства показывают сообщение о фокусе и ссылаются на «клавиши со стрелками», которых, скорее всего, нет.</p> <p>Поддержка тача, в первую очередь, означает отслеживание того, взаимодействует ли пользователь с устройством с помощью прикосновений.</p> <p>Важно то, что мы не хотим отслеживать поддержку тача на уровне устройства, так как многие поддерживают его наравне с другими способами. Мы просто хотим знать, что <em>пользователь коснулся</em> экрана. Это возможно с помощью отслеживания одного события <code>touchstart</code>. Вот крошечный скрипт (все лучшие скрипты такие!):</p> <pre><code tabindex="0" class="language-js">window.addEventListener('touchstart', function touched() { document.body.classList.add('touch'); window.removeEventListener('touchstart', touched, false); }, false); </code></pre> <p>Всё, что делает скрипт — это определяет событие <code>touchstart</code>, использует его для добавления <code>class</code> к элементу <code><body></code> и для удаления обработчика событий. Имея <code>class</code>, мы можем показать сообщение «Свайпните, чтобы увидеть больше»:</p> <pre><code tabindex="0" class="language-css">.touch .instructions p { display: none !important; } .touch .instructions #touch { display: block !important; } </code></pre> <p><strong>Примечание:</strong> <code>!important</code> здесь потому, что я упростил селекторы для удобства чтения, по ходу уменьшив их специфичность.</p> <h2>Слайды</h2> <p>В зависимости от вашего случая и контента, вы можете просто остановиться здесь, решив, что слайдер уже довольно хорош. У нас есть что-то совместимое и мультимодальное, и для него используется примерно 100 байт JavaScript. Это преимущество создания с нуля чего-то простого, и отсутствие зависимости от универсальной библиотеки.</p> <p>Но пока наш слайдер на самом деле не является «слайдами», которые обычно занимают всю ширину своего контейнера. Если мы решим эту проблему адаптивно, то люди смогут любоваться каждым произведением искусства на разных размерах экрана. Также было бы неплохо иметь возможность добавлять подписи к слайдам, поэтому с этого момента будем использовать <code><figure></code> и <code><figcaption></code>.</p> <pre><code tabindex="0" class="language-html"><li> <figure> <figcaption>[Название произведения искусства]</figcaption> </figure> </li> </code></pre> <p>Давайте переключимся на флексы.</p> <pre><code tabindex="0" class="language-css">[aria-label="gallery"] ul { display: flex; } [aria-label="gallery"] li { list-style: none; flex: 0 0 100%; } </code></pre> <ul> <li><code>display: flex</code> — это всё, что нам нужно для контейнера, потому что значение <code>flex-wrap</code> по умолчанию <code>nowrap</code>.</li> <li>Сокращённо значение <code>100%</code> для <code>flex</code> — это <code>flex-basis</code>. В результате этого каждый элемент занимает 100% от контейнера <code><ul></code>.</li> </ul> <p>Также я добавил флексовый контекст и для <code><figure></code>, поэтому теперь могу центрировать контент как по вертикальной, так и по горизонтальной осям.</p> <pre><code tabindex="0" class="language-css">[aria-label="gallery"] figure { display: flex; flex-direction: column; align-items: center; justify-content: center; width: 100%; height: 50vh; } </code></pre> <p>Значение <code>50vh</code> — это единственный <em>как бы фиксированный</em> размер, который я использую. Нужно убедиться, что слайдер имеет адекватную высоту, но вписывается во вьюпорт. Чтобы изображение и <code><figcaption></code> всегда помещались в контейнер, мы пропорционально масштабируем картинку, но компенсируем ожидаемую высоту <code><figcaption></code>. Для этого можем использовать <code>calc</code>:</p> <pre><code tabindex="0" class="language-css">[aria-label='gallery'] figcaption { padding: 0.5rem; font-style: italic; } [aria-label='gallery'] img { max-width: 100%; max-height: calc(100% - 2rem); margin-top: 2rem; } </code></pre> <p>С внутренним отступом <code>0.5rem</code> текст подписи становится примерно <code>2rem</code> в высоту. Это вычитается из высоты адаптивного изображения. Затем <code>margin-top</code> со значением <code>2rem</code> повторно центрирует изображение.</p> <h2>Производительность и ленивая загрузка</h2> <p>Одно из самых неожиданных наблюдений, отмеченных на <a href="http://shouldiuseacarousel.com/">shouldiuseacarousel.com</a>, состоит в том, что в каруселях со ссылками только «1% пользователей нажал на ссылку, из них 89% было на первом слайде». <a href="https://erikrunyon.com/2013/01/carousel-interaction-stats/">Исследования показывают</a>, что даже для автоматически вращающихся каруселей количество кликов по слайдам, расположенных после первого, резко уменьшается.</p> <p>Вполне вероятно, что первое изображение в нашем слайдере — единственное, которое увидит большинство скринридеров. Поэтому нужно рассматривать его как одно единственное и загружать последующие картинки только в случае, <em>если</em> пользователь решит на них посмотреть.</p> <p>Мы можем использовать <code>IntersectionObserver</code> там, где он поддерживается, чтобы загрузить каждое изображение отдельно. Это связано с тем, что каждый слайд начинает прокручиваться, когда находится в области видимости.</p> <p>Вот скрипт, примечания следуют:</p> <pre><code tabindex="0" class="language-js">const slides = document.querySelectorAll('[aria-label="gallery"] li'); const observerSettings = { root: document.querySelector('[aria-label="gallery"]'); } if ('IntersectionObserver' in window) { const callback = (slides, observer) => { entries.forEach(entry => { if (!entry.isIntersecting) { return; } let img = entry.target.querySelector('img'); img.setAttribute('src', img.dataset.src); observer.unobserve(entry.target); }); } const observer = new IntersectionObserver( callback, observerSettings ); slides.forEach(t => observer.observe(t)); } else { Array.prototype.forEach.call(slides, function (s) { let img = s.querySelector('img'); img.setAttribute('src', img.getAttribute('data-src')); }); } </code></pre> <ul> <li>В <code>observerSettings</code> определяем внешний элемент галереи как корневой. Мы можем совершить действие тогда, когда элементы <code><li></code> становятся видимыми.</li> <li>Обнаруживаем функцию при помощи <code>'IntersectionObserver' in window</code> и просто загружаем изображения, если их нет. Извините, пользователи старых браузеров, но это лучшее, что мы можем предложить: по крайне мере вы получите контент.</li> <li>Для каждого слайда, который пересекается с другим, мы устанавливаем его <code>src</code> через атрибут <code>data-src</code>, как в случае с обычной ленивой загрузкой.</li> </ul> <p>Позаботьтесь о том, чтобы пользователи не видели неработающие изображения при медленном соединении. Для этого случая добавим для них заглушку в качестве исходного значения <code>src</code>. Получим крошечный SVG с data URI:</p> <pre><code tabindex="0" class="language-html"> </code></pre> <h3>Без JavaScript</h3> <p>В данный момент пользователи с отключенным JavaScript работают без изображений, так как переключение <code>data-src</code> на <code>src</code> невозможно. Кажется, самое простое решение — добавить теги <code><noscript></code>, в которых содержатся изображения с уже установленными значениями <code>src</code>.</p> <pre><code tabindex="0" class="language-html"><noscript> </noscript> </code></pre> <p>Теперь наш слайдер работает и без JavaScript. У нас неплохо выходит. Однако мы обрабатываем только случай «без JavaScript», который редко встречается. Это не печально распространённая ситуация со «сломанным JavaScript». Рик Шеннинк <a href="https://twitter.com/rikschennink/status/931256220303978496">решил эту проблему</a>, поместив <code>mutationObserver</code> в <code><head></code> документа.</p> <h2>Кнопки вперёд и назад</h2> <p>У типичных слайдеров есть кнопки по обеим сторонам, которые перемещают слайды вперёд и назад. Это соглашение, возможно, стоит принять по двум причинам:</p> <ul> <li>Наличие кнопок делает слайдер больше похожим на самого себя. Так же становится более очевидной возможность взаимодействия с ним.</li> <li>Кнопки позволяют пользователю зафиксировать слайды на месте. Больше не нужно крутить туда-сюда, чтобы отцентрировать нужный слайд.</li> </ul> <p>Хитрость заключается в том, чтобы использовать уже разработанную нами функциональность, а не заменять её. Наши кнопки должны заранее знать о том, что кто-то уже прокручивает или свайпает слайды, и уметь с этим работать.</p> <p>Адаптируя наш скрипт <code>IntersectionObserver</code>, мы можем добавлять и удалять класс <code>.visible</code> у слайдов:</p> <pre><code tabindex="0" class="language-js">slides.forEach(entry => { entry.target.classList.remove('visible'); if (!entry.isIntersecting) { return; } let img = entry.target.querySelector('img'); if (img.dataset.src) { img.setAttribute('src', img.dataset.src); img.removeAttribute('data-src'); } entry.target.classList.add('visible'); }); </code></pre> <p>Это означает не только то, что мы найдём <code>class="visible"</code> у любого слайда, который виден на 100% (как первый слайд), но и в случае, когда пользователь прокрутил позицию между двумя слайдами. У них обоих будет этот класс.</p> <p>Чтобы полностью переместить нужный слайд в зону видимости, когда пользователь нажимает одну из кнопок, нам нужно знать только три вещи:</p> <ol> <li>Какой ширины контейнер.</li> <li>Какое количество слайдов.</li> <li>В каком направлении пользователь хочет двигаться.</li> </ol> <p>Если два слайда видны частично и пользователь жмёт «Вперёд», мы определяем необходимый слайд как второй <code>.visible</code>. Затем мы изменяем значение контейнера <code>scrollLeft</code> на основе следующей формулы:</p> <p><code>нужный номер слайда × (ширина контейнера ÷ количество слайдов)</code></p> <p>Обратите внимание на размер кнопок «Вперёд» и «Назад» из демо ниже. Они оптимизированы для лёгкого взаимодействия с тачем без потерь для десктопа.</p> <h3>Точки фиксации</h3> <p>Как заметил <a href="https://twitter.com/justmarkup">Майкл Шарнагль</a>, некоторые браузеры, включая Safari и Firefox, поддерживают простой CSS-метод фиксации слайдов при прокрутке или использовании клавиш со стрелками. Так как Safari не поддерживает <code>IntersectionObserver</code> <em>(уже поддерживается с <a href="https://caniuse.com/#feat=intersectionobserver">версии 12.1</a> — прим. переводчика),</em> то это один из способов сделать удобнее пользователям этого браузера. Мешанина из проприетарных и стандартных свойств ниже: вот что сработало в нашем случае.</p> <pre><code tabindex="0" class="language-css">[aria-label='gallery'] { -webkit-overflow-scrolling: touch; -webkit-scroll-snap-type: mandatory; -ms-scroll-snap-type: mandatory; scroll-snap-type: mandatory; -webkit-scroll-snap-points-x: repeat(100%); -ms-scroll-snap-points-x: repeat(100%); scroll-snap-points-x: repeat(100%); } </code></pre> <p>Фиксация прокрутки поддерживается в <a href="https://cdpn.io/heydon/debug/xPWOLp">демо со связанным контентом</a>, если хотите изучить этот способ. Совет: часть с <code>repeat(100%)</code> относится к 100% ширины каждого слайда.</p> <h3>Группа кнопок</h3> <p>Если разместить две кнопки внутри списка, то дальше они будут рассматриваться как сгруппированные ненумерованные элементы. После того, как в <code><ul></code> добавлена поддержка <code>aria-label</code>, мы можем добавить вспомогательную групповую подпись «Контролы галереи». Так будет легче установить цель кнопок.</p> <pre><code tabindex="0" class="language-html"><ul aria-label="Контролы галереи"> <li> <button id="previous" aria-label="Предыдущий"> <svg aria-hidden="true" focusable="false"><use xlink:href="#arrow-left"></use></svg> </button> </li> <li> <button id="next" aria-label="Следующий"> <svg aria-hidden="true" focusable="false"><use xlink:href="#arrow-right"/></svg> </button> </li> </ul> </code></pre> <p>У каждой кнопки, конечно, должна быть собственная подпись, которая, в данном случае, так же задаётся при помощи <code>aria-label</code>. Когда пользователь скринридера столкнётся с первой кнопкой, он услышит что-то вроде: <em>«Назад, кнопка, список, контролы галереи, два пункта».</em></p> <p>Мы создали контролы для браузера, который поддерживает <code>IntesectionObserver</code>. Для других браузеров, которые его не поддерживают, слайдер всё ещё рендерится и доступен для мыши, клавиатуры и тача.</p> <pre><code tabindex="0" class="language-js">instructions.parentNode.insertBefore( controls, instructions.nextElementSibling ); </code></pre> <h2>Индикаторы загрузки</h2> <p>Следует отметить, что теперь можно нажать на кнопку для мгновенной загрузки слайда. При этом может возникнуть очевидный временной разрыв между появлением слайда в области видимости и загрузкой самого изображения.</p> <p>Есть техника, которая поможет с этим разобраться: использовать для видимого плейсхолдера доминантный цвет изображения. Вы могли такое видеть на Pinterest и других подобных сайтах. Однако, это означает, что мы знаем размеры изображения, и наши картинки по своей природе адаптивны.</p> <p>Чтобы раскладка не «подпрыгивала», когда изображения подгружаются (так как установлена высота <code>50vh</code>), мы можем вместо этого схитрить и отцентрировать индикатор загрузки для каждого слайда. Потом он будет скрыт загрузившейся картинкой.</p> <h2>Обработка связанного контента</h2> <p>Порядок фокуса в нашем слайдере сейчас довольно простой: слайдер сам по себе принимает фокус (при прокрутке с помощью клавиш со стрелками), после чего можно сделать фокус на каждой кнопке по очереди.</p> <p>Но что, если контент каждого слайда связан? После того, как вы сделали фокус на самом слайдере, первый слайд окажется в фокусе, затем каждый последующий слайд (не важно сколько их), наконец, в фокусе окажутся кнопки.</p> <p>Помимо того, что нужно совершить много шагов, связанных с фокусом, чтобы добраться до кнопок (или вообще выйти из слайдера), у нас есть ещё одна небольшая проблема. Если пользователь прокрутит область до зоны видимости с третьим пунктом, то он будет ожидать, что это единственный элемент, который получит фокус. Вместо этого фокус будет сделан на первом пункте и слайдер вернётся в изначальное положение, показав его в области видимости.</p> <p>Это не катастрофа. На самом деле пункты, получающие фокус, автоматически оказываются в области видимости без JavaScript, что служит нам хорошую службу. На невидимом контенте никогда нельзя сделать фокус.</p> <p>Там, где поддерживается <code>IntersectionObserver</code> и рендерятся кнопки, при наличии в данный момент только видимого пункта в порядке фокуса, это станет хорошим вариантом улучшения. Мы можем поправить наш скрипт так, чтобы ссылки в пунктах, которые не пересекаются, принимали <code>tabindex="-1"</code>. Это сделает невозможным установление на них фокуса. Обратите внимание на строки с комментариями 1 и ниже:</p> <pre><code tabindex="0" class="language-js">slides.forEach(entry => { entry.target.classList.remove('visible'); let a = entry.target.querySelector('a'); a.setAttribute('tabindex', '-1'); // 1 if (!entry.isIntersecting) { return; } let img = entry.target.querySelector('img'); if (img.dataset.src) { img.setAttribute('src', img.dataset.src); img.removeAttribute('data-src'); } entry.target.classList.add('visible'); a.removeAttribute('tabindex', '-1'); // 2 }) </code></pre> <p>Просто. Теперь только один или два слайда получают фокус, в зависимости от того, сколько из них сейчас пересекаются. Так что до кнопок становится быстрее и проще добраться.</p> <figure> <figcaption> Показано два слайда с каждой стороны слайдера. Они вне области видимости. У каждого есть <code>tabindex</code> со значением минус один. </figcaption> </figure> <p>Весь минифицированный скрипт для этого слайдера весит примерно 1,7 Кб. Первый результат поисковой выдачи по запросу «плагин карусель» в Google весит 41,9 Кб в сжатом виде и с неправильными атрибутами WAI-ARIA. В некоторых случаях от скринридеров скрывался контент, на котором сделан фокус, при помощи <code>aria-hidden</code>. Остерегайтесь <a href="https://www.w3.org/TR/using-aria/#fourth">четвёртого правила использования ARIA</a>.</p> <p>В этом финальном демо учтены некоторые моменты для Edge и Internet Explorer:</p> <ul> <li>Код скомпилирован в ES5;</li> <li>Баг с увеличением изображений на флексах устраняется при помощи <code>min-width: 1px</code> и <code>min-height: 1px</code> у картинок.</li> <li>Изначально <code>tabindex="-1"</code> установлен для каждой ссылки. В этом нет необходимости в других браузерах. Это учитывается в колбэке <code>InterSectionObserver</code> при первой загрузке.</li> </ul> <p>Safari пока не поддерживает <code>IntersectionObserver</code> <em>(<a href="https://caniuse.com/#feat=intersectionobserver">актуально</a> для версий, ниже 12.1 — прим. переводчика),</em> но есть <a href="https://github.com/w3c/IntersectionObserver/tree/master/polyfill">полифил</a>, который в сжатом виде весит примерно 6 Кб. Слайдер нормально работает в этом браузере, как и в других, которые не поддерживают <code>IntersectionObserver</code>.</p> <h2>Заключение</h2> <p>Инклюзивный дизайн не только про то, как сделать интерфейс одинаковым для всех. Он также о том, как предоставить как сделать интерфейс удобным как можно большему числу людей. У нашего слайдера не самая модная реализация, но он всё ещё достаточно хорош. Это контент должен поражать людей, а не сам интерфейс: эпохальные дадаистские фотомонтажи Ханны Хёх не должны задвигаться на второй план. Убедитесь, что слайдер адаптивный, мало весит, надёжный и совместимый. Тогда у художницы будет большая аудитория, которую она заслуживает.</p> <p>Я предложил в своём докладе <a href="https://vimeo.com/190834530">«Пишите меньше чёртового кода»</a> концепцию <em>непрогрессивного неулучшения</em> (unprogressive non-enhancement). Идея заключается в том, что поток контента, на основе которого мы строим вкладки, карусели и тому подобное, часто не следует перестраивать. Отсутствие улучшения может быть лучше «улучшения». Однако при разумном и бережном расширении представления контента, как, например, в слайдерах, это может быть довольно привлекательным способом получения информации. Лучше всего найти хорошую и исследованную причину для такого исключения.</p> <h2>Чек-лист</h2> <ul> <li>Используйте списки для объединения слайдов в группу. Тогда пользователи скринридеров в «режиме просмотра» смогут пользоваться шорткатами для перемещения по ним.</li> <li>Предусмотрите адекватную работу слайдера в HTML благодаря CSS, а после — проверяйте поддержку в процессе улучшения с помощью JavaScript.</li> <li>Не загружайте заранее контент, который пользователи вряд ли увидят. Отложите загрузку, пока они не выполнят какое-то действие.</li> <li>Увеличьте область клика для пользователей мобильных устройств или устройств с маленькими экранами.</li> <li>В случае, если есть сомнения насчёт возможности взаимодействия с контролом или виджетом, расскажите об этом в инструкции к ним.</li> <li>Если вы мужчина и не обиделись, прочитав первый параграф, поздравляю! Вы не относитесь к мужчинам и женщинам как к конкурирующим командам.</li> </ul> </article> <article> <h1>Помимо автоматизированного тестирования доступности: шесть вещей, которые я проверяю на каждом своём сайте</h1> <p>Tue, 05 Nov 2019 00:00:00 GMT</p> <p>Я только что закончил аудит доступности для заказчика и решил поделиться некоторыми быстрыми проверками, которые я провожу всегда, когда работаю с сайтами. Вы можете прямо сейчас применить их к своему проекту, вам не придётся разбираться со специальными инструментами или софтом.</p> <h3>0. Автоматизированное тестирование</h3> <p>Прежде всего я запускаю тест доступности в <a href="https://developers.google.com/web/tools/lighthouse">Lighthouse</a>, чтобы выяснить, есть ли какие-то очевидные проблемы. Автоматизированные тесты хороши, но они проверяют только часть того, что должны. <a href="https://www.matuzo.at/blog/building-the-most-inaccessible-site-possible-with-a-perfect-lighthouse-score/">Можно получить 100 баллов или 0 ошибок, но это не означает, что уже всё хорошо</a>. Вы лишь заложили основу для ручного тестирования.</p> <h3>1. Проверьте описания изображений</h3> <p>Первый полуавтоматический тест, который я выполняю — проверяю, есть ли у изображения описание и правильное ли оно. Для этого я использую браузерное расширение <a href="https://addons.mozilla.org/de/firefox/addon/web-developer/">Web Developer</a>. С его помощью можно выделить картинки, у которых нет атрибута <code>alt</code>, а также вывести значение <code>alt</code> рядом с изображением.</p> <figure> <figcaption> Раздел настроек изображений в панели инструментов расширения Web Developer. </figcaption> </figure> <h3>2. Отключите все стили</h3> <p>Ещё одной полезной функцией расширения <a href="https://addons.mozilla.org/de/firefox/addon/web-developer/">Web Developer</a> является его способность отключения стилей на странице. Отключение CSS поможет проверить различные вещи:</p> <ul> <li>Работает ли сайт без стилей? (например, когда они не загрузились)</li> <li>Правильный ли порядок элементов на странице?</li> <li>Корректный ли размер у картинок и иконок?</li> <li>Хорошо ли структурирован ваш документ?</li> </ul> <figure> <figcaption> Страница расписания на сайте <a href="https://webclerks.at/">webclerks.at</a> с отключённым CSS. </figcaption> </figure> <h3>3. Валидируйте HTML</h3> <p>Вы можете использовать <a href="https://validator.w3.org/">W3C Markup Validation Service</a> для проверки разметки. Валидатор не отлавливает все ошибки, но это в любом случае хороший способ обнаружения очевидных багов в вашем HTML, например, дублирующихся <code>id</code> или сломанных ARIA-атрибутов.</p> <figure> <figcaption> Ошибки на странице результатов W3C-валидатора. </figcaption> </figure> <h3>4. Проверьте структуру документа</h3> <p><a href="https://webaim.org/projects/screenreadersurvey8/#finding">Большое значение имеет хорошо продуманная структура документа</a>. Она должна начинаться с <code><h1></code>, за которым в иерархическом порядке следуют <code><h2></code>, <code><h3></code>, и т.д. Это отлично подходит для поисковых систем и пользователей скринридеров, ведь так они могут перемещаться по вашему сайту, прыгая по заголовкам.</p> <figure> <figcaption> Список заголовоков на сайте <a href="https://webclerks.at/">webclerks.at</a> (скриншот из tota11y). </figcaption> </figure> <p>Для проверки структуры документа можно использовать <a href="https://validator.w3.org/">W3C Markup Validation Service</a> или инструмент <a href="https://khan.github.io/tota11y/">tota11y</a> (см. скриншот выше).</p> <h3>5. Включите монохромный режим</h3> <p>Для отображения сайтов в монохромном режиме я использую браузерное расширение <a href="https://chrome.google.com/webstore/detail/high-contrast/djcfdncoelnlbldjfhinnjlhdjlikmph">High Contrast</a>. Это важный тест: он покажет те элементы дизайна, которые работают только с цветом. Следует убедиться, что вы не используете исключительно цвет для передачи информации. Идеальный пример — ссылки: они должны быть подчёркнуты, чтобы можно было легко отличить их от обычного текста. <a href="https://adrianroselli.com/2019/01/underlines-are-beautiful.html">Подчёркивания — это прекрасно!</a></p> <blockquote> <p>Подчёркивайте ваши чёртовы ссылки, социопаты!</p> <footer> <cite> Хейдон Пикеринг </cite> </footer> </blockquote> <figure> <figcaption> Сайт <a href="https://www.smashingmagazine.com/">The Smashing Magazine</a> в монохромном режиме. </figcaption> </figure> <p>Не обязательно устанавливать расширение, можно использовать CSS для получения такого же эффекта:</p> <pre><code tabindex="0" class="language-css">body { filter: grayscale(100%); } </code></pre> <h3>6. Используйте клавиатуру</h3> <p>Уберите подальше свою мышь, пройдитесь по странице, используя только клавишу <kbd>Tab</kbd>, и проверьте, можете ли вы попасть в каждую отдельную её часть без мыши или тачпада. <kbd>Tab</kbd> — это мощный инструмент тестирования, он расскажет вам многое о вашем сайте:</p> <ul> <li>Хорошо ли видны стили состояния фокуса?</li> <li>Всё ли, что должно иметь фокус, может его получить?</li> <li>Действительно ли ваши кнопки <code><button></code>?</li> <li>Удобно ли вообще использовать клавиатуру на вашем сайте?</li> <li>Правильно ли вы управляете фокусом?</li> <li>Правильно ли прячутся и отображаются элементы?</li> <li>Соответствует ли визуальный порядок элементов реальному порядку в DOM-дереве?</li> <li>Можете ли вы использовать кастомные JS-компоненты без мыши?</li> </ul> <p>Есть даже <a href="https://www.npmjs.com/package/no-mouse-days">npm-пакет для отключения курсора мыши</a>, созданный чудесной <a href="https://twitter.com/marcysutton">Марси Саттон</a>.</p> <p>Это не конец истории. Существует ещё немало вещей, которые стоит тестировать, но сейчас хватит и этих. Я расскажу больше в другом посте :)</p> </article> <article> <h1>Доступность и закон</h1> <p>Mon, 04 Nov 2019 00:00:00 GMT</p> <h2>Разбираем законы и стандарты по веб-доступности</h2> <p>Часто встречаю комментарии о том, что доступность не нужна. «Зачем мне думать о слепых пользователях, их же мало!». «Зачем людям с инвалидностью интернет?». «А что мне за это будет? В чём выгода?». Тысячи их.</p> <p>У меня есть пара контраргументов. Во-первых, <a href="http://www.who.int/news-room/fact-sheets/detail/disability-and-health">мировая статистика</a> говорит, то в мире живёт более 1 миллиарда людей с инвалидностью. Это примерно 15% от всего населения планеты. И их число с каждым годом увеличивается.</p> <p>Во-вторых, не стоит решать за других каким сервисом они должны пользоваться, а каким нет. Кто-нибудь так же может решить за вас.</p> <p>В-третьих, здоровье не вечно. Люди болеют и <em>иногда</em> даже стареют. Если вы не <a href="https://en.wikipedia.org/wiki/Turritopsis_dohrnii">бессмертная медуза</a>, то доступность нужна в первую очередь вам самим.</p> <blockquote> <p> «Не иметь нарушений — это временно», — мудрые слова <a href="https://twitter.com/sonniesedge">@sonniesedge</a> на <a href="https://twitter.com/hashtag/Fronteers">#Fronteers</a> </p> <footer> <cite> <a href="https://twitter.com/charis/status/1179658993649750016">@charis</a> </cite> </footer> </blockquote> <p>Наконец, правовое регулирование доступности в тренде. Сейчас активно принимаются и дорабатываются уже существующие законы, которые делают её обязательной для сайтов и приложений.</p> <p>В статье я разберу несколько законов, пару стандартов и одну директиву. Они могут коснуться вас как разработчиков, если вы работаете с европейскими и американскими компаниями или с государственным сектором в России.</p> <p>Эта статья обзорная и в ней нет чёткого ответа <em>как именно</em> решить проблему доступности. За деталями переходите по ссылкам, которые я здесь собрала. Начнём.</p> <h2>Евросоюз</h2> <figure> <figcaption>Фото <a href="https://unsplash.com/@markusspiske">Markus Spiske</a>.</figcaption> </figure> <p>Принятие законов о доступности в Европе запустила <a href="https://www.un.org/development/desa/disabilities/convention-on-the-rights-of-persons-with-disabilities.html">Конвенция ООН о защите прав людей с инвалидностью</a> (Convention on the Rights of Persons with Disabilities — CRPD). Она принята в 2006 году и запрещает дискриминацию людей с инвалидностью.</p> <p>В Европе есть несколько важных документов о веб-доступности:</p> <ul> <li>Директива о веб-доступности.</li> <li>Европейский закон о доступности (пока не утверждён окончательно).</li> <li>Европейский стандарт EN 301 549.</li> </ul> <p>На их основе принимаются все национальные законы о доступности <a href="https://ru.wikipedia.org/wiki/%D0%93%D0%BE%D1%81%D1%83%D0%B4%D0%B0%D1%80%D1%81%D1%82%D0%B2%D0%B0_%E2%80%94_%D1%87%D0%BB%D0%B5%D0%BD%D1%8B_%D0%95%D0%B2%D1%80%D0%BE%D0%BF%D0%B5%D0%B9%D1%81%D0%BA%D0%BE%D0%B3%D0%BE_%D1%81%D0%BE%D1%8E%D0%B7%D0%B0">в странах Евросоюза</a> (дальше просто ЕС).</p> <h2>Директива о веб-доступности</h2> <p>«Web Accessibility Directive» или «Directive (EU) 2016/2102»</p> <p>Полное название: «Директива Европейского Парламента и Совета ЕС 2016/2102 от 26 октября 2016 года о доступности сайтов и мобильных приложений органов публичного сектора». Последние изменения сделаны в сентябре 2018.</p> <p>Доступность с точки зрения директивы означает, что контент в вебе и в мобильных приложениях должен быть воспринимаемым, управляемым, понятным и надёжным.</p> <h3>Кого защищает</h3> <p>Всех граждан стран ЕС с инвалидностью.</p> <h3>Что именно затрагивает</h3> <p>Информационно-коммуникационные технологии, которые создают органы публичного сектора в странах ЕС:</p> <ul> <li>сайты;</li> <li>мобильные приложения;</li> <li>интранет;</li> <li>программное обеспечение и операционные системы;</li> <li>электронные документы.</li> </ul> <p>При этом требования не касаются:</p> <ul> <li>контента неправительственных организаций, если он не важен для пользователей с особыми потребностями;</li> <li>сайтов и приложений общественных вещательных компаний;</li> <li>документов Office, которые опубликованы до 23 сентября 2018, если они не используются в работе органов публичного сектора;</li> <li>прямых трансляций;</li> <li>онлайн-карт.</li> </ul> <h3>Кто обязан исполнять</h3> <p>Органы публичного сектора в странах ЕС: городские администрации, суды, больницы, университеты, школы, библиотеки и многие другие.</p> <p>Если коммерческая компания сотрудничает с государственной, то она тоже попадает под действие директивы. Например, когда Microsoft предоставляет государственным больницам Бельгии Windows, то она обязана выполнить требования этого закона.</p> <h3>Содержание</h3> <p>Закон разбит на 15 статей.</p> <ol> <li>Предмет и сфера применения.</li> <li>Минимальная гармонизация (приведение директивы в соответствие с Европейским стандартом EN 301 549, о котором я расскажу чуть позже).</li> <li>Определения.</li> <li>Требования к доступности веб-сайтов и мобильных приложений.</li> <li>Несоразмерное бремя.</li> <li>Презумпция соответствия требованиям к доступности.</li> <li>Дополнительные меры.</li> <li>Мониторинг и отчёты.</li> <li>Правоприменительная процедура.</li> <li>Делегирование.</li> <li>Процедура Комитета.</li> <li>Преобразование в национальное право.</li> <li>Пересмотр.</li> <li>Вступление в силу.</li> <li>Адресаты.</li> </ol> <h3>Какие требования</h3> <p>Они основаны на принципах доступности и 38 критериях соответствия им на уровне AA из <a href="https://www.w3.org/TR/WCAG20/">Web Guidelines Access Content 2.0</a> или просто WCAG 2.0. Руководство будет упоминаться часто, так что я сделала его краткий обзор в конце статьи.</p> <p>Некоторые эксперты считают, что в отношении мобильных приложений нужно полагаться на последнюю версию руководства — <a href="https://www.w3.org/TR/WCAG21/">WCAG 2.1</a>.</p> <p>Ещё страны ЕС должны:</p> <ul> <li>Регулярно обновлять отчёты о доступности. В них описывается какие стандарты по доступности приняты в этой стране.</li> <li>Объяснять, чем грозит нарушение директивы.</li> <li>Описывать доступные способы обратной связи для сообщения о нарушениях требований директивы.</li> <li>Продумывать методы и способы мониторинга и отчётности.</li> <li>Разрабатывать технические спецификации для мобильных приложений.</li> </ul> <h3>Что, если я её нарушу?</h3> <p>В директиве указаны сроки, за которые государственные органы должны привести свои сайты и приложения в порядок:</p> <ul> <li>Все сайты, созданные до 23 сентября 2018, должны быть доступны к сентябрю 2019.</li> <li>Сайты, которые появились позже сентября 2018 — к 23 сентября 2020.</li> <li>Мобильные приложения — к 23 июня 2021.</li> </ul> <p>Судебной практики пока нет, но в ближайшее время она начнёт появляться. За нарушения будут назначаться штрафы.</p> <h3>Полезные ссылки</h3> <ul> <li><a href="https://ec.europa.eu/digital-single-market/en/web-accessibility">Веб-доступность</a>.</li> <li><a href="https://eur-lex.europa.eu/legal-content/en/TXT/?uri=CELEX%3A32016L2102">Текст Директивы</a>.</li> <li><a href="https://directive2102.eu/">Что такое Директива 2102?</a>.</li> <li><a href="https://nda.ie/monitoring/eu-web-accessibility-directive">Европейская директива о веб-доступности</a>.</li> </ul> <h2>Европейский закон о доступности</h2> <p>European Accessibility Act — EAA</p> <figure> <figcaption> Фото <a href="http://www.edf-feph.org/european-accessibility-act-1">edf-feph.org</a>. </figcaption> </figure> <p>Закон утверждён Европарламентом в Страсбурге весной 2019 года. Сейчас дорабатывается.</p> <p>У закона несколько целей:</p> <ul> <li>Уменьшить количество барьеров для людей с особыми потребностями, которые пользуются современным технологиям.</li> <li>Установить чёткие требования для компаний, создающих технологии. Для начала стандартизировать их на основе WCAG, а потом расширить.</li> <li>Сделать требования обязательными для всех компаний, не только государственных.</li> </ul> <h3>Кого защищает</h3> <p>Граждан стран ЕС с инвалидностью, в том числе пожилых людей.</p> <h3>Что именно затрагивает</h3> <p>Все виды информационно-коммуникационных технологий:</p> <ul> <li>компьютеры;</li> <li>смартфоны;</li> <li>планшеты;</li> <li>электронные книги;</li> <li>телевизоры, в целом ТВ-вещание;</li> <li>банкоматы;</li> <li>сайты и приложения;</li> <li>программы и операционные системы;</li> <li>многое другое.</li> </ul> <h3>Кто обязан исполнять</h3> <p>Государственные и коммерческие компании, которые создают информационно-коммуникационные технологии.</p> <h3>Какие требования</h3> <p>Взяты из руководств <a href="https://www.w3.org/TR/WCAG20/">WCAG 2.0</a> и <a href="https://www.w3.org/TR/WCAG21/">WCAG 2.1</a>. Потом их планируется расширить. Текста закона нет в публичном доступе, так что пока сложно сказать что-то конкретное.</p> <h3>Что, если я его нарушу?</h3> <p>Вас явно будут ждать штрафы. Какие — покажет окончательный текст закона и время.</p> <h3>Полезные ссылки</h3> <ul> <li><a href="https://ec.europa.eu/social/main.jsp?catId=1202">Европейский закон о доступности</a>.</li> <li><a href="https://www.3playmedia.com/2019/03/22/european-accessibility-act-eaa/">Что вам нужно знать о Европейском законе о доступности</a>.</li> </ul> <h2>Европейский стандарт EN 301 549</h2> <p>Standard EN 301 549 — EN 301 549</p> <p>Полное название: «Европейский стандарт EN 301 549 „Требования к доступности информационно-коммуникационных технологий продуктов и услуг“» (European standard EN 301 549 «Accessibility requirements for ICT products and services»).</p> <h3>Кого защищает</h3> <p>Пользователей с инвалидностью в странах ЕС.</p> <h3>Что именно затрагивает</h3> <p>Любые информационно-коммуникационные технологии:</p> <ul> <li>сайты (веб-контент);</li> <li>медиа (видео и аудио);</li> <li>электронные документы;</li> <li>программы;</li> <li>мобильные приложения.</li> </ul> <h3>Содержание</h3> <p>Состоит из трёх частей: общей информации, положении о функциональной производительности и функциональных требований к доступности. Важный нам <a href="http://mandate376.standards.eu/standard/technical-requirements">последний раздел</a> включает 9 пунктов:</p> <ul> <li>Общие требования.</li> <li>Информационно-коммуникационные технологии с голосовой связью.</li> <li>Информационно-коммуникационные технологии с субтитрами.</li> <li>Оборудование.</li> <li>Веб-контент.</li> <li>Документы.</li> <li>Программное обеспечение (не веб-контент).</li> <li>Документация и сервисы техподдержки.</li> <li>Диспетчерские и аварийные службы.</li> </ul> <h3>Какие требования</h3> <p>Основан на требованиях <a href="https://www.w3.org/TR/WCAG20/">WCAG 2.0</a> на уровне критерия соответствия AA.</p> <h3>Кто обязан его исполнять</h3> <p>Государственные органы и любая европейская и транснациональная компания, которая сотрудничает со странами ЕС.</p> <h3>Что, если я его нарушу?</h3> <p>Стандарт даёт только рекомендации. Он становится обязательным, когда на него ссылается документ с юридической силой. Это может быть Директива о веб-доступности или Европейский закон о доступности.</p> <h3>Полезные ссылки</h3> <ul> <li><a href="http://mandate376.standards.eu/standard">Текст Стандарта</a>.</li> <li><a href="https://www.essentialaccessibility.com/blog/en-301-549/">EN 301 549: Европейский стандарт веб-доступности</a>.</li> </ul> <h2>США</h2> <figure> <figcaption> Фото <a href="https://www.pexels.com/@einfoto">Matthis Volquardsen</a>. </figcaption> </figure> <p>Если вы интересуетесь темой доступности, то скорее всего уже что-то слышали о двух американских законах: Разделе 508 и ADA. Давайте их разберём.</p> <h2>Раздел 508</h2> <p>Section 508, 508 Compliance</p> <p>Раздел 508 — это один из разделов федерального Закона о реабилитации 1973 года (Rehabilitation Act of 1973 или Rehab Act). Он защищает права американцев с инвалидностью в разных сферах.</p> <p>Раздел 508 был добавлен в текст закона в 1998. Его цель «установить требования для федеральных агентств для того, чтобы они делали свои информационно-коммуникационные технологии доступными для людей с инвалидностью».</p> <h3>Кого защищает</h3> <p>Американцев с различными нарушениями.</p> <h3>Что именно затрагивает</h3> <p>Любые информационно-коммуникационные технологии, которые создают и используют федеральные агентства:</p> <ul> <li>Сайты;</li> <li>Приложения;</li> <li>Мультимедиа: видео и аудио, компьютерные игры;</li> <li>Электронные письма и документы;</li> <li>Программное обеспечение и операционные системы;</li> <li>Технику: смартфоны, компьютеры, клавиатуры, принтеры, сканеры и другую.</li> </ul> <h3>Кто обязан исполнять</h3> <p>Федеральные агентства и <strong>любые компании, которые сотрудничают с ними.</strong> Ими могут быть частные фирмы из США и других стран.</p> <p>Федеральные агентства США — это разные государственные органы, например, министерства, парламент, суды, государственные учебные заведения.</p> <p>Ещё действие закона распространяется на общественные организации, частные вузы, колледжи, школы и компании, которые получают субсидии и гранты из федерального бюджета или любые другие деньги от государства.</p> <h3>Содержание</h3> <p>Раздел 508 состоит из подразделов A, B, C и D.</p> <ul> <li>Подраздел A общий. В нём есть цели раздела, определения, как его применять.</li> <li>Подраздел B содержит технические стандарты, которые касаются программного обеспечения, операционных систем, мультимедиа, приложений и компьютеров.</li> <li>В подразделе C функциональные критерии производительности.</li> <li>В последнем подразделе, D, говорится о документации и поддержке.</li> </ul> <h3>Какие требования</h3> <p>Все требования из Раздела 508 можно разделить на три большие группы:</p> <ul> <li><strong>Технические требования:</strong> Код сайтов и приложений, программное обеспечение и операционные системы должны быть совместимы со вспомогательными технологиями.</li> <li><strong>Функциональные требования:</strong> Люди с инвалидностью должны иметь доступ ко всей системе в целом, а не к её отдельной части.</li> <li><strong>Требования поддержки:</strong> Люди с особыми потребностями должны иметь доступ ко всем документам, которые описывают как взаимодействовать с системой.</li> </ul> <p>Требования в законе тоже основаны на принципах и критериях соответствия им на уровне AA из <a href="https://www.w3.org/TR/WCAG20/">WCAG 2.0</a>.</p> <p>В положении «Безопасная гавань» (Safe Harbor) указано, что если продукт был создан давно и не изменялся, то он должен соответствовать старому стандарту <a href="https://www.w3.org/TR/WAI-WEBCONTENT/">WCAG 1.0</a> 1999 года. Если изменился, то тогда применяются требования из WCAG 2.0.</p> <h3>Что, если я его нарушу?</h3> <figure> <figcaption> В любой статье о законах должна быть картинка с молотком судьи. Фото <a href="https://www.pexels.com/@pixabay">Pixabay</a>. </figcaption> </figure> <p>Требования «Раздела 508» жёстче, чем у других американских законов.</p> <p>Одно из самых известных судебных разбирательств — <a href="https://www.3playmedia.com/2016/09/28/dra-v-uc-berkeley-a-win-win-with-structured-negotiation/">дело Защитников прав инвалидов (Disability Rights Advocates, DRA) против Университета Беркли</a>. Оно началось в 2011 и закончилось в 2013 тем, что университет согласился выплатить штраф и разобраться с доступностью. А причина в том, что в университетской библиотеке не было доступных электронных учебников для студентов с нарушениями зрения.</p> <p>100 000 $ университет должен был заплатить адвокатам, 93 000 $ — за внедрение в течение трёх лет доступных электронных учебников, а 120 000 $ — за найм новых сотрудников и покупку нового оборудования для библиотеки.</p> <p>Ещё одно дело, которое началось в феврале 2015 — <a href="https://www.3playmedia.com/2015/02/12/harvard-mit-sued-captioning-violation-ada-rehabilitation-act/">дело против Гарвардского университета и Массачусетского технологического института</a>. Национальная ассоциация глухих (National Association of the Deaf, NAD) подала иск против вузов из-за отсутствия субтитров в видео из онлайн-курсов. Разбирательства продолжаются.</p> <h3>Полезные ссылки</h3> <ul> <li><a href="https://en.wikipedia.org/wiki/Rehabilitation_Act_of_1973">Закон о реабилитации 1973 года</a>.</li> <li><a href="https://web.archive.org/web/20201112021536/https://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-section-508-standards/section-508-standards">Текст Раздела 508</a>.</li> <li><a href="https://siteimprove.com/en-us/accessibility/section-508-compliance/">Соответствие требованиям 508: что такое Раздел 508?</a>.</li> <li><a href="https://web.archive.org/web/20200715142027/https://www.hhs.gov/web/section-508/making-files-accessible/checklist/index.html">Чеклист доступности соответствия Разделу 508 Министерства здравоохранения и социальных служб США</a>.</li> <li><a href="https://www.3playmedia.com/2017/12/21/the-ultimate-section-508-refresh-checklist/">Полный чеклист обновлённого Раздела 508</a>.</li> <li><a href="https://508compliantdocumentconversion.com/section-508-lawsuits/">Судебные процессы</a>.</li> </ul> <h2>Закон об американцах-инвалидах</h2> <p>Americans with Disabilities Act — ADA</p> <p>ADA — это закон, который защищает права людей с инвалидностью. Принят в 1990 году.</p> <p>Он запрещает дискриминацию людей с особыми потребностями во всех сферах жизни общества: на работе, в школах, транспорте и в других публичных местах.</p> <h3>Кого защищает</h3> <p>Американцев с инвалидностью.</p> <h3>Что именно затрагивает</h3> <p>Те же информационно-коммуникационные технологии, что и Раздел 508:</p> <ul> <li>Сайты;</li> <li>Приложения;</li> <li>Мультимедиа: видео и аудио, компьютерные игры;</li> <li>Электронные письма и документы;</li> <li>Программное обеспечение и операционные системы;</li> <li>Технику: смартфоны, компьютеры, клавиатуры, принтеры, сканеры и так далее.</li> </ul> <h3>Кто обязан исполнять</h3> <p>Любые коммерческие и некоммерческие организации, которые оказывают услуги большому числу людей. Это банки, магазины, школы, гостиницы, кинотеатры, места общественного питания.</p> <p>Исключения — религиозные организации, частные клубы и другие компании, которые, наоборот, работают с небольшим числом людей.</p> <h3>Содержание</h3> <p>Закон содержит пять больших разделов:</p> <ol> <li>Трудоустройство.</li> <li>Общественные организации и транспорт.</li> <li>Общественные места и коммерческие объекты.</li> <li>Телекоммуникации.</li> <li>Прочие положения.</li> </ol> <p>Это не очевидно, но 3 раздел связан с веб-доступностью. Подразумевается, что информационно-коммуникационные технологии — это места общественного пользования. В разделе с судебной практикой я подробнее раскрою эту логику.</p> <h3>Какие требования</h3> <p>Все требования к информационно-коммуникационным технологиям в ADA разделены на три группы:</p> <ul> <li><strong>Технические:</strong> Код сайтов и приложений, программное обеспечение и в целом операционные системы должны быть совместимы со вспомогательными технологиями.</li> <li><strong>Функциональные:</strong> Люди с инвалидностью должны иметь доступ ко всей системе в целом.</li> <li><strong>Поддержка:</strong> Люди с особыми потребностями должны иметь доступ к документам, которые описывают как работать с системой.</li> </ul> <p>В самом законе нет чётких предписаний для сайтов и приложений, но суды по аналогии с «Разделом 508» ссылаются на критерии <a href="https://www.w3.org/TR/WCAG20/">WCAG 2.0</a> и соответствие им на уровне AA.</p> <h3>Что, если я его нарушу?</h3> <p>В 2018 году количество исков, поданных из-за нарушения третьего раздела ADA, было почти в три раза больше, чем в 2017. Их число <a href="https://www.adatitleiii.com/2019/01/number-of-federal-website-accessibility-lawsuits-nearly-triple-exceeding-2250-in-2018/">выросло с 814 до 2258</a>.</p> <p>Одним из самых известных процессов стало <a href="http://www.adasoutheast.org/ada/publications/legal/Gil_v_Winn-Dixie.php">дело Гила против Winn-Dixie</a> в 2018.</p> <p>Хуан Карлос Гил подал иск против продуктовой сети Winn-Dixie из-за того, что не смог воспользоваться скринридером на её сайте. Так как у Гила есть инвалидность по зрению, то суд состоялся на основании нарушения 3 раздела ADA.</p> <p>Суд сделал вывод, что магазины этой сети — общественные места и попадают под действие ADA. Так как на сайте размещена информация о магазинах, то он — это один из сервисов мест общественного пользования.</p> <p>В итоге Winn-Dixie была признана виновной в нарушении ADA. Ей был назначен штраф в 250 000 $. Также она обязана сделать сайт доступным и соответствующим критериям WCAG 2.0.</p> <p>Это решение стало прецедентным и используется в качестве основания для вынесения приговоров по другим делам. Например, в <a href="https://medium.com/@sheribyrnehaber/this-week-in-accessibility-robles-v-dominos-1af8fdb4ce8f">деле Роблеса против Domino’s Pizza</a>.</p> <p>У Гильермо Роблеса слепота. Он пытался заказать пиццу через приложение Domino’s Pizza, но не смог из-за его недоступности. Гильермо подал в суд на сеть пиццерий в 2018. Разбирательства ещё продолжаются, но всё идёт к тому, что сторона обвинения выиграет.</p> <blockquote> <p> Глядя на неразборчивое заявление Domino’s (контраст, размер текста), думаю, что за ними могут прийти не только незрячие пользователи. </p> <footer> <cite> <a href="https://twitter.com/aardrian/status/1181713165220040706">@aardrian</a> </cite> </footer> </blockquote> <p>Есть важный нюанс: суды обычно выносят обвинительные приговоры тем организациям, у которых есть физическое помещение и сайт или приложение с информацией о нём. Например, у Domino’s Pizza в приложении есть доставка из конкретных пиццерий и меню. Если у организации сайт не связан с помещением, скажем, это просто кулинарный блог, то штрафа может и не быть.</p> <h3>Полезные ссылки</h3> <ul> <li><a href="https://en.wikipedia.org/wiki/Americans_with_Disabilities_Act_of_1990">Статья о законе в Википедии</a>.</li> <li><a href="https://www.ada.gov/2010_regs.htm">Текст Закона об американцах-инвалидах</a>.</li> <li><a href="https://adata.org/learn-about-ada">Что такое Закон об американцах-инвалидах (ADA)?</a></li> <li><a href="https://medium.com/@krisrivenburgh/the-ada-checklist-website-compliance-guidelines-for-2019-in-plain-english-123c1d58fad9">«Чеклист ADA: правила соответствия сайтов стандарту в 2019 году простым языком»</a> Криса Ривенбурга.</li> <li><a href="https://www.adatitleiii.com/">Сайт с новостями о судах из-за нарушений ADA</a>.</li> </ul> <h2>Россия</h2> <figure> <figcaption> Фото <a href="https://www.pexels.com/@ajtandle">Ajinkya Tandle</a>. </figcaption> </figure> <p>Веб-доступность в России регулируется тремя законодательными актами и одним стандартом:</p> <ul> <li>Федеральным законом № 419-ФЗ.</li> <li>Федеральным законом № 8-ФЗ.</li> <li>Приказом Министерства связи и массовых коммуникаций России № 483.</li> <li>ГОСТом Р 52872–2012. Интернет-ресурсы. Требования доступности для инвалидов по зрению.</li> </ul> <h2>Федеральный закон № 419-ФЗ</h2> <p>У закона <em>лаконичное</em> название «Федеральный закон от 1 декабря 2014 года № 419-ФЗ „О внесении изменений в отдельные законодательные акты Российской Федерации по вопросам социальной защиты инвалидов в связи с ратификацией конвенции о правах инвалидов“». Вступил в силу в январе 2016.</p> <p>Он запрещает дискриминацию людей по признаку инвалидности. Основан на <a href="https://www.un.org/development/desa/disabilities/convention-on-the-rights-of-persons-with-disabilities.html">Конвенции ООН о защите прав людей с инвалидностью</a> и <a href="http://www.consultant.ru/document/cons_doc_LAW_8559/">Федеральном законе № 181-ФЗ «О социальной защите инвалидов в Российской Федерации»</a>.</p> <p>В нём дискриминация — это</p> <blockquote> <p>Любое различие, исключение или ограничение по причине инвалидности, целью либо результатом которых является умаление или отрицание признания, реализации или осуществления наравне с другими всех гарантированных в Российской Федерации прав и свобод человека и гражданина в политической, экономической, социальной, культурной, гражданской или любой иной области.</p> </blockquote> <h3>Кого защищает</h3> <p>Россиян с инвалидностью.</p> <h3>Что именно затрагивает</h3> <p>Разные сферы от железных дорог, музеев и библиотек до государственных органов власти.</p> <p>Веб-доступности касается только статья 22. В ней сказано, что нужно внести изменения в статью 10 Федерального закона от 9 февраля 2009 года № 8-ФЗ и установить «порядок обеспечения условий доступности для инвалидов по зрению официальных сайтов» органов государственной власти.</p> <h3>Кто должен его исполнять</h3> <p>Российские федеральные органы государственной власти, органы государственной власти субъектов и местного самоуправления. Если говорить конкретно, то это:</p> <ul> <li>Федеральное Собрание (Совет Федерации и Государственная Дума);</li> <li>Министерства и организации, которые им подчиняются;</li> <li>Городские администрации;</li> <li>Суды;</li> <li>Государственные больницы и поликлиники;</li> <li>Государственные школы, колледжи, вузы;</li> <li>…и другие.</li> </ul> <h3>Содержание</h3> <p>Состоит из 26 статей, которые дополняют другие законы новыми требованиями.</p> <h3>Какие требования</h3> <p>В самом тексте 22 статьи ничего конкретно не указано. Но отсылки приведут нас к 10 статье Федерального закона № 8-ФЗ, о котором речь пойдёт ниже.</p> <p>Спойлер: на всех государственных сайтах должна быть <em>отдельная</em> версия для слепых и слабовидящих. Требования к ней основаны на требованиях из <a href="https://www.w3.org/TR/WCAG20/">WCAG 2.0</a>.</p> <h3>Что, если я его нарушу?</h3> <p>Для судов отсутствие версии сайта для слепых и слабовидящих — дискриминация людей по признаку инвалидности. Можно получить штраф за нарушение <a href="http://www.consultant.ru/document/cons_doc_LAW_34661/8b36cedfef8c1b205cdbdcd85ee7a7dc250f5109/">статьи 5.62</a> Кодекса об административных правонарушениях или <a href="http://www.consultant.ru/document/cons_doc_LAW_10699/67c198fece5202f893460246a15f884f72173c28/">статьи 136</a> Уголовного Кодекса.</p> <p>За нарушение Кодекса об административных правонарушениях штраф для физических лиц составит от 1 000 до 3 000 ₽, а для юридических — от 50 000 до 100 000 ₽.</p> <p>Если суд сделает вывод, что нарушение связано со злоупотреблением служебным положением, то оно станет уголовным преступлением. Возможные последствия:</p> <ul> <li>Штраф от 100 000 до 300 000 ₽ или в размере доходов виновного за период от 1 до 2 лет;</li> <li>Запрет на занимание государственных должностей и аналогичную работу до 5 лет;</li> <li>Общественные работы до 480 часов, исправительные работы до 2 лет или принудительные работы до 5 лет;</li> <li>При крайней тяжести нарушения — лишение свободы до 5 лет.</li> </ul> <p>Можно найти и примеры судебных разбирательств.</p> <p>В августе 2017 сайт администрации Шенкурского муниципального района из Архангельской области не прошёл проверку на наличие версии для слепых и слабовидящих. В декабре 2017 <a href="https://sudact.ru/regular/doc/ie1hS05hLNHY/">суд обязал</a> администрацию района решить проблему с доступностью. Она <a href="http://shenradm.ru/">выполнила требования</a> и не получила штраф.</p> <p>На <a href="https://sudact.ru/">сайте судебных и нормативных актов Российской Федерации</a> можно поискать другие решения судов.</p> <h3>Полезные ссылки</h3> <ul> <li><a href="http://www.consultant.ru/document/cons_doc_LAW_171577/">Текст Федерального закона № 419-ФЗ</a>.</li> <li><a href="https://usabilitylab.ru/blog/funkczional-dlya-slabovidyashhix-nebolshoj-obzor-i-rekomendaczii/">«Функционал для слабовидящих: небольшой обзор и рекомендации»</a> Анны Минаевой.</li> </ul> <h2>Федеральный закон № 8-ФЗ</h2> <p>Полное название «Федеральный закон от 9 февраля 2009 года № 8-ФЗ „Об обеспечении доступа к информации о деятельности государственных органов и органов местного самоуправления“».</p> <h3>Структура</h3> <p>Закон состоит из 5 глав. В каждой есть несколько статей.</p> <ol> <li>Общие положения.</li> <li>Организация доступа к информации о деятельности государственных органов и органов местного самоуправления. Основные требования при обеспечении доступа к этой информации.</li> <li>Предоставление информации о деятельности государственных органов и органов местного самоуправления.</li> <li>Ответственность за нарушение порядка доступа к информации о деятельности государственных органов и органов местного самоуправления.</li> <li>Заключительные положения.</li> </ol> <p>Федеральный закон № 419-ФЗ вносит изменения в статью 10. Она входит во вторую главу и называется «Организация доступа к информации о деятельности государственных органов и органов местного самоуправления, размещаемой в сети „Интернет“».</p> <h3>Кого защищает</h3> <p>Россиян с инвалидностью.</p> <h3>Что именно затрагивает</h3> <p>Государственные сайты и их контент.</p> <h3>Кто должен его исполнять</h3> <p>Российские федеральные органы государственной власти, органы государственной власти субъектов и местного самоуправления. Это парламент, министерства, суды, местные администрации и советы.</p> <h3>Какие требования</h3> <p>Они не указаны напрямую. Нас опять отсылают к другому закону. В этот раз к Приказу министерства связи и массовых коммуникаций России № 483. Его я разберу дальше.</p> <p>На самом деле мы снова встретим требования из <a href="https://www.w3.org/TR/WCAG20/">WCAG 2.0</a>, которые ограничиваются <em>отдельной</em> версией сайта для слепых и слабовидящих.</p> <figure> <figcaption> Версия для слабовидящих <a href="https://www.roscosmos.ru/">сайта Роскосмоса</a>. </figcaption> </figure> <h3>Что, если я его нарушу?</h3> <p>Если вы работаете в государственных организациях, то можете понести дисциплинарную, административную, гражданскую и уголовную ответственность.</p> <p>Это <a href="http://www.consultant.ru/document/cons_doc_LAW_34661/8b36cedfef8c1b205cdbdcd85ee7a7dc250f5109/">статья 5.62</a> Кодекса об административных правонарушениях или <a href="http://www.consultant.ru/document/cons_doc_LAW_10699/67c198fece5202f893460246a15f884f72173c28/">статья 136</a> Уголовного Кодекса. О них я уже рассказала в разделе про Федеральный закон № 419-ФЗ.</p> <h3>Полезные ссылки</h3> <ul> <li><a href="http://www.consultant.ru/document/cons_doc_LAW_84602/">Текст Федерального закона № 8-ФЗ</a>.</li> </ul> <h2>Приказ министерства связи и массовых коммуникаций России № 483</h2> <p>У приказа <em>самое лаконичное</em> название из всех «Об установлении порядка обеспечения условий доступности для инвалидов по зрению официальных сайтов федеральных органов государственной власти, органов государственной власти субъектов Российской Федерации и органов местного самоуправления в сети „Интернет“».</p> <p>Принят 30 ноября 2015.</p> <h3>Кого защищает</h3> <p>Людей со зрительными нарушениями: слепых и слабовидящих.</p> <h3>Что именно затрагивает</h3> <p>Сайты органов государственной власти и их контент.</p> <h3>Кто должен его исполнять</h3> <p>Российские федеральные органы власти, органы власти субъектов и местного самоуправления. Это могут быть разные министерства, суды, городские администрации.</p> <h3>Структура</h3> <p>Состоит из 4 пунктов требований.</p> <h3>Какие требования</h3> <p>В приказе перечислена пара конкретных требований к версиям сайтов для слепых и слабовидящих:</p> <ul> <li>На неё можно перейти с главной страницы сайта;</li> <li>Изображения должны быть описаны в виде текста, если они не декоративные;</li> <li>На специализированных сайтах для людей с инвалидностью по зрению должна быть информация о том, как им воспользоваться госуслугами.</li> </ul> <h3>Что, если я его нарушу?</h3> <p>Тогда вы понесёте административную или уголовную ответственность, так как нарушите <a href="http://www.consultant.ru/document/cons_doc_LAW_34661/8b36cedfef8c1b205cdbdcd85ee7a7dc250f5109/">статью 5.62</a> Кодекса об административных правонарушениях или <a href="http://www.consultant.ru/document/cons_doc_LAW_10699/67c198fece5202f893460246a15f884f72173c28/">статью 136</a> Уголовного Кодекса.</p> <h3>Полезные ссылки</h3> <ul> <li><a href="https://minsvyaz.ru/ru/documents/4985/">Текст Приказа Минкомсвязи России № 483</a>.</li> </ul> <h2>Государственный стандарт</h2> <p>ГОСТ Р 52872–2012 Интернет-ресурсы. Требования доступности для инвалидов по зрению</p> <figure> <figcaption> Фото <a href="https://unsplash.com/@dtravisphd">David Travis</a>. </figcaption> </figure> <p>Введён в 2014 после ратификации Россией в мае 2012 года <a href="https://www.un.org/development/desa/disabilities/convention-on-the-rights-of-persons-with-disabilities.html">Конвенции о правах людей с инвалидностью</a>, содержит рекомендации о доступности сайтов и их контента.</p> <p>Доступность для людей с нарушениями зрения — это</p> <blockquote> <p>Возможность полноценного доступа инвалидов по зрению ко всем компонентам электронных ресурсов сети Интернeт.</p> </blockquote> <h3>Кого защищает</h3> <p>Людей с нарушениями зрения: слепых и слабовидящих.</p> <h3>Что именно затрагивает</h3> <p>Электронные интернет-ресурсы на русском языке.</p> <blockquote> <p>Интернет-ресурс — элемент сети Интернет, например, веб-страница, почтовый сервер или поисковая машина.</p> </blockquote> <p>То есть как минимум:</p> <ul> <li>Сайты и их контент;</li> <li>Поисковики;</li> <li>Почтовые сервисы.</li> </ul> <h3>Кто обязан исполнять</h3> <p>Если на него не ссылаются законы и суды, то никто, так как стандарт даёт только рекомендации.</p> <h3>Содержание</h3> <ul> <li>Предисловие.</li> <li>Область применения.</li> <li>Нормативные ссылки.</li> <li>Термины, определения и сокращения.</li> <li>Общие требования.</li> <li>Требования к компонентам интернет-ресурсов.</li> <li>Соответствие уровням доступности.</li> <li>Приложения.</li> <li>Библиография.</li> </ul> <h3>Какие требования</h3> <p>Требования и уровни соответствия им взяты из <a href="https://www.w3.org/TR/WCAG20/">WCAG 2.0</a>. Только довольно урезанного руководства, так как они касаются <em>отдельной</em> версии сайта для слепых и слабовидящих.</p> <h3>Полезные ссылки</h3> <ul> <li><a href="http://docs.cntd.ru/document/1200103663">Текст ГОСТ Р 52872–2012. Интернет-ресурсы. Требования доступности для инвалидов по зрению</a>.</li> <li><a href="https://weblind.ru/">Как помочь слепым на вашем сайте</a>.</li> </ul> <h2>WCAG</h2> <p>Все законы, о которых я рассказала, используют требования из <a href="https://www.w3.org/TR/WCAG20/">Руководства по обеспечению доступности веб-контента</a> (Web Guidelines Access Content, WCAG). Это руководство разработано группой <a href="https://www.w3.org/WAI/">Web Accessibility Initiative</a> (WAI) из <a href="https://www.w3.org/">W3C</a>.</p> <p>Оно состоит из рекомендаций о том, как сделать контент в вебе максимально доступным для большого числа пользователей с ограниченными возможностями. Это могут быть люди с ограничениями по зрению (незрячие и слабовидящие), с нарушениями слуха (глухие и слабослышащие), с когнитивными или моторными нарушениями.</p> <p>Критерии выполнения WCAG — это проверяемые утверждения, которые не привязаны к конкретным технологиям. В предпоследней версии WCAG 2.0 их 38. В последней WCAG 2.1 их на 17 больше — 55.</p> <p>В основном все законы требуют соответствия предпоследней версии стандарта. Это связано с тем, что последняя вышла после их принятия — в июне 2018. Внесение правок в законы занимает много времени, поэтому они не всегда успевают за изменениями в стандартах.</p> <p>Руководство основано на четырёх базовых принципах:</p> <ol> <li><strong>Воспринимаемость:</strong> Пользовательские интерфейсы и информация в них должны быть представлены только в том виде, который могут воспринимать любые пользователи.</li> <li><strong>Управляемость:</strong> Навигация должна быть доступна для всех пользователей, включая тех, кто пользуется клавиатурой или вспомогательными технологиями.</li> <li><strong>Понятность:</strong> Контент и дизайн пользовательского интерфейса должен быть понятным каждому пользователю.</li> <li><strong>Надёжность:</strong> Контент должен быть надёжным и отображаться на всех устройствах и во всех программах и приложениях, которые используют пользователи, в том числе вспомогательные технологии.</li> </ol> <p>Сокращённо все принципы называются POUR по их первым буквам: <strong>P</strong>erceivable, <strong>O</strong>perable, <strong>U</strong>nderstandable, <strong>R</strong>obust.</p> <p>Рекомендации имеют несколько уровней соответствия:</p> <ul> <li>A (низший).</li> <li>AA (средний).</li> <li>AAA (наивысший).</li> </ul> <p>Законы о доступности требуют минимум уровня AA.</p> <h3>Полезные ссылки</h3> <ul> <li><a href="https://www.w3.org/TR/WCAG20/">WCAG 2.0 на английском языке</a>.</li> <li><a href="https://www.w3.org/Translations/WCAG20-ru/WCAG20-ru-20130220/">WCAG 2.0 на русском языке</a>.</li> <li><a href="https://www.w3.org/TR/WCAG21/">WCAG 2.1</a>.</li> <li><a href="https://medium.com/c2-group/wcag-2-1-guidelines-explained-with-examples-5c7c5d8b69eb#7312">WCAG 2.1: руководства с поясняющими примерами</a>.</li> <li><a href="https://webaim.org/standards/wcag/checklist">Чеклист WCAG 2 WebAIM</a>.</li> </ul> <h2>Выводы</h2> <p>Обсуждать доступность хорошо, а регулировать её с помощью законов — ещё лучше. Это помогает не только людям с инвалидностью, но и компаниям, которые создают технологии. Сложно что-то делать правильно, если не знаешь, как именно это нужно делать. Поэтому стандартизация требований к доступности делает разработку предсказуемой и прозрачной.</p> <p>В статье я разобрала важные законы о доступности в ЕС, США и России. Они есть и в Австралии, Исландии, Японии, Южной Корее и многих других странах. Можете заглянуть в обзор Гаренна Бигби <a href="https://dynomapper.com/blog/27-accessibility-testing/532-international-web-accessibility-laws-and-policies">«Международные законы и политика в отношении доступности сайтов»</a>, чтобы узнать об этом больше. Ещё есть книга о законодательстве в области доступности — <a href="https://www.amazon.com/Web-Accessibility-Standards-Regulatory-Compliance/dp/1590596382">«Веб-доступность: веб-стандарты и нормативные требования»</a>.</p> <p>В основном требования к доступности в законах основаны на WCAG. Это руководство о том, как сделать доступными сайты и приложения. Так что для того, чтобы не получить штраф за нарушение законов о доступности, стоит держать его под рукой.</p> <p>Европейское и американское законодательства в целом похожи. Они покрывают много информационно-коммуникационных технологий. При этом регулируются продукты и госсектора, и частных компаний.</p> <p>В российском законодательстве о доступности много пробелов. И законы, и стандарт выделяют <em>только</em> людей с нарушениями зрения. Это странно для законов, которые борются с дискриминацией по признаку инвалидности. Почему из них тогда исключены люди с глухотой, проблемами с моторикой и ментальными нарушениями?</p> <p>Не менее странно то, что проблему доступности для людей с нарушениями зрения решают с помощью отдельной версии сайта. Уже на уровне закона мир зрячих отделяют от мира незрячих, хотя можно сделать сайт доступным и без такого старомодного подхода. Гораздо проще учесть основные требования WCAG и сделать сайт доступным для большинства пользователей, чем делать одну версию недоступной для всех и другую доступной для конкретных пользователей.</p> <p>Ещё больше вопросов к российским законам появляется, когда вспоминаешь о реальном мире. Кроме сайтов в нём есть мобильные приложения и настольные программы. Они никак не регулируются.</p> <p>Также кроме государственных сайтов в законах напрямую не упомянуты негосударственные. Хорошо, когда ты можешь без проблем оформить пособие по инвалидности, но что насчёт остального веба? Как купить билет на концерт, прочитать книгу по функциональному программированию или записаться на онлайн-курсы по C++?</p> <p>Не ограничивайтесь только требованиями законов. Конечно, важно их знать и понимать, какие требования нужно учитывать при разработке своих продуктов. Просто помните, что если вы создаёте недоступный продукт для других, то однажды можете оказаться на их месте. И это будет не самое приятное и инклюзивное место.</p> </article> <article> <h1>Инклюзивные компоненты: сворачиваемые секции</h1> <p>Thu, 17 Oct 2019 00:00:00 GMT</p> <p>Сворачиваемые секции, возможно, самый элементарный паттерн проектирования взаимодействия в вебе. Всё, что они делают — это переключают видимость контента при клике на заголовок. Ничего особенного.</p> <p>Хотя это простое взаимодействие, оно <a href="https://caniuse.com/#feat=details">не имеет нативной и одинаковой реализации в разных браузерах</a>. И это несмотря на то, что есть движение в сторону его стандартизации. Так что это отличный аналог «hello world» для погружения в доступность с точки зрения проектирования взаимодействия с использованием JavaScript и WAI-ARIA.</p> <p>Почему я говорю об этом только после того, как рассказал про более сложные компоненты? Дело в том, что в этой статье я сосредоточусь на опыте автора и разработчика: мы собираемся сделать наши раскрываемые области веб-компонентами, чтобы они могли легко стать частью более крупных паттернов и быть встроенными в существующий контент.</p> <p>Как и в случае вкладок, это помогает понять, каким будет наш компонент без улучшения при помощи JavaScript и почему это действительно поможет сделать что-то лучше. В этом случае сворачиваемая секция без JavaScript — просто раздел. То есть это подзаголовок, кратко описывающий какой-то контент: текст, медиа, да что угодно.</p> <pre><code tabindex="0" class="language-html"><h2>Мой раздел</h2> <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras efficitur laoreet massa. Nam eu porta dolor. Vestibulum pulvinar lorem et nisl tempor lacinia.</p> <p>Cras mi nisl, semper ut gravida sed, vulputate vel mauris. In dignissim aliquet fermentum. Donec arcu nunc, tempor sed nunc id, dapibus ornare dolor.</p> </code></pre> <p>Одно из преимуществ _сворачивания _контента заключается в том, что заголовки становятся смежными элементами. Это даёт пользователю возможность изучить доступный контент без необходимости много скроллить и увидеть его полностью, развернув блок.</p> <p>Другое преимущество — это то, что пользователям клавиатуры не нужно проходить через все элементы страницы, на которых можно сделать фокус, чтобы попасть туда, куда они хотят. На скрытом контенте его установить нельзя.</p> <h2>Адаптивная разметка</h2> <p>Рискованно просто добавлять обработчик клика для заголовков, чтобы связать с ними контент. Это не то взаимодействие, которого ожидают вспомогательные технологии или которого можно добиться при помощи клавиатуры. Вместо этого нам нужно адаптировать разметку, добавив в неё стандартную кнопку.</p> <pre><code tabindex="0" class="language-html"><h2><button>Мой раздел</button></h2> <div> <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras efficitur laoreet massa. Nam eu porta dolor. Vestibulum pulvinar lorem et nisl tempor lacinia.</p> <p>Cras mi nisl, semper ut gravida sed, vulputate vel mauris. In dignissim aliquet fermentum. Donec arcu nunc, tempor sed nunc id, dapibus ornare dolor.</p> </div> </code></pre> <p><strong>Примечание</strong>: я обернул контент в элемент <code><div></code> для того, чтобы использовать скрипт ниже для его показа и скрытия.</p> <p>Кнопка в данном случае — дочерний элемент заголовка. Это означает, что, когда пользователь скринридера сделает фокус на <code><button></code>, то кнопка будет определена вместе с её родительским элементом: <em>«Мой раздел, кнопка, заголовок второго уровня»</em> (или аналогичным образом в зависимости от скринридера).</p> <p>Если бы вместо этого мы _преобразовали _заголовок в кнопку, используя ARIA-атрибут <code>role="button"</code>, то переопределили бы семантику заголовка. Пользователи скринридеров потеряли бы заголовок в качестве структурной и навигационной метки.</p> <p>Также нам бы пришлось кастомизировать код для всех вариантов поведения элемента <code><button></code>, например, для поведения при фокусе (см. <code>tabindex</code> в примере ниже), и привязывать нужные клавиши, чтобы активировать наш кастомный контрол.</p> <pre><code tabindex="0" class="language-html"> <h2 role="button" tabindex="0">Мой раздел</h2> </code></pre> <h3>Состояние</h3> <p>Наш компонент может находится в одном из двух взаимоисключающих состояний: свёрнутом и развёрнутом. Его состояние может быть отображено визуально, но необходимо также сообщать о нём и программно. Можно сделать это, добавив для кнопки атрибут <code>aria-expanded</code> с начальным значением <code>false</code> (в свёрнутом состоянии). Соответственно, нам нужно скрыть связанный <code><div></code>. В данном случае при помощи <code>hidden</code>.</p> <pre><code tabindex="0" class="language-html"><h2><button aria-expanded="false">Мой раздел</button></h2> <div hidden> <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras efficitur laoreet massa. Nam eu porta dolor. Vestibulum pulvinar lorem et nisl tempor lacinia.</p> <p>Cras mi nisl, semper ut gravida sed, vulputate vel mauris. In dignissim aliquet fermentum. Donec arcu nunc, tempor sed nunc id, dapibus ornare dolor.</p> </div> </code></pre> <p>Некоторые совершают ошибку, добавляя <code>aria-expanded</code> для <em>управляемого элемента</em> вместо контрола. И это понятно, ведь фактически именно у контента переключается состояние. Если подумать, это не принесёт особой пользы: пользователю придётся найти раскрывающийся контент (это возможно только тогда, когда он на самом деле развёрнут!), а потом ещё поискать элемент, который им управляет. Поэтому информация о состоянии сообщается через контрол, который используется для переключения видимости контента.</p> <h2>Примечание. Это всё ARIA-кнопка?</h2> <p>Да конечно. Нам не нужно добавлять <code>role="button"</code>, так как элементу <code><button></code> неявно задана эта роль (ARIA-роль всего лишь имитирует роль по умолчанию). И, в отличие от <a href="https://inclusive-components.design/menus-menu-buttons/">кнопки меню</a> <em>(есть в <a href="https://medium.com/web-standards/menu-buttons-7f3aa1ad008d">переводе на русский</a>. — прим. переводчика),</em> нам не нужно сразу же менять контекст при перемещении фокуса. Следовательно, <code>aria-haspopup</code> в данном случае не подходит.</p> <p>Некоторые добавляют атрибут <code>aria-controls</code> и указывают <code>id</code> для контейнера, в котором хранится контент. Имейте в виду, что атрибут <a href="https://web.archive.org/web/20200924080848/https://heydonworks.com/article/aria-controls-is-poop/"><code>aria-controls</code> работает только в JAWS</a> на момент написания этой статьи <em>(на момент перевода в октябре 2019 года <a href="https://a11ysupport.io/tech/aria/aria-controls_attribute">ситуация не изменилась</a>. — прим. переводчика).</em> Пока контент в разделе следует за заголовком или кнопкой в исходном порядке (source order), это не нужно. Пользователь будет сразу же сталкиваться с раскрытым контентом, когда перемещается дальше по странице.</p> <h3>Стилизация кнопки</h3> <p>Мы оказались в ситуации, когда используем кнопку, но при этом она должна выглядеть как улучшенная версия заголовка, внутри которого она находится. Наиболее эффективный способ это сделать — удалить все авторские и браузерные стили для кнопок и наследовать их от их родительского заголовка.</p> <pre><code tabindex="0" class="language-css">h2 button { all: inherit; } </code></pre> <p>Отлично, однако сейчас кнопка интуитивно не понятна (<a href="https://www.interaction-design.org/literature/book/the-glossary-of-human-computer-interaction/affordances">affordance</a>). Она не выглядит так, будто её можно активировать. Именно здесь обычно добавляется символ плюс или минус. Плюс означает, что раздел может быть развёрнут, а минус, что его можно свернуть.</p> <p>Теперь возникает такой вопрос: как нам рендерить иконку? Ответ: максимально эффективно и доступно. Простые формы, например, прямоугольники (<code><rect></code>) — это хороший способ создания иконок в SVG, поэтому давайте это сделаем.</p> <pre><code tabindex="0" class="language-xml"><svg viewBox="0 0 10 10"> <rect height="8" width="2" y="1" x="4"/> <rect height="2" width="8" y="4" x="1"/> </svg> </code></pre> <p>Кода так мало, что он может поместиться в твит. Поскольку программно состояние передаётся через атрибут <code>aria-expanded</code>, нам не нужно, чтобы эта графика была доступна для скринридера или была интерактивной. В этом случае нам нужно добавить ещё пару атрибутов.</p> <pre><code tabindex="0" class="language-html"><button aria-expanded="false"> Мой раздел <svg viewBox="0 0 10 10" aria-hidden="true" focusable="false"> <rect class="vert" height="8" width="2" y="1" x="4"/> <rect height="2" width="8" y="4" x="1"/> </svg> </button> </code></pre> <ul> <li><code>aria-hidden="true"</code> скрывает SVG-иконку от скринридеров и других вспомогательных технологий.</li> <li><code>focusable="false"</code> решает проблему добавления фокуса по умолчанию для SVG-файлов в Internet Explorer и Edge.</li> </ul> <p>Обратите внимание на класс <code>vert</code> для прямоугольника, который представляет собой вертикальную конструкцию. Мы собираемся с помощью CSS показывать и скрывать его в зависимости от состояния, превращая иконку то в плюс, то в минус.</p> <pre><code tabindex="0" class="language-css">[aria-expanded="true"] .vert { display: none; } </code></pre> <p>Связывание состояния и его визуального представления — <em>очень хорошая практика.</em> Это гарантия того, что сообщение об изменении состояния совместимо с разными системами. Не слушайте тех, кто выступает за абсолютное разделение HTML-семантики и CSS-стилей. Форма должна следовать за функцией, и такое решение напрямую более надёжно.</p> <p>Обратите внимание, что стиль фокуса по умолчанию был сброшен при помощи <code>inherit: all</code>. Можно объявить стиль фокуса для SVG следующим образом:</p> <pre><code tabindex="0" class="language-css">h2 button:focus svg { outline: 2px solid; } </code></pre> <h3>Высококонтрастные темы</h3> <p>Ещё одна вещь: мы можем обеспечить поддержку высококонтрастных тем для элементов <code><rect></code>. Если указать в <code>fill</code> значение <code>currentColor</code> для <code><rect></code>, то такие элементы изменяют цвет вместе с текстом, когда на него влияет изменение темы.</p> <pre><code tabindex="0" class="language-css">[aria-expanded] rect { fill: currentColor; } </code></pre> <p>Чтобы протестировать ваш дизайн в высококонтрастной теме в Windows найдите «Высокая контрастность» и выберете нужную тему в пункте «Выбор темы». Многие высококонтрастные темы инвертируют цвета для уменьшения яркости. Это помогает людям, страдающим мигренью или светобоязнью, а также людям с нарушениями зрения.</p> <h2>Примечание. Почему бы не использовать <code><use></code>?</h2> <p>Если у нас много сворачиваемых областей на странице, то повторное использование одного и того же содержимого SVG-элемента <code><pattern></code> при помощи <a href="https://wearejh.com/inline-svg-use-element/">элементов <code><use></code></a> и <code>xlink:href</code> уменьшило бы их избыточность.</p> <pre><code tabindex="0" class="language-html"><button aria-expanded="false"> Мой раздел <svg viewBox="0 0 10 10 aria-hidden="true" focusable="false"> <use xlink:href="#plusminus"/> </svg> </button> </code></pre> <p>К сожалению, это означало бы, что мы больше не можем управлять конкретным прямоугольником <code>.vert</code> для его показа и скрытия. В нашем случае использование небольшого количества строк кода для определения идентичного SVG не такая большая проблема.</p> <h2>Небольшой скрипт</h2> <p>Учитывая простоту такого взаимодействия, а также все элементы с их семантикой, нам нужно только написать очень лаконичный скрипт:</p> <pre><code tabindex="0" class="language-js">(function() { const headings = document.querySelectorAll('h2'); Array.prototype.forEach.call(headings, heading => { let btn = heading.querySelector('button'); let target = heading.nextElementSibling; btn.onclick = () => { let expanded = btn.getAttribute('aria-expanded') === 'true' || false; btn.setAttribute('aria-expanded', !expanded); target.hidden = expanded; } }) })() </code></pre> <p><a href="https://codepen.io/heydon/pen/QqzRvQ/">Вот демо на CodePen</a>:</p> <h2>Прогрессивное улучшение</h2> <p>Проблема со скриптом выше заключается в том, что для него требуется вручную адаптировать HTML для работы сворачивающихся секций. Ожидается, что это реализовано инженером как компонент через шаблон или JSX. Однако для статических сайтов, например, блогов, есть две неизбежные проблемы:</p> <ul> <li>Если JavaScript недоступен, то в DOM остаются интерактивные элементы, которые ничего не делают, поэтому в этом случае их семантика не имеет смысла.</li> <li>Ответственность за создание и поддержку сложного HTML лежит на авторе или редакторе.</li> </ul> <p>Вместо этого мы можем взять базовый ввод текста, скажем, в виде разметки или WYSIWYG <em>(от англ. «What You See Is What You Get», проще говоря — визуальный редактор. — прим. переводчика)</em> и улучшить его <em>постфактум</em> с помощью скрипта. Это довольно просто сделать с помощью jQuery, учитывая методы <code>nextUntil</code> и <code>wrapAll</code>, однако в обычном JavaScript нам нужно сделать некоторую итерацию. Вот другое демо на CodePen, в котором автоматически добавляются переключатель и группа с контентом для переключения. Он нацелен на все <code><h2></code>, найденные на странице в <code><main></code>.</p> <p>Почему это написано на JavaScript? Потому что современные браузеры одинаково поддерживают методы Web API и такой небольшой интерактив не должен зависеть от большой библиотеки.</p> <h2>Прогрессивный веб-компонент</h2> <p>Последний пример показывает, что нам не нужно думать о раскрывающихся секциях во время редактирования. Они появляются автоматически. Но то, что мы приобрели в плане удобства, мы потеряли в контроле. Что, если вместо этого, мы найдём компромисс между лаконичной разметкой и тем, какие разделы будут раскрывающимися и в каком состоянии они будут находиться при загрузке страницы после того, что мы <em>написали</em>?</p> <p>Веб-компоненты могут стать ответом. Рассмотрим пример ниже:</p> <pre><code tabindex="0" class="language-html"><toggle-section open="false"> <h2>Мой раздел</h2> <p>Lorem ipsum dolor sit amet, consectetur adipiscing elit. Cras efficitur laoreet massa. Nam eu porta dolor. Vestibulum pulvinar lorem et nisl tempor lacinia.</p> <p>Cras mi nisl, semper ut gravida sed, vulputate vel mauris. In dignissim aliquet fermentum. Donec arcu nunc, tempor sed nunc id, dapibus ornare dolor.</p> </toggle-section> </code></pre> <p>Имя кастомного элемента проще запомнить, а последствия взаимодействия с ним очевидны благодаря атрибуту <code>open</code>. Ещё лучше то, что, когда JavaScript недоступен, этот внешний элемент обрабатывается как просто-напросто <code><div></code>, а сворачиваемая секция остается простым разделом. Это не принесёт никакого вреда.</p> <p>Фактически, если мы проверяем поддержку элемента с <code><template></code> и <code>attachShadow</code> при помощи скрипта, то такой же фолбэк будет отображаться в браузерах, которые эти возможности не поддерживают.</p> <pre><code tabindex="0" class="language-js">if ('content' in document.createElement('template')) { // Определяем <template> для веб-компонента if (document.head.attachShadow) { // Определяем веб-компонент, используя синтаксис версии v1 } } </code></pre> <h2>Шаблон</h2> <p>Мы можем добавить элемент шаблона в разметку и ссылаться на него или создать его на лету. Это я собираюсь сделать позже.</p> <pre><code tabindex="0" class="language-js">tmpl.innerHTML = ` <h2> <button aria-expanded="false"> <svg aria-hidden="true" focusable="false" viewBox="0 0 10 10"> <rect class="vert" height="8" width="2" y="1" x="4"/> <rect height="2" width="8" y="4" x="1"/> </svg> </button> </h2> <div class="content" hidden> <slot></slot> </div> <style> h2 { margin: 0; } h2 button { all: inherit; box-sizing: border-box; display: flex; justify-content: space-between; width: 100%; padding: 0.5em 0; } button svg { height: 1em; margin-left: 0.5em; } [aria-expanded="true"] .vert { display: none; } [aria-expanded] rect { fill: currentColor; } </style> `; </code></pre> <p>Этот шаблон компонента станет поддеревом Shadow DOM.</p> <p>Когда мы стилизуем сворачиваемую секцию <em>внутри</em> её собственной Shadow DOM, то такие стили не влияют на элементы из Light DOM (стандартной, внешней DOM). Кроме того, они не применяются, если браузер не поддерживает <code><template></code> и кастомные элементы.</p> <h2>Определение компонента</h2> <p>Обратите внимание на элемент <code><slot></code> в HTML-шаблоне. Он — это окно в нашей Light DOM. В него гораздо проще обернуть контент, который предоставил автор, в отличие от <a href="https://codepen.io/heydon/pen/gGNaoM">предыдущего демо с прогрессивным улучшением</a>.</p> <p>Внутри компонента <code>this.innerHTML</code> есть ссылка на этот контент в Light DOM. Мы должны создать <code>shadowRoot</code> и заполнить его контентом шаблона. Разметка Shadow DOM вместо этого находится в <code>this.shadowRoot.innerHTML</code>.</p> <pre><code tabindex="0" class="language-js">class ToggleSection extends HTMLElement { constructor() { super(); this.attachShadow({ mode: 'open' }); this.shadowRoot.appendChild(tmpl.content.cloneNode(true)); } } </code></pre> <p>С помощью этих ссылок можно переместить Light DOM в Shadow DOM. Это означает, что мы можем повторно использовать лейбл <code><h2></code> в Light DOM и убрать ставший ненужным элемент. Такие манипуляции с DOM могут выглядеть дико, особенно если вы привыкли использовать простые, декларативные (React) компоненты. Однако это то, что делает веб-компоненты прогрессивными.</p> <pre><code tabindex="0" class="language-js">this.btn = this.shadowRoot.querySelector('h2 button'); var oldHeading = this.querySelector('h2'); var label = oldHeading.textContent; this.btn.innerHTML = label + this.btn.innerHTML; oldHeading.parentNode.removeChild(oldHeading); </code></pre> <p>Вообще-то мы можем сделать лучше и поддерживать разные начальные уровни заголовков. Вместо того, чтобы управлять заголовками, можно просто получить первый элемент из Light DOM. Убедитесь, что он — заголовок. Это необходимо для его редактирования. Однако, если это не заголовок, мы можем использовать любой элемент. Я покажу как.</p> <pre><code tabindex="0" class="language-js">var oldHeading = this.querySelector(':first-child'); </code></pre> <p>Сейчас нужно просто убедиться в том, что <em>уровень</em> заголовка в Shadow DOM соответствует оригиналу из Light DOM. Я могу запросить <code>tagName</code> заголовка из Light DOM и в соответствии с этим повысить его уровень в Shadow DOM при помощи <code>aria-level</code>.</p> <pre><code tabindex="0" class="language-js">let level = parseInt(oldHeading.tagName.substr(1)); this.heading = this.shadowRoot.querySelector('h2'); if (level && level !== 2) { this.heading.setAttribute('aria-level', level); } </code></pre> <p>Второй символ из <code>tagName</code> спарсился как целое. Если это натуральное число (<code>NaN</code> — ложное) и не <code>2</code>, которое неявно присутствует в <code><h2></code>, то применится атрибут <code>aria-level</code>. Элементы, которые не являются заголовками, в качестве фоллбека всё ещё отдают содержимое <code>textContent</code> как лейбл для хранящегося в Shadow DOM <code><h2></code>. Это может сопровождаться «вежливым» (polite) предупреждением <code>console.warn</code>, которое рекомендует разработчикам использовать заголовок в качестве предпочтительного элемента.</p> <pre><code tabindex="0" class="language-js">if (!level) { console.warn('У первого элемента внутри каждого <toggle-section> должен быть заголовок подходящего уровня.'); } </code></pre> <p>Одно из преимуществ использования <code>aria-level</code> заключается в том, что, в нашем случае, атрибут не используется в качестве стилевого хука (styling hook), поэтому внешний вид заголовка или кнопки остаётся неизменным.</p> <pre><code tabindex="0" class="language-html"><h2 aria-level="3"> <button aria-expanded="false"> <svg aria-hidden="true" focusable="false" viewBox="0 0 10 10"> <rect class="vert" height="8" width="2" y="1" x="4"/> <rect height="2" width="8" y="4" x="1"/> </svg> </button> </h2> </code></pre> <p>Если вы хотите, чтобы заголовки вашей сворачиваемой секции внешне отражали их уровень, вы должны включить что-то вроде CSS-стилей ниже:</p> <pre><code tabindex="0" class="language-css">toggle-section [aria-level="2"] { font-size: 2rem; } toggle-section [aria-level="3"] { font-size: 1.5rem; } /* И так далее… */ </code></pre> <h3>Роль <code>region</code></h3> <p>Любой контент, который представлен заголовком, является _де-факто _(под)разделом страницы. Но, как я уже говорил в <a href="https://inclusive-components.design/a-todo-list/#headinglevel">«Списке дел»</a> <em>(есть в <a href="https://medium.com/web-standards/a-todo-list-40a324436b3e">переводе на русский</a>. — прим. переводчика),</em> вы можете использовать явные секционные элементы-контейнеры <code><section></code>. Вы добьётесь того же эффекта, если примените атрибут <code>role="region"</code> к элементу вроде нашего кастомного <code><toggle-section></code> (который, в противном случае, не будет обладать такой семантикой).</p> <pre><code tabindex="0" class="language-html"><toggle-section role="region"> … </toggle-section> </code></pre> <p>Пользователи скринридеров <a href="https://web.archive.org/web/20201108115147/https://heydonworks.com/article/responses-to-the-screen-reader-strategy-survey/">больше предпочитают перемещаться по документу по заголовкам, чем по областям</a>, однако у многих скринридеров <em>есть</em> функция шорткатов по областям страницы (region shortcuts). Добавление атрибута <code>role="region"</code> даёт довольно много:</p> <ul> <li>Обеспечивает фоллбек в виде навигационной подсказки для пользователей скринридеров в ситуациях, когда Light DOM не содержит заголовка.</li> <li>Объявляется как «область» (region), когда пользователь скринридера попадает в этот раздел и ведёт себя как структурная подсказка.</li> <li>Предоставляет стилевой хук в виде <code>toggle-button[role="region"]</code>. Это позволяет нам добавлять те стили, которые мы хотим увидеть, если скрипт запущен и веб-компоненты поддерживаются.</li> </ul> <h2>Привязка <code>open и aria-expanded</code></h2> <p>Когда значение атрибута <code>open</code> меняется с <code>true</code> на <code>false</code> мы хотим, чтобы было также видно переключение контента. Используя <code>observedAttributes()</code> и <code>attributeChangedCallback()</code>, мы можем сделать это <em>напрямую.</em> Разместим этот код после конструктора компонента:</p> <pre><code tabindex="0" class="language-js">static get observedAttributes() { return ['open']; } attributeChangedCallback(name) { if (name === 'open') { this.switchState(); } } </code></pre> <ul> <li><code>observedAttributes()</code> получает массив всех атрибутов родительского <code><toggle-section></code>, которые мы хотим увидеть.</li> <li><code>attributeChangedCallback(name)</code> позволяет нам выполнять нашу функцию <code>switchState()</code> в случае изменения значения <code>open</code>.</li> </ul> <p>Преимущество такого подхода в том, что мы можем переключать состояние, используя скрипт, который просто изменяет значение <code>open </code>за пределами компонента. Чтобы <em>пользователи</em> могли изменить состояние, мы можем просто перебросить <code>open</code> в функцию клика:</p> <pre><code tabindex="0" class="language-js">this.btn.onclick = () => { this.setAttribute('open', this.getAttribute('open') === 'true' ? 'false' : 'true' ); } </code></pre> <p>Так как функция <code>switchState()</code> увеличивает значение <code>aria-expanded</code>, то мы привязали <code>open</code> к <code>aria-expanded</code>, убедившись в доступности изменения состояния.</p> <pre><code tabindex="0" class="language-js">this.switchState = () => { let expanded = this.getAttribute('open') === 'true' || false; this.btn.setAttribute('aria-expanded', expanded); this.shadowRoot.querySelector('.content').hidden = !expanded; } </code></pre> <p><a href="https://codepen.io/heydon/pen/ZXdbxj/">Вот демо с CodePen с этой версией веб-компонента</a> с комментариями:</p> <h2>Свернуть или развернуть всё</h2> <p>Поскольку мы переключаем элемент <code><toggle-section></code> через атрибут <code>open</code>, нужно элементарно дать пользователям возможность развернуть или свернуть всё сразу. Одним из преимуществ такой меры является то, что пользователи, которые открыли несколько разделов независимо друг от друга, могут «сбросить» исходное, свёрнутое состояние для лучшей видимости содержимого. К тому же пользователи, которые считают, что возня с интерактивными элементами отвлекает или утомляет, могут вернуться к прокрутке раскрытых секций.</p> <p>Кажется заманчивым добавить «развернуть или свернуть всё» как два отдельных переключателя. Но мы не знаем, как много разделов будет изначально в другом состоянии. Мы также не знаем, сколько их пользователь открыл или закрыл вручную.</p> <p>Поэтому нам нужно сгруппировать два альтернативных контрола.</p> <pre><code tabindex="0" class="language-html"><ul class="controls" aria-label="Контролы секции"> <li><button id="expand">развернуть всё</button></li> <li><button id="collapse">свернуть всё</button></li> </ul> </code></pre> <p>Важно объединить в группу связанные контролы, и списки — это стандартная разметка для того, чтобы это сделать. Кроме того списки ссылок рассматривались в <a href="https://inclusive-components.design/menus-menu-buttons/">«Меню и кнопки меню»</a> <em>(всё ещё есть <a href="https://medium.com/web-standards/menu-buttons-7f3aa1ad008d">перевод на русский</a>. — прим. переводчика).</em> Списки и элементы списков подсказывают пользователям скринридеров о том, что они взаимодействуют со связанными элементами, и количество таких элементов.</p> <p>У некоторых составных ARIA-виджетов есть свои собственные механизмы группировки, например, <code>role="menu"</code> группирует элементы с <code>role="menuitem"</code> или <code>role="tablist"</code> группирует элементы с <code>role="tab"</code>. Наш вариант использования не подходит ни для одной из этих парадигм, так что хватит простого списка с заголовком.</p> <p>Так как в тег <code><ul></code> уже встроен «групповой» элемент (group element), то многие вспомогательные технологии знают, что групповая подпись добавляется при помощи <code>aria-label</code>. Когда пользователи VoiceOver попадут в список и сделают фокус на кнопке, то услышат: <em>«Развернуть всё, кнопка, список, контролы секции, два пункта».</em></p> <p>Обратите внимание, что при использовании <code>aria-label</code> добавляется только невидимый лейбл. Это допустимо, если назначение кнопок можно определить визуально с помощью других подсказок, по той же раскладке. В этом случае, вероятно, будет достаточно расположить кнопки рядом с разделами, но нужно это протестировать.</p> <h2>Отслеживание URL</h2> <p>Одно последнее улучшение.</p> <p>Обычно, если нет улучшения с помощью JavaScript, пользователи могут переходить по ссылкам на определенные разделы страниц и делиться ими со своими <code>hash</code>. Такое поведение ожидаемо и является частью привычного UX-паттерна в вебе.</p> <p>Большинство парсеров с этой целью добавляет атрибуты <code>id</code> для заголовков. Поскольку заголовок для целевого раздела в нашем расширенном интерфейсе может находиться внутри свёрнутого раздела или раздела, на котором не сделан фокус, нам нужно его открыть, чтобы показать контент и перенести фокус на него. Жизненный цикл <code>connectedCallback()</code> даёт нам это сделать, когда компонент готов. Это похоже на <code>DOMContentLoaded</code>, но только для веб-компонентов.</p> <pre><code tabindex="0" class="language-js">connectedCallback() { if (window.location.hash.substr(1) === this.heading.id) { this.setAttribute('open', 'true'); this.btn.focus(); } } </code></pre> <p>Обратите внимание на то, что мы делаем фокус на кнопке внутри заголовка компонента. Это перемещает пользователей клавиатуры к соответствующему компоненту, готовому к взаимодействию. Скринридерами будет объявлен уровень родительского заголовка вместе с названием кнопки.</p> <p>В дополнение к этому нам нужно обновлять <code>hash</code> каждый раз, когда пользователи открывают последующий раздел. Тогда они могут поделиться определённым URL без необходимости копаться в инструментах разработчика (если они знают как!), чтобы скопировать и вставить <code>id</code> заголовка. Давайте используем <code>pushState</code> для динамичного изменения URL без перезагрузки страницы:</p> <pre><code tabindex="0" class="language-js">this.btn.onclick = () => { let open = this.getAttribute('open') === 'true' || false; this.setAttribute('open', open ? 'false' : 'true'); if (this.heading.id && !open) { history.pushState(null, null, '#' + this.heading.id); } } </code></pre> <p><a href="https://codepen.io/heydon/pen/ZXgqKG">А вот демо с добавленной возможностью отслеживания <code>hash</code></a>:</p> <h2>Заключение</h2> <p>Ваша роль как дизайнера и разработчика (да, вы можете быть и тем, и другим одновременно) заключается в том, чтобы удовлетворять потребности людей, которые получают ваш контент и используют предложенный вами функционал. Эти потребности охватывают как потребности «конечных пользователей», так и других контрибьютеров. Продукт должен быть, конечно же, доступным и обладать хорошей производительностью, но поддержка и расширение его возможностей не должны быть завязаны на эзотерических технических знаниях.</p> <p>Вне зависимости от того, используете ли вы веб-компоненты или нет, прогрессивное улучшение не только гарантирует, что интерфейс хорошо структурирован и надёжен. Как мы здесь увидели, это также может упростить процесс редактирования контента. Это делает разработку приложения и его контент более инклюзивным.</p> <h2>Чеклист</h2> <ul> <li>Не зависьте от больших библиотек в случае небольших взаимодействий, если только рассматриваемая библиотека не будет использоваться для других улучшений взаимодействия.</li> <li>Не переопределяйте важные роли элементов. Прочитайте <a href="https://www.w3.org/TR/using-aria/#second">второе правило использования ARIA</a>.</li> <li>Поддерживайте высококонтрастные темы в ваших SVG-иконках при помощи <code>currentColor</code>.</li> <li>Если контент уже статичный, то это хорошая возможность для прогрессивного улучшения вашего веб-компонента.</li> <li>Пожалуйста, используйте информативные лейблы в секциях, а не «Раздел 1», «Раздел 2» и так далее. В таком случае это будут просто плейсхолдеры!</li> </ul> </article> <article> <h1>Извлекаем критический CSS</h1> <p>Tue, 08 Oct 2019 00:00:00 GMT</p> <p>Браузер должен скачать и распарсить CSS-файл перед тем, как отрисует страницу. Это делает CSS ресурсом, блокирующим рендеринг. Если файл большой или соединение медленное, то запрос стилей может значительно увеличить время отрисовки страницы.</p> <p><strong>Ключевой термин</strong>: критический CSS — это метод, который извлекает CSS для контента «над сгибом» <em>(above the fold — термин из газетного дизайна — прим. редактора),</em> чтобы максимально быстро показать его пользователю.</p> <figure> <figcaption> Над сгибом и под сгибом. </figcaption> </figure> <p>Над сгибом — это то, что пользователь видит в первую очередь при загрузке страницы, до прокрутки. Не существует универсального способа определить, где заканчивается экран пользователя и что находится в первом экране, поскольку существует огромное количество устройств с разными размерами экрана.</p> <p>Критический CSS можно заинлайнить внутри <code><head></code> прямо в HTML-документе. Это позволит избежать дополнительного запроса к серверу для получения этих стилей. Остальной CSS может быть загружен асинхронно.</p> <p>Увеличение времени рендеринга может существенно повлиять на <a href="https://developers.google.com/web/fundamentals/performance/rail#ux">воспринимаемую производительность</a>, особенно при плохом соединении. В мобильных сетях высокая задержка является проблемой независимо от пропускной способности.</p> <p>Если у вас плохой <a href="https://web.dev/first-contentful-paint/">First Contentful Paint</a> (FCP) и вы видите рекомендацию «Устранить ресурсы, блокирующие рендеринг» в отчёте Lighthouse, то стоит попробовать методику критического CSS.</p> <h3><strong>Подводные камни!</strong></h3> <p><em>Помните, что если вы заинлайнили большой кусок CSS, то это повлияет на размер и, как следствие, время получения HTML-файла. Если важно всё, то не важно ничего. У заинлайненого CSS есть несколько недостатков: он не кэшируется браузером для повторного использования при последующих загрузках страницы, поэтому лучше использовать его осторожно.</em></p> <p>Чтобы минимизировать запросы при первом рендеринге, старайтесь чтобы размер контента над сгибом не превышал 14 Кб (после сжатия).</p> <p>Новые <a href="https://hpbn.co/building-blocks-of-tcp/">TCP-соединения</a> не могут сразу же использовать весь доступный поток передачи данных между клиентом и сервером. Соединение происходит с <a href="https://hpbn.co/building-blocks-of-tcp/#slow-start">медленным стартом</a>, что позволяет избежать перегрузки соединения большим количеством данных, которые оно может принять. При таком подходе сервер начинает передачу с небольшой порции данных и, если соединение с клиентом идеальное, то удваивает эту порцию при следующей отправке. Большинство серверов может передать максимум 10 пакетов или 14 Кб при первой передаче.</p> <p>Положительный эффект на перформанс, которого вы можете добиться этим методом, зависит от типа вашего сайта. Проще говоря, чем больше CSS используется на сайте, тем заметнее будет влияние метода критического CSS.</p> <h2>Обзор инструментов</h2> <p>Существует несколько отличных инструментов, которые позволяют автоматически определять критический CSS для страницы. Это хорошие новости, поскольку делать это вручную довольно муторно. Требуется анализ всего DOM, чтобы определить стили, применяемые к каждому элементу в области просмотра.</p> <h2>Critical</h2> <p><a href="https://github.com/addyosmani/critical">Critical</a> извлекает, минифицирует и инлайнит критический CSS. Доступен в виде <a href="https://www.npmjs.com/package/critical">npm-модуля</a>. Может быть использован в Gulp (прямо внутри) или Grunt (в виде <a href="https://github.com/bezoerb/grunt-critical">плагина</a>). Есть и <a href="https://github.com/anthonygore/html-critical-webpack-plugin">плагин для Webpack</a>.</p> <p>Это простой инструмент, который решает вашу головную боль. Для него даже не нужно указывать пути до файлов стилей, Critical автоматически определит их. Он также поддерживает извлечение критического CSS для разных разрешений экрана.</p> <h2>criticalCSS</h2> <p><a href="https://github.com/filamentgroup/criticalCSS">CriticalCSS</a> это ещё один <a href="https://www.npmjs.com/package/criticalcss">npm-модуль</a>, который извлекает критический CSS. Он так же доступен в виде CLI.</p> <p>У него нет опций инлайна или минификации критического CSS, но он позволяет вам дописать правила, которые не относятся к разряду критических и дает вам более тонкий контроль над декларацией <code>@font-face</code>.</p> <h2>Penthouse</h2> <p><a href="https://github.com/pocketjoso/penthouse">Penthouse</a> — хороший выбор, если на вашем сайте или в приложении используется большое количество стилей или если стили динамически внедряются в DOM (как это бывает, например, в приложениях Angular). В этом инструменте под капотом скрывается <a href="https://github.com/GoogleChrome/puppeteer">Puppeteer</a> и у него даже есть <a href="https://jonassebastianohlsson.com/criticalpathcssgenerator/">онлайн-версия</a>.</p> <p>Penthouse не умеет автоматически определять расположение файлов стилей, вы должны руками указать пути до HTML и CSS-файлов, для которых нужно сгенерировать критический CSS. Плюс этого инструмента в том, что он отлично справляется с многопоточностью.</p> </article> <article> <h1>Инклюзивные компоненты: интерфейсы со вкладками</h1> <p>Mon, 30 Sep 2019 00:00:00 GMT</p> <p>Если вы задумаетесь о том, что же именно происходит с интерфейсами, когда вы взаимодействуете с ними, то чаще всего что-то показывается или скрывается. Я уже рассказывал о <a href="https://inclusive-components.design/menus-menu-buttons/">кнопках меню</a> <em>(есть в <a href="https://web-standards.ru/articles/tabbed-interfaces/articles/menu-buttons">переводе на русский</a>. — прим. переводчика),</em> при клике по которым появляется выпадающее меню, и их родственниках — более простых и менее очевидных <a href="https://inclusive-components.design/tooltips-toggletips/">тултипах и тоглтипах</a> <em>(тоже есть в <a href="https://web-standards.ru/articles/tabbed-interfaces/articles/tooltips-toggletips">переводе</a>. — прим. переводчика).</em> Вы можете добавить к этому списку простые виджеты для раскрытия блоков, составные «аккордеоны» <strong>и интерфейсы со вкладками</strong> <em>(от англ. «tabbed interfaces», дальше я буду называть их просто «вкладками». — прим. переводчика).</em> Стоит также отметить, что одностраничные приложения (single-page applications, SPA) эмулируют отображение и скрытие целых страниц при помощи JavaScript.</p> <p>Как мы уже знаем, разница между панелями вкладок, представлениями приложений и простым фрагментом документа не так очевидна, как может показаться. Тем не менее, нам нужно быть уверенными в том, какой именно интерфейс мы предоставляем пользователям. Иначе им будет сложно понять, как им правильно пользоваться.</p> <p>Сторонники прогрессивного улучшения под термином интерфейс в первую очередь понимают структурированный статический контент, а уже потом то, как он может быть расширен и сделан интерактивным с помощью JavaScript. Даже если вы хотите использовать JavaScript на ранних этапах проектирования интерфейса, полезно создать надёжную основу с помощью семантического HTML, опирающегося на стандартное поведение браузера. Иногда вы даже можете обнаружить, что JavaScript — это шаг, который вообще не нужен.</p> <p>Ставлю деньги на то, что изначально вкладки — это просто <a href="https://inclusive-components.design/menus-menu-buttons/#tablesofcontent">оглавление с якорными ссылками</a>, которые ведут к разным разделам страницы. Список вкладок, как и оглавление, позволяет пользователю выбирать между различными разделами контента.</p> <ul> <li>Оглавление → список вкладок.</li> <li>Якорные ссылки → вкладки.</li> <li>Разделы → панели вкладок.</li> </ul> <h2>Улучшение с помощью CSS</h2> <p>Что, если я использую немного CSS, чтобы визуализировать выбор раздела из моего оглавления? Конечно, это можно сделать при помощи псевдокласса <code>:target</code>.</p> <pre><code tabindex="0" class="language-css">section:not(:target) { display: none; } </code></pre> <p>Давая пользователям возможность раскрывать контент, мы превращаем наше оглавление во вкладки с помощью CSS. Поскольку <code>display: none</code> скрывает контент от вспомогательных технологий, то это улучшение затрагивает пользователей скринридеров так же, как и всех остальных.</p> <p>Возьмите ссылки из оглавления и выровняйте их по горизонтали: тогда этот небольшой CSS-эксперимент действительно приведёт к тому, что оглавление станет похожим на вкладки. Но в этом и заключается проблема.</p> <p>Во <a href="https://resilientwebdesign.com/chapter2/">второй главе своей книги «Resilient Web Design»</a> Джереми Кит рассказывает о <em>материальной честности</em> (material honesty) следующее: «Один материал не должен использоваться в качестве замены другому». В этом случае мы делаем оглавление всего лишь <em>похожим</em> на список вкладок. Следует этого избегать. Пользователи, которые видят вкладки, ожидают определённого поведения, которого нет у простого списка ссылок.</p> <p>По этой же причине элементы, по дизайну похожие на вкладки, не должны использоваться для навигации по всему сайту. По крайней мере, когда пользователь выбирает «вкладку», он не ожидает перехода на новую страницу!</p> <p>Я встречал огромное количество полноценных вкладок, написанных на JavaScript и обвешанных атрибутами ARIA, для которых простые оглавления разделов страницы хорошо работали. Так даже лучше, ведь они более надёжны и эффективны. Но ради всего святого, пусть они <em>выглядят</em> как оглавления. Пусть семантика и поведение соответствуют тем ожиданиям, которые продиктованы визуальным дизайном интерфейса.</p> <h2>Настоящие вкладки</h2> <p>Преимущество использования списков якорных ссылок и стандартного поведения браузера, на котором они основаны, заключается в том, что в их случае всё просто и понятно. Их поведение специфично для веба.</p> <p>Вкладки, с другой стороны, парадигма, которая пришла из десктопных приложений. Если она <em>вообще</em> и понятна пользователям в контексте веб-страниц, то только благодаря аккуратному, хорошо проработанному визуальному дизайну и семантике ARIA.</p> <p>Что делает вкладки вкладками, так это удобство взаимодействия с ними с клавиатуры. На самом деле единственная причина, по которой в этом случае нужна семантика ARIA — это для предупреждения пользователей скринридеров об ожидаемом поведении клавиатуры. Ниже базовая семантическая структура и примечания к ней:</p> <pre><code tabindex="0" class="language-html"><ul role="tablist"> <li role="presentation"> <a role="tab" href="#section1" id="tab1" aria-selected="true"> Раздел 1 </a> </li> <li role="presentation"> <a role="tab" href="#section2" id="tab2"> Раздел 2 </a> </li> <li role="presentation"> <a role="tab" href="#section3" id="tab3"> Раздел 3 </a> </li> </ul> <section role="tabpanel" id="section1" aria-labelledby="tab1"> … </section> <section role="tabpanel" id="section2" aria-labelledby="tab2" hidden> … </section> <section role="tabpanel" id="section3" aria-labelledby="tab3" hidden> … </section> </code></pre> <ul> <li>Эти вкладки прогрессивно улучшаются за счёт оглавления и соответствующих разделов страницы. В некоторых случаях требуется добавление (<code>aria-selected</code>) или переопределение (<code>role="tab"</code>) семантики. В других (<code>role="presentation"</code>) — удаление семантики, которую больше нельзя применять или от которой нет никакой пользы. Вам не нужно, чтобы вкладки объявлялись так же, как простой список.</li> <li><code>role="tablist"</code> не распространяется на дочерние элементы. Эту роль нужно сочетать вместе с отдельными ролями <code>tab</code>, чтобы их могли обнаружить и перечислить вспомогательные технологии.</li> <li>Элементы <code>tabpanel</code>, которые не связаны с выбранной вкладкой, скрываются с помощью атрибута <code>hidden</code>.</li> <li>Пользователи, которые выбирают вкладку, должны быть уверены в её назначении. Следовательно, <code>aria-labelledby</code> используется для добавления подписи к панели вкладок при помощи названия вкладки. На практике это приводит к тому, что пользователь скринридера, попавший в панель вкладок и сделавший фокус на ссылке, услышит что-то вроде: <em>«Панель вкладок, раздел 1, [текст ссылки], ссылка».</em></li> </ul> <h3>Поведение клавиатуры</h3> <p>В отличие от якорных ссылок, вкладки не перемещают пользователя к связанным с ними разделам и панелям. Они просто показывают скрытый контент. Это удобно для зрячих пользователей (включая тех из них, кто пользуется скринридерами). Такие пользователи хотят переключаться между различными разделами и не возвращаться в начало страницы каждый раз, когда хотят выбрать новый.</p> <p>Тут есть и побочный эффект: если пользователь хочет перейти к разделу с помощью клавиатуры и взаимодействовать с его внутренним содержимым, то он вынужден пройти через все вкладки справа от текущей, которые расположены в порядке фокуса.</p> <p>Эту проблему можно решить, если реализовать переключение между вкладками с помощью клавиш со стрелками. Пользователь может выбрать и активировать вкладки стрелками, в то время как клавиша <kbd>Tab</kbd> используется для того, чтобы установить фокус на контенте внутри панели вкладок или под активной. Другими словами, клавиша <kbd>Tab</kbd> нужна не для вкладок, что, признаю, немного сбивает с толку. Хотелось бы, чтобы у клавиши и контрола были разные имена, но увы.</p> <p>Не менее важно то, что пользователя возвращает к выбранной вкладке после нажатия <kbd>Shift Tab</kbd>. Всё это можно сделать, если добавить для каждой вкладки атрибут <code>tabindex="-1"</code>, кроме выбранной в данный момент. Это убирает интерактивные вкладки из порядка фокуса, но даёт возможность установить его с помощью скрипта. В примере ниже выбрана вторая вкладка, которой задано состояние <code>aria-selected</code> со значением <code>true</code>.</p> <pre><code tabindex="0" class="language-html"><ul role="tablist"> <li role="presentation"> <a role="tab" tabindex="-1" href="#section1"> Раздел 1 </a> </li> <li role="presentation"> <a role="tab" href="#section2" aria-selected="true"> Раздел 2 </a> </li> <li role="presentation"> <a role="tab" tabindex="-1" href="#section2"> Раздел 3 </a> </li> </ul> </code></pre> <p>При помощи атрибута <code>tabindex="-1"</code> я могу для оставшихся вкладок отслеживать событие <code>keydown</code> для клавиш с левой и правой стрелками, чтобы сделать активной нужную неактивную вкладку.</p> <pre><code tabindex="0" class="language-js">tab.addEventListener('keydown', e => { let dir = e.which === 37 ? 'left' : 39 ? 'right' : null; if (dir) { switchTab(e.eventTarget, dir); } }) </code></pre> <p>Каждый раз, когда пользователь выбирает новую вкладку, появляется связанная с ней панель вкладок. Когда первая из четырёх вкладок выбрана, то любой скринридер объявит примерно следующее: <em>«[Название вкладки] выбрана, вкладка, 2 из 4».</em> Исчерпывающая информация.</p> <h3>Проблема чтения панелей вкладок</h3> <p>Теперь, когда при нажатии на клавишу <kbd>Tab</kbd> вкладки пропускаются, пользователям клавиатуры легко переместить фокус на первую ссылку или другие интерактивные элементы в открытой панели.</p> <p>Для пользователей скринридеров такое решение не настолько оптимально. Хотя незрячие пользователи тоже могут сделать фокус на элементах внутри панели выбранной вкладки, они не смогут увидеть контент, который появляется до или после этого взаимодействия. Если в панели вкладок вообще нет интерактивного контента, то они случайно сделают фокус на первом интерактивном элементе за пределами вкладок или под ними.</p> <p>При работе со скринридерами, такими как NVDA и JAWS, <a href="https://webaim.org/resources/shortcuts/nvda#reading">стрелка вниз перемещает пользователя к следующему элементу</a> (тому, на котором можно сделать фокус или к какому-то другому), после чего они объявят его. Если не изменять поведение, то это будет следующая вкладка в <code>tablist</code>. Вместо этого можно перехватить нажатие клавиши со стрелкой вниз и программно переместить фокус на открытую панель вкладок, убедившись, что она не пропущена. Посмотрите на <code>panels[i].focus()</code> в следующем фрагменте кода:</p> <pre><code tabindex="0" class="language-js">tab.addEventListener('keydown', e => { let index = Array.prototype.indexOf.call(tabs, e.currentTarget); let dir = e.which === 37 ? index - 1 : e.which === 39 ? index + 1 : e.which === 40 ? 'down' : null; if (dir !== null) { e.preventDefault(); dir === 'down' ? panels[i].focus() : tabs[dir] ? switchTab(e.currentTarget, tabs[dir]) : void 0; } }); </code></pre> <p>Часть с <code>void 0</code> означает «не делай ничего» в случае, если соседней вкладки не существует (так как вы находитесь в начале или в конце <code>tablist</code>). Можете посмотреть полное <a href="https://codepen.io/heydon/pen/veeaEa/">демо на CodePen</a>.</p> <p>После того, как панелям со вкладками задан лейбл при помощи связанных с ними вкладок, то, когда сделан фокус на нужной вкладке и нажата клавиша со стрелкой вниз, скринридер объявит: <em>«[Название вкладки], панель вкладок».</em> Таким образом пользователи точно узнают о своём новом местоположении в интерфейсе. Оттуда они могут продолжить просматривать дочерние элементы панели вкладок или нажать сочетание <kbd>Shift Tab</kbd>, чтобы вернуться к <code>tablist</code> и выбранной вкладке.</p> <p>Хотя зрячие пользователи клавиатуры с меньшей вероятностью будут использовать клавишу со стрелкой вниз, важно, чтобы у выбранной панели вкладок был стиль для фокуса, который указывает на изменение его положения. Всё это не помешает работе зрячих пользователей клавиатуры, которые могут делать всё, что нужно, со вкладками с помощью клавиши <kbd>Tab</kbd> и левой и правой стрелок.</p> <h2>Фокус на неинтерактивных элементах</h2> <p>В этой реализации мы, технически, даём пользователям возможность сделать на неинтерактивных элементах фокус при помощи нестандартных клавиш.</p> <p>Главное правило гласит, что пользователь не должен иметь возможность сделать фокус на неинтерактивных элементах, так как тогда он будет ожидать, что каждый из них <em>что-то делает.</em> Следовательно, код вроде этого не соответствует критерию WCAG <a href="https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-order.html">2.4.3 Порядок фокуса</a>. В нём есть непригодный для использования элемент.</p> <pre><code tabindex="0" class="language-html"><h2 tabindex="0">Раздел 3</h2> </code></pre> <p>Однако установление фокуса на элементе с помощью скрипта допустимо, когда пользователь <em>выбрал</em> это изменение контекста. В некоторых реализациях одностраничных приложений, если пользователь выбирает новое «представление» (view), то фокус устанавливается на вновь созданном элементе представления или на его основном заголовке.</p> <pre><code tabindex="0" class="language-html"><h2 tabindex="-1">Представление приложения</h2> </code></pre> <p>При фокусе на заголовке будет объявлено его содержимое, которое дублируется как лейбл представления. Это помогает пользователям скринридеров узнать об изменениях контекста. Обратите внимание на то, как использован атрибут <code>tabindex="-1"</code>. Как и в случае со вкладками, которыми мы управляем при помощи стрелок, это даёт возможность настроить фокус с помощью скрипта без участия пользователя (если не назначена кастомная клавиша). На практике это позволяет нам перемещать фокус без добавления элемента, на котором сделан фокус, в пользовательский порядок табуляции, как в случае со свойством <code>tabindex="0"</code>.</p> <p>Вот <a href="https://codepen.io/heydon/pen/veeaEa/">демо со вкладками на CodePen</a>, которое написано на JavaScript. Также там есть пояснения о поведении элементов и их семантике. Это список ссылок и элементов <code><section></code>, которые были прогрессивно улучшены и минифицированы до 1,3 Кб:</p> <h2>Адаптивный дизайн</h2> <p>Адаптивный дизайн — это инклюзивный дизайн. Он не только совместим с максимальным числом устройств, но также чувствителен к пользовательским настройкам увеличения страницы. За масштабирование всей страницы отвечает <code>@media</code> точно так же, как и за уменьшение области просмотра — вьюпорта.</p> <p>Для вкладок нужен брейкпоинт, на котором недостаточно места для размещения всех вкладок по горизонтали. Самый быстрый способ исправить это — перестроить контент в один столбец.</p> <p>С визуальной точки зрения это нельзя больше считать вкладками, так как они больше не выглядят как <em>вкладки.</em> Это не обязательно проблема, если выбранная вкладка (или опция) чётко обозначена. Не визуально, с точки зрения скринридеров, такой элемент выглядит и ведёт себя точно так же.</p> <h2>Аккордеоны для небольших вьюпортов?</h2> <p>Некоторые пытаются превратить вкладки в аккордеоны на небольших вьюпортах. Учитывая, что последние структурированы, реализованы и управляются совершенно иначе, чем вкладки, я бы не рекомендовал так делать.</p> <p>Аккордеоны имеют свои преимущества: они объединяют заголовок и кнопку с их контентом, что, возможно, лучше подходит для одной колонки. Но адаптивный гибрид вкладок и аккордеона просто не стоит того с точки зрения производительности.</p> <p>Там, где много вкладок или их количество заранее не известно, аккордеон безопаснее всего для <em>всех</em> размеров экранов. Одноколоночная раскладка адаптивна вне зависимости от количества контента. Проще простого.</p> <h2>Когда панели вкладок — представления</h2> <p>Ранее я замечал, что группа ссылок для навигации по сайту в виде вкладок может ввести в заблуждение: пользователь ожидает от клавиатуры поведения как со вкладками, а также того, что фокус будет установлен на вкладке на текущей странице. Ссылка, ведущая на другую страницу, приведёт к загрузке этой страницы, а фокус переместится на сам документ (<code><body></code>).</p> <p>Что касается «представлений» в одностраничных приложениях, то разные ли пути у разных экранов? Технически, они ближе к панелям вкладок, которые при этом являются полностью страницами. Но это не говорит о том, что их стоит <em>связывать</em> с панелями вкладок. Это не то, что может ожидать пользователь.</p> <p>Представления одностраничных приложений, как правило, должны выглядеть как отдельные страницы или области на них, так что об этом стоит рассказать подробнее. Вот некоторые условия, которые нужно выполнять:</p> <h3>1. Используйте ссылки!</h3> <p>Убедитесь, что ссылки, которые дают пользователям возможность выбирать между представлениями, действительно являются ссылками. Даже если эти ссылки <code>return false</code> и вы используете JavaScript для переключения представлений. Поскольку благодаря этим контролам пользователи будут ориентироваться в навигации (путём изменения местоположения фокуса, см. ниже), роль ссылки больше всего подходит для такого случая. Ссылкам не нужна ARIA-роль <code>link</code>. Они объявляются скринридерами как «ссылка» по умолчанию.</p> <p>В <a href="https://heydon.github.io/xiao/#home">Xiao</a> <em>(читается как «сяо». — прим. переводчика),</em> прогрессивно улучшенном роутере для одностраничных приложений, для обозначения представлений используются стандартные хеш-фрагменты. Ссылки на них будут объявлены как <em>«якорные ссылки»</em> большинством вспомогательных технологий. В их основе лежит стандартное поведение браузера, так что пользователь будет знать о том, что он попадёт на новую, отдельную часть страницы или приложения.</p> <pre><code tabindex="0" class="language-html"><a href="#some-route">Какой-то путь</a> </code></pre> <h3>2. Управляйте фокусом</h3> <p>Простая замена какого-то контента на странице не приводит к тому, что пользователя автоматически переносит к этому контенту или (в случае слепых пользователей вспомогательных технологий), что его предупреждают о существовании такого контента. Как сказано выше в примечании «Фокус на неинтерактивных элементах», можно сделать фокус на основном заголовке нового представления или на внешнем элементе. Если вы делаете фокус на последнем, то рекомендуется задать ему подпись либо непосредственно при помощи <code>aria-label</code>, либо по принципу заголовка с использованием <code>aria-labelledby</code>.</p> <pre><code tabindex="0" class="language-html"><div aria-label="На главную" role="region" tabindex="-1"> … </div> </code></pre> <p>Когда вы используете этот атрибут вместе с ролью <code>region</code> (как во фрагменте кода выше), то, если на элементе сделан фокус, скринридеры сделают объявление с контекстной информацией: <em>«На главную, область».</em></p> <p>Если использовать Xiao, то фокус не будет сделан ни на одной области главной страницы при её загрузке. Это означает, что документ или <code><body></code> получают фокус по умолчанию и <code><title></code> объявляется скринридерами (см. ниже).</p> <h3>3. Обновляйте <code><title></code></h3> <p>Название приложения должно быть для конкретного представления добавлено к лейблу. Это соответствует рекомендованному паттерну для статических сайтов, где к названию сайта добавляется имя страницы.</p> <pre><code tabindex="0" class="language-html"><title>[Название приложения] | [Название представления]</title> </code></pre> <p>Вы можете подгрузить приложение с роутером Xiao для любого пути, просто добавив хеш-фрагмент пути в URL. При событии загрузки <code><title>;</code> принимает значение лейбла этого пути, а скринридеры идентифицируют приложение и конкретный роутер.</p> <h2>Заключение</h2> <p>С помощью JavaScript можно легко показывать и скрывать или создавать и удалять контент, но у этих событий в DOM могут быть разные цели и значения в зависимости от контекста. В этой статье мы упростили показ и скрытие элементов при помощи JavaScript для создания двух совершенно разных интерфейсов: вкладок и навигации в одностраничном приложении.</p> <p>В инклюзивном дизайне нет чего-то правильного и неправильного. Это просто попытка сделать всё возможное, чтобы как можно больше людей получило ценный для них опыт. По большому счёту всё сводится к объединению представления и поведения таким образом, чтобы пользователи, вне зависимости от характера взаимодействия с интерфейсом и особенностей чтения контента, знали, что поставленные задачи выполняются.</p> <h2>Чеклист</h2> <ul> <li>Не используйте вкладки, если они не подходят для вашей ситуации и не будут поняты и оценены пользователем. То, что вы можете что-то сделать, не означает, что вы это должны делать.</li> <li>Оглавления и якорные ссылки более простое и надёжное решение для различных вариантов использования вкладок.</li> <li>Убедитесь, что интерфейсы, которые выглядят как вкладки, имеют ожидаемую семантику и поведение.</li> <li>Одностраничные приложения не должны выглядеть и вести себя как вкладки несмотря на то, что в них используется JavaScript для переключения между панелями содержимого или для наполнения их содержимым.</li> </ul> </article> <article> <h1>Инклюзивные компоненты: переключатель темы</h1> <p>Mon, 02 Sep 2019 00:00:00 GMT</p> <p>Моя мантра при создании веб-интерфейсов: «Если нельзя сделать это грамотно, не делай это вообще». Я учил людей <a href="https://vimeo.com/190834530">писать как можно меньше дурацкого кода</a> в Великобритании, Европе и Китае. Если фича может быть реализована только при значительном снижении производительности, то конечный результат будет отрицательным: так что от такой фичи следует отказаться. Насколько важна в вебе производительность.</p> <p>Предлагать пользователям выбор того, как будет выглядеть интерфейс, правильно, если вы его не навязываете. Это отвечает одному из принципов инклюзивного дизайна — <a href="https://inclusivedesignprinciples.org/#offer-choice">предлагать варианты</a>. <em>Однако</em> выбор настроек, например, темы, прекрасен и должен быть реализован только тогда, когда это можно сделать грамотно.</p> <p>Обычно альтернативные темы создаются как отдельные таблицы стилей, между которыми можно переключаться при помощи JavaScript. В некоторых случаях они приводят к проблемам с производительностью (так как перезаписывание темы требует загрузки большого количества дополнительного CSS) и, в большинстве случаев, к проблеме их дальнейшей поддержки (потому что отдельные таблицы стилей должны постоянно обновляться по мере развития сайта).</p> <p>Один тип альтернативных тем, который имеет ценность для пользователей — это «ночной режим» с низкой яркостью. Это не только проще для глаз, когда читаешь в темноте, но также уменьшает вероятность появления мигрени и разных нарушений, связанных со светобоязнью. Для меня, как для человека, страдающего от мигреней, это важно!</p> <p>В этой статье я расскажу о том, как грамотно сделать React-компонент, который позволит пользователям переключать светлую тему, установленную по умолчанию, на «тёмный режим», и настроить его с помощью API <code>localStorage</code>.</p> <p>В случае со светлой темой (чаще всего это тёмный текст на светлом фоне) самым разумным будет создать не полностью новую таблицу стилей, а расширить существующие стили настолько, насколько это возможно. К счастью, в CSS есть свойство <code>filter</code>, которое позволяет инвертировать цвета. Хотя его часто связывают с изображениями, оно может быть применено к любому элементу, включая <code><html></code>:</p> <pre><code tabindex="0" class="language-css">:root { filter: invert(100%); } </code></pre> <p><strong>Примечание</strong>: далеко не все браузеры поддерживают сокращённую запись <code>invert()</code>. Используйте <code>100%</code> для лучшей поддержки.</p> <p>Единственная проблема заключается в том, что <code>filter</code> может инвертировать только <em>явно заданные</em> цвета. Поэтому, если у элемента нет фонового цвета, текст инвертируется, при этом фоновый цвет по умолчанию (белый) останется прежним. Что в итоге? Светлый текст на светлом фоне.</p> <p>Это легко исправить, присвоив для <code>background-color</code> светлый цвет.</p> <pre><code tabindex="0" class="language-css">:root { background-color: #fefefe; filter: invert(100%); } </code></pre> <p>Но у нас всё ещё остаётся проблема с дочерним элементом, у которого также нет цвета фона. И это тот случай, когда нам пригодится ключевое слово из CSS — <code>inherit</code>.</p> <pre><code tabindex="0" class="language-css">:root { background-color: #fefefe; filter: invert(100%); } * { background-color: inherit; } </code></pre> <p>На первый взгляд может показаться, что мы обладаем слишком большими возможностями, но не стоит переживать: у селектора <code>*</code> очень низкая специфичность. Он влияет только на цвет фона для элементов, для которых он ещё не задан. На практике <code>#fefefe</code> — это просто фолбэк.</p> <h2>Сохранение растровых изображений</h2> <p>Когда мы хотим инвертировать тему, то, скорее всего, не собираемся инвертировать растровые изображения или видео. В противном случае интерфейс будет заполнен жуткими негативами. Хитрость заключается в дважды инвертированных <code></code>. Селектор, который я использую, исключает SVG-изображения. Они, как правило, легко и просто инвертируются из-за того, что представлены в виде простых цветовых схем.</p> <pre><code tabindex="0" class="language-css">:root { background-color: #fefefe; filter: invert(100%); } * { background-color: inherit; } img:not([src*=".svg"]), video { filter: invert(100%); } </code></pre> <p>Получилось 153 байта без сжатия: об этом позаботилась поддержка тёмных тем. Если вы всё ещё не не уверены, то вот стили, которые используются на популярных новостных сайтах:</p> <figure> <figcaption> The Boston Globe и The Independent. </figcaption> </figure> <figure> <figcaption> The New York Times и Private Eye. </figcaption> </figure> <h2>Компонент переключения темы</h2> <p>Поскольку переключение между светлой (по умолчанию) и тёмной (инвертированной) темами — это просто включение и выключение, мы можем использовать для этого что-то простое, например, <a href="https://inclusive-components.design/toggle-button/">переключатели</a>. Мы разбирали их в предыдущей статье <em>(<a href="https://medium.com/web-standards/toggle-buttons-a41388e80974">перевод на русский</a> — прим. переводчика).</em> Однако в этот раз мы сделаем переключатель частью <a href="https://react-cn.github.io/react/index.html">React</a>-компонента. На это есть несколько причин:</p> <ul> <li>Возможность повторного использования в проектах на основе React, в которых вы привыкли работать.</li> <li>Возможность использовать преимущества React: <code>props</code> и <code>defaultProps</code>.</li> <li>Некоторые люди думают, что фреймворки вроде React и Angular мешают им писать доступный HTML. Это заблуждение должно уйти в прошлое.</li> </ul> <p>Также мы не забудем про прогрессивное улучшение и будем показывать компонент только тогда, когда браузер поддерживает свойство <code>filter: invert(100%)</code>.</p> <h3>Настройка</h3> <p>Если у вас ещё не настроено окружение для React, то можете легко это сделать, установив <code>create-react-app</code>.</p> <pre><code tabindex="0" class="language-sh">npm i -g create-react-app create-react-app theme-switch cd theme-switch npm start </code></pre> <p>Теперь заготовка приложения будет работать на <code>localhost:3000</code>. В новом проекте <code>theme-switch</code> наш компонент называется <strong>ThemeSwitch</strong> и будет добавлен в <code>render()</code> в <code>App.js</code> как <code><ThemeSwitch/></code>.</p> <pre><code tabindex="0" class="language-jsx">class App extends Component { render() { return ( <div className="App"> <div className="App-header"> <h2>Добро пожаловать в React</h2> </div> <p className="App-intro"> Чтобы начать, отредактируйте {gfm-js-extract-pre-1} и сохраните для перезагрузки. </p> <ThemeSwitch/> </div> ); } } </code></pre> <p><strong>Примечание</strong>: я ленивый, поэтому оставляю заготовку. Чтобы протестировать переключатель тем, добавьте его вместе со стилизованным контентом, взятым из другого проекта. Вы можете включить CSS в <code>App.css</code>.</p> <p>Не забудьте импортировать компонент <strong>ThemeSwitch</strong> в начале файла <code>App.js</code>:</p> <pre><code tabindex="0" class="language-jsx">import ThemeSwitch from './components/ThemeSwitch' </code></pre> <h2>Файл основы компонента</h2> <p>Как следует из пути в строке с импортом выше, мы будем работать с файлом <code>ThemeSwitch.js</code>, размещённом в новой папке «components». Так что нужно создать папку и файл. Основа для <strong>ThemeSwitch</strong> выглядит так:</p> <pre><code tabindex="0" class="language-jsx">import React, { Component } from 'react'; class ThemeSwitch extends Component { render() { // Разметка компонента в JSX } } export default ThemeSwitch; </code></pre> <p>После рендеринга разметка переключателя, имеющего неактивное состояние и состояние по умолчанию, будет выглядеть таким образом (примечания после этого фрагмента кода):</p> <pre><code tabindex="0" class="language-jsx"><div> <button aria-pressed="false"> тёмная тема: <span aria-hidden="true">выключить</span> </button> <style media="none"> html { filter: invert(100%); background: #fefefe } * { background-color: inherit } img:not([src*=".svg"]), video { filter: invert(100%) } </style> </div> </code></pre> <ul> <li>Не все переключатели создаются одинаково. В этом случае мы используем <code>aria-pressed</code> для переключения доступного состояния, и явных «включена» и «выключена» для тех, кто не пользуется скринридерами. Так что часть компонента с «включена» или «выключена» не объявляется. Чтобы не было конфликта между этими состояниями, она скрыта от вспомогательных технологий при помощи <code>aria-hidden</code>. Пользователи скринридеров услышат: _«кнопка переключения тёмной темы, не нажата», <em>«кнопка переключения тёмной темы, нажата»</em> или что-то похожее на это.</li> <li>CSS настолько лаконичен, что можно использовать его в инлайновом виде. Зададим <code>media="none"</code> или <code>media="screen"</code>, когда включена тёмная тема.</li> </ul> <p>Скоро эта разметка станет очень сложной, так как мы конвертируем её в JSX.</p> <h2>Состояние переключения</h2> <p>Наш компонент будет хранить текущее состояние. Это позволит пользователю переключаться между активным и неактивным состояниями тёмной темы. Сначала мы инициализируем состояние в конструкторе компонента:</p> <pre><code tabindex="0" class="language-jsx">constructor(props) { super(props); this.state = { active: 'false' }; } </code></pre> <p>Чтобы оживить компонент, включим вспомогательную функцию <code>isActive()</code>, а также <code>toggle()</code>, которая фактически переключает состояние:</p> <pre><code tabindex="0" class="language-jsx">isActive = () => this.state.active; toggle = () => { this.setState({ active: !this.isActive() }); } </code></pre> <p><strong>Примечание</strong>: стрелочные функции неявно возвращают отдельные операторы, отсюда и краткость функции <code>isActive()</code>.</p> <p>В <code>render()</code> для компонента мы можем использовать <code>isActive()</code> для переключения значения <code>aria-pressed</code>, текста кнопки и значения CSS-атрибута <code>media</code>:</p> <pre><code tabindex="0" class="language-jsx">return ( <div> <button aria-pressed={this.isActive()} onClick={this.toggle}> тёмная тема: <span aria-hidden="true"> {this.isActive() ? 'включена' : 'выключена'} </span> </Button> <style media={this.isActive() ? 'screen' : 'none'}> {this.css} </style> </div> ); </code></pre> <figure> <figcaption> Конечно, когда выбрана тёмная тема, то сама кнопка тоже инвертирована. </figcaption> </figure> <p>Обратите внимание на часть с <code>{this.css}</code>. JSX напрямую не поддерживает встроенный CSS, поэтому мы должны сохранить его в переменной и ввести здесь динамически. В конструкторе:</p> <pre><code tabindex="0" class="language-jsx">this.css = ` html { filter: invert(100%); background: #fefefe; } * { background-color: inherit } img:not([src*=".svg"]), video { filter: invert(100%) }`; </code></pre> <h3>Боремся с проблемами браузеров</h3> <p>К сожалению, не во всех браузерах применяются нужные стили, когда переключаешься между <code>media="none"</code> и <code>media="screen"</code>. Для того, чтобы вызвать перерисовку, мы должны перезаписать текстовое содержимое тега <code><style></code>. Самый простой способ, который я нашёл — это использовать метод <code>trim()</code>. Любопытно, что он нужен только для Chrome.</p> <pre><code tabindex="0" class="language-jsx">{this.isActive() ? this.css.trim() : this.css} </code></pre> <h2>Сохраняем настройки темы</h2> <p>Для того, чтобы сохранить выбор темы, сделанный пользователем, нам нужно использовать <code>localStorage</code> и методы жизненного цикла. Во-первых, я задал алиасы для <code>localStorage</code> в конструкторе. Это устраняет ошибки линтинга, которые возникают при прямом вызове <code>localStorage</code>.</p> <pre><code tabindex="0" class="language-jsx">this.store = typeof localStorage === 'undefined' ? null : localStorage; </code></pre> <p>Используя метод <code>componentDidMount</code>, я могу отследить и применить сохранённые настройки после того, как компонент подключится. В выражении по умолчанию используется значение <code>false</code>, если элемент ещё не создан.</p> <pre><code tabindex="0" class="language-jsx">componentDidMount() { if (this.store) { this.setState({ active: this.store.getItem('ThemeSwitch') || false }); } } </code></pre> <p>Так как управление состоянием в React происходит асинхронно, недостаточно просто сохранять изменённое состояние после того, как оно было дополнено. Вместо этого мне нужно использовать метод <code>componentDidUpdate</code>:</p> <pre><code tabindex="0" class="language-jsx">componentDidUpdate() { if (this.store) { this.store.setItem('ThemeSwitch', this.state.active); } } </code></pre> <h2>Скрываем в неподдерживаемых браузерах</h2> <p>Некоторые браузеры ещё не поддерживают <code>filter: invert(100%)</code>. Для них нужно скрыть наш переключатель темы. Лучше, если он просто недоступен, чем когда доступен и при этом не работает. Благодаря специальной функции <code>invertSupported</code> мы можем узнать о поддержке свойства, чтобы установить состояние <code>supported</code>.</p> <p>Если вы когда-нибудь имели дело с <a href="https://modernizr.com/">Modernizr</a>, то могли бы использовать похожий тест свойства и его значения для CSS. Однако не стоит его здесь использовать, поскольку мы не хотим, чтобы наш компонент имел какие-либо зависимости, если в этом нет необходимости.</p> <pre><code tabindex="0" class="language-jsx">invertSupported (property, value) { var prop = property + ':', el = document.createElement('test'), mStyle = el.style; el.style.cssText = prop + value; return mStyle[property]; } componentDidMount() { if (this.store) { this.setState({ supported: this.invertSupported('filter', 'invert(100%)'), active: this.store.getItem('ThemeSwitch') || false }); } } </code></pre> <p>Это можно использовать в нашем JSX для того, чтобы скрыть компонент интерфейса с помощью свойства <code>hidden</code> там, где оно не поддерживается.</p> <pre><code tabindex="0" class="language-html"><div hidden={!this.state.supported}>  </div> </code></pre> <p>В современных браузерах свойство <code>hidden</code> скроет компонент от вспомогательных технологий и запретит делать на них фокус с клавиатуры. Для того, чтобы в старых браузерах оно тоже работало, используйте в стилях этот селектор:</p> <pre><code tabindex="0" class="language-css">[hidden] { display: none; } </code></pre> <p>В качестве альтернативы вы можете вообще отказаться от отображения содержимого компонента на странице, возвращая <code>null</code>.</p> <pre><code tabindex="0" class="language-jsx">render() { if (!this.supported) { return null; } return ( <div> <button aria-pressed={this.state.active} onClick={this.toggle}> inverted theme: <span aria-hidden="true"> {this.state.active ? 'on' : 'off'} </span> </button> <style media={this.state.active ? 'screen' : 'none'}> {this.state.active ? this.css.trim() : this.css} </style> </div> ); } </code></pre> <h2>Режим высокой контрастности в Windows</h2> <p>Пользователям Windows предлагается ряд тем с высокой контрастностью уже на уровне операционной системы: несколько светлых и тёмных (свет в темноте) как наша инверсированная тема. Важно убедиться, что WHCM <em>(Windows High Contrast Mode. — прим. переводчика)</em> поддерживается настолько, насколько это возможно. Вот несколько советов:</p> <ul> <li>Не используйте фоновые изображения в качестве контента. Это не только инвертирует изображения в нашей инвертированной тёмной теме, но и полностью исключает их из большинства тем с высокой контрастностью Windows. Используйте в тегах <code></code> изображения со смысловой нагрузкой, а не декоративные, с хорошо описывающим их <code>alt</code>.</li> <li>Для инлайновых SVG-иконок используйте значение <code>currentColor</code> в <code>fill</code> и <code>stroke</code>. Благодаря этому цвет иконки будет меняться вместе с цветом окружающего текста при включении высококонтрастной темы.</li> <li>Если вам нужно определить WHCM, чтобы добавить улучшения, вы можете использовать следующий медиазапрос:</li> </ul> <pre><code tabindex="0" class="language-css">@media (-ms-high-contrast: active) { /* Относящийся к WHCM код */ } </code></pre> <h2>Проп <code>preserveRasters</code></h2> <p>Пропсы (свойства компонентов) — это стандартный способ настройки компонентов. Конфигурируемый компонент может использоваться в разных ситуациях и проектах, что делает его более инклюзивным.</p> <p>В нашем случае, почему бы нам не сделать так, чтобы у Implementor был выбор: действительно ли сохранить растровые изображения или инвертировать их вместе со всем остальным контентом. Я создам проп <code>preserveRasters</code>, который принимает значения «true» или «false». Вот как это выглядит на примере нашего компонента:</p> <pre><code tabindex="0" class="language-jsx"><ThemeSwitch preserveRasters={false} /> </code></pre> <p>Я могу запросить этот проп в виде строки CSS и повторно инвертировать изображения, если её значение равно <code>true</code>:</p> <pre><code tabindex="0" class="language-jsx">this.css = ` html { filter: invert(100%); background: #fefefe; } * { background-color: inherit } ${this.props.preserveRasters === 'true' ? `img:not([src*=".svg"]), video { filter: invert(100%) }` : ``}`; </code></pre> <p><strong>Примечание</strong>: допустимо, хотя и немного некрасиво, использовать таким образом тернарные операторы для интерполяции строк.</p> <h3>Значение по умолчанию</h3> <p>Чтобы сделать компонент более надёжным и дать Implementor возможность пропустить атрибут, мы также можем добавить <code>defaultProp</code>. После определения класса компонента можно использовать следующее:</p> <pre><code tabindex="0" class="language-jsx">ThemeSwitch.defaultProps = { preserveRasters: true } </code></pre> <h2>Устанавливаем компонент</h2> <p>Пример <a href="https://github.com/Heydon/react-theme-switch">такого компонента</a> есть в npm:</p> <pre><code tabindex="0" class="language-sh">npm i --save react-theme-switch </code></pre> <p>Помимо этого, простой пример с JavaScript, в основе которого лежит чекбокс, есть на <a href="https://codepen.io/heydon/pen/Vzyrre">СodePen</a>:</p> <h2>Расположение</h2> <p>Осталось только решить, где мы собираемся разместить компонент в документе. Как правило, утилиты вроде выбора темы следует искать в области ориентиров (landmark region), а не в <code><main></code>, поскольку пользователь скринридера ожидает, что этот контент будет меняться между страницами. Допустимы <code><header></code> (<code>role="banner"</code>) или <code><footer></code> (<code>role="contentinfo"</code>).</p> <p>Переключатель должен появляться в одном и том же месте на всех страницах, чтобы пользователь мог легко найти его после того, как использовал в первый раз. Примите во внимание <a href="https://inclusivedesignprinciples.org/#be-consistent">принцип консистентности</a>, который здесь применяется.</p> <h2>Чеклист</h2> <ul> <li>Внедряйте полезные функции только в том случае, если снижение производительности минимально, а конечный интерфейс не становится сильно сложнее.</li> <li>Используйте в интерфейсах только поддерживаемые функции. Проверяйте их доступность.</li> <li>Используйте семантическую разметку в React-компоненте: такие компоненты всегда будут работать!</li> <li>Используйте пропсы для того, чтобы сделать ваши компоненты более конфигурируемыми и иметь возможность использовать их много раз.</li> </ul> </article> <article> <h1>Инклюзивные компоненты: тултипы и тоглтипы</h1> <p>Tue, 23 Jul 2019 00:00:00 GMT</p> <p>Тултипы <em>(в этом переводе я буду транслитерировать слово «tooltip», их ещё часто называют подсказкой — прим. переводчика),</em> которые мой друг <a href="https://twitter.com/stevefaulkner">Стив</a> ласково называет «тутлипы» (tootlips), давно устоявшийся интерфейсный паттерн. Буквально это «подсказки для инструментов» в виде небольших пузырей с информацией, которые объясняют цель непонятных контролов и инструментов. Распространённый пример — контрол в виде таинственной иконки, смысл которой пользователь пока ещё не понимает.</p> <p>Я хотел бы поговорить о том, когда и как эти пузыри должны появляться, так как столкнулся с большим количеством тултипов, которые, кажется, ведут себя немного по-разному. Я сделал вывод, что все эти реализации можно разделить на две самостоятельные группы: настоящие тултипы и паттерны, которые я с опаской называю «тоглтипы» (toggletips). Это слово придумал Стив в ходе <a href="https://developer.paciellogroup.com/blog/2016/01/simple-standalone-toggletip-widget-pattern/">пары исследований и экспериментов</a>, которые не так давно провёл.</p> <p>Инклюзивный дизайн часто затрагивает проблему того, как обеспечить пользователя правильным инструментом для работы, и как создать правильный тултип к нему. В этой статье я рассмотрю разные ситуации, для которых могут потребоваться тултипы или тоглтипы, и покажу как сделать их инклюзивными.</p> <h2>Атрибут <code>title</code></h2> <p>Мы не можем говорить о тултипах без упоминания атрибута <code>title</code>: стандартный для HTML атрибут, предназначенный для пузырей с контекстной информацией. Блог Paciello Group не обходится без сарказма при описании вклада <code>title</code> в веб-интерфейсы:</p> <blockquote> <p>Если вы хотите скрыть контент от пользователей мобильных и планшетов, а также от пользователей вспомогательных технологий и клавиатуры, то используйте атрибут <code>title</code>. <a href="https://developer.paciellogroup.com/blog/2013/01/using-the-html-title-attribute-updated/">Блог The Paciello Group</a>.</p> </blockquote> <p>Это <em>довольно плохой</em> вклад с точки зрения инклюзивности. На самом деле единственное место, где атрибут title может хорошо работать в связке со скринридерами — это элементы форм вроде <code><input></code>. Во всех других случаях пользователи мобильных устройств и клавиатуры не смогут увидеть сообщение из <code>title</code>. Вкратце: просто добавьте хорошо сформулированный, постоянно видимый лейбл.</p> <p>Я большой сторонник использования стандартных HTML-элементов и атрибутов тогда, когда они доступны. Это наиболее эффективный и правильный с точки зрения производительности путь создания удобных веб-интерфейсов. Но, несмотря на то, что атрибут <code>title</code> поддерживается спецификацией, он действительно не подходит для своей цели.</p> <p>Опять же, нам ещё предстоит определить эту цель. Для чего <em>следует</em> использовать тултипы? И даже если мы сможем сделать их такими, что с ними смогут взаимодействовать многие пользователи, нужны ли они вообще?</p> <h2>Случаи использования тултипов</h2> <p>Как мы уже установили, тултипы нужны для пояснений: они дают <em>недостающую</em> информацию. Но почему эта информация должна изначально отсутствовать? Как я писал в <a href="https://shop.smashingmagazine.com/products/inclusive-design-patterns">Inclusive Design Patterns</a>, иконки могут упростить понимание интерфейса и помочь в его интернационализации. Существуя отдельно, они всегда могут запутать пользователя, потому что <em>ничего не объясняют.</em> Иконки не содержат информации для пользователей, которые не узнают или не могут расшифровать их.</p> <p>В большинстве случаев вы должны просто размещать текст рядом с иконками. Как и видимые подписи к полям, которые я только что упомянул, текстовые лейблы являются самым простым способом добавления подписей к элементам. Также они автоматически доступны для скринридеров, если это настоящий текст (а не картинки с текстом).</p> <p>Типичное объяснение, почему лейблов нет — это «нет места». И это, вероятно, так, если вы решили не использовать их в первую очередь. Если вы считаете их важными с самого начала, то найдёте способ это сделать.</p> <figure> <figcaption>Всегда есть место для текста, если вы решили его добавить. Однако в некоторых случаях для него остаётся больше места, чем в других.</figcaption> </figure> <p>Тултипы — последнее средство там, где пространство действительно стоит дорого — возможно, из-за огромного количества элементов управления, как на панели инструментов в редакторе WYSIWYG. Итак, как бы мы разработали их максимально инклюзивно?</p> <h2>Инклюзивные тултипы</h2> <p>Первое, что нужно сделать — это сделать текст в тултипах доступным для вспомогательных технологий. Есть несколько способов привязки тултипа к контролу, и мы выбираем между ними исходя из его конкретной роли: это основной лейбл или он нужен для дополнительного пояснения?</p> <p>У контрола для управления уведомлениями с тултипом «Уведомления» — это основной лейбл. А тултип «Просмотр уведомлений и управление настройками» является дополнительным.</p> <h2>Тултип как основной лейбл</h2> <p>Чтобы связать один элемент с другим в качестве основного лейбла, нужно использовать <code>aria-labelledby</code>. Связь устанавливается благодаря <code>aria-labelledby</code> и <code>id</code> с одинаковыми значениями.</p> <pre><code tabindex="0" class="language-html"><button class="notifications" aria-labelledby="notifications-label"> <svg> <use xlink:href="#notifications-icon"></use> </svg> </button> <div role="tooltip" id="notifications-label"> Уведомления </div> </code></pre> <ul> <li>Обратите внимание, как устанавливается роль <code>tooltip</code>. С практической точки зрения она гарантирует, что <code>aria-describedby</code> точно работает там, где поддерживается. Как указывает Леони Уотсон, <a href="https://developer.paciellogroup.com/blog/2017/07/short-note-on-aria-label-aria-labelledby-and-aria-describedby/">ARIA-лейблы и описания иногда работают не со всеми элементами</a>, если вы не используете соответствующую роль. В этом случае самой важной является роль кнопки по умолчанию у элемента <code><button></code>. Однако <code>role="tooltip"</code> может расширить поддержку этого метода присвоения лейблов в некоторых программах.</li> <li>Каким бы ни был текст в SVG, он не будет прочитан. <code>aria-labelledby</code> <em>переопределяет</em> текстовое содержимое кнопки на то, которое есть у лейбла.</li> </ul> <p>Сейчас пример выше для скринридеров и их пользователей с точки зрения функциональности похож на простую подпись вроде этой:</p> <pre><code tabindex="0" class="language-html"><button class="notifications"> Уведомления </button> </code></pre> <p>Текст тултипа доступен при фокусе так же, как если бы на него навёл курсор зрячий пользователь. На самом деле, если бы весь текст появлялся только при наведении, то для зрячих пользователей интерфейс был бы в некоторой степени аналогичен интерфейсу пользователей скринридеров.</p> <h2>Примечание: лишние тултипы</h2> <p>Всё то время, что я работаю консультантом по дизайну интерфейсов, я вижу людей, которые добавляют атрибут <code>title</code> для ссылок с точно таким же текстом:</p> <pre><code tabindex="0" class="language-html"><a href="/some/path" title="Специальная страница Хейдона"> Специальная страница Хейдона </a> </code></pre> <p>Если текстовое содержимое элемента хорошо видно, то это избыточно. <code>title</code> ничего не делает для скринридеров, кроме повтора в некоторых случаях.</p> <h3>Добавляем счётчик уведомлений</h3> <p>Что, если кнопка показывает число непрочитанных сообщений, как это часто бывает (я имею в виду, конечно, Twitter)?</p> <p>К счастью, атрибут <code>aria-labelledby</code> может содержать несколько <code>id</code>, разделённых пробелами.</p> <pre><code tabindex="0" class="language-html"><button class="notifications" aria-labelledby="notifications-count notifications-label"> <svg> <use xlink:href="#notifications-icon"></use> </svg> <span id="notifications-count">3</span> </button> <div role="tooltip" id="notifications-label"> Уведомления </div> </code></pre> <p>Несмотря на то, что элемент с <code>#notifications-count</code> находится внутри <code><button></code>, он не является сам по себе лейблом: он формирует первую часть лейбла в качестве первого <code>id</code>, указанного в значении <code>aria-labelledby</code>. Элемент расположен там, где он находится (в разметке), так что дизайнер может использовать относительное и абсолютное позиционирование, чтобы разместить элемент в нужном месте.</p> <p>Сейчас для пользователей скринридеров лейбл — это «три уведомления». Такое решение лаконично и элемент работает одновременно как счётчик текущих уведомлений и как напоминание о том, что это контрол для управления уведомлениями.</p> <h2>Тултип как дополнительное описание</h2> <p>Давайте попробуем сейчас создать тултип в виде дополнительного описания. Это его классическая форма. Как и плейсхолдер для <code><input></code>, тултип нужен для добавления информации и пояснений.</p> <p>Некоторые интерактивные элементы могут иметь доступные описания, но все они нуждаются в доступных лейблах. Если мы используем <code>aria-describedby</code> для связи текста тултипа, нам нужен другой метод для добавления лейбла «Уведомления». В отличие от <code>aria-labelledby</code> мы можем добавить визуально скрытый <code><span></code> для текстового содержимого кнопки рядом со счётчиком «3».</p> <pre><code tabindex="0" class="language-html"><button class="notifications" aria-describedby="notifications-desc"> <svg> <use xlink:href="#notifications-icon"></use> </svg> <span id="notifications-count">3</span> <span class="visually-hidden">Уведомления</span> </button> <div role="tooltip" id="notifications-desc"> Посмотреть и изменить настройки уведомлений </div> </code></pre> <p>Класс <code>visually-hidden</code> аналогичен специальному CSS, который мы обсуждали ранее в Inclusive Components. Он скрывает <code><span></code> визуально, при этом оставляя его доступным для объявления скринридерами.</p> <pre><code tabindex="0" class="language-css">.visually-hidden { clip-path: inset(100%); clip: rect(1px, 1px, 1px, 1px); height: 1px; overflow: hidden; position: absolute; white-space: nowrap; width: 1px; } </code></pre> <p>Предписанное поведение <code>aria-describedby</code> заключается в том, чтобы давать последнюю информацию об изменениях для контрола после объявления лейбла и роли. В этом случае будет объявлено следующее:</p> <blockquote> <p>Кнопка, уведомления… Посмотреть и изменить настройки уведомлений.</p> </blockquote> <p>Большинство скринридеров сделают паузу перед описанием.</p> <h3>Взаимодействие</h3> <p>Чтобы улучшить поведение печально известного атрибута <code>title</code>, наши тултипы должны появляться как при фокусе, так и при наведении. Добавить всплывающую подсказку в элементе рядом с кнопкой мы можем только с помощью CSS:</p> <pre><code tabindex="0" class="language-css">[role="tooltip"] { display: none; } button:hover + [role="tooltip"], button:focus + [role="tooltip"] { display: block; } </code></pre> <p>Однако, нам может понадобиться обернуть кнопку и тултип в один контейнер для позиционирования:</p> <pre><code tabindex="0" class="language-css">.button-and-tooltip { position: relative; } [role="tooltip"] { position: absolute; /* требуются значения для left, top, right, bottom */ } </code></pre> <h2>Взаимодействие с тач-устройствами</h2> <p>Пока что всё это не работает хорошо для пользователей тач-экранов, потому что фокус и активное состояние существуют одновременно. На практике это означает, что вы увидите всплывающую подсказку только при нажатии на кнопку.</p> <p>То, насколько <em>много</em> проблем возникает в этой ситуации, зависит от природы приложения в котором есть этот контрол. Насколько плохо, если пользователь нажимает на контрол без понимания того, что он сделает в первый раз? Насколько легко такие контролы могут восстанавливать первоначальное состояние?</p> <p>Есть другая вещь, которую вы можете попробовать. Можно было бы запретить для кнопки действие по умолчанию при первом нажатии, чтобы она <em>просто</em> показывала в этот момент тултип. Вы можете развить идею с «режимом обучения» дальше и показать тултипы в виде инлайнового текста для новичков, а затем упростить интерфейс и показывать только иконки освоившимся пользователям. К этому времени они должны понять, что означают иконки.</p> <figure> <figcaption>В других случаях экран для каждого из вариантов должен иметь понятный (<code><h1></code>) заголовок с тем же самым текстом, что и у лейбла. Тогда, по крайней мере, пользователь узнает, что это за иконка, когда зайдёт на страницу.</figcaption> </figure> <p>Это может помочь избавиться от тултипов, что, вероятно, к лучшему. Однако, родственник тултипов — тоглтип, может работать как при взаимодействии с мышью, так и у пользователей, использующих клавиатуры и сенсорные экраны.</p> <h2>Инклюзивные тоглтипы</h2> <p>Тоглтипы <em>(буквально «подсказка-переключатель» — прим. переводчика)</em> похожи на тултипы в том, что они могут предоставить дополнительную информацию или что-то разъяснить. Но они отличаются тем, что их контрол сам по себе вспомогательный: тоглтипы существуют для того, чтобы показывать пузыри с информацией. Больше у них нет никакой цели.</p> <p>Часто они имеют вид иконки с маленькой «i»:</p> <p>Работая с тапами так же хорошо, как с мышкой и клавиатурой, тоглтипы появляются чаще при клике, чем при наведении или фокусе. Это значит, что <code>aria-describedby</code> больше не подходит. Почему? Потому что пользователь скринридера не может получить доступ к информации до того, как нажмёт на кнопку, так что это нажатие ничего не изменит. Технически, у них есть <em>доступ</em> к информации, которая делает контрол «доступным», но сам по себе он просто не имеет смысла. Другими словами, это больше проблема пользовательского опыта, чем доступности. Однако, это важная проблема.</p> <h2>Тоглтипы с интерактивными областями</h2> <p>Хитрость заключается в том, чтобы скринридеры объявляли информацию после события по клику. Это подходящий случай для использования интерактивных областей (<a href="https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Live_Regions">live region</a>). Мы можем добавить пустую интерактивную область и заполнить её событиями при инициализации тоглтипов. Это поможет одновременно отобразить пузырь c информацией и сделать объявление о тултипе.</p> <p>Ниже разметка с пустой интерактивной областью. Обратите внимание на элемент <code>.tooltip-container</code>, который нужен для позиционирования. Для него должно быть задано свойство <code>position: relative</code>, которое позволяет абсолютно позиционировать рядом элемент <code>.toggletip-bubble</code>.</p> <pre><code tabindex="0" class="language-html"><span class="tooltip-container"> <button type="button" aria-label="больше информации" data-toggletip-content="Это уточняет то, что нужно уточнить">i</button> <span role="status"></span> </span> </code></pre> <p>Также обратите внимание на атрибут <code>type="button"</code>, запрещающий некоторым браузерам определять элемент как кнопку отправки данных, если он расположен внутри формы. Вот разметка с интерактивной областью, в которой происходят какие-то события (после того, как на кнопку с тоглтипом кликнули):</p> <pre><code tabindex="0" class="language-html"><span class="tooltip-container"> <button type="button" aria-label="больше информации" data-toggletip-content="Это уточняет то, что нужно уточнить">i</button> <span role="status"> <span class="toggletip-bubble"> Это уточняет то, что нужно уточнить </span> </span> </span> </code></pre> <p>Дополнительный скрипт с комментариями и CodePen:</p> <pre><code tabindex="0" class="language-js">(function() { // Получаем все кнопки-тоглтипы var toggletips = document.querySelectorAll('[data-toggletip-content]'); // Обходим их Array.prototype.forEach.call(toggletips, function (toggletip) { // Получим сообщение из элемента с data-content var message = toggletip.getAttribute('data-toggletip-content'); // Получаем все элементы с интерактивными областями var liveRegion = toggletip.nextElementSibling; // Переключаем сообщение toggletip.addEventListener('click', function () { liveRegion.innerHTML = ''; window.setTimeout(function() { liveRegion.innerHTML = '<span class="toggletip-bubble">' + message + '</span>'; }, 100); }); // Закрываем по клику на другую область document.addEventListener('click', function (e) { if (toggletip !== e.target) { liveRegion.innerHTML = ''; } }); // Убираем тоглтип по нажатию на Esc toggletip.addEventListener('keydown', function(e) { if ((e.keyCode || e.which) === 27) liveRegion.innerHTML = ''; }); }); }()); </code></pre> <h3>Примечания</h3> <ul> <li>Наша кнопка не переключатель, по крайне мере в обычном понимании. При нажатии она только показывает пузырь с информацией, а не показывает и скрывает его. Чтобы скрыть пузырь, нужно убрать фокус с кнопки, кликнуть мышью в другой области или нажать клавишу <kbd>Esc</kbd>.</li> <li>Когда по кнопке кликнули во второй (или третий, четвёртый, пятый раз…) интерактивная область снова заполняется событиями через определённый интервал времени, после чего скринридеры повторно объявляют контент. Это проще и интуитивно понятнее в отличие от состояний при переключении (состояние «сообщение получено» не имеет особого смысла, особенно если оно уже было объявлено).</li> <li>Сдержанный интервал (discreet interval) у последнего элемента добавлен при помощи <code>setTimeout</code>. Без этого невозможно было бы зарегистрировать повторное заполнение интерактивной области событиями и объявить контент снова.</li> <li>Атрибут <code>role="tooltip"</code> не подходит из-за того, что для интерактивной области задан <code>role="status"</code>.</li> </ul> <h3>Прогрессивное улучшение <code>title</code></h3> <p>Как я уже упоминал, атрибут <code>title</code> <em>действительно</em> ненадёжный. Но он, по крайней мере, добавляет доступный лейбл для некоторых вспомогательных технологий, присутствующий, когда на кнопке сделан фокус. Мы можем с помощью <code>title</code> добавить контент для пузыря и использовать его для создания атрибута <code>data-toggletip-content</code> при загрузке страницы. Первоначальный хук нашего скрипта теперь становится логическим <code>data-toggletip</code>:</p> <pre><code tabindex="0" class="language-html"><button data-toggletip aria-label="больше информации" title="Это уточняет то, что нужно уточнить">i</button> </code></pre> <p>В скрипте нам нужно взять значение <code>title</code> для создания <code>data-tooltip-content</code>, а после удалить <code>title</code>, так как он нам не нужен. Если не трогать его, то его всё ещё может объявить скринридер.</p> <pre><code tabindex="0" class="language-js">var toggletips = document.querySelectorAll('[data-toggletip][title]'); Array.prototype.forEach(toggletips, function (toggletip) { var message = toggletip.getAttribute('title'); toggletip.setAttribute('data-tooltip-content', message); toggletip.removeAttribute('title'); }); </code></pre> <h3>Более совершенное прогрессивное улучшение</h3> <p>Кнопка, которая ничего не делает и имеет атрибут <code>title</code> — не самое хорошее начало. Вместо этого я бы порекомендовал инлайново отображать контент тоглтипа, а затем улучшать его, создавая кнопку динамически.</p> <p>Вот ещё один CodePen, в котором обычный параграф прогрессивно улучшается до тоглтипа:</p> <h2>Тесты и сообщения об ошибках</h2> <p>О чём я ещё не говорил в Inclusive Components, это написание тестов. Давайте немного обсудим это здесь. Не волнуйтесь, я не имею в виду юнит-тесты.</p> <p>Если наш компонент, тоглтип, является частью дизайн-системы, его могут взять и использовать разные люди. Когда мы пишем тесты и включаем предупреждения, то можем убедиться, что они не используются неправильно.</p> <p>Тоглтип-кнопка, которая не является <code><button></code>, обманывает вспомогательные технологии и на ней нельзя сделать фокус с помощью клавиатуры (если это не другой неправильный в данном случае элемент вроде ссылки). В нашем скрипте мы можем обнаружить элемент nodeName и вернуть сообщение об ошибке, если это не BUTTON. Мы используем <code>return</code>, чтобы остановить выполнение оставшейся части IIFE <em>(Immediately Invoked Function Expression — немедленно вызываемой функции — прим. переводчика).</em></p> <pre><code tabindex="0" class="language-js">if (toggletip.nodeName !== 'BUTTON') { console.error('Тоглтипы должны быть элементами <button>.') return; } </code></pre> <h2>CSS-тесты и сообщения об ошибках</h2> <p>В <a href="https://shop.smashingmagazine.com/products/inclusive-design-patterns">Inclusive Design Patterns</a> я писал про использование визуальной регрессии для того, чтобы подсветить ошибки в коде и добавить сообщения об ошибке в инструменте разработчика.</p> <p>Ошибка, которую мы ранее отловили с помощью JavaScript, может быть обнаружена с помощью CSS-селектора <code>[data-tooltip]:not(button)</code>. Мы можем подсветить элементы с ошибками с помощью красного аутлайна и добавить сообщение о них с помощью <code>ERROR</code>:</p> <pre><code tabindex="0" class="language-css">[data-tooltip]:not(button) { outline: red solid 0.5em; ERROR: Тоглтипы должны быть элементами <button>. } </code></pre> <p>ERROR, несмотря на невалидное значение, появится в инструментах разработчика, когда элемент будет изучен.</p> <figure> <figcaption>Красный аутлайн показывает, где есть ошибка, и помогает разработчику найти нужный элемент в инспекторе DOM.</figcaption> </figure> <h2>Заключение</h2> <p>Чаще всего тултипы не нужны, если вы используете понятные текстовые лейблы или знакомые пользователям иконки. Чаще всего тоглтипы — это сложный способ предоставления информации, которая может быть просто частью контента на странице. Но я всё время встречаю эти компоненты при аудите сайтов, поэтому дал некоторые рекомендации о том, как максимально правильно их использовать.</p> <h3>Чеклист</h3> <ul> <li>Если у вас есть свободное пространство, не используйте тултипы или тоглтипы. Просто добавьте понятные лейблы и достаточное количество текста на страницу.</li> <li>Если вы хотите использовать тултип, решите, следует ли указывать содержание подсказки в качестве лейбла или описания, и выберите соответствующие свойства ARIA.</li> <li>Не полагайтесь на атрибуты <code>title</code>. Они не доступны для клавиатуры и не поддерживаются многими скринридерами.</li> <li>Не описывайте тоглтип при помощи атрибута <code>aria-describedby</code>. Это делает кнопку с ним нефункциональной для пользователей скринридеров.</li> <li>Не добавляйте в тултипы или тоглтипы интерактивный контент, например, кнопку закрытия или согласия, ссылки. Это работа для более сложных меню и диалоговых компонентов.</li> </ul> <p><em>Спасибо <a href="https://twitter.com/backwardok">@backwardok</a>, которая заметила, что я создал повторяющийся лейбл, используя текстовый узел для описания того же элемента. Упс!</em></p> </article> <article> <h1>Инклюзивные компоненты: меню и кнопки меню</h1> <p>Tue, 21 May 2019 00:00:00 GMT</p> <p>Классифицировать сложно. Например, возьмём крабов. Раки-отшельники, веерные крабы и подковообразные крабы, с точки зрения таксономии, <em>не настоящие</em> крабы, но это не мешает использовать в их названиях слово «краб». Всё становится ещё запутаннее, когда через какое-то время благодаря процессу, называемому <em>канцеризацией</em>, ненастоящие крабы эволюционируют, чтобы больше походить на настоящих. Это то, что произошло с королевскими крабами, которые в прошлом были раками-отшельниками. Представьте размеры их раковин!</p> <p>В дизайне мы часто совершаем такую же ошибку, когда называем разные вещи одинаковыми именами. Они кажутся похожими, но внешность может быть обманчивой. Это плохо сказывается на прозрачности вашей библиотеки компонентов. С точки зрения инклюзивности это может привести к тому, что вы измените нужную семантику и поведение компонента на совершенно противоположные. Пользователи будут ожидать одного поведения, а получат другое.</p> <p>Классический пример — термин «выпадающий список» (dropdown). В интерфейсах многие вещи «выпадают», включая <code><option></code> в <code><select></code>, и подменю навигации со списком ссылок, которое раскрывается с помощью JavaScript. Одинаковые названия — разные явления. Некоторые называют это «выпадающее меню» (pull-down menu), но давайте не вдаваться в подробности.</p> <p>Выпадающие списки, которые состоят из нескольких пунктов, часто называют «меню». Об этом я и хочу поговорить в этой статье. Мы будем делать <em>настоящее</em> меню, но по пути обсудим их не совсем настоящие реализации.</p> <p>Давайте начнём с вопроса: является ли блок ссылок с картинки, выпадающий вниз из панели навигации, меню?</p> <p>Правильный ответ: нет, это не настоящее меню.</p> <p>То, что навигационная схема состоит из списков или ссылок — давнее соглашение. Оно почти так же давно предписывает, что дополнительная навигация (sub-navigation) должна быть <em>вложенными</em> списками со ссылками. Если бы я удалил стили для компонента, показанного выше, я бы увидел что-то вроде этого списка ссылок, только с Times New Roman и синего цвета.</p> <pre><code tabindex="0" class="language-md">• [Главная](#) • [О нас](#) • [Магазин](#) ◦ [Одежда для собак](#) ◦ [Вафельницы](#) ◦ [Магические шары](#) • [Контакты](#) </code></pre> <p>С точки зрения семантики вложенные списки со ссылками в этом контексте корректны. Системы навигации на самом деле <strong>оглавления</strong>: именно так они устроены. Единственное, что действительно заставляет думать, что перед нами меню — это стилизация вложенных списков и способ их отображения при наведении курсора или при фокусе.</p> <p>В этом месте часто ошибаются и начинают добавлять семантику из WAI-ARIA: <code>aria-haspopup="true"</code>, <code>role="menu"</code>, <code>role="menuitem"</code> и так далее. Их можно использовать, но в другом контексте. Вот две причины для этого:</p> <ol> <li>ARIA-меню предназначены не для навигации, а для десктопных приложений. Представьте себе систему меню для любого из них.</li> <li>Ссылка верхнего уровня должна быть <em>ссылкой.</em> То есть она не ведёт себя как кнопка меню.</li> </ol> <p>Относительно второго пункта: при перемещении по области навигации в подменю ожидаешь, что каждое подменю будет появляться при наведении или при фокусе на ссылке верхнего уровня (например, «Магазин» из примера выше). Это одновременно показывает подменю и размещает ссылки в нём в порядке получения фокуса. С помощью JavaScript можно управлять событиями фокуса (focus) и его потери (blur) и сохранить внешний вид подменю пока это необходимо. При этом те, кто использует для навигации клавиатуру, должны иметь возможность переходить по очереди от одной ссылки каждого уровня к другой.</p> <p>Кнопки меню, которым задан атрибут <code>aria-haspopup="true"</code>, так себя не ведут. Они становятся активными <em>по клику</em> и у них нет другой цели кроме показа скрытого меню.</p> <p>Как показано на картинке, вне зависимости от того раскрывается меню или скрывается, это будет объявлено благодаря атрибуту <code>aria-expanded</code>. Вам нужно только изменить это состояние при клике, а не при фокусе. Пользователи обычно не ожидают явного изменения состояния при простом событии фокуса. На самом деле в нашей системе навигации состояние не изменяется. Это просто трюк со стилизацией. С точки зрения поведения мы можем перемещаться с помощью клавиши <kbd>Tab</kbd> так, как если бы не было никакого трюка с показом и скрытием элемента.</p> <h2>Проблема с навигационными подменю</h2> <p>Навигационные подменю (или для кого-то «выпадающие списки») отлично работают с мышью или с клавиатуры, но не так хороши для касаний. Когда вы в первый раз нажимаете на ссылку верхнего уровня «Магазин» из примера, то сообщаете, что надо открыть подменю и перейти по ссылке.</p> <p>Здесь есть два возможных варианта решения проблемы:</p> <ol> <li>Избежать поведения по умолчанию ссылок верхнего уровня (<code>e.preventDefault()</code>) и написать скрипт для полной поддержки семантики и поведения меню WAI-ARIA.</li> <li>Убедиться, что каждая страница, на которую ведёт ссылка верхнего уровня меню, имеет оглавление в качестве альтернативы подменю.</li> </ol> <p>Первое решение не самое хорошее. Я ранее замечал, что этот тип семантики и поведения нежелателен в данном контексте, где ссылки — это управляемые контролы (subject controls). Кроме того пользователи больше не смогут переходить на страницу верхнего уровня, если она есть.</p> <h3>Какие устройства — сенсорные?</h3> <p>Заманчиво думать: «Это не самое хорошее решение, но я применю его только для сенсорных интерфейсов». Проблема в том, как определить, есть ли у устройства сенсорный экран?</p> <p>Вам точно не стоит относить любой «маленький экран» к разряду «экранов с сенсорным управлением». Работая в одном офисе с людьми, разрабатывающими сенсорные дисплеи для музеев, я могу заверить вас, что самые большие экраны — сенсорные. Не забывайте о ноутбуках с клавиатурой и сенсорным дисплеем.</p> <p>К тому же многие, но далеко не все устройства небольшого размера являются сенсорными. В инклюзивном дизайне вы не можете позволить себе предполагать.</p> <p>Второе решение более инклюзивное и надёжное. Это «фолбэк» для пользователей всех устройств. Но я специально взял в кавычки это слово, потому что думаю, что на самом деле постраничные оглавления — это <em>лучший</em> способ обеспечения навигации.</p> <p>Похоже, получившая премию <a href="https://www.gov.uk/guidance/content-design/organising-and-grouping-content-on-gov-uk">команда Government Digital Services</a> с этим согласится. Вы также могли видеть такие оглавления в Wikipedia.</p> <h2>Оглавление</h2> <p>Оглавления — это навигация для связанных между собой страниц или их разделов, которые должны быть семантически похожи на основные области навигации сайта. Для них используются элементы с <code><nav></code>, списки и общие подписи к ним.</p> <pre><code tabindex="0" class="language-html"><nav aria-labelledby="sections-heading"> <h2 id="sections-heading">Продукты</h2> <ul> <li><a href="/products/dog-costumes">Одежда для собак</a></li> <li><a href="/products/waffle-irons">Вафельницы</a></li> <li><a href="/products/magical-orbs">Магические шары</a></li> </ul> </nav>  </code></pre> <h3>Примечания</h3> <ul> <li>В этом примере мы представляем каждый раздел как отдельную страницу, как если бы это было в выпадающем подменю.</li> <li>Важно, чтобы каждая страница из «Магазин» имела одинаковую структуру. Поэтому оглавление «Продукты» находится в одном и том же месте. Консистентность улучшает понимание.</li> <li>Список группирует элементы, а вспомогательные технологии могут установить их количество и объявить о них, например, с помощью синтезированного голоса в скринридерах.</li> <li>Тегу <code><nav></code> заголовок задан с помощью атрибута <code>aria-labelledby</code>. Это означает, что большинство скринридеров объявит «Продукты, навигация» при попадании в область с помощью клавиши <kbd>Tab</kbd>. Также это приведёт к тому, что такая навигация будет разбита скринридерами на отдельные элементы, через которые пользователи смогут переходить к областям страницы напрямую.</li> </ul> <h3>Всё на одной странице</h3> <p>Если вы можете поместить все разделы на одной странице, при этом не сделав её слишком длинной и избежав утомительной прокрутки, то так даже лучше. Просто задайте для каждого раздела якорную ссылку. Например, <code>href="#waffle-irons"</code> должна вести к <code>id="waffle-irons"</code>.</p> <pre><code tabindex="0" class="language-html"><nav aria-labelledby="sections-heading"> <h2 id="sections-heading">Продукты</h2> <ul> <li><a href="#dog-costumes">Одежда для собак</a></li> <li><a href="#waffle-irons">Вафельницы</a></li> <li><a href="#magical-orbs">Магические шары</a></li> </ul> </nav>  <section id="waffle-irons" tabindex="-1"> <h2>Вафельницы</h2> </section>  </code></pre> <p><strong>Примечание</strong>: в некоторых браузерах фокус плохо переносится на отдельные фрагменты страницы. Добавление <code>tabindex="-1"</code> к нужному фрагменту исправляет это.</p> <p>В случае, если на сайте много контента, лучше тщательно продумывать информационную архитектуру с оглавлениями меню, чем делать ненадёжную и громоздкую систему выпадающих меню. Так будет легче сделать адаптивную версию страницы с меньшим количеством кода, а также это упростит восприятие её структуры. Там, где системы выпадающих меню скрывают структуру, оглавления обнажают её.</p> <p>На некоторых сайтах, включая правительственный цифровой сервис <a href="https://www.gov.uk/">gov.uk</a>, есть страницы с указателями (или «темами»), которые представляют собой <em>просто</em> оглавления. Это настолько мощная концепция, что популярный генератор статических сайтов Hugo <a href="https://gohugo.io/templates/lists/">создаёт такие страницы по умолчанию</a>.</p> <p>Информационная архитектура — это важная часть инклюзивности. Плохо организованный сайт может соответствовать нужным вам техническим требованиям, но при этом будет отталкивать многих пользователей. Особенно это касается тех, у кого есть когнитивные нарушения или у кого мало времени на то, чтобы с чем-то долго разбираться.</p> <h2>Кнопки навигационного меню</h2> <p>Пока мы обсуждаем тему фальшивых навигационных меню, было бы упущением с моей стороны не поговорить про кнопки меню. Вы наверняка видели состоящую из трёх линий иконку-гамбургер или «navicon».</p> <p>Даже с упрощённой информационной архитектурой и одним уровнем навигационных ссылок пространство на маленьких экранах на вес золота. Скрытие навигации за кнопкой означает, что во вьюпорте будет больше места для основного контента.</p> <p>Кнопка навигации больше всего из того, что мы изучали, похожа на <em>настоящую</em> кнопку меню. Так как она открывает меню по клику, то она должна:</p> <ol> <li>Быть кнопкой, а не ссылкой.</li> <li>Содержать информацию о развёрнутом или свёрнутом состоянии соответствующего меню (которое, строго говоря, представляет собой просто список ссылок).</li> </ol> <h3>Прогрессивное улучшение</h3> <p>Давайте не будем забегать вперёд. Мы должны помнить о прогрессивном улучшении и подумать, как это будет работать без JavaScript.</p> <p>В изначальном HTML-файле мало что можно сделать с помощью кнопок (кроме кнопок для отправки данных, но они даже близко не связаны с тем, что нам нужно сделать). Может быть, вместо этого, нам следует начать с простой ссылки, которая приведёт нас к навигации?</p> <pre><code tabindex="0" class="language-html"><a href="#navigation">Навигация</a>  <nav id="navigation"> <ul> <li><a href="/">Главная</a></li> <li><a href="/about">О нас</a></li> <li><a href="/shop">Магазин</a></li> <li><a href="/content">Контент</a></li> </ul> </nav> </code></pre> <p>Нет особой необходимости использовать ссылку, если между ней и навигацией нет большого количества контента. Так как навигация сайта в большинстве случаев должна размещаться наверху страницы, то в этом решении нет необходимости. Так что, действительно, навигационное меню без JavaScript должно быть просто… навигацией.</p> <pre><code tabindex="0" class="language-html"><nav id="navigation"> <ul> <li><a href="/">Главная</a></li> <li><a href="/about">О нас</a></li> <li><a href="/shop">Магазин</a></li> <li><a href="/content">Контент</a></li> </ul> </nav> </code></pre> <p>Вы улучшите его, добавив кнопку, которая в исходном состоянии скрывает навигацию с помощью атрибута <code>hidden</code>:</p> <pre><code tabindex="0" class="language-html"><nav id="navigation"> <button aria-expanded="false">Меню</button> <ul hidden> <li><a href="/">Главная</a></li> <li><a href="/about">О нас</a></li> <li><a href="/shop">Магазин</a></li> <li><a href="/content">Контент</a></li> </ul> </nav> </code></pre> <p>Некоторые более старые браузеры, сами знаете какие, не поддерживают <code>hidden</code>, так что не забудьте учесть это в вашем CSS. Селектор ниже решит эту проблему, так как <code>display: none</code> делает то же самое, что и атрибут <code>hidden</code>: скрывает меню от вспомогательных технологий и удаляет ссылку из порядка получения фокуса.</p> <pre><code tabindex="0" class="language-css">[hidden] { display: none; } </code></pre> <p>Делать всё возможное для поддержки старого программного обеспечения — это, конечно, часть инклюзивного дизайна. Некоторый софт невозможно обновить или его разработчики не хотят этого делать.</p> <h3>Расположение</h3> <p>Многие неправильно размещают кнопку <em>за пределами</em> области (навигации). Это может привести к тому, что пользователи скринридеров, которые перемещаются по <code><nav></code> с помощью горячих клавиш, решат, что область пустая, что не особо им поможет. Со списком, скрытым от скринридеров, они просто столкнулись бы с этим:</p> <pre><code tabindex="0" class="language-html"><nav id="navigation"> </nav> </code></pre> <p>Вот как мы можем переключить состояние:</p> <pre><code tabindex="0" class="language-js">var navButton = document.querySelector('nav button'); navButton.addEventListener('click', function() { let expanded = this.getAttribute('aria-expanded') === 'true' || false; this.setAttribute('aria-expanded', !expanded); let menu = this.nextElementSibling; menu.hidden = !menu.hidden; }); </code></pre> <h2>ARIA-controls</h2> <p>Как я уже писал в <a href="https://web.archive.org/web/20200924080848/https://heydonworks.com/article/aria-controls-is-poop/">«Aria-controls Is Poop»</a>, атрибут <code>aria-controls</code>, который помогает пользователям скринридеров при переходе от контролирующего элемента к контролируемому, поддерживается только в JAWS. Так что на него нельзя положиться.</p> <p>Без хорошего метода перемещения между элементами, вам нужно убедиться в том, что одно из следующего верно:</p> <ol> <li>Первая ссылка раскрывающегося списка — следующая в порядке фокуса после кнопки (как в предыдущем примере кода).</li> <li>При раскрытии списка на первую ссылку сделан фокус.</li> </ol> <p>В нашей ситуации я рекомендовал бы первый вариант. Это намного проще, так как не нужно беспокоиться о перемещении фокуса обратно на кнопку и о том, какие события для этого нужны. Кроме того, сейчас нет ничего, что могло бы предупредить пользователей о том, что фокус будет перемещён в другое место. В настоящих меню, которые мы вскоре обсудим, за это отвечает <code>aria-haspopup="true"</code>.</p> <p>Использование <code>aria-controls</code> на самом деле не приносит большого вреда, за исключением того, что делает объявления в скринридере более подробным. Однако некоторым пользователям JAWS это может быть нужно. Вот как будет использоваться атрибут вместе с <code>id</code> для списка:</p> <pre><code tabindex="0" class="language-html"><nav id="navigation"> <button aria-expanded="false" aria-controls="menu-list"> Меню </button> <ul id="menu-list" hidden> <li><a href="/">На главную</a></li> <li><a href="/about">О нас</a></li> <li><a href="/shop">Магазин</a></li> <li><a href="/content">Товары</a></li> </ul> </nav> </code></pre> <h2>Меню и роли menuitem</h2> <p><em>Настоящее</em> меню (с точки зрения WAI-ARIA) должно себя идентифицировать с помощью роли <code>menu</code> (для контейнера) и, обычно, роли <code>menuitem</code> для дочерних элементов (или других ролей для подобных элементов). Эти роли для родителей и детей работают сообща и предоставляют вспомогательным технологиям нужную информацию. Вот как можно расширить список, добавив для него семантику меню:</p> <pre><code tabindex="0" class="language-html"><ul role="menu"> <li role="menuitem">Пункт 1</li> <li role="menuitem">Пункт 2</li> <li role="menuitem">Пункт 3</li> </ul> </code></pre> <p>Поскольку наше навигационное меню начинает вести себя как «настоящее» меню, не должно ли тут быть ролей <code>menuitem</code>?</p> <p>Краткий ответ — нет. Более подробный ответ: нет, потому что наши элементы списка содержат ссылки, а <a href="https://w3c.github.io/html-aria/#index-aria-menuitem">элементы <code>menuitem</code> не могут иметь интерактивных потомков</a>. То есть они <em>являются</em> контролами в меню.</p> <p>Мы можем, конечно, удалить семантику списка у элементов <code><li></code> с помощью <a href="https://www.w3.org/TR/wai-aria/#presentation"><code>role="presentation"</code></a> или <code>role="none"</code> (они эквивалентны друг другу) и добавить для каждой ссылки роль menuitem. Однако, это удалит встроенную в них по умолчанию роль <code>link</code>. Другими словами, в примере ниже скринридерами будет объявлено: «Главная, пункт меню», а <em>не</em>: «Главная, ссылка» или «Главная, пункт меню, ссылка». ARIA-роли просто переопределяют HTML-роли.</p> <pre><code tabindex="0" class="language-html"> <li role="presentation"> <a href="/" role="menuitem">Главная</a> </li> </code></pre> <p>Мы хотим, чтобы пользователи знали, что они используют ссылку и могут ожидать от неё поведения ссылки, так что пример выше не очень хороший. Как я уже сказал, настоящие меню предназначены для (написанных на JavaScript) приложений.</p> <p>То, что у нас осталось, это своего рода гибридный компонент, который не совсем настоящее меню, но, по крайней мере, сообщает пользователям, открыт ли список ссылок, благодаря состоянию <code>aria-expanded</code>. Это подходящий паттерн для навигационных меню.</p> <h3>Примечание. Элемент <code><select></code></h3> <p>Если вы давно знакомы с адаптивным дизайном, то можете вспомнить паттерн, в котором навигация была свёрнута в элемент <code><select></code> в небольших вьюпортах.</p> <p>Как и в случае с <a href="https://inclusive-components.design/toggle-button/">переключателями на основе чекбоксов, которые мы обсуждали</a> <em>(<a href="https://medium.com/web-standards/toggle-buttons-a41388e80974">см. в переводе</a> — прим. переводчика),</em> использование нативного элемента, который ведёт себя не так, как задумано, без дополнительного скрипта — хороший выбор. Особенно с точки зрения эффективности и производительности в случае мобильных устройств. Элементы <code><select></code> — это своего рода меню, с семантикой, аналогичной меню, открывающееся кнопкой, которую мы скоро будем создавать.</p> <p>Однако, так же как и с переключателем, основанном на чекбоксе, мы используем элемент, связанный со вводом данных, а не просто делаем выбор. Это может запутать многих пользователей, тем более, что этот шаблон использует JavaScript, чтобы выбранный элемент <code><option></code> вёл себя как ссылка. Неожиданное изменение контекста, которое это вызывает, считается ошибкой согласно критерию <a href="https://www.w3.org/TR/WCAG20/#consistent-behavior-unpredictable-change">3.2.2 On Input (Level A)</a>.</p> <h2>Настоящие меню</h2> <p>Теперь, когда мы обсудили ненастоящие меню и квази-меню, пришло время создать <em>настоящее</em> меню, которое открывается и закрывается настоящей кнопкой меню. С этого момента я буду называть вместе кнопку и меню — «кнопкой меню».</p> <p>Но в каком случае наша кнопка меню может считаться настоящей? Что ж, это будет компонент меню, предназначенный для выбора параметров в приложении, который предусматривает всю нужную семантику и стандартное поведение для такого инструмента.</p> <p>Как я уже упоминал, эти соглашения пришли из дизайна десктопных приложений. ARIA-атрибуты и управление фокусом с помощью JavaScript необходимы для их полной имитации. Одна из целей ARIA — помочь веб-разработчикам создавать сложные веб-интерфейсы и не нарушать при этом устоявшие паттерны взаимодействия, пришедшие из реального мира.</p> <p>В этом примере мы представим, что наше приложение — это какая-то игра или викторина. Наша кнопка меню даёт пользователю выбрать уровень сложности. С учётом всей семантики меню выглядит следующим образом:</p> <pre><code tabindex="0" class="language-html"><button aria-haspopup="true" aria-expanded="false"> Сложность <span aria-hidden="true">▾</span> </button> <div role="menu"> <button role="menuitem">Лёгкая</button> <button role="menuitem">Средняя</button> <button role="menuitem">Очень высокая</button> </div> </code></pre> <h3>Примечания</h3> <ul> <li><code>aria-haspopup</code> просто указывает на то, у кнопки есть скрытое меню. Это работает как предупреждение о том, что при нажатии на кнопку пользователь будет перемещён в выпадающее меню (скоро мы рассмотрим поведение фокуса). Его значение не меняется: оно всегда <code>true</code>.</li> <li>Элемент <code><span></code> внутри кнопки содержит символ Юникод с маленьким чёрным перевёрнутым треугольником. Он визуально показывает, что нажатие на кнопку раскроет что-то под ней. Этого <code>aria-haspopup</code> не может показать. Атрибут <code>aria-hidden="true"</code> не разрешает скринридерам объявлять «перевёрнутый треугольник» или что-то подобное. Благодаря <code>aria-haspopup</code> этого не нужно делать в невизуальном контексте.</li> <li><code>aria-haspopup</code> дополняет <code>aria-expanded</code>. Атрибут сообщает пользователю, находится ли он в данный момент в открытом (развёрнутом) меню или оно закрыто (свёрнуто), переключаясь между значениями <code>true</code> и <code>false</code>.</li> <li>Само меню имеет (точно названную) роль <code>menu</code>. Для него нужны потомки с ролями <code>menuitem</code>. Они не обязательно должны быть прямыми потомками элемента <code>menu</code>. В этом примере так сделано для простоты.</li> </ul> <h2>Клавиатура и поведение при фокусе</h2> <p>Когда дело доходит до того, чтобы сделать интерактивные контролы доступными для клавиатуры, лучшее, что вы можете сделать, это использовать правильные элементы. Поскольку здесь используются элементы <code><button></code>, то мы можем быть уверены в том, что события по клику будут срабатывать при нажатии клавиш <kbd>Enter</kbd> и <kbd>Space</kbd>, как указано в <a href="https://developer.mozilla.org/en/docs/Web/API/HTMLButtonElement">HTMLButtonElement interface</a>. Также это означает, что мы можем отключить пункты меню, используя связанное с кнопкой свойство <code>disabled</code>.</p> <p>Есть намного больше способов взаимодействовать с кнопкой с клавиатуры. Вот краткий обзор поведения при фокусе с клавиатуры, которое мы будем реализовывать на основе <a href="https://www.w3.org/TR/wai-aria-practices-1.1/#menubutton">WAI-ARIA Authoring Practices 1.1</a>:</p> <ul> <li><strong><kbd>Enter</kbd>, <kbd>Space</kbd> или <kbd>↓</kbd> на кнопке меню</strong> — открывает меню.</li> <li><strong><kbd>↓</kbd> на пункте меню</strong> — перемещает фокус к следующему пункту меню или к первому, когда вы дошли до последнего пункта.</li> <li><strong><kbd>↑</kbd> на пункте меню</strong> — перемещает фокус к предыдущему пункту меню или к последнему, если вы находитесь на первом.</li> <li><strong><kbd>↑</kbd> на кнопке меню</strong> — закрывает меню, если оно открыто.</li> <li><strong><kbd>Esc</kbd> на пункте меню</strong> — закрывает меню и перемещает фокус на кнопку меню.</li> </ul> <p>Преимущество перемещения фокуса между пунктами меню с помощью клавиш со стрелками состоит в том, что за <kbd>Tab</kbd> сохраняется функция выхода из меню. На практике это означает, что пользователям не нужно проходить через каждый пункт меню, чтобы выйти из меню. Это значительно улучшает юзабилити, особенно в меню, где много пунктов.</p> <p>Добавление <code>tabindex="-1"</code> к пунктам меню делает их недоступными для фокуса с помощью <kbd>Tab</kbd>, но сохраняет возможность фокуса на элементах при нажатии на клавиши со стрелками.</p> <pre><code tabindex="0" class="language-html"><button aria-haspopup="true" aria-expanded="false"> Сложность <span aria-hidden="true">▾</span> </button> <div role="menu"> <button role="menuitem" tabindex="-1">Лёгкая</button> <button role="menuitem" tabindex="-1">Средняя</button> <button role="menuitem" tabindex="-1">Очень высокая</button> </div> </code></pre> <h2>Метод <code>open</code></h2> <p>Мы можем создать методы для обработки различных событий как часть продуманного дизайна API.</p> <p>Например, метод <code>open</code> нужен для переключения значения <code>aria-expanded</code> на <code>true</code>, изменить значение меню <code>hidden</code> на <code>false</code> и сделать фокус на первом элементе меню с <code>menuitem</code>, который не скрыт:</p> <pre><code tabindex="0" class="language-js">MenuButton.prototype.open = function () { this.button.setAttribute('aria-expanded', true); this.menu.hidden = false; this.menu.querySelector(':not([disabled])').focus(); return this; } </code></pre> <p>Мы можем исполнить этот метод, когда пользователь нажимает клавишу вниз на кнопке меню, на которой сделан фокус:</p> <pre><code tabindex="0" class="language-js">this.button.addEventListener('keydown', function (e) { if (e.keyCode === 40) { this.open(); } }.bind(this)); </code></pre> <p>Кроме того, разработчик, использующий этот скрипт, сможет теперь программно открывать меню:</p> <pre><code tabindex="0" class="language-js">exampleMenuButton = new MenuButton( document.querySelector('[aria-haspopup]') ); exampleMenuButton.open(); </code></pre> <h3>Примечание. Хак с чекбоксом</h3> <p>Если вам не нужен JavaScript, то лучше не использовать его настолько, насколько это возможно. Использование третьей технологии поверх HTML и CSS всегда усложняет систему и приводит к появлению в ней слабых мест. Однако не все компоненты можно создать без использования JavaScript.</p> <p>В случае с кнопками меню желание сделать их «работающими без JavaScript» привело к появлению так называемого хака с чекбоксом. В нём состояние <code>checked</code> (или <code>unchecked</code>) скрытого чекбокса используется для переключения видимости элемента меню с помощью CSS.</p> <pre><code tabindex="0" class="language-css">/* Меню закрыто */ [type="checkbox"] + [role="menu"] { display: none; } /* Меню открыто */ [type="checkbox"]:checked + [role="menu"] { display: block; } </code></pre> <p>Для пользователей скринридеров роль чекбокса и состояние <code>checked</code> бессмысленны в этом контексте. Это можно частично исправить, добавив <code>role="button"</code> для чекбокса.</p> <pre><code tabindex="0" class="language-html"><input type="checkbox" role="button" aria-haspopup="true" id="toggle"> </code></pre> <p>К сожалению, это отменяет взаимодействие со встроенным состоянием <code>checked</code>, лишая нас обратной связи о состоянии элемента без JavaScript (что плохо, хотя в этом контексте это было бы так же связано с состоянием <code>checked</code>).</p> <p>Но это <em>возможно</em> имитировать с помощью <code>aria-expanded</code>. Нам просто нужно добавить наш лейбл к двум элементам со <code><span></code>, как показано ниже.</p> <pre><code tabindex="0" class="language-html"><input type="checkbox" role="button" aria-haspopup="true" id="toggle" class="vh"> <label for="toggle" data-opens-menu> Сложность <span class="vh expanded-text">развёрнуто</span> <span class="vh collapsed-text">свёрнуто</span> <span aria-hidden="true">▾</span> </label> </code></pre> <p>Оба этих элемента визуально скрыты благодаря <a href="http://a11yproject.com/posts/how-to-hide-content/">классу <code>visually-hidden</code></a>, но, в зависимости от того в каком состоянии мы находимся, только один из них скрыт от скринридера. То есть только одному задано свойство <code>display: none</code> и это определяется установленным (но не объявляемым) состоянием <code>checked</code>:</p> <pre><code tabindex="0" class="language-css">/* Класс, который скрывает визуально элементы со <span> */ .vh { position: absolute !important; clip: rect(1px, 1px, 1px, 1px); padding:0 !important; border:0 !important; height: 1px !important; width: 1px !important; overflow: hidden; } /* Отобразить правильное состояние для скринридеров с помощью текущего состояния элемента */ [type="checkbox"]:checked + label .expanded-text { display: inline; } [type="checkbox"]:checked + label .collapsed-text { display: none; } [type="checkbox"]:not(:checked) + label .expanded-text { display: none; } [type="checkbox"]:not(:checked) + label .collapsed-text { display: inline; } </code></pre> <p>Это разумное решение, но работа над нашей кнопкой меню всё ещё не закончена. Ожидаемое поведение фокуса, которое мы обсудили, просто не может быть реализовано без JavaScript.</p> <p>Такое поведение принято и предсказуемо, оно делает кнопку более удобной. Однако, если вам действительно нужно сделать кнопку меню без JavaScript, то это самый подходящий вариант. Учитывая то, что урезанная кнопка навигационного меню, которую я рассмотрел ранее, предлагает контент меню, который <em>не</em> зависит от самого JavaScript (то есть ссылки), этот подход может быть подходящим вариантом.</p> <p>Забавы ради, <a href="https://codepen.io/heydon/pen/afdeffcc8a349ab8138e32573ec85cd3">вот CodePen c кнопкой меню без JavaScript</a>.</p> <p><strong>Примечание</strong>: меню открывает только пробел.</p> <h2>Событие <code>choose</code></h2> <p>Исполнение некоторых методов должно вызывать события, чтобы мы могли настроить обработчики событий. Например, мы можем транслировать событие <code>choose</code>, когда пользователь кликает по пункту меню. Мы можем установить это с помощью <code>CustomEvent</code>, которое даёт нам возможность передавать аргумент в свойство события <code>detail</code>. В этом случае аргумент (<code>choice</code>) будет узлом DOM выбранного пункта меню.</p> <pre><code tabindex="0" class="language-js">MenuButton.prototype.choose = function (choice) { // Определить событие 'choose' var chooseEvent = new CustomEvent('choose', { detail: { choice: choice } }); // Передать событие (Dispatch the event) this.button.dispatchEvent(chooseEvent); return this; } </code></pre> <p>Есть много всего, что мы можем сделать с помощью этого механизма. Возможно, у нас есть live region с <code>id</code> со значением <code>menuFeedback</code>:</p> <pre><code tabindex="0" class="language-html"><div role="alert" id="menuFeedback"></div> </code></pre> <p>Теперь мы можем настроить обработчик событий и заполнить live region информацией, скрытой внутри события:</p> <pre><code tabindex="0" class="language-js">exampleMenuButton.addEventListener('choose', function (e) { // Получить текст узла (label) var choiceLabel = e.details.choice.textContent; // Получить узел live region var liveRegion = document.getElementById('menuFeedback'); // Заполнить live region liveRegion.textContent = `Your difficulty level is ${choiceLabel}`; }): </code></pre> <figure> <figcaption> Когда пользователь выбирает пункт, меню закрывается и фокус перемещается на кнопку меню. Для пользователей важно возвращаться к такому элементу после закрытия меню. </figcaption> </figure> <p>При выборе пункта меню пользователь скринридера услышит: <em>«Вы выбрали [название пункта меню]».</em> Изменения контента live region (которому задан здесь атрибут <code>role="alert"</code>) объявляются скринридерами при каждом его обновлении. Live region не является обязательным, но это пример того, что может произойти в интерфейсе, когда пользователь сделал выбор в меню.</p> <h2>Сохранение выбора</h2> <p>Не все пункты меню нужны для выбора сохранения настроек. Многие из них ведут себя как стандартные кнопки, которые при нажатии приводят к тому, что что-то происходит в интерфейсе. Однако, в случае с нашей кнопкой меню со сложностью, мы хотели бы указать текущую настройку сложности. То есть ту, которая выбрана последней.</p> <p>Атрибут <code>aria-checked="true"</code> работает для элементов, которым вместо <code>menuitem</code> задана роль <code>menuitemradio</code>. Расширенная разметка со вторым выбранным элементом <em>(установленным)</em> выглядит так:</p> <pre><code tabindex="0" class="language-html"><button aria-haspopup="true" aria-expanded="false"> Сложность <span aria-hidden="true">▾</span> </button> <div role="menu"> <button role="menuitemradio" tabindex="-1">Лёгкая</button> <button role="menuitemradio" aria-checked="true" tabindex="-1">Средняя</button> <button role="menuitemradio" tabindex="-1">Очень высокая</button> </div> </code></pre> <p>В нативных меню на многих платформах выбранные элементы отмечаются с помощью галочек. Мы можем это без проблем сделать, используя чуть больше CSS:</p> <pre><code tabindex="0" class="language-css">[role="menuitemradio"][aria-checked="true"]::before { content: '\2713\0020'; } </code></pre> <p>При перемещении по меню с запущенным скринридером при фокусе на этом выбранном элементе он объявит что-то вроде: <em>«Галочка, средний, пункт меню, выбрано».</em></p> <p>Поведение при открытии меню с выбранным <code>menuitemradio</code> немного отличается. Вместо того, чтобы сделать фокус на первом (включённом) элементе в меню, фокус устанавливается на <em>выбранном</em> элементе.</p> <p>Какая польза от такого поведения? Пользователь (любой) помнит о своём предыдущем выборе. В меню с многочисленными параметрами (например, с масштабом), люди, работающие на клавиатуре, находятся в оптимальном положении для изменения настроек.</p> <h2>Использование кнопки меню с помощью скринридера</h2> <p>В этом видео я покажу вам как использовать кнопку меню в VoiceOver и Chrome. В примере используются элементы с ролью <code>menuitemradio</code>, атрибутом <code>aria-checked</code> и обсуждается поведение кнопки при фокусе. Таким образом ведут себя и другие популярные скринридеры.</p> <h3>Расшифровка</h3> <p><strong>Хейдон:</strong> Это кнопка меню со сложностью и я собираюсь протестировать её на VoiceOver в Chrome. Для начала я сделаю фокус на самой кнопке.</p> <p><strong>VoiceOver:</strong> Сложность, всплывающая кнопка.</p> <p><strong>Хейдон:</strong> Сначала вы услышите «Сложность» — это подпись. Затем «всплывающая кнопка», что означает её состояние, что ей задано <code>area-expanded="false"</code> и что она всплывающая, потому что для неё установлено значение <code>true</code> в атрибуте <code>aria-haspopup</code>. Сейчас я открою меню с помощью клавиши со стрелкой вниз.</p> <p><strong>VoiceOver:</strong> Галочка, очень сложно, пункт меню, выбран, меню, пять пунктов.</p> <p><strong>Хейдон:</strong> Здесь много информации. Для начала «Галочка, очень сложная». Это подпись. Я использую псевдоэлемент для того, чтобы добавить галочку. «Пункт меню», потому что в этом случае это пункт меню с ролью <code>menuitemradio</code>. «Выбран», потому что задан атрибут <code>aria-checked</code> со значением <code>checked</code>. И также вы слышите, что в меню пять пунктов. Это потому, что этот пункт меню вместе с другими находится внутри элемента, которому задана роль <code>menu</code>. Сейчас я нажму на кнопку со стрелкой вниз, чтобы сделать фокус на пункте «Очень высокая».</p> <p><strong>VoiceOver:</strong> Очень высокая, пункт меню.</p> <p><strong>Хейдон:</strong> На этот раз вы услышали только подпись и роль элемента, потому что он очевидно не выбран. Для того, чтобы выбрать этот пункт, я нажимаю кнопку <kbd>Enter</kbd>.</p> <p><strong>VoiceOver:</strong> Сложность, всплывающая кнопка.</p> <p><strong>Хейдон:</strong> Это закрывает меню и перемещает фокус на саму кнопку меню «Сложность». Итак, вы вернулись туда, откуда начали.</p> <h2>Инклюзивная кнопка меню на Github</h2> <p>Я и <a href="https://twitter.com/HugoGiraudel">Хьюго Жирадель</a> вместе работали над созданием компонента кнопки меню с фичами API, которые я описал, и ещё многим другим. Вы должны поблагодарить Хьюго за многие из этих фич, так как они основывались на работе над a11y-dialog — доступным модальным окном. Он есть на <a href="https://github.com/Heydon/inclusive-menu-button">Гитхабе</a> и в npm.</p> <pre><code tabindex="0" class="language-sh">npm i inclusive-menu-button --save </code></pre> <p>Кроме того, Хьюго сделал специально для вас <a href="https://github.com/HugoGiraudel/react-menu-button">версию кнопки на React</a>.</p> <h2>Чеклист</h2> <ul> <li>Не используйте семантику ARIA для меню в случае с системами навигационных меню.</li> <li>На сайтах с большим количеством контента не скрывайте структуру в выпадающих меню.</li> <li>Используйте <code>aria-expanded</code> у кнопок для того, чтобы сообщить о том, что навигационное меню открыто или закрыто.</li> <li>Убедитесь, что навигационное меню следующее в порядке фокуса после кнопки, которая его открывает и закрывает.</li> <li>Никогда не жертвуйте юзабилити ради решений без JavaScript. Это заносчиво.</li> </ul> </article> <article> <h1>Всё, что нужно знать про ARIA Live Regions</h1> <p>Tue, 12 Mar 2019 00:00:00 GMT</p> <p>Как сделать изменение контента доступным.</p> <p>Если у вас есть динамически изменяющаяся часть страницы и вы задумались о её доступности, то может возникнуть закономерный вопрос о том, как же это сделать. Это могут быть:</p> <ul> <li>Чаты;</li> <li>Прогресс-бары и таймеры;</li> <li>Виджеты с новостями и погодой;</li> <li>Разные ошибки и оповещения: новое сообщение, лайк, подписка;</li> <li>Тикеры (биржевая информация о котировках акций, индексов, облигаций), курсы валют;</li> <li>Спортивная статистика и многое другое.</li> </ul> <p>Раньше вспомогательные технологии (в том числе скринридеры) не умели правильно их обрабатывать. Пользователи не могли узнать о том, появилась ли какая-то ошибка или новые данные до тех пор, пока не возвращались в предыдущий блок или не доходили до конца страницы. Теперь проблему доступности динамически изменяющегося контента страниц можно решить с помощью ARIA.</p> <p>Если вы не знакомы с этой аббревиатурой, то WAI-ARIA <em>(англ. Web Accessibility Initiative — Accessible Rich Internet Applications)</em> или просто ARIA — это стандарт, состоящий из набора специальных ролей и атрибутов, которые добавляются в разметку и расширяют или дополняют функции стандартных HTML-элементов.</p> <p>Всё, что нам нужно — это сделать часть страницы, в которой происходят изменения. В терминологии ARIA, это называется «live region» или «интерактивной областью». В стандарте можно найти <a href="https://www.w3.org/TR/wai-aria-1.2/#dfn-live-region">такое определение</a>:</p> <blockquote> <p><strong>Live Region</strong> — это воспринимаемые области страниц, которые обычно обновляются в результате внешнего события, когда пользователь сделал фокус где-то в другом месте. Эти области не всегда обновляются из-за взаимодействия пользователей с ними. Такая практика стала обычным делом в результате активного использования Ajax.</p> </blockquote> <p>Таким образом, главная цель таких областей — сообщать скринридерам как правильно обрабатывать изменения контента, которые не обязательно зависят от пользователей.</p> <p>Чтобы сделать интерактивную область на странице, нам нужно просто добавить к любому родительскому элементу ARIA-атрибут <code>aria-live=""</code> или специальную ARIA-роль. Тогда изменения всех его дочерних элементов станут доступными для скринридеров. Теперь они будут знать, как обрабатывать обновления содержимого таких элементов.</p> <p>В ARIA есть несколько таких ролей и атрибутов. Давайте сначала поговорим о ролях.</p> <h2>Роли интерактивных областей</h2> <p>ARIA-ролей, которые делают часть страницы интерактивной областью, не так много. Используются они вот так: <code>role="alert"</code> Вот их полный список:</p> <ul> <li><code>alert</code>;</li> <li><code>status</code>;</li> <li><code>log</code>;</li> <li><code>timer</code>;</li> <li><code>marquee</code>.</li> </ul> <p>Разберёмся с каждой ролью по порядку.</p> <h3>Alert</h3> <p>Тип интерактивной области, который содержит важную в определённый момент времени информацию. Это может быть сообщение об ошибке, предупреждение, которое появляется на экране после каких-то действий пользователя или без его участия (внезапная ошибка на стороне сервера). Такое сообщение может быть как текстовым, так и звуковым.</p> <p>Рассмотрим простой пример, в котором мы предупреждаем пользователей о чём-то <em>действительно</em> важном:</p> <pre><code tabindex="0" class="language-html"><div class="warning" role="alert"> Вы слишком долго смотрели в бездну, и теперь бездна смотрит в вас. </div> </code></pre> <p>Скринридер моментально объявит его в момент появления и прервёт другое объявление, если оно было.</p> <p>👉 Для максимальной совместимости используйте <code>role="alert"</code> вместе с атрибутом <code>aria-live="assertive"</code>. При этом такой элемент всё ещё может быть неправильно объявлен VoiceOver на iOS. Внесём небольшие изменения в наш пример:</p> <pre><code tabindex="0" class="language-html"><div class="warning" role="alert" aria-live="assertive"> Вы слишком долго смотрели в бездну, и теперь бездна смотрит в вас. </div> </code></pre> <p>Получается, что мы продублировали уже встроенное в <code>role="alert"</code> поведение с помощью значения <code>assertive</code> атрибута <code>aria-live</code>. Последнее как раз подсказывает скринридерам, что объявить об изменениях нужно немедленно.</p> <h3>Status</h3> <p>Область с такой ролью содержит дополнительную информацию, которая не особо важна и описывает состояние изменений (status bar). Это может быть информация о том, что действие пользователя успешно или наоборот, что требуется подождать завершения какого-то процесса или где-то есть ошибка. Например, такую роль можно задать сообщению об успешном автосохранении текста или использовать при валидации полей в форме регистрации.</p> <p>Кстати, в скринридерах есть специальная команда, которая помогает узнать пользователям о статусе. В NVDA она вызывается сочетанием клавиш <kbd>Ins End</kbd>, а в JAWS — <kbd>Ins 3</kbd>.</p> <p>В примере мы сообщаем пользователям о том, что изменения сохранены:</p> <pre><code tabindex="0" class="language-html"><div class="status-message" role="status"> Мы сохранили ваши изменения автоматически, не благодарите. </div> </code></pre> <p>Скринридер объявит это с паузой, а не сразу же, как в случае с <code>role="alert"</code>.</p> <p>👉 В <code>role="status"</code> встроено поведение атрибута <code>aria-live="polite"</code>. Для максимальной совместимости их рекомендуется использовать вместе. Поэтому пример выше выглядит теперь так:</p> <pre><code tabindex="0" class="language-html"><div class="status-message" role="status" aria-live="polite"> Мы сохранили ваши изменения автоматически, не благодарите. </div> </code></pre> <p>Скринридер сообщит об успешном автосохранении с паузой и не будет прерывать другие объявления.</p> <h3>Log</h3> <p>Тип интерактивной области, в которой содержатся логи. Например, история сообщений из чатов, список ошибок и тому подобное. Для логов имеет важное значение последовательность, в которой появляется новая информация. Вспомните журнал событий в Windows.</p> <p>В этом примере показано обновление контента в чате. Когда пользователь вводит сообщение в текстовое поле, то оно добавляется в конец переписки.</p> <pre><code tabindex="0" class="language-html"><div role="log"> <h4>История сообщений</h4> <ul> <li> Одолжишь своего вельш-корги-кардигана до понедельника? Очень нужно. </li> </ul> </div> </code></pre> <p>Теперь скринридер объявляет о новых комментариях после того, как пользователь перестал набирать или отправлять сообщение.</p> <p>👉 <code>role="log"</code> на всякий случай лучше сочетать с атрибутом <code>aria-live="polite"</code>:</p> <pre><code tabindex="0" class="language-html"><div role="log" aria-live="polite"> <h4>История сообщений</h4> <ul> <li> Одолжишь своего вельш-корги-кардигана до понедельника? Очень нужно. </li> <li>Тебя снова взломали?</li> </ul> </div> </code></pre> <p>В этом случае все изменения будут наверняка объявляться с паузой и не прерывать другие более важные изменения.</p> <h3>Marquee</h3> <p>В такой области содержится информация, которая быстро изменяется. Эта роль похожа на <code>log</code>, но в этом случае последовательность обновления информации не имеет значения. Простой пример, где может пригодиться <code>role="marquee"</code> — тикеры и курсы валют.</p> <p>В этом примере мы добавляем <code>role="marquee"</code> для блока с информацией о курсах валют:</p> <pre><code tabindex="0" class="language-html"><ul role="marquee"> <li>¥ 9999,56 ₽ за юань</li> <li>F 100000000000,32 ₽ за фронтендкоин</li> </ul> </code></pre> <p>Скринридер будет объявлять об изменениях в этом блоке тогда, когда пользователь сделает фокус на нём. Курсы валют часто изменяются, поэтому постоянные объявления об этом будут только раздражать пользователей.</p> <p>👉 <code>role="marquee"</code> стоит использовать вместе с атрибутом <code>aria-live="off"</code>:</p> <pre><code tabindex="0" class="language-html"><ul role="marquee" aria-live="off"> <li>¥ 9999,56 ₽ за юань</li> <li>F 100000000000,32 ₽ за фронтендкоин</li> </ul> </code></pre> <p>Мы просто продублировали поведение <code>role="marquee"</code> по умолчанию для максимальной совместимости.</p> <h3>Timer</h3> <p>Эта роль нужна для тех областей, в которых содержатся счётчики, отсчитывающие время в обычном и обратном порядке. Например, таймер обратного отсчёта, часы или секундомер.</p> <pre><code tabindex="0" class="language-html"><div role="timer">  </div> </code></pre> <p>В эту роль по умолчанию встроено поведение, при котором скринридер не будет объявлять об изменениях, произошедших с таймером, и пользователь узнает о них только при фокусе на нём.</p> <p>👉 Элементу с <code>role="timer"</code> стоит также задать атрибут <code>aria-live="off"</code> для полной совместимости со всеми вспомогательными устройствами и браузерами:</p> <pre><code tabindex="0" class="language-html"><div role="timer" aria-live="off">  </div> </code></pre> <p>Если нужно, чтобы скринридер объявлял об изменениях через определённый интервал времени, то сделать это можно при помощи JavaScript. Нам нужно переключать <code>aria-live="off"</code> на <code>aria-live="polite"</code> через нужный промежуток времени, например, 60 минут.</p> <h2>Атрибуты интерактивных областей</h2> <p>Теперь поговорим об атрибутах, которые делают любую область страницы интерактивной. Их всего четыре:</p> <ul> <li><code>aria-live</code>;</li> <li><code>aria-atomic</code>;</li> <li><code>aria-relevant</code>;</li> <li><code>aria-busy</code>.</li> </ul> <p>Рассмотрим каждый из них.</p> <h3>Aria-live</h3> <p>Этот атрибут используется для определения важности изменений, которые произошли с элементами.</p> <p>То есть значения данного атрибута отражают то, насколько срочно и быстро вспомогательным технологиям нужно сообщить пользователям об этих изменениях. У атрибута есть три значения: <code>off</code>, <code>polite</code> и <code>assertive</code>.</p> <ul> <li><code>off</code> (значение по умолчанию) — указывает на низший приоритет, поэтому такие изменения не объявляются. Это поведение встроено в элементы с <code>role="marquee"</code> и <code>role="timer"</code>. Его можно задавать тем областям, которые не важны, или слишком быстро изменяются.</li> <li><code>polite</code> — обозначает низкий уровень приоритета. Используется в случаях, когда в области происходят изменения, которые вспомогательным технологиям не нужно объявлять моментально. Скринридеры делают перед таким объявлением паузу, не прерывают текущие задачи и ждут, пока пользователь перестанет взаимодействовать с интерфейсом. Так себя ведут элементы с <code>role="status"</code> и <code>role="log"</code>. Подходит для оповещений о новых сообщениях, лайках, автосохранении и тому подобном.</li> <li><code>assertive</code> — указывает на наивысший уровень приоритета. О таких изменениях будет объявлено сразу же, а изменения с более низким приоритетом встанут в очередь и будут объявлены позже. Так себя ведут элементы с <code>role="alert"</code>, так что этот атрибут можно использовать для сообщений о важных изменениях, например, о серверной ошибке или о том, что данные не сохранились. Спецификация не рекомендует использовать это значение, когда нет необходимости сразу же сообщать пользователям об изменениях.</li> </ul> <p>Приведу пару простых примеров использования <code>aria-live="polite"</code> и <code>aria-live="assertive"</code>.</p> <p>В этом примере с <code>aria-live="polite"</code> при нажатии на кнопку с помощью скрипта меняется название блюда в параграфе.</p> <pre><code tabindex="0" class="language-html"><p aria-live="polite">Моё любимое блюдо <span id="food">лютефиск</span>. </p> <button type="button">Следующее блюдо</button> </code></pre> <p>Скринридер сделает перед объявлением паузу.</p> <p>А здесь у нас есть форма с несколькими настройками и кнопкой сохранения. Если изменения не сохранились, то должно появляться сообщение об этом. Зададим ему <code>aria-live="assertive"</code>:</p> <pre><code tabindex="0" class="language-html"><form> <p> <label for="devil-fruit">Любимый дьявольский фрукт</label> <input type="text" id="devil-fruit"> </p> … <button type="submit">Сохранить настройки</button> </form> <div class="alert-window" role="alert" aria-live="assertive"> Ваши настройки не сохранились, попробуйте ещё раз, йо-хо-хо! </div> </code></pre> <p>Здесь скринридер сделает объявление немедленно.</p> <p>❗ В стандарте WAI-ARIA также указано, что в некоторых случаях вспомогательные технологии могут переопределять значения атрибута <code>aria-live</code> и объявлять о каких-то изменениях моментально.</p> <h3>Aria-atomic</h3> <p>Этот атрибут необязательный и влияет на то, в каком объёме вспомогательные технологии объявят об изменениях: это будет весь контент целиком или только его изменившаяся часть.</p> <p>У атрибута есть всего два значения — <code>false</code> и <code>true</code>.</p> <ul> <li><code>false</code> (значение по умолчанию) — значение, при котором вспомогательные технологии сообщат только об изменениях.</li> <li><code>true</code> — при этом значении объявляется весь контент, включая изменившуюся часть.</li> </ul> <p>При выборе нужного значения для <code>aria-atomic=""</code> надо понять, важен ли для понимания изменений контекст. В большинстве случаев достаточно оставить значение по умолчанию.</p> <p>В этом примере важно сохранить контекст, так что можно использовать <code>aria-atomic="true"</code>:</p> <pre><code tabindex="0" class="language-html"><p aria-live="polite" aria-atomic="true">Моё любимое блюдо <span id="food">лютефиск</span>. </p> <button type="button">Следующее блюдо</button> </code></pre> <p>Теперь скринридер будет зачитывать всё предложение целиком, а не только ту часть, которая изменяется после нажатия на кнопку.</p> <h3>Aria-relevant</h3> <p>Цель этого атрибута — сообщить вспомогательным технологиям о том, какие именно изменения произошли на странице и, соответственно, в дереве доступности. Это может быть удаление старого или добавление нового контента. Атрибут необязательный.</p> <p><code>aria-relevant=""</code> может содержать одно или несколько значений, разделённых пробелом.</p> <ul> <li><code>additions</code> — на страницу добавлена новая информация.</li> <li><code>removals</code> — информация удалена.</li> <li><code>text</code> — добавлен новый текст или эквивалентная ему информация, например, новое содержимое атрибута <code>alt</code>.</li> <li><code>additions text</code> <strong>(значение по умолчанию)</strong> указывает на то, что текст был изменён и появилась новая информация на странице.</li> <li><code>all</code> — все возможные значения. Эквивалентно значению <code>"additions removals text"</code>.</li> </ul> <p>На самом деле реальных сценариев использования этого атрибута мало. Он либо <a href="https://github.com/w3c/aria/issues/712">не работает во многих браузерах и скринридерах</a>, либо его <a href="https://medium.com/dev-channel/why-authors-should-avoid-aria-relevant-5d3164fab1e3">советуют вообще не использовать</a> и прибегать к альтернативным методам.</p> <p>Самый реалистичный сценарий его использования — это список друзей. Когда какой-то друг вышел из сети и больше не активен, то мы можем использовать этот атрибут, чтобы сообщить пользователю об этом. Нам нужно задать для списка <code>aria-relevant="all"</code>. Тогда некоторые скринридеры объявят об удалении контакта. Это работает в JAWS, когда удаляется дочерний элемент (с родительским уже не работает). На VoiceOver и NVDA этот атрибут никак не влияет.</p> <h3>Aria-busy</h3> <p><code>aria-busy=""</code> даёт вспомогательным технологиям знать, обновляется ли сейчас содержимое элемента или нет. Атрибут имеет смысл применять тогда, когда на странице происходит автообновление контента. Что-то было удалено, что-то добавлено, какая-то его часть изменилась, и обо всё этом нам надо сообщить сразу за один раз. Это может быть полезно в случаях, когда на нашей странице есть спортивная статистика, которая обновляется в режиме реального времени, текстовый документ, который может редактировать несколько человек, какой-то новостной виджет или виджет с погодой.</p> <p>У <code>aria-busy=""</code> есть два значения — <code>false</code> и <code>true</code>.</p> <ul> <li><code>false</code> (значение по умолчанию) — при этом значении вспомогательные технологии не ждут, пока изменения завершаться.</li> <li><code>true</code> — это значение говорит вспомогательным технологиям, что им нужно подождать, пока элемент не закончит изменяться, после чего они могут собрать все изменения и сделать объявление. То есть во время обновления контента пользователи скринридеров, например, не смогут читать эту обновляющуюся часть.</li> </ul> <p>В примере ниже у нас есть спортивные результаты, которые регулярно обновляются в ходе соревнований:</p> <pre><code tabindex="0" class="language-html"><h2>Текущий счёт</h2> <p role="score" aria-live="polite" aria-busy="true">9:0</p> </code></pre> <p>Для того, чтобы вся информация объявлялась после всех изменений, сначала добавим атрибут <code>aria-busy</code> со значением <code>true</code>, а потом, с помощью JavaScript, заменим его значение на <code>false</code> или вообще его удалим, когда все изменения завершатся.</p> <h2>Краткие выводы</h2> <p>Если у вас на странице есть часть, содержимое которой изменяется, то нужно сделать её интерактивной областью. Тогда скринридеры смогут держать своих пользователей в курсе всех изменений. Сделать такую часть интерактивной можно с помощью <code>role="alert"</code>, <code>role="status"</code>, <code>role="log"</code>, <code>role="marquee"</code>, <code>role="timer"</code> и атрибута <code>aria-live</code>.</p> <p>Используйте <code>role="alert"</code> для важных ошибок, предупреждений. Для большей совместимости добавляйте её для нужных элементов вместе с атрибутом <code>aria-live="assertive"</code> и <code>aria-atomic="true"</code> (опционально).</p> <p><code>role="status"</code> подходит для сообщений о менее важных ошибках и предупреждениях. Например, сообщение об автосохранении, неправильно заполненном поле и тому подобное. Для совместимости следует сочетать эту роль с атрибутом <code>aria-live="polite"</code>.</p> <p>Если вам нужно сделать доступными историю сообщений, список ошибок и что-то, где важна последовательность обновления информации, используйте <code>role="log"</code>. Для большей совместимости используйте вместе с ней атрибут <code>aria-live="polite"</code>.</p> <p>Когда у вас на странице есть тикеры, курсы валют или любой другой элемент, информация в котором быстро изменяется, то задайте для них <code>role="marquee"</code>. Для совместимости дополните её <code>aria-live="off"</code>.</p> <p>Для таймера, счётчика или секундомера задавайте <code>role="timer"</code>. Не забудьте о <code>aria-live="off"</code> для лучшей совместимости.</p> <p>За то, насколько срочно нужно сообщить об изменениях, отвечает <code>aria-live=""</code>. Там, где об изменениях не нужно объявлять, используйте <code>aria-live="off"</code>. В большинстве случаев не нужно срочно сообщать об изменениях, поэтому в них пригодится <code>aria-live="polite"</code>. Иногда, когда речь идёт о важном сообщении, например, серверной ошибке, можно использовать <code>aria-live="assertive"</code>.</p> <p><code>aria-atomic=""</code> — необязательный атрибут. Он влияет на то, сообщит ли скринридер о контексте или объявит только об изменениях. По умолчанию всем элементам задан <code>aria-atomic="false"</code>, то есть скринридеры сообщают только об изменениях контента. Если заменить его на <code>aria-atomic="true"</code>, то скринридеры будут зачитывать всё целиком, включая неизменную часть. В большинстве случаев нет необходимости изменять поведение по умолчанию.</p> <p>Ещё один необязательный атрибут — <code>aria-relevant=""</code>. Он нужен для определения типа изменений контента. У него есть несколько значений, которые можно перечислять через пробел. Реальных сценариев использования мало (удаление или добавление друга в список друзей), а многие скринридеры его игнорируют.</p> <p>Последний необязательный атрибут — <code>aria-busy=""</code>. Сообщает вспомогательным технологиям обновляется ли сейчас содержимое элемента или нет. По умолчанию элементам задан <code>aria-busy="false"</code>. Скринридеры объявляют об изменениях не дожидаясь, пока они завершатся. В некоторых случаях можно использовать <code>aria-busy="true"</code>, когда нужно дождаться всех обновлений. Может быть полезно для спортивной статистики или текстового документа в режиме группового редактирования.</p> <h2>Что ещё можно почитать</h2> <ul> <li>Стандарт <a href="https://www.w3.org/TR/wai-aria-1.2/">WAI-ARIA 1.2</a>.</li> <li>Заметка <a href="https://developers.google.com/web/fundamentals/accessibility/semantics-aria/hiding-and-updating-content">Hiding and Updating Content</a> на Web Fundamentals.</li> <li>Несколько примеров использования ARIA-атрибутов в <a href="https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Live_Regions">ARIA Live Regions</a> на MDN.</li> <li><a href="https://medium.com/@rishabhsrao/aria-live-regions-6cc96e1a8b72">ARIA Live Regions</a> Ришабха Рао.</li> <li>Перевод статьи <a href="https://medium.com/high-technologies-center/%D0%BA%D0%B0%D0%BA-%D1%81%D0%B4%D0%B5%D0%BB%D0%B0%D1%82%D1%8C-%D1%81%D0%BE%D0%BE%D0%B1%D1%89%D0%B5%D0%BD%D0%B8%D1%8F-%D0%BE%D0%B1-%D0%BE%D1%88%D0%B8%D0%B1%D0%BA%D0%B0%D1%85-%D0%B4%D0%BE%D1%81%D1%82%D1%83%D0%BF%D0%BD%D1%8B%D0%BC%D0%B8-1400134a59cc">Как сделать сообщения об ошибках доступными</a> Хидде де Вриса.</li> </ul> </article> <article> <h1>Советы по доступности интерактивных элементов на мобильных устройствах</h1> <p>Thu, 21 Feb 2019 00:00:00 GMT</p> <p><a href="https://www.w3.org/TR/WCAG21/">Web Content Accessibility Guidelines</a> (WCAG) — это набор правил для создания доступных сайтов. Вторая версия была опубликована в 2008 году, еще перед тем, как стало возможно просматривать сайты на мобильных устройствах.</p> <p>Несколько лет назад WCAG был обновлён до версии 2.1, в которую был включен совершенно новый раздел <a href="https://www.w3.org/TR/mobile-accessibility-mapping/">с правилами доступности для мобильных устройств</a>. Среди них есть несколько правил, актуальных только для мобильных. Например, <a href="https://www.w3.org/TR/WCAG21/#orientation">правило 1.3.4</a>, которое гласит: контент не должен ограничивать свою читаемость и работоспособность только одной ориентацией экрана, такой, как книжная или альбомная, если только определённая ориентация не обоснована.</p> <p>В этой статье я расскажу о некоторых новых рекомендациях, касающихся интерактивных элементов на странице.</p> <h3>Располагайте интерактивные элементы там, где к ним легко получить доступ</h3> <p>Первое, что следует учитывать при разработке сайта под мобильные устройства — это размещение интерактивных или активных элементов. По сравнению с ограниченными способами взаимодействия с десктопными устройствами, мобильными девайсами мы можем пользоваться очень по-разному — одной рукой, двумя руками, только левой или только правой и т.д.</p> <p>Из-за подобного разнообразия способов взаимодействия рекомендуется создавать гибкие интерфейсы. Например, вы скорее всего подумаете, что расположить интерактивный элемент лучше всего в правом нижнем углу, поскольку большинство людей работают на мобильном правой рукой. И тем не менее это самое неудачное место на экране, если пользоваться мобильным левой рукой. Наилучшим решением в данной ситуации будет сделать элемент на всю ширину экрана.</p> <h2>Дайте понять, что с элементом можно взаимодействовать</h2> <p>Опять же, показать на тач-экранах что элемент интерактивен, может стать той ещё задачкой, по сравнению с десктопными устройствами. Без ховеров мы должны одним только внешним видом показать пользователю, что с элементом можно взаимодействовать.</p> <p>Лучший способ показать, что с элементом можно взаимодействовать — придерживаться негласного соглашения о том, как должны выглядеть подобные элементы. Например, <a href="https://bitsofco.de/tips-for-making-interactive-elements-accessible-on-mobile-devices/">ссылки</a> обычно подчёркнуты или имеют цвет, отличный от цвета текста на всей странице. А кнопки соцсетей обычно квадратной формы с закруглёнными краями.</p> <p>Мы также можем использовать расположение элементов, чтобы дать понять, что они доступны для какого-либо действия. Навигация, например, обычно располагается сверху. Для мобильных устройств также вполне допустимо расположить навигацию внизу окна.</p> <h2>Дайте инструкции к доступным кастомным жестам</h2> <p>Так же, как и в предыдущем случае, очень важно давать чёткие инструкции по кастомным жестам именно на устройствах с тач-экраном.</p> <p>Хорошим примером для этого служит жест «потянуть чтобы обновить». Если нет никаких признаков того, что этот жест доступен, пользователь никогда им не воспользуется. В мобильной версии Твиттера есть иконка, указывающая, что можно потянуть страницу для обновления ленты. Она появляется, когда пользователь скроллит страницу вверх.</p> <figure> <figcaption>При прокручивании вверх страницы профиля в мобильном Твиттере, появляется иконка «потянуть чтобы обновить»</figcaption> </figure> <h2>Обеспечьте разумные размер и положение интерактивной цели</h2> <p>На устройствах с тач-экраном курсором является палец пользователя. Конечно, из-за этого точность касания гораздо ниже, нежели при работе с мышкой. Следовательно, область, на которую может тапнуть пользователь, должна быть достаточно большой для пальцев разного размера.</p> <p>Согласно <a href="https://www.w3.org/TR/WCAG21/#target-size">правилу 2.5.5</a>, интерактивные элементы должны иметь размер не меньше чем 44×44 пикселя, за исключением случаев, когда цель встроена в блок текста.</p> <h2>Группируйте элементы, выполняющие одно и то же действие</h2> <p>Этот совет лучше всего проиллюстрировать следующим примером. Предположим, что у нас есть ссылка, ведущая на главную страницу сайта и, помимо этого, у нас также есть иконка домашней страницы. По различным причинам мы можем захотеть разделить эти два элемента и в итоге получим две ссылки, ведущие в одно и то же место.</p> <pre><code tabindex="0" class="language-html"> <a href="/"></a> <a href="/">Главная</a> </code></pre> <p>У этого метода два основных недостатка:</p> <ol> <li>Уменьшается размер области касания, поскольку промежуток между ссылками не будет активным.</li> <li>Увеличивается количество элементов, по которым придётся проходить пользователю при навигации с клавиатуры. Если перемещаться по странице при помощи таба, то подобное дублирование может утомить.</li> </ol> <p>Лучшим решением будет сгруппировать оба элемента в одну ссылку:</p> <pre><code tabindex="0" class="language-html"> <a href="/"> Главная </a> </code></pre> <p>Это не только увеличит область касания для ссылки, но и уменьшит количество ссылок, по которым придётся проходить при навигации с клавиатуры.</p> <h2>Упростите набор текста с помощью специальных раскладок клавиатуры</h2> <p>Одна из главных проблем устройств с тач-экранами — набор текста с экранной клавиатуры. Мы можем упростить этот момент, предоставляя специальные клавиатуры в зависимости от типа вводимых данных.</p> <p>Например, если нужно вводить цифры, то мы можем показать клавиатуру с цифрами, указав нужное значение атрибута <code>type</code> у элемента <code><input></code>.</p> <pre><code tabindex="0" class="language-html"><label> Сколько вам лет? <input type="number"> </label> </code></pre> <p>В некоторых случаях мы должны указать определённое значение атрибута <code>type</code> у элемента <code><input></code>, например, <code>text</code>, хотя всё ещё ожидаем от пользователя ввода цифр. В этой ситуации на помощь приходит атрибут <code>inputmode</code>, который позволяет указать, какую именно клавиатуру показать пользователю, вне зависимости от значения атрибута <code>type</code>.</p> <pre><code tabindex="0" class="language-html"><label> Сколько вам лет? <input type="text" inputmode="numeric"> </label> </code></pre> <p>На момент написания статьи атрибут <code>inputmode</code> <a href="https://caniuse.com/#feat=input-inputmode">имеет не очень хорошую поддержку</a>.</p> <h2>Предоставьте альтернативу набору текста</h2> <p>Ещё один способ решить проблему с набором текста на тач-устройствах — уменьшить количество ситуаций, в которых требуется ввод текста.</p> <p>Вообще, на мобильных устройствах проще работать с чекбоксами, радиокнопками и выпадающими списками, чем с полями для ввода текста.</p> <p>В тех местах, где требуется ввод текста, мы можем постараться автоматически заполнять поля. Например, подставляя текущую локацию в поле адреса.</p> </article> <article> <h1>Инклюзивные компоненты: список дел</h1> <p>Mon, 18 Feb 2019 00:00:00 GMT</p> <p>Следуя традициям, каждый новый JS-фреймворк проходит через несколько этапов создания простого приложения со списком дел — приложения для добавления и удаления позиций из списка. Первый пример, написанный на Angular.js, который я видел, был как раз таким списком. Добавление и удаление пунктов демонстрировало высокую скорость работы одностраничного приложения, реализованного на основе шаблона ViewModel.</p> <p>Инструмент <a href="http://todomvc.com/">TodoMVC</a> сравнивает и находит различия в разных реализациях приложений со списком дел в популярных MV*-фреймворках вроде Vue.js, Angular.js и Ember.js. Он помогает разработчику, который ищет технологию для нового проекта, принять правильное решение.</p> <p>Инклюзивный дизайн интерфейса такого списка, однако, отличается от его реализации во фреймворках. Вашего пользователя не волнует, написан он на Backbone или React. Ему просто нужен конечный продукт, который будет доступен и прост в использовании. К сожалению, реализации списков дел в <a href="http://todomvc.com/">TodoMVC</a> имеют недостатки. В частности, доступ к функции удаления появляется только при наведении курсора на пункт списка, что делает её полностью недоступной для клавиатуры.</p> <p>В этой статье я буду создавать список дел с нуля. Но то, что вы узнаете, можно использовать <em>не только</em> для подобных списков. На самом деле мы разберёмся, как сделать создание и удаление контента инклюзивным.</p> <p>В отличие от простого переключателя из <a href="https://medium.com/web-standards/toggle-buttons-a41388e80974">предыдущей статьи</a>, списки состоят из нескольких частей. Вот что мы собираемся сделать:</p> <h2>Заголовок</h2> <p>Лейблы — одна из важных составляющих юзабилити. Элемент <code><label></code> добавляет подписи к полям форм. Но простые текстовые фрагменты у кнопок и ссылок — это тоже лейблы. Они сообщают, что делают эти элементы, когда вы нажимаете на них.</p> <p>Заголовки — тоже лейблы, которые задают имена для разделов (регионов, участков, блоков), из которых состоит интерфейс. Не зависимо от того, создаёте ли вы статичный документ, такой как пост в блоге, или интерактивное одностраничное приложение, каждый крупный раздел контента этой страницы должен начинаться с заголовка. Наше название списка в этом примере — «Мой список дел». Он должен быть размечен соответственно.</p> <pre><code tabindex="0" class="language-html"><h1>Мой список дел</h1> </code></pre> <p>Это очень <em>прямолинейный</em> способ разделения интерфейса, но очевидность — это хорошо. Мы не хотим, чтобы нашим пользователям приходилось проводить целое расследование, чтобы понять, с чем они имеют дело.</p> <h3>Уровень заголовка</h3> <p>Выбор правильного уровня заголовков часто связан с вопросом важности, но, на самом деле, это вопрос <em>принадлежности.</em> Если список дел является единственным содержимым <code><main></code>, то для него стоит задать заголовок первого уровня, как в предыдущем примере. Его не окружают другие элементы, поэтому он на высшем уровне с точки зрения глубины.</p> <p>В случае, если список задач — дополнительный контент, то он должен иметь уровень, который это отражает. Например, если это страница о планах на отпуск, то список «Вещи, которые нужно собрать» может быть вспомогательным инструментом.</p> <ul> <li>Планы на моё путешествие (<code><h1></code>) <ul> <li>Места, где можно выпить (<code><h2></code>) <ul> <li>Бары (<code><h3></code>)</li> <li>Клубы (<code><h3></code>)</li> </ul> </li> <li>Вещи, которые нужно собрать (список дел) (<code><h2></code>)</li> </ul> </li> </ul> <p>В примере выше и «Бары», и «Клубы» входят в пункт «Места, где можно выпить». Он, в свою очередь, является подпунктом «Планы на моё путешествие». Это третий уровень принадлежности, следовательно, для них заданы заголовки <code><h3></code>.</p> <p>Даже если вам кажется, что список задач про сбор вещей менее важен, чем определение того, какие бары лучше посетить, он всё ещё находится на том же уровне с точки зрения принадлежности. Так что у него должен быть тот же уровень заголовка.</p> <p>Страница, структура которой образована логически вложенными разделами, имеет хорошую визуальную иерархию и помогает пользователям скринридеров составить чёткое представление о ней. Также они используют заголовки в качестве инструментов навигации. Например, в JAWS клавиша <kbd>2</kbd> переместит вас к следующему разделу, который начинается с заголовка <code><h2></code>. Клавиша <kbd>H</kbd> перемещает к следующему заголовку любого уровня.</p> <h3>Примечание: элемент <code><section></code></h3> <p>После всего этого разговора о секциях, мы должны использовать элементы <code><section></code>, верно? Может быть. Вот о чём нужно подумать:</p> <ol> <li>Элементы заголовков уже описывают секции. То есть контент, который начинается с заголовка и заканчивается непосредственно перед заголовком того же уровня, <em>де-факто</em> является секцией.</li> <li>Если вы используете элемент <code><section></code>, то для него всё ещё требуется задать заголовок, в противном случае это секция без описания.</li> </ol> <p>На практике значение, которое задаётся элементам <code><section></code>, ограничено, но всё же стоит отметить:</p> <ol> <li>Некоторые скринридеры будут объявлять начало и конец секции, когда пользователи перемещаются по странице от элемента к элементу.</li> <li>Некоторые скринридеры поддерживают навигацию по регионам. Например, в JAWS элементы <code><section></code> помечены как «regions» и между ними можно перемещаться с помощью клавиши <kbd>R</kbd> или сочетания <kbd>Shift R</kbd>.</li> <li>Эти теги могут улучшить организацию кода и сделать его более понятным. Они будут контейнером для секций страницы.</li> </ol> <p>Чтобы максимально эффективно использовать <code><section></code>, вы должны подписать их. То есть, связать их заголовки с элементами <code><section></code>, используя <code>aria-labelledby</code>:</p> <pre><code tabindex="0" class="language-html"><section aria-labelledby="todos-label"> <h1 id="todos-label">Мой список дел</h1>  </section> </code></pre> <p>Заметьте, что значение <code>aria-labelledby</code> должно полностью соответствовать значению <code>id</code> у заголовка.</p> <p>Фактически это добавляет групповую подпись к разделу. Подпись будет объявлена некоторыми скринридерами при фокусе на разделе. Если запустить NVDA, то, когда я окажусь в разделе и сделаю фокус на первом чекбоксе, то услышу: <em>«Регион мой список дел, список из трёх пунктов, забрать детей из школы, выбран».</em> Полезно давать такую информацию о контексте пользователям, которые перемещаются с помощью фокуса, а не по регионам или заголовкам.</p> <h2>Список</h2> <p>Я рассказал о достоинствах списков в книге <a href="https://shop.smashingmagazine.com/products/inclusive-design-patterns">«Inclusive Design Patterns»</a>. Вместе с заголовками, списки помогают придавать страницам структуру. Без заголовков или списков страницы пустые и однообразные. Это делает их сложными как для визуального восприятия, так и для любого другого.</p> <p>Не всем спискам нужны маркеры, за отображение которых отвечает свойство <code>list-style</code>. Однако у них должны быть видимые признаки того, что их пункты похожи, эквивалентны, а также связаны друг с другом. На уровне разметки использование контейнера с <code><ul></code> или <code><ol></code> означает, что список будет определён, когда его обнаружит скринридер, а число пунктов в нём будет сосчитано. Скринридер сообщит о нашем списке из трёх пунктов как-то так: <em>«Список из трёх пунктов».</em></p> <p>Список дел, как следует из названия — это список. В этом случае подходит неупорядоченный список, так как он не содержит никаких сведений о приоритетности пунктов. Вот разметка нашего списка задач (добавления, удаления и выбора чекбоксов пока нет):</p> <pre><code tabindex="0" class="language-html"><section aria-labelledby="todos-label"> <h1 id="todos-label">Мой список дел</h1> <ul> <li>Забрать детей из школы</li> <li>Выучить Haskell</li> <li>Поспать</li> </ul> </section> </code></pre> <h3>Пустое состояние</h3> <p>Пустые состояния — это один из аспектов UI-дизайна, который <a href="https://techcrunch.com/2015/11/22/the-most-overlooked-aspect-of-ux-design-could-be-the-most-important/">можно игнорировать, но на свой страх и риск</a>. Инклюзивный дизайн должен учитывать особенности стиля жизни пользователей. Новые пользователи — это одна из наиболее уязвимых групп. Им не знаком ваш интерфейс — если не вести таких пользователей осторожно за руку, эта неизвестность может их оттолкнуть.</p> <p>Благодаря нашему заголовку и кнопке <em>«Добавить»</em> некоторым пользователям может быть сразу понятно, что нужно делать, даже без примеров или инструкций. Но интерфейс может быть менее знакомым и более сложным, чем этот простой список дел, поэтому давайте всё равно добавим пустое состояние — для тренировки.</p> <h3>Отображение пустого состояния</h3> <p>Конечно, можно использовать наши данные, чтобы определить, должно ли быть показано пустое состояние. Во Vue.js мы можем использовать <code>v-if</code>:</p> <pre><code tabindex="0" class="language-html"><div class="empty-state" v-if="!todos.length"> <p> Либо вы уже выполнили все задачи, либо ещё есть что добавить в ваш список. Добавьте первый пункт ↓ </p> </div> </code></pre> <p>Но вся необходимая нам информация о состоянии уже находится в DOM. Поэтому всё, что нам нужно сделать для переключения между списком и пустым состоянием, можно сделать через CSS.</p> <pre><code tabindex="0" class="language-css">.empty-state, ul:empty { display: none; } ul:empty + .empty-state { display: block; } </code></pre> <p>Это целесообразнее, поскольку нам не нужно запрашивать данные или изменять разметку. Также это доступно для скринридеров. <code>display: none</code> означает, что элемент будет скрыт как визуально, так и от скринридеров.</p> <p>Все псевдоклассы относятся к неявным состояниям. Псевдокласс <code>:empty</code> означает, что у элемента пустое состояние. <code>:checked</code> значит, что элемент отмечен. <code>:first-child</code> означает, что он находится в начале набора. Чем больше вы их используете, тем меньше потребуется манипулировать DOM через JavaScript для добавления и изменения состояния.</p> <h2>Добавление задачи</h2> <p>До этого мы не обсуждали добавление задач, так что давайте сделаем это сейчас. Под списком (или пустым состоянием, если в нём ничего нет) расположены текстовое поле и кнопка «Добавить»:</p> <h3>Форма или нет?</h3> <p>В HTML допустимо использовать <code><input></code> вне <code><form></code>. Без помощи JavaScript нельзя успешно передать из <code><input></code> данные на сервер, но это не проблема для приложений, использующих XHR <em>(<code>XMLHttpRequest</code> — прим. переводчика).</em></p> <p>Но могут ли элементы с <code><form></code> дать что-то пользователям? Когда пользователи скринридеров JAWS или NVDA столкнутся с <code><form></code>, то автоматически включится специальный режим взаимодействия, который называют «режим форм» или «режим приложения». В этом режиме некоторые клавиши, которые могли бы использоваться в специальных сочетаниях, отключаются. Это позволяет пользователям скринридеров взаимодействовать с полями формы в полном объёме.</p> <p>К счастью, многие типы полей, включая <code>type="text"</code>, активируют режим форм самостоятельно при фокусе. Например, если я должен ввести «h» в какое-то поле, то «h» ввелась бы в него, а не переместила меня к ближайшему заголовку.</p> <p>Настоящая причина, по которой нам необходим тег <code><form></code> заключается в том, что мы хотим дать пользователям возможность отправлять данные при нажатии на клавишу <kbd>Enter</kbd>. Это надёжно работает только тогда, когда кнопка расположена внутри <code><form></code>. Этот тег нужен не только для организации кода или семантики, но влияет и на поведение браузера.</p> <pre><code tabindex="0" class="language-html"><form> <input type="text" placeholder="Например, взять сову"> <button type="submit">Добавить</button> </form> </code></pre> <p><em><strong>Примечание:</strong> <a href="https://twitter.com/LeonieWatson">Леони Уотсон</a> сообщает, что <code><input></code> с типом <code>range</code> не работают в связке Firefox + JAWS, когда они не вложены в <code><form></code> или режим форм не включён пользователем вручную.</em></p> <h3>Добавление подписи</h3> <p>Можете ли вы найти ошибку во фрагменте кода, которую я допустил специально? Ответ: я не добавил подпись. В коде есть только атрибуты <code>placeholder</code>, а они нужны для предоставления дополнительной информации. В данном случае это предложение «взять сову».</p> <p>Плейсхолдеры не очень хорошо подходят для скринридеров в качестве подписей, так что здесь нужен другой подход. Вопрос в том, должна ли эта подпись быть видимой или её стоит сделать доступной только для скринридеров.</p> <p><em>Почти</em> во всех случаях видимая подпись должна располагаться над полем или слева от него. Это связано с тем, что плейсхолдер исчезает при фокусе и может быть заменён текстом автозаполнения. Это означает, что зрячие пользователи потеряют подписи. Заполнение поля информацией или исправление текста автозаполнения превратятся в гадание на кофейной гуще.</p> <p>Однако, наш случай особый, потому что подписи «Добавить» для кнопки, расположенной рядом, вполне достаточно. Те, кто смотрит на форму, знают, для чего нужно поле благодаря одной кнопке.</p> <p><strong>У всех полей должны быть подписи</strong>, потому что пользователи скринридеров не могут заглянуть вперёд и увидеть, даёт ли кнопка отправки, до которой они ещё не дошли, подсказки о целях формы. В связке простые поле-кнопка, как в этом случае, и регионы поиска не нуждаются в <em>видимой</em> подписи. Это работает тогда, когда текст кнопки достаточно информативный.</p> <figure> <figcaption>Кроме того, убедитесь, что у форм с несколькими полями есть видимые подписи для каждого из них. Без этого пользователи не будут знать какое поле за что отвечает.</figcaption> </figure> <p>Есть несколько способов добавить невидимую подпись к полю для пользователей скринридеров. Один из самых простых и более лаконичных — <code>aria-label</code>. В примере ниже «Добавить новую задачу» — это значение. Оно более наглядно, чем просто «Добавить», и помогает отличить его от текста кнопки без путаницы при переключении между двумя элементами.</p> <pre><code tabindex="0" class="language-html"><form> <input type="text" aria-label="Добавить новую задачу" placeholder="Например, взять сову"> <button type="submit">Добавить</button> </form> </code></pre> <h3>Примечание: стилизация плейсхолдера</h3> <p>Обратите внимание на то, что в некоторых браузерах серый текст плейсхолдера очень бледный и не соответствует минимальным требованиям контраста <a href="https://www.w3.org/TR/WCAG20/#visual-audio-contrast">WCAG 1.4.3 Contrast (Minimum)</a>.</p> <p>Я рекомендую делать текст плейсхолдеров с кроссбраузерной поддержкой более контрастным. Также стоит использовать дополнительные стили, например, курсив как в примере ниже, чтобы отличать текст плейсхолдера от введённого пользователем текста.</p> <pre><code tabindex="0" class="language-css">::-webkit-input-placeholder { color: #444; font-style: italic; } ::-moz-placeholder { color: #444; font-style: italic; } :-ms-input-placeholder { color: #444; font-style: italic; } :-moz-placeholder { color: #444; font-style: italic; } </code></pre> <p>К сожалению, для этого нужны отдельные блоки правил, так как у каждого браузера есть проблемы с парсингом таких селекторов для других браузеров.</p> <h2>Представление поведения</h2> <p>Одно из преимуществ использования <code><form></code> с кнопкой типа <code>submit</code> заключается в том, что пользователи могут отправить данные, нажав на кнопку напрямую или с помощью клавиши <kbd>Enter</kbd>. Даже пользователи, которые не всегда используют клавиатуру для управления интерфейсом, могут нажать на <kbd>Enter</kbd>, потому что это быстрее. То, что делает взаимодействие возможным для некоторых, делает его лучше для других. Это инклюзивно.</p> <p>Если пользователь пытается отправить неверные данные, то нам нужно остановить его. Отключив кнопку пока поле заполнено неправильно, отправка по клику или нажатию на <kbd>Enter</kbd> будет запрещена. На самом деле на кнопке с <code>type="submit"</code> в этом случае нельзя сделать фокус с клавиатуры. Также мы добавляем к полю <code>aria-invalid="true"</code>. Скринридеры объявят пользователям, что поле заполнено неправильно и нужно изменить введённые данные.</p> <pre><code tabindex="0" class="language-html"><form> <input type="text" aria-invalid="true" aria-label="Создать новую задачу" placeholder="Например, взять сову"> <button type="submit" disabled>Добавить</button> </form> </code></pre> <h2>Обратная связь</h2> <p>Суть взаимодействия человека с компьютером состоит в том, что когда одна сторона что-то делает, то другая должна откликнуться в ответ. Это просто вежливо. Для большинства пользователей ответ компьютера при добавлении элемента не очевиден: они просто видят новый элемент, который появился на странице. Если есть возможность <em>анимировать</em> появление нового элемента, то лучше это сделать. Какое-то движение на странице при его возникновении с большей вероятностью заметят.</p> <p>В этом случае для незрячих пользователей или тех, кто не пользуется обычным интерфейсом, ничего не происходит. У них по-прежнему установлен фокус на поле, которое не содержит ничего нового, о чём может объявить скринридер. Тишина.</p> <p>Перемещая фокус на другую часть страницы, скажем, на новый пункт списка, этот элемент будет объявлен. Но мы не хотим перемещать фокус на другой элемент. Может пользователям нужно добавить больше задач. Вместо этого мы можем использовать интерактивную область (live region).</p> <h3>Обратная связь с интерактивной областью</h3> <p>Интерактивные области — это элементы, о содержимом которых скринридеры сообщат <em>при каждом его изменении.</em> С интерактивной областью мы можем сделать так, чтобы скринридеры общались с пользователями, не заставляя их выполнять какие-либо действия (например, перемещать фокус).</p> <p>Простые интерактивные области обозначаются с помощью атрибута <code>role="status"</code> или эквивалентного ему <code>aria-live="polite"</code>. Для максимальной совместимости с разными скринридерами стоит использовать оба атрибута. Это может показаться излишним, но благодаря этому у вас будет больше пользователей.</p> <pre><code tabindex="0" class="language-html"><div role="status" aria-live="polite">  </div> </code></pre> <p>Что касается события отправки формы, я могу просто добавить обратную связь в интерактивную область, о чём объявит скринридер.</p> <pre><code tabindex="0" class="language-js">var todoName = document.querySelector('[type="text"]').value; function addedFeedback(todoName) { let liveRegion = document.querySelector('[role="status"]'); liveRegion.textContent = `${todoName} added.`; } // Пример использования addedFeedback(todoName); </code></pre> <p>Самый простой способ сделать ваше веб-приложение более доступным — разместить сообщения о состоянии в интерактивной области. Тогда, когда оно обновится визуально, это также будут объявлено скринридерами.</p> <figure> <figcaption>Это общепринятый цвет для сообщения о состоянии. Например, сообщение об успешности действия зелёное. Но важно полагаться не только на цвет, чтобы не исключить дальтоников. Поэтому в примере есть дополнительная галочка.</figcaption> </figure> <p>Инклюзивность заключается в том, чтобы у всех пользователей был <strong>равноценный опыт</strong>, не обязательно одинаковый. Иногда то, что работает для одного пользователя, бессмысленно, избыточно или мешает другому.</p> <p>В этом случае сообщение о состоянии не нужно делать видимым, так как пункт виден при добавлении. На самом деле одновременное добавление пункта в список и показ сообщения о состоянии могут отвлечь внимание пользователей. Другими словами, видимое добавление элемента и объявление «[имя элемента] добавлено» уже эквивалентны.</p> <p>Так что мы можем скрыть такое сообщение с помощью класса <code>vh</code>.</p> <pre><code tabindex="0" class="language-html"><div role="status" aria-live="polite" class="vh">  </div> </code></pre> <p>Этот служебный класс использует магию и определяет, скрыты ли элементы. При этом они обнаруживаются и объявляются скринридерами. Вот как это выглядит:</p> <pre><code tabindex="0" class="language-css">.vh { position: absolute !important; clip: rect(1px, 1px, 1px, 1px); padding: 0 !important; border: 0 !important; height: 1px !important; width: 1px !important; overflow: hidden; } </code></pre> <h2>Отчекиваем задачи</h2> <p>В отличие от переключателя из <a href="https://medium.com/web-standards/toggle-buttons-a41388e80974">предыдущей статьи</a>, в этот раз чекбокс, с точки зрения семантики, правильный способ что-то активировать и наоборот. Вам не нужно <em>включать</em> или <em>отключать</em> задачи, нужно их <em>отметить.</em></p> <p>К счастью, чекбоксы позволяют легко это сделать прямо из коробки. Нам просто нужно помнить, что <code><label></code> нужен для каждого <code><input></code>. При переборе данных мы можем записать уникальные значения для каждой пары <code>for</code>-<code>id</code>, используя для связки текущий индекс и интерполяцию строк. Вот как это можно сделать с помощью Vue.js:</p> <pre><code tabindex="0" class="language-html"><ul> <li v-for="(todo, index) in todos"> <input type="checkbox" :id="`todo-${index}`" v-model="todo.done"> <label :for="`todo-${index}`">{{todo.name}}</label> </li> </ul> </code></pre> <p><em><strong>Примечание</strong>: в этом примере каждый пункт списка имеет значение <code>done</code>, следовательно, <code>v-model="todo.done"</code> автоматически отмечает чекбокс, когда он определяется как <code>true</code>.</em></p> <h3>Стиль для зачёркивания</h3> <p>Создание надёжных и доступных компонентов просто, когда вы используете семантические элементы по назначению. В моём варианте я просто добавил незначительное улучшение — свойство <code>line-through</code> для выбранных пунктов. Оно применяется к <code><label></code> с помощью <code>:checked</code> при использовании смежного селектора.</p> <pre><code tabindex="0" class="language-css">:checked + label { text-decoration: line-through; } </code></pre> <p>Ещё раз, я использую неявное состояние, чтобы повлиять на стиль. Не нужно добавлять и убирать <code>class="crossed-out"</code> или делать что-то подобное.</p> <p><em><strong>Примечание</strong>: если вы хотите стилизовать чекбоксы сами, то посмотрите <a href="http://wtfforms.com/">WTF Forms</a>. Там есть советы о том, как это сделать без кастомных элементов. В конце этой статьи вы найдёте <a href="https://codepen.io/heydon/pen/VpVNKW">демо</a>, в котором я использую класс <code>.tick</code> для <code><span></code>, чтобы сделать что-то похожее.</em></p> <h2>Удаление задач</h2> <p>Отчекивание и удаление задач — это разные действия. Иногда вам нужно видеть, какие из них вы сделали, иногда вы добавляете не тот пункт в список или он вообще становится ненужным.</p> <p>Удаление задачи можно осуществить с помощью простой кнопки. Для этого не требуется какой-то информации о состоянии: подпись описывает всё, что нам нужно знать. Конечно, если кнопка содержит иконку или глиф вместо текста, то нужно использовать дополнительную подпись.</p> <pre><code tabindex="0" class="language-html"><button aria-label="Удалить"> × </button> </code></pre> <p>На самом деле, давайте будем более конкретными и включим имя элемента с текстом задачи. Всегда лучше добавлять подписи, которые имеют смысл при отдельном рассмотрении элементов. Эта уникальная подпись поможет отличить его от других. В вашем JS-фреймворке должны быть шаблонные решения для этого. В моём случае во Vue.js это выглядит так:</p> <pre><code tabindex="0" class="language-html"><button :aria-label="`Удалить ${todo.name}`"> × </button> </code></pre> <p>В этом примере специальный символ <code>×</code> используется для добавления символа с крестиком. Если бы не <code>aria-label</code>, которая переопределяет значение, подпись была бы объявлена как «умножить».</p> <p>Всегда следите за тем, как скринридеры интерпретируют специальные символы и символы Юникода. А в примере ниже символ будет объявлен как «стрелка вниз» или что-то вроде этого. Так как в нашем случае текстовое поле всегда находится под списком как визуально, так и в HTML-коде, стрелка приводит пользователя к нему.</p> <p>Здесь значок с мусорной корзиной добавлен с помощью SVG. Это отличный формат графики, потому что он масштабируется без потери качества. Многим пользователям часто нужно изменять масштаб интерфейсов, в том числе тем, у кого близорукость, проблемы с двигательным аппаратом и кому нужна большая область касания или клика.</p> <pre><code tabindex="0" class="language-html"><button aria-label="удалить"> <svg> <use xlink:href="#bin-icon"></use> </svg> </button> </code></pre> <p>Чтобы уменьшить количество кода при повторном использовании одного и того же SVG, мы используем элемент <code><use></code>. Он ссылается на экземпляр SVG, определённой как <code><symbol></code> в <code><body></code>:</p> <pre><code tabindex="0" class="language-html"><body> <svg style="display: none"> <symbol id="bin-icon" viewBox="0 0 20 20"> <path d="[здесь координаты]"> </symbol> </svg> </body> </code></pre> <p>Раздутый DOM может ухудшить взаимодействие с интерфейсом для многих пользователей, так как действия займут больше времени. Пользователи вспомогательных технологий, в частности, могут столкнуться с тем, что их программное обеспечение не отвечает.</p> <h3>Примечание: инклюзивные иконки</h3> <p>Повышение <a href="http://uxmyths.com/post/715009009/myth-icons-enhance-usability">удобства использования интерфейсов благодаря иконкам — спорный вопрос</a>. Конечно, в сочетании с текстом, они могут помочь лучше что-то понять. Особенно это касается тех пользователей, у которых низкий уровень грамотности или тех, кто знакомится с интерфейсом на другом языке. Однако любые иконки без дополнительного текста могут быть неправильно интерпретированы.</p> <p>Иконка с мусорной корзиной на самом деле нужна для <em>удаления</em>? Могу я сделать иконку получше, которая будет выглядеть больше похожей на мусорное ведро? Я могу попытаться сделать что-то другое, например, использовать иконку с крестиком (как это сделано в реализациях на TodoMVC), но не выглядит ли она больше похожей на иконку для <em>завершения</em> действия? Тут нет простых ответов, поэтому лучшее, что вы можете сделать — тестировать это на реальных пользователях.</p> <p>К счастью, случайное удаление пункта списка не такая критичная ошибка. Пользователи могут без проблем понять, что означает иконка методом проб и ошибок. Там, где удаление <em>критично</em>, поможет диалоговое окно подтверждения, которое всё объясняет и при этом в нём можно завершить действие.</p> <h3>Управление фокусом</h3> <p>Когда пользователь кликает по кнопке удаления пункта списка, задача, включая чекбокс, подпись и <strong>сама кнопка</strong>, будут удалены из DOM. Это приводит к возникновению интересной проблемы: что произойдёт с фокусом, когда вы удаляете элемент, на котором сейчас сделан фокус?</p> <p>Если вы не будете соблюдать осторожность, то решение этой проблемы будет <em>сильно раздражать</em> пользователей клавиатуры, в том числе пользователей скринридеров.</p> <p>На самом деле браузеры не знают, где сделать фокус, когда он был удалён таким образом. Некоторые добавляют «призрачный» фокус там, где раньше был удалённый элемент, а другие делают фокус на следующем элементе. Некоторые по умолчанию делают фокус на внешнем документе. Это означает, что пользователям клавиатуры придётся снова проходить через весь DOM, чтобы попасть обратно в место удалённого элемента.</p> <p>Для того, чтобы взаимодействие разных пользователей с интерфейсом было консистентным, мы должны всё тщательно обдумать и использовать <code>focus()</code> для соответствующего элемента, но какого именно?</p> <p>Один из вариантов — сделать фокус на первом чекбоксе списка. При этом будут объявлены не только его имя и состояние, но и общее количество оставшихся элементов списка. Их количество будет на один пункт меньше, чем раньше. Это всё полезный контекст.</p> <pre><code tabindex="0" class="language-js">document.querySelector('ul input').focus(); </code></pre> <p>Примечание: <code>querySelector</code> возвращает <em>первый</em> элемент, соответствующий селектору. В нашем случае это первый чекбокс в списке задач.</p> <p>Но что, если мы просто удалили последний пункт нашего списка и вернулись к пустому состоянию? Здесь нет чекбокса, на котором можно сделать фокус. Давайте попробуем что-нибудь другое. Вместо всего этого я хочу сделать две вещи:</p> <ol> <li>Сделать фокус на заголовке области «Мой список дел».</li> <li>Использовать уже добавленную интерактивную область для обратной связи.</li> </ol> <p>Вы никогда не должны делать неинтерактивные элементы вроде заголовков фокусируемыми, потому что в этом случае предполагается, что они должны что-то <em>делать.</em> Когда я тестирую интерфейс и в нём есть подобные элементы, то я не смогу привести его в соответствие с требованием <a href="https://www.w3.org/TR/WCAG20/#navigation-mechanisms">WCAG 2.4.3 Focus Order</a>.</p> <p>Однако иногда вам нужно привести пользователя к определённой части страницы с помощью скрипта. Чтобы переместить пользователя к заголовку и объявить его, нужно сделать две вещи:</p> <ol> <li>Добавить к заголовку атрибут <code>tabindex="-1"</code>.</li> <li>Сделать фокус при помощи метода <code>focus()</code>.</li> </ol> <pre><code tabindex="0" class="language-html"><h1 tabindex="-1">Мой список дел</h1> </code></pre> <p>Значение <code>-1</code> выполняет сразу несколько задач: оно делает элементы не сфокусированными для пользователей (включая те элементы, на которых можно сделать фокус). При этом оно позволяет устанавливать фокус на элементах с помощью JavaScript. Таким образом мы можем переместить пользователя к неинтерактивному элементу и не сделать его «остановкой табуляции» (элементом, к которому можно перемещаться с помощью <kbd>Tab</kbd>).</p> <p>Кроме того, при установлении фокуса на заголовке будут объявлены его текст, роль, уровень и информация о контексте, такая как «region» (некоторыми скринридерами). По крайней мере, вы должны услышать: <em>«Мой список дел, заголовок второго уровня».</em> Поскольку он в фокусе, нажатие на клавишу <kbd>Tab</kbd> вернёт пользователя обратно в список к первому чекбоксу. По сути, мы сообщаем: <em>«Теперь, когда вы удалили этот элемент из списка, вот снова весь список».</em></p> <p>Обычно я не добавляю стили фокуса для элементов, на которых можно сфокусироваться таким образом. В этом случае я использую этот метод из-за того, что целевой элемент не является интерактивным и не должен таким быть.</p> <pre><code tabindex="0" class="language-css">[tabindex="-1"] { outline: none } </code></pre> <p>После того, как элемент с фокусом был удалён (и вместе с ним его стиль фокуса), фокус перемещается на заголовок. Пользователь клавиатуры может затем нажать на <kbd>Tab</kbd>, чтобы найти первый чекбокс или, если не осталось элементов, перейти к текстовому полю в нижней части этого компонента.</p> <h3>Обратная связь</h3> <p>Возможно, мы дали достаточно информации пользователю и он в идеальном положении для продолжения взаимодействия с интерфейсом. Но всегда лучше быть максимально точным. Поскольку у нас уже есть интерактивная область, почему бы не использовать её для сообщения о том, элемент был успешно удалён?</p> <pre><code tabindex="0" class="language-js">function deletedFeedback(todoName) { let liveRegion = document.querySelector('[role="status"]'); liveRegion.textContent = `${todoName} удалено.`; } // Пример использования deletedFeedback(todoName); </code></pre> <p>Я понимаю, что вы, вероятно, не написали бы это на ванильном JavaScript. Это просто примерный вариант того, как это будет работать.</p> <p>Сейчас, потому что мы используем <code>role="status"</code> (<code>aria-live="polite"</code>), со скринридерами происходит кое-что интересное. Сначала объявляется <em>«Мой список дел, заголовок второго уровня»</em>, а потом <em>«[название задачи] удалено».</em></p> <p>Это происходит из-за того, что при значении <code>polite</code> интерактивные области ждут, пока пользователь не остановится, прежде чем сделать объявление. Если бы я использовал <code>role="alert"</code> (<code>aria-live="assertive"</code>), то сообщение о состоянии полностью или частично переопределило бы объявление заголовка с фокусом. В нашем случае пользователь знает и где он находится, и что его действие оказалось успешным.</p> <h2>Рабочее демо</h2> <p>Я создал <a href="https://codepen.io/heydon/pen/VpVNKW/">страницу на СodePen</a>, чтобы наглядно продемонстрировать технику из этой статьи. В демке используется Vue.js, но это можно реализовать с помощью любого JS-фреймворка. Её можно протестировать в разных браузерах и скринридерах.</p> <h2>Заключение</h2> <p>При создании инклюзивного компонента со списком дел нужно учесть довольно много моментов: семантическую структуру, добавление подписей, иконки, работу с фокусом и обратную связь. Если это делает инклюзивный дизайн сложным для вас, то учтите следующее:</p> <ol> <li>Это новая информация. Не волнуйтесь, скоро это войдёт в привычку.</li> <li>Всё, что вы узнали здесь, можно применить ко многим компонентам и его контенту.</li> <li>Вам нужно только один раз создать такой компонент. Тогда он будет длительное время находиться в вашей библиотеке компонентов и его можно постоянно использовать.</li> </ol> <h2>Чеклист</h2> <ul> <li>Задайте для каждого крупного компонента, такого как список, понятный заголовок.</li> <li>Добавляйте подписи к полям «только для скринридеров» только тогда, когда есть видимые подписи. Плейсхолдеры не в счёт.</li> <li>Когда вы исключаете элемент с фокусом из DOM, сделайте фокус на соответствующем соседнем элементе с помощью метода <code>focus()</code>.</li> <li>Внимательно отнеситесь к описаниям в пустых состояниях. Они знакомят новых пользователей с вашим интерфейсом.</li> </ul> </article> <article> <h1>Новые логические свойства в CSS!</h1> <p>Wed, 06 Feb 2019 00:00:00 GMT</p> <p>Следующий шаг в эволюции CSS</p> <h2>Интро</h2> <p>Большинство из нас, разработчиков, мыслят терминами право-лево и верх-низ. Всё потому что изначально интернет предназначался главным образом для загрузки документов, а не для сайтов со сложной структурой, которые мы создаём теперь. Потому никто в тот момент не учитывал потребностей многоязычных сайтов.</p> <p>До недавнего времени переменные в Sass были лучшим способом поддержки сайтов с языками, пишущимися в разные стороны (RTL и LTR). Если вы хотите узнать больше, то почитайте мою статью «<a href="https://medium.com/@elad/the-best-way-to-rtl-your-website-with-sass-105e34a4298a">The Best Way to RTL Websites with Sass!</a>»</p> <p>Новые логические свойства дают нам гораздо больше возможностей управлять нашими сайтами, независимо от того, на каком они языке (английский, арабский, японский или другие), с минимальными изменениями стилей.</p> <p>Самое время начать!</p> <h2>Мыслить логическими CSS-свойствами</h2> <p>Мы привыкли видеть что-то подобное, когда обсуждаем блочную модель:</p> <p>Раньше так было правильно, и есть до сих пор, но подходят последние деньки классических физических свойств типа <code>margin-left</code>, <code>padding-right</code>, <code>border-top</code> и других.</p> <p>Прежде чем начать использовать новые логические свойства, вам нужно перестать думать терминами право-лево, верх-низ, и заменить из на <code>inline-start</code>, <code>inline-end</code> и <code>block-start</code>, <code>block-end</code>.</p> <h3>Строчная ось</h3> <p>Давайте для примера возьмём английский язык. Направление чтения начинается слева и идёт направо. Это строчный аспект свойств. Это можно легко запомнить, рассмотрев ряд элементов с <code>display: inline</code>. Каждый элемент отображается в строку.</p> <p>Например, <code>padding-inline-start</code> задаст отступ с той стороны, где начинается контент на текущем языке:</p> <ul> <li>Английский: <code>padding-inline-start</code> = <code>padding-left</code></li> <li>Арабский: <code>padding-inline-start</code> = <code>padding-right</code></li> <li>Японский: <code>padding-inline-start</code> = <code>padding-top</code></li> </ul> <h3>Блочная ось</h3> <p>При замене верхних и нижних связанных свойств легко вспоминать, что верх находится в начале нашего сайта, а низ — в конце. Просто представьте несколько элементов с <code>display: block</code>, которые расположены друг над другом.</p> <p>Возможно, вы всё ещё спрашиваете себя, а разве это не всегда так?!</p> <p>Ответ чуточку сложнее. В настоящее время все сайты на любых языках работают именно таким образом. Просто потому что до сих пор не было других доступных методов.</p> <p>Сайты на японском языке и некоторых других восточных языках идут справа налево, а не сверху вниз! Чтобы понять, каково это, представьте, что вы повернули экран на 90° вправо. Сайт приходится листать не по вертикали, а по горизонтали!</p> <p>Пример блочных свойства:</p> <ul> <li>Английский и арабский: <code>padding-block-start</code> = <code>padding-top</code></li> <li>Японский: <code>padding-block-start</code> = <code>padding-right</code></li> </ul> <h2>Новые свойства блочной модели</h2> <p><code>margin</code>, <code>padding</code> и <code>border</code></p> <p>После того, как вы разобрались со строчной и блочной осями, вы можете использовать их по прямому назначению.</p> <p>Пример для английского:</p> <h3>margin</h3> <ul> <li><code>margin-block-start</code> = <code>margin-top</code></li> <li><code>margin-block-end</code> = <code>margin-bottom</code></li> <li><code>margin-inline-start</code> = <code>margin-left</code></li> <li><code>margin-inline-end</code> = <code>margin-right</code></li> </ul> <h3>padding</h3> <ul> <li><code>padding-block-start</code> = <code>padding-top</code></li> <li><code>padding-block-end</code> = <code>padding-bottom</code></li> <li><code>padding-inline-start</code> = <code>padding-left</code></li> <li><code>padding-inline-end</code> = <code>padding-right</code></li> </ul> <h3>border</h3> <ul> <li><code>border-block-start</code> = <code>border-top</code></li> <li><code>border-block-end</code> = <code>border-bottom</code></li> <li><code>border-inline-start</code> = <code>border-left</code></li> <li><code>border-inline-end</code> = <code>border-right</code></li> </ul> <h2>Логическая величина</h2> <p><code>width</code> и <code>height</code> заменяются на <code>inline-size</code> и <code>block-size</code></p> <p>Свойства <code>height</code> и <code>width</code> также должны соответствовать этой новой методологии. Как только мы свыкнемся с методологией строка-блок, станет легче разобраться с размерами. Для английского языка свойство <code>width</code> следует заменить на <code>inline-size</code>, а свойство <code>height</code> — на <code>block-size</code>.</p> <p>Пример строчного и блочного размеров: Для английского и арабского (LTR и RTL)</p> <ul> <li><code>width</code> = <code>inline-size</code></li> <li><code>height</code> = <code>block-size</code></li> </ul> <p>В языках, идущих сверху вниз, например, японском, мы столкнёмся с противоположным:</p> <ul> <li><code>inline-size</code> = <code>height</code></li> <li><code>block-size</code> = <code>width</code></li> </ul> <p>Для минимальных и максимальных свойств просто добавьте <code>min</code> или <code>max</code> в начале. К примеру:</p> <ul> <li><code>min-inline-size: 300px</code></li> <li><code>max-block-size: 100px</code></li> </ul> <h3>Позиционирование в CSS</h3> <p>Свойства, которые мы раньше использовали для позиционирования, <code>top</code>, <code>bottom</code>, <code>left</code>, <code>right</code>, превратились в новые свойства с префиксом <code>inset: inset-block-start</code>, <code>inset-block-end</code>, <code>inset-inline-start</code>, <code>inset-inline-end</code>.</p> <p>Для английского (LTR):</p> <ul> <li><code>top</code> = <code>inset-block-start</code></li> <li><code>bottom</code> = <code>inset-block-end</code></li> <li><code>left</code> = <code>inset-inline-start</code></li> <li><code>right</code> = <code>inset-inline-end</code></li> </ul> <pre><code tabindex="0" class="language-css">/* Старая техника */ .popup { position: fixed; top: 0; bottom: 0; left: 0; right: 0; } /* Новая техника */ .popup { position: fixed; inset-block-start: 0; /* top — для английского */ inset-block-end: 0; /* bottom — для английского */ inset-inline-start: 0; /* left — для английского */ inset-inline-end: 0; /* right — для английского */ } </code></pre> <p>Бросив беглый взгляд, вы можете задаться вопросом, какого чёрта я должен использовать такие сложные имена?! Но на то есть веская причина. Новые имена свойств можно комбинировать в шорткаты, подобно текущим <code>padding</code>, <code>margin</code>, <code>border</code>.</p> <p>Пример:</p> <pre><code tabindex="0" class="language-css">.popup { position: fixed; inset: 0 0 0 0; /* top, right, bottom, left — для английского */ } </code></pre> <h3>Обтекание в CSS</h3> <p>Обтекание довольно простое, есть всего два значения, <code>inline-start</code> и <code>inline-end</code>, которые заменяют собой <code>left</code> и <code>right</code>.</p> <p>Для английского (LTR):</p> <ul> <li><code>float: left</code> = <code>float: inline-start</code></li> <li><code>float: right</code> = <code>float: inline-end</code></li> </ul> <h3>Text-align</h3> <p>Это свойство даже проще, чем обтекание, значения <code>left</code> и <code>right</code> заменяются на <code>start</code> и <code>end</code>.</p> <p>Для английского (LTR):</p> <ul> <li><code>text-align: left</code> = <code>text-align: start</code></li> <li><code>text-align: right</code> = <code>text-align: end</code></li> </ul> <h3>Ещё</h3> <p>Свойство resize: используется в основном для <code><textarea></code>. Его значения изменятся с <code>horizontal</code> и <code>vertical</code> на <code>inline</code> и <code>block</code>.</p> <p>Для английского (LTR):</p> <ul> <li><code>resize: horizontal</code> = <code>resize: inline</code></li> <li><code>resize: vertical</code> = <code>resize: block</code></li> </ul> <p>У свойства <code>background-position</code> пока нет реализации ни в одном из браузеров, но если копнуть поглубже, то можно найти отсылки к <code>background-position-inline</code> и <code>background-position-block</code> на <a href="https://developer.mozilla.org/en-US/">MDN</a>. Ещё нет нормальной документации, но они работают над этим! :)</p> <p>Прочее: уже сейчас можно предположить, что свойства типа <code>transform-origin</code> тоже будут обновлены, как и любые другие свойства, имеющие отношение к направлению.</p> <h3>Гриды и флексбоксы</h3> <p>Хорошая новость в том, что гриды и флексбоксы уже построены на новых логических свойствах и нет нужды их обновлять.</p> <h3>Рабочий процесс с учётом логических свойств</h3> <p>На первый взгляд это выглядит очень сложно. Но в работе всё просто. При написании стилей не нужно беспокоится о поддержке нескольких языков. Вы просто используете логические свойства взамен старых физических свойств.</p> <h2>Применение выравнивания в зависимости от языка</h2> <p>После того, как мы рассмотрели все обновлённые логические свойства, вот вам ещё два, которые позволят определить <strong>выравнивание блочной оси</strong> (поток сайта) и <strong>выравнивание строчной оси</strong> (направление чтения текста).</p> <h3>Свойство <code>writing-mode</code> (блочная ось)</h3> <p>Определились с потоком сайта. В большинстве случаев он будет идти сверху вниз, но, как уже упоминалось, для некоторых языков он может идти справа налево (японский) или даже слева направо (монгольский). В обоих случаях у нас будет горизонтальная прокрутка, а не вертикальная, как мы привыкли.</p> <p>Примечание: на данный момент есть три основных значения для <code>writing-mode</code>. Их имена могут сбить с толку. Всё потому, что в них есть направление блочной оси плюс выравнивание текста (строчная ось). Это вгоняет в тоску, выравнивание текста тут явно избыточно и только вызывает путаницу.</p> <p>Чтобы избежать этой путаницы, я рекомендую игнорировать часть значения со строчной осью и обращать внимание только на часть значения для блочной оси.</p> <h3>Примеры</h3> <p>Значения:</p> <ul> <li><code>writing-mode: horizontal-tb</code> — сверху вниз, как для английского (значение по умолчанию).</li> <li><code>writing-mode: vertical-rl</code> — справа налево, для японского.</li> <li><code>writing-mode: vertical-lr</code> — слева направо, для монгольского.</li> </ul> <p>Моё личное мнение — в значениях нужно оставить только <code>tb</code>, <code>rl</code>, <code>lr</code> (часть для блочной оси), чтобы устранить потенциальную путаницу.</p> <p>Пример для японского:</p> <pre><code tabindex="0" class="language-css">html { writing-mode: vertical-rl; } </code></pre> <h3>Свойство <code>direction</code> (строчная ось)</h3> <p>Определяет, откуда должен начинаться текст: слева направо или справа налево, но только в случае, если задано значение по умолчанию для свойства <code>writing-mode</code>. Если мы поменяем значение <code>writing-mode</code> на один из вертикальных режимов, то фактическое направление написания изменится с положения слева направо и будет идти сверху вниз. Или наоборот, при значении с <code>rtl</code> (справа налево), оно изменится на сверху вниз.</p> <p>Пример направления для арабского:</p> <pre><code tabindex="0" class="language-css">html { direction: rtl; } </code></pre> <p>Даже удивительно, на сколько просто сайт, идущий сверху вниз, можно преобразовать в идущий справа налево с горизонтальной прокруткой.</p> <p>Я сделал небольшое демо. Его лучше смотреть в Firefox, в текущий момент именно в нём поддерживается наибольшее количество свойств.</p> <p><a href="https://codepen.io/elad2412/pen/oQJmYQ/">Демо</a> (попробуйте поменять язык):</p> <h2>Браузерная поддержка</h2> <ul> <li>Все свойства блочной модели <code>margin</code>, <code>padding</code>, <code>border</code> и новые свойства ширины и высоты (<code>inline-size</code>, <code>block-size</code>) уже работают во всех основных браузерах, кроме Edge.</li> <li>Новые значения для <code>text-align</code> также работают везде, кроме Edge.</li> <li>Свойства и значения для <code>float</code>, <code>position</code>, <code>resize</code> работают пока только в Firefox.</li> </ul> <h2>Проблемы с логическими свойствами</h2> <p>Со всеми этими новыми доработками мы столкнёмся с новыми для нас проблемами. Например, что если мы захотим записать все значения свойства в сокращённом виде: <code>margin: 10px 20px 8px 5px</code>? В таком случае мы не сможем предсказать, как это будет проинтерпретировано браузером. Если сайт построен на физических свойствах, то значения будут расшифрованы следующим образом: <code>margin-top</code>, <code>margin-right</code>, <code>margin-bottom</code>, <code>margin-left</code>. Но если сайт построен на новых логических свойствах, то значения будут расшифрованы так: <code>margin-block-start</code>, <code>margin-inline-end</code>, <code>margin-block-end</code>, <code>margin-inline-start</code>.</p> <p>На сайтах, написанных под английский (или русский) языки, физические и логические свойства будут работать одинаково. Для сайтов на других языках значения сокращений, как в примере с <code>margin</code>, должны работать в соответствии со значением свойства <code>direction</code> или <code>writing-mode</code>.</p> <p>Это вопрос всё ещё открыт. Я внёс предложение, которое <a href="https://github.com/w3c/csswg-drafts/issues/1282#issuecomment-443253091">может решить эту проблему</a>. Если у вас есть решение получше, то вы можете оставить комментарий в этой ветке!</p> <p>В данный момент, если вы хотите использовать логические единицы, вам следует отказаться от шорткатов в пользу полных названий свойств.</p> <p>Предложенное мною решение:</p> <pre><code tabindex="0" class="language-css">html { flow-mode: physical; /* или */ flow-mode: logical; } .box { /* будет интерпретироваться согласно значению flow-mode** ***/ margin: 10px 5px 6px 3px; padding: 5px 10px 2px 7px; } </code></pre> <h3>Проблемы с адаптивным дизайном</h3> <p>Пока пытался создать рабочее демо, я попробовал использовать новое свойство максимальной ширины <code>max-inline-size</code> внутри медиавыражения, предполагая, что для языков «справа налево» и «слева направо» оно будет вести себя как <code>max-width</code>, а для языков вроде японского — как <code>max-height</code>. К сожалению, браузеры пока отказываются понимать это свойство внутри медиавыражений.</p> <pre><code tabindex="0" class="language-css">/* Не работает */ @media (max-inline-size: 1000px) { .main-content { background: red; grid-template-columns: auto; } } </code></pre> <h3>Изменения, которые нужно учесть</h3> <p>Во время написания этого поста, уже после глубокого изучения и понимания концепции логических свойств, я заметил несколько упущенных моментов, которые следует поправить в будущем:</p> <ul> <li><code>line-height</code> заменить на <code>line-size</code></li> <li><code>border-width</code> заменить на <code>border-size</code></li> </ul> <p>Но, похоже, пока не стоит этого ждать, по крайней мере в отношении <code>border-width</code>. Это свойство обновили буквально только что и в его названии по прежнему присутствует <code>width</code>. Пример: <code>border-block-start-width</code>.</p> <p>Но кто знает, может этот пост попадётся на глаза правильным людям из W3C :)</p> <h2>Резюмируя</h2> <p>Вот и всё. Я надеюсь, что вам понравилась эта статья и вы узнали что-то новое. Я буду признателен, если вы поаплодируете или поделитесь этим постом :)</p> <h3>Больше постов по типографике</h3> <ul> <li><a href="https://24ways.org/2016/css-writing-modes/">CSS Writing Modes</a> — крайне рекомендую!</li> <li><a href="https://tympanus.net/codrops/css_reference/text-orientation/">Text Orientations</a></li> </ul> <h3>Другие мои посты о CSS</h3> <ul> <li><a href="https://medium.com/@elad/the-best-way-to-rtl-your-website-with-sass-105e34a4298a">The Best Way to RTL Websites with Sass!</a></li> <li><a href="https://medium.com/@elad/css-architecture-for-multiple-websites-with-sass-7e923fc53f7a">CSS Architecture for Multiple Websites With Sass</a></li> <li><a href="https://medium.com/@elad/becoming-a-css-grid-ninja-f4c6db018cc1">Becoming a CSS Grid Ninja!</a></li> <li><a href="https://medium.com/@elad/the-new-responsive-design-evolution-2bfb9b504a4e">The New Responsive Design Evolution</a></li> <li><a href="https://medium.com/web-standards/sticky-bc7ff7088693">Как на самом деле работает position: sticky в CSS</a></li> </ul> </article> <article> <h1>Как быстро создать десктопное приложение на HTML, CSS и JavaScript</h1> <p>Wed, 06 Feb 2019 00:00:00 GMT</p> <figure> <figcaption> Фотография <a href="https://unsplash.com/@robinpierre">Робина Пьерра</a> </figcaption> </figure> <p>Можно ли использовать HTML, CSS и JavaScript для создания десктопных приложений?</p> <p>Ответ — да 😄</p> <p>В этой статье мы сосредоточимся в основном на том, как Electron можно использовать для создания десктопных приложений с использованием веб-технологий.</p> <h2>Electron</h2> <p><a href="https://electronjs.org/">Electron</a> может быть использован для создания десктопных приложений, также эти приложения будут мультиплатформенными — Windows, Mac, Linux и другие.</p> <p>Electron объединяет Chromium и Node.js в одну среду исполнения. Это позволяет нам запускать код HTML, CSS и JavaScript в виде десктопного приложения.</p> <h2>Electron Forge</h2> <p>Если Electron используется напрямую, то перед сборкой приложения потребуется определённая ручная настройка. Также, если вы хотите использовать Angular, React, Vue или любой другой фреймворк или библиотеку, вам нужна будет ручная настройка.</p> <p><a href="https://electronforge.io/">Electron Forge</a> значительно упрощает все вышеперечисленное.</p> <p>Он предоставляет шаблонные приложения с Angular, React, Vue и другими фреймворками, что позволяет избежать дополнительных танцев с бубном.</p> <p>Также он обеспечивает простоту сборки и упаковки приложения. В нём есть множество других функций, которые можно найти в <a href="https://docs.electronforge.io/">документации</a>.</p> <h2>Предварительная подготовка</h2> <p>Убедитесь, что у вас установлен Node.js. Если нет, то его можно скачать <a href="https://nodejs.org/en/">отсюда</a>. Установите Electron Forge глобально, используя следующую команду:</p> <pre><code tabindex="0" class="language-sh">npm install -g electron-forge </code></pre> <h2>Начнём с приложения</h2> <p>Используйте следующую команду для создания вашего приложения:</p> <pre><code tabindex="0">electron-forge init simple-desktop-app-electronjs </code></pre> <p>Где <em>simple-desktop-app-electronicjs</em> — это название приложения.</p> <p>Потребуется некоторое время, чтобы команда, указанная выше, отработала. После завершения предыдущего процесса запустите приложение с помощью следующих команд:</p> <pre><code tabindex="0" class="language-sh">cd simple-desktop-app-electronjs npm i npm start </code></pre> <p>Это должно открыть окно как на скрине ниже:</p> <h2>Разберёмся в структуре и коде</h2> <p>Приложение имеет определенную структуру папок. Здесь я перечислю некоторые важные моменты в этой структуре папок.</p> <h3>package.json</h3> <p>Содержит информацию о приложении, которое вы создаете, все зависимости, необходимые для приложения, и несколько скриптов. Некоторые из скриптов уже предварительно настроены, но вы также можете добавлять новые.</p> <p>Путь config.forge содержит все конфигурации конкретно для Electron. Например, make-target используется для указания целевых файлов для различных платформ, таких как Windows, Mac или Linux.</p> <p>Также в <code>package.json</code> есть <code>"main": "src/index.js"</code>, который указывает, что <code>src/index.js</code> является входной точкой приложения.</p> <h3>src/index.js</h3> <p>Согласно <code>package.json</code>, <code>index.js</code> является основным скриптом. Процесс, который запускает основной скрипт, называется <strong>главным процессом.</strong> Таким образом, основной процесс запускает скрипт <code>index.js</code>.</p> <p>Основной процесс нужен для отображения элементов интерфейса. Это делается путем создания страниц. Каждая созданная страница выполняется в процессе, называемом <strong>процессом отрисовки.</strong></p> <h3>Главный процесс и процесс отрисовки</h3> <p>Основное предназначение главного процесса — создание страниц с помощью экземпляра <code>BrowserWindow</code>. Экземпляр <code>BrowserWindow</code> использует процесс отрисовки для запуска каждой страницы.</p> <p><strong>Любое приложение может иметь только один главный процесс, но много процессов визуализации.</strong></p> <p>Также возможно взаимодействие между главным процессом и процессом отрисовки. Однако, я не буду останавливаться на этом в текущей статье.</p> <figure> <figcaption> Архитектура Electron, показывающая главный процесс и процессы отрисовки. Названия файлов могут быть другими. </figcaption> </figure> <p><strong>abcd.html</strong> показан в качестве второй веб-страницы в приведенной выше архитектуре. Но в нашем коде у нас не будет второй веб-страницы.</p> <h3>src/index.html</h3> <p><code>index.js</code> загружает файл <code>index.html</code> в новый экземпляр <code>BrowserWindow</code>.</p> <p>Это означает, что <code>index.js</code> создает новое окно GUI и загружает его со страницей <code>index.html</code>. Страница <code>index.html</code> запускается в своем собственном процессе отрисовки.</p> <h3>Код в index.js с пояснениями</h3> <p>Большая часть кода, созданного в <code>index.js</code>, содержит хорошие комментарии, объясняющие, что происходит. Здесь я упомяну несколько ключевых моментов, которые следует отметить в <code>index.js</code>:</p> <pre><code tabindex="0" class="language-js">mainWindow = new BrowserWindow({ width: 800, height: 600, }); // и загрузи index.html из app. mainWindow.loadURL(`file://${__dirname}/index.html`); </code></pre> <p>Приведенный выше фрагмент кода просто создает экземпляр <code>BrowserWindow</code> и загружает <code>index.html</code> в <code>BrowserWindow</code>. Вы увидите, что <code>app</code> часто используется в коде. Например, возьмите приведенный ниже фрагмент:</p> <pre><code tabindex="0" class="language-js">app.on('ready', createWindow); </code></pre> <p><code>app</code> используется для управления жизненным циклом событий приложения. Приведенный выше фрагмент кода говорит, что, когда приложение будет готово, нужно загрузить первое окно.</p> <p>Точно так же <code>app</code> может использоваться для выполнения других действий с различными событиями. Например, его можно использовать для выполнения некоторых действий непосредственно перед закрытием приложения и так далее.</p> <h2>Создадим десктопное приложение конвертера температур</h2> <p>Давайте воспользуемся тем же приложением, которое мы создали ранее, и немного изменим его, чтобы создать приложение конвертера температуры.</p> <p>Сначала давайте установим Bootstrap с помощью следующей команды:</p> <pre><code tabindex="0" class="language-sh">npm install bootstrap --save </code></pre> <p>Скопируйте следующий код в src/index.html:</p> <pre><code tabindex="0" class="language-html"><!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>Конвертер температур</title> <link rel="stylesheet" href="../node_modules/bootstrap/dist/css/bootstrap.min.css"> </head> <body> <h1>Конвертер температур</h1> <div class="form-group col-md-3"> <label for="celcius">По Цельсию:</label> <input type="text" class="form-control" id="celcius" onkeyup="celciusToFahrenheit()"> </div> <div class="form-group col-md-3"> <label for="fahrenheit">По Фаренгейту:</label> <input type="text" class="form-control" id="fahrenheit" onkeyup="fahrenheitToCelcius()"> </div> <script src="renderer.js"></script> </body> </html> </code></pre> <p>Приведенный выше код выполняет следующие действия:</p> <ol> <li>Создаёт поле ввода текста с <code>id="celcius"</code>. Всякий раз, когда в это поле что-то вводится, вызывается функция <code>celciusToFahrenheit()</code>.</li> <li>Создаёт поле ввода текста с <code>id="fahrenheit"</code>. Всякий раз, когда в это поле что-то вводится, вызывается функция <code>fahrenheitToCelcius()</code>.</li> <li>Когда в поле ввода «По Цельсию» вводится значение, в поле «По Фаренгейту» показывается та же температура, но в Фаренгейтах.</li> <li>Когда в поле ввода «По Фаренгейту» вводится значение, в поле «По Цельсию» показывается та же температура, но в Цельсиях.</li> </ol> <p>2 функции, которые выполняют преобразование температуры, будут храниться в <code>renderer.js</code>.</p> <p>Создайте файл с именем <code>renderer.js</code> внутри <code>src</code>. Скопируйте в него следующий код:</p> <pre><code tabindex="0" class="language-js">function celciusToFahrenheit(){ let celcius = document.getElementById('celcius').value; let fahrenheit = (celcius * 9 / 5) + 32; document.getElementById('fahrenheit').value = fahrenheit; } function fahrenheitToCelcius(){ let fahrenheit = document.getElementById('fahrenheit').value; let celcius = (fahrenheit - 32) * 5 / 9; document.getElementById('celcius').value = celcius; } </code></pre> <p>Функция <code>celciusToFahrenheit()</code> считывает значение в текстовом поле «По Цельсию», преобразует его в градусы Фаренгейта и записывает новую температуру в текстовое поле «По Фаренгейту».</p> <p>Функция <code>fahrenheitToCelcius()</code> делает ровно наоборот.</p> <h2>Запускаем приложение</h2> <p>Запустите приложение, используя следующую команду:</p> <pre><code tabindex="0" class="language-sh">npm start </code></pre> <p>Должно открыться следующее окно. Попробуйте ввести разные значения в инпуты.</p> <h2>Упаковываем приложение</h2> <p>Команда для упаковки приложения:</p> <pre><code tabindex="0" class="language-sh">npm run package </code></pre> <p>Выполнение этой команды потребует некоторого времени. Как только выполнение закончится, проверьте папку out в папке проекта.</p> <p>Я проверил это на машине c Windows. Была создана папка с именем <code>simple-desktop-app-Electronjs-win32-x64</code> внутри папки <code>out</code>.</p> <p>Таким образом, в папке <code>out/simple-desktop-app-Electronjs-win32-x64</code> команда создала файл <code>.exe</code> для этого приложения. Нажатие на исполняемый файл автоматически запускает десктопное приложение.</p> <p><em>При создании приложения на macOS, папка внутри <code>out</code> называется <code>simple-desktop-app-Electronjs-darwin-x64</code> и создаётся файл <code>.app</code>, который работает точно так же — прим. переводчика.</em></p> <p>Имя папки <code>simple-desktop-app-electronicjs-win32-x64</code> может быть разделено на <code>имя-платформа-архитектура</code>, где:</p> <ul> <li>имя — <code>simple-desktop-app-electronjs</code></li> <li>платформа — <code>win32</code> <em>(darwin на macOS — прим. переводчика)</em></li> <li>архитектура — <code>x64</code></li> </ul> <p>Когда вы запускаете команду без каких-либо параметров, по умолчанию она упаковывает пакеты для платформы, на которой вы разрабатываете.</p> <p>Допустим, мы хотим пакет для другой платформы и архитектуры. Тогда вы можете использовать следующий синтаксис:</p> <pre><code tabindex="0" class="language-sh">npm run package -- --platform=<платформа> arch=<архитектура> </code></pre> <p>Например, чтобы упаковать приложение для Linux, вы можете использовать следующую команду:</p> <pre><code tabindex="0" class="language-sh">npm run package -- --platform=linux --arch=x64 </code></pre> <p>Это создаст папку с именем <code>simple-desktop-app-electronicjs-linux-x64</code> внутри папки <code>out</code>.</p> <h2>Создание файла make</h2> <p>Чтобы создать файл <code>make</code> или установщик для приложения, используйте следующую команду:</p> <pre><code tabindex="0" class="language-sh">npm run make </code></pre> <p>Потребуется некоторое время на выполнение этой команды. Как только процесс закончится, проверьте папку <code>out</code> в папке проекта.</p> <p>В папке <code>out/make</code> будет создан установщик Windows для десктопного приложения <em>(или ZIP-архив на macOS — прим. переводчика).</em></p> <p>Когда вы запускаете эту команду без каких-либо параметров, по умолчанию она создает установщик для платформы, которую вы используете для разработки.</p> <h2>Код</h2> <p>Код для этого приложения доступен <a href="https://github.com/aditya-sridhar/simple-desktop-app-electronjs">в моем репозитории GitHub</a>. <em>См. форк репозитория на русском: <a href="https://github.com/solarrust/simple-desktop-app-electronjs">solarrust/simple-desktop-app-electronjs</a> — прим. переводчика.</em></p> <h2>Поздравляю 😄</h2> <p>Теперь вы знаете, как создавать десктопные приложения с использованием HTML, CSS и JavaScript. В этой статье были рассмотрены основные понятия об Electron и Electron Forge. Почитайте <a href="https://docs.electronforge.io/">документацию</a> чтобы узнать больше.</p> <h2>Об авторе</h2> <p>Я люблю технологии и слежу за новинками. Мне также нравится помогать другим, делясь своими технологическими знаниями.</p> <p>Не стесняйтесь связаться со мной через <a href="https://www.linkedin.com/in/aditya1811/">LinkedIn</a>, вы также можете подписаться на меня <a href="https://twitter.com/adityasridhar18">в Твитере</a> или зайти <a href="https://adityasridhar.com/">на мой сайт</a>.</p> </article> <article> <h1>CSS и JS в состоянии войны: как это остановить</h1> <p>Mon, 04 Feb 2019 00:00:00 GMT</p> <p><strong>Резюмируя</strong>: множество людей любят и JS и UX, CSS и т.д. Если мы перестанем раздавать ярлыки типа «JS-разработчик» или «UX-разработчик», то сможем добиться перемирия в текущей войне «JS против CSS».</p> <h2>Война реальна</h2> <p>Некоторые называют её «<a href="https://css-tricks.com/the-great-divide/">Великим расколом</a>»: линия фронта реальна; с приверженцами JavaScript с одной стороны и людьми из лагеря UX и CSS, которые пропагандируют подход «без-JS» к интерфейсам, с другой стороны.</p> <p>Фронтенд-разработчики боятся, что потеряют работу если не будут следовать за хайпом вокруг JS. И это вполне логично: проводится значительно меньше конференций и митапов по CSS по сравнению с JS, React и иже с ними. Например, в Нью-Йорке существует больше шести JS-митапов и ноль регулярных CSS-митапов.</p> <p>С другой стороны мы видим, что простые статические сайты слишком перегружены только из-за <a href="https://ru.wikipedia.org/wiki/%D0%A1%D0%B8%D0%BD%D0%B4%D1%80%D0%BE%D0%BC_%D1%83%D0%BF%D1%83%D1%89%D0%B5%D0%BD%D0%BD%D0%BE%D0%B9_%D0%B2%D1%8B%D0%B3%D0%BE%D0%B4%D1%8B">синдрома упущенной выгоды</a>.</p> <p>Мы каждый день наблюдаем, как видные деятели фронтенд сообщества обвиняют друг друга. И это, мягко говоря, расстраивает.</p> <h2>Выйти за рамки</h2> <p>Воюющих часто разделяют на коалиции:</p> <ol> <li><strong>JS-JS-JS:</strong> разработчики, создающие SPA с клиентской частью на каком-нибудь JavaScript-фреймворке, типа React, Vue.js и Angular. Они являются активными пользователями всяческих инструментов для сборки (Babel, Webpack и т.д.) и JS-библиотек.</li> <li><strong>UX-разработчики, CSS-разработчики, HTML-JS-CSS-разработчики:</strong> разработчики, создающие статичные сайты на ванильном JavaScript и чистом CSS. Доступность и быстродействие — главные темы обсуждений внутри комьюнити.</li> </ol> <p>Но <strong>существует</strong> ли этот раскол? Может этот дуализм основан только лишь на наших предрассудках?</p> <p>На мой взгляд, эта предвзятость во многом обусловлена двумя вещами.</p> <p>Во-первых, существует тренд разделять конференции по CSS и JS. Думаю, что это началось с очень популярного семейства ивентов JSConf и CSSConf и тенденции организации митапов Впиши-Свой-Город-Сюда.js. Западные платформы публикации контента поддерживают этот разлад: некоторые публикуют в основном статьи о React и JS в то время, как другие сфокусированы на CSS и UX.</p> <p>Во-вторых, соцсети хороши в <a href="http://www.pewresearch.org/fact-tank/2016/01/27/the-demographic-trends-shaping-american-politics-in-2016-and-beyond/">поляризации сообщества</a>. Мы помещаем себя в пузырь единомышленников путём подписки на их фиды и ухудшаем ситуацию, делая перепосты только самых агрессивных мнений, приходящих <em>с той стороны.</em></p> <p>Современный веб невероятно сложен. Крайне сложно освоить все необходимые для работы веба технологии и никто по-настоящему не может назвать себя на 100% фулстэк-разработчиком. Но из-за искусственно увеличенного разрыва между ветками обсуждения JS и CSS с UX люди с разными, но не обязательно противоположными увлечениями, сталкиваются с чёрно-белым взглядом на мир «JS против CSS». Разработчики на React, которые увлекаются CSS-анимацией и <a href="https://en.wikipedia.org/wiki/Computer_accessibility">a11y</a>, получают ярлык «фанат JS». И CSS-разработчик, который любит Babel и CSS-in-JS с без рантайма, всё ещё будет носить звание CSS-парня или девчонки.</p> <h2>Люди, любящие обоих</h2> <p>Как создатель <a href="https://postcss.org/">PostCSS</a>, я никогда не мог выбрать сторону даже если очень хотел этого. С одной стороны PostCSS это инструмент для CSS (что отражено в названии). С другой стороны PostCSS это инструмент сборки, написанный на <strong>JavaScript</strong>, а сборщики не особо в чести в современном сообществе CSS.</p> <p>И я не одинок, есть ещё куча таких же людей: к примеру, создатель великолепных <a href="https://github.com/aholachek/react-flip-toolkit">инструментов для анимации в React</a> или создатель <a href="https://github.com/YozhikM/stylelint-a11y">CSS-линтера доступности</a>.</p> <p>По правде говоря, каждый из нас знает лишь небольшое подмножество технологий. И чьи-то увлечения не обязаны лежать в одной области. Это нормально — любить и React и CSS одновременно. Или использовать сложную систему сборки чтобы быть уверенным, что твой продукт является доступным. Или может погрузиться в распределённые системы, чтобы сделать действительно <a href="https://github.com/logux">классный UX в условиях отсутствия интернета</a>.</p> <p>Даже сами технологии не могут быть чёрно-белыми.</p> <p>Сторонники «лагеря CSS» часто упоминают <a href="http://getbem.com/">БЭМ</a> как решение тех проблем, для которых создавался CSS-in-JS. Но не многие знают, что он, БЭМ, был спроектирован в <a href="https://yandex.com/company/">Яндексе</a> не как чисто CSS-технология. В него также входят JavaScript-фреймворк и изначально строился на ряде принципов, которые были позже использованы в React (например, вложенность маленьких изолированных компонентов).</p> <p>Конфиги для ESLint, популярные в React-сообществе (по типу <a href="https://www.npmjs.com/package/eslint-config-airbnb">конфига AirBnB</a>), содержат <a href="https://github.com/evcohen/eslint-plugin-jsx-a11y#supported-rules">множество правил обеспечения доступности</a>.</p> <h2>Решение</h2> <p>Я считаю, что война реальна. Я думаю, что мы можем остановить эту войну, перестав разделять разработчиков на категории чёрного и белого.</p> <ol> <li>Если ты любишь технологии с обеих «сторон»: рассказывай об этом! Вытащи это на свет, дай людям возможность начать цивилизованное обсуждение. Тебе нравятся современные JS-фреймворки, но также тебе нравится создавать статические сайты, которые рендерятся на сервере? Скажи об этом миру. Независимые разработчики будут создавать больше фреймворков для статических сайтов, если будут видеть необходимость в них.</li> <li>Давайте устроим публичный форум для обсуждений между мирами JS и CSS. Если вы организуете JavaScript-митап, то пусть в программе будет один доклад о CSS или UX. Пусть будут фронтенд-конференции вместо JS-конференций и CSS-конференций, где люди из разных лагерей смогут рассказать своим оппонентам о своих ежедневных проблемах и предпочитаемых решениях.</li> <li>Давайте пробовать технологии, пришедшие с другой стороны:</li> </ol> <ul> <li>Если вы CSS- или UX-разработчик, то начните с линтеров. <a href="https://stylelint.io/">Stylelint</a> отличный CSS-линтер для начала знакомства.Он будет предупреждать вам об ошибках и позволит делиться лучшими практиками внутри команды. И вы можете запустить его как плагин в вашем любимом текстовом редакторе, поэтому вам даже не нужен какой-либо сборщик.</li> <li>Если вы React-разработчик — попробуйте ванильный JS на следующем лендинге или блоге. Это поможет лучше понять внутренности вашего фреймворка. А ваши юзеры скажут вам спасибо за более быструю загрузку за счёт более лёгкого бандла.</li> </ul> <h2>Что ещё почитать</h2> <p>Моя статья <a href="https://evilmartians.com/chronicles/five-years-of-postcss-state-of-the-union">о будущем PostCSS, линтеров и CSS-in-JS</a> из <a href="https://evilmartians.com/chronicles/">Марсианских хроник</a>.</p> </article> <article> <h1>HTML, CSS и исчезающие точки входа в индустрию</h1> <p>Fri, 01 Feb 2019 00:00:00 GMT</p> <p>Все опять обозлились на CSS. Я даже не стану перечислять причины. В общей сложности всё сводится к тому, что CSS достаточно прост, но одновременно с этим и достаточно сложен. До такой степени, что, во избежание волнений общественности, проще завернуть его в JavaScript. Вы можете прочитать более осмысленный взгляд Криса Койера <a href="https://css-tricks.com/the-great-divide/">«The Great Divide»</a>.</p> <p>Подобные споры об инструментах, фреймворках и технологиях возникают повсеместно. Я постоянно наблюдаю их те 20 лет, что работаю в вебе. Стандартные технологии де-факто имеют свои ограничения, мы сталкиваемся с проблемами и хотим их решить. Частенько мы решаем эти проблемы просто выбрасывая всё. Старые вещи ужасны и были изобретены когда не было лучших альтернатив! Теперь, имея все свои знания, мы можем сделать лучше. Давайте переизобретём колесо!</p> <p>Мы можем наблюдать подобное в мире хранилищ данных, где люди всячески избегают реляционных баз данных, хотя чаще всего <a href="https://twitter.com/simonw/status/1089554577723056128?s=20">именно они им и нужны</a>.</p> <p>Мы видим это в стремлении к статическим сайтам. Всё начинается под предлогом экономии скорости отрисовки при отсутствии базы данных и заканчивается воссозданием баз данных в файловой системе или использованием сторонних сервисов в попытках заткнуть дыры, с которыми отлично справилась бы традиционная CMS.</p> <p>В обоих описанных сценариях есть исключения, когда альтернатива в виде РСУБД (<a href="https://ru.wikipedia.org/wiki/%D0%A0%D0%B5%D0%BB%D1%8F%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%B0%D1%8F_%D0%A1%D0%A3%D0%91%D0%94">Реляционная СУБД</a>) является правильным решением. Статические сайты отлично подходят для некоторых типов контента. Это хорошее решение определённой части проблем. Однако я видела много ситуаций, в которых попытка использовать новейшие технологии приводила проект в упадок и в конечном итоге требовался дорогостоящий рефакторинг или полная переделка.</p> <p>Это постоянное переосмысление колеса — наша Ахиллесова пята. Мы всегда оптимистичны и надеемся, что из этого выйдет что-то хорошее, но чаще всего это просто приводит к беспорядку. Команды раз за разом сталкиваются с проектами, которые никто не в силах исправить, потому что они, эти проекты, основаны на цепочке малоизвестных технологий. Компании часто получают сайты, разработанные подрядчиками на технологиях, которые быстро канули в лету. И когда бизнес хочет что-то обновить, то новый подрядчик предлагает ему переделать всё заново.</p> <p>Однако, когда дело доходит до фреймворков и подходов, которые усложняют написание HTML и CSS, проблема становится чуть более существенной, чем бизнес, теряющий пару лет работы и попадающий на полную переделку по причине того, что не может поддерживать опрометчиво выбранный фреймворк.</p> <p>Все обсуждения HTML и CSS напрямую сказываются на точке входа в профессию разработчика. Не важно, фронтендер ты или бэкендер, большинство из нас с вами, не имеющих за плечами высшего <em>технического</em> образования, начали своё знакомство с профессией с простых в изучении HTML и CSS. Волшебное чувство видеть, как твой код работает на реальной странице! Мы уже потеряли большинство точек входе, которые у нас были. Исчезли родительские форумы, где люди учат друг друга HTML и CSS в попытках создать семейный альбом. Эти люди теперь использую Facebook или, возможно, завели блог со стандартной темой оформления на Wordpress.com или SquareSpace. Пропали люди, кастомизирующие свои странички на MySpace или изучающие HTML на <a href="https://www.reddit.com/r/neopets/comments/25nmni/how_many_people_started_coding_because_of_neopets/">Neopets</a>. Больше нет людей, в основном женщин, попадавших в индустрию потому что были вынуждены изучить HTML, ведь ведение сайта организации являлось частью рабочих обязанностей администратора.</p> <p>Как подчёркивает <a href="https://twitter.com/betsythemuffin/status/1090342513054007296">этот классный тред</a>, входной точкой для большинства людей без традиционного образования стали буткемпы. Как правило там преподаётся стиль разработки, основанный на фреймворке, который позволит учащимся как можно быстрее получить работу. Однако, на основании вопросов от людей, прошедших подобное обучение, я вижу, что основы часто пропускаются и откладываются до лучших времён. Мы оказываем этим людям «медвежью услугу», если они впоследствии попадают в среду, где до основ дело никогда не дойдёт или, что ещё хуже, где HTML и CSS полностью обесценены. Из-за своих знаний HTML и CSS я спокойно реагирую на любые изменения в вебе. Я по опыту знаю, что эти знания позволят мне легко переключится и быстро освоить любые, построенные вокруг этих технологий, новинки.</p> <p>Есть что-то удивительное в том, что, несмотря на всё, что мы насоздавали за последние 20 лет, я могу за день научить любого новичка создавать страничку на HTML и CSS. Нам не потребуется говорить об инструментах и фреймворках, изучать как создавать пулреквест или как перед стартом перетащить на компьютер кучу кода с помощью npm. Нам понадобится только текстовый редактор и пара часов. <em>И на нашей страничке уже что-то появится.</em></p> <p>Это реальная точка входа и да, если работа является их целью, то в 2019 году им придётся быстро переключиться на инструменты и технологии, которые востребованы у работодателей. Но так или иначе, все эти инструменты в конце выдают HTML и CSS. Это основа всего, что мы делаем. И это делает маловероятным обесценивание тех, кто обладает действительно глубокими знаниями.</p> <p>Если у вас есть практические знания проблем, с которыми вы сталкивались при работе с CSS, то вы сможете создать действительно классное решение этих проблем на JavaScript. Многие из нас, кто работает с CSS, хотят услышать ваши идеи. Однако, если вы начнёте наш разговор с признания, что на самом деле не изучали CSS до того, как предложить ему замену или если я увижу, что вы унижаете меня (или других людей) за незнание выбранного вами фреймворка, то я буду более скептически относится к вашим предложениям. Я не буду помогать вам строить мир, в который такой человек как я никогда не смог бы попасть.</p> <blockquote> <p>Когда вы делаете навыки программирования ключевым компонентом роли каждого веб-разработчика, вы превращаете веб в песочницу для программистов. Это когда вы начинаете мыслить фабриками объектов и, жаловаться «почему пользователь не может обновиться» и обесценивать такие «мягкие и женственные» навыки, как дизайн.</p> <p>Задаёте потрясающий вопрос <strong>«а как ещё мы должны строить сложные приложения»</strong>, когда вообще никто не говорит об этом. По сути, спорите о том, как повысить базовый уровень создания <strong>всего</strong> до такого, который полностью исключается человек. <a href="https://twitter.com/sonniesedge/status/1089801399788101632">Чарли Оуэн @sonniesedge</a></p> </blockquote> <p>Возможно я из «старой гвардии», но если вы думаете, что я не способна изучить React и потому так яростно отстаиваю <em>свой путь</em>, то, прошу вас, остановитесь. Посмотри я на всё это, будучи 22 лет отроду, я бы развернулась и убежала прочь. Если мы сделаем так, что для старта потребуется понимание программирования, то мы передадим всю власть тем, кто уже находится в привилегированной группе. У меня ещё много сил для борьбы с этим.</p> </article> <article> <h1>Как на самом деле работает position: sticky в CSS</h1> <p>Thu, 31 Jan 2019 00:00:00 GMT</p> <p>У <code>position: sticky</code> уже очень неплохая браузерная поддержка, но большинство разработчиков так и не используют это свойство.</p> <p>У этого есть две основные причины: во-первых, браузерам потребовалось много времени на реализацию адекватной поддержки этого свойства. И все просто успели забыть о нём.</p> <p>Во-вторых, многие разработчики до конца не понимают логику, по которой это свойство работает. И тут появляюсь я!</p> <p>Я полагаю, что вы хорошо знакомы с позиционированием в CSS, но давайте кратко повторим основные моменты:</p> <p>Ещё три года назад существовало четыре типа позиционирования: <code>static</code>, <code>relative</code>, <code>absolute</code> и <code>fixed</code>.</p> <p>Основное различие между <code>static</code> и <code>relative</code>, <code>absolute</code> и <code>fixed</code> в том, какое место они занимают в потоке документа (DOM). Элементы с позицией <code>static</code> и <code>relative</code> сохраняют своё естественное положение в потоке документа, в то время как <code>absolute</code> и <code>fixed</code> «вырываются» из потока документа и становятся плавающими.</p> <p>Новое значение <code>sticky</code> похоже на все предыдущие значения сразу. Я проиллюстрирую это чуть позже.</p> <h3>Моё первое знакомство с «липким» позиционированием</h3> <p>Думаю, что большинство из вас игрались с «липким» позиционированием. Так было и у меня, пока в один момент я не осознал, что совсем не понимаю это свойство.</p> <p>При первом знакомстве с <code>position: sticky</code> все быстро понимают, что элемент <em>залипает</em>, когда область просмотра достигает определённой позиции.</p> <p>Пример:</p> <pre><code tabindex="0" class="language-css">.some-component { position: sticky; top: 0; } </code></pre> <p>Проблема в том, что иногда это работает, а иногда нет. Когда всё работает, то элемент и правда залипает. Но когда не работает, то при прокрутке элемент перестаёт залипать. Как человеку, который живёт одним только CSS, мне было важно разобраться в сути проблемы. Именно поэтому я решил тщательно изучить <strong>«липкое» позиционирование.</strong></p> <h3>«Липкая» разведка</h3> <p>Во время своих экспериментов я заметил, что если элемент с <code>position: sticky</code> является единственным ребёнком своего родителя-обёртки, то этот «липкий» элемент не залипает.</p> <pre><code tabindex="0" class="language-html"> <style> .sticky { position: sticky; top: 0; } </style> <div class="wrapper"> <div class="sticky"> Некий контент </div> </div> </code></pre> <p>Когда я добавлял больше элементов внутрь родителя-обёртки всё начинало работать как ожидалось.</p> <p><strong>Почему так происходит?</strong></p> <p>Причина кроется в том, что элемент с <code>position: sticky</code> может перемещаться только в пределах контейнера, в котором находится. А поскольку в моём случае он был единственным ребёнком, у него не было элементов-братьев, поверх которых он мог перемещаться.</p> <h3>Как на самом деле работает position: sticky в CSS</h3> <p>«Липкое» позиционирование состоит из двух основных частей: <strong>«липкого» элемента</strong> и <strong>«липкого» контейнера.</strong></p> <p><strong>«Липкий» элемент</strong> — это элемент, которому мы задали <code>position: sticky</code>. Элемент будет становиться плавающим, как только область видимости достигнет определённой позиции, например <code>top: 0px</code>.</p> <p>Пример:</p> <pre><code tabindex="0" class="language-css">.some-component { position: sticky; top: 0px; } </code></pre> <p><strong>«Липкий» контейнер</strong> — это HTML-элемент, который оборачивает «липкий» элемент. Это максимальная область, в которой может перемещаться наш элемент.</p> <p><strong>Когда вы задаёте элементу <code>position: sticky</code>, его родитель автоматически становится «липким» контейнером!</strong> Очень важно это запомнить! Контейнер будет являться областью видимости для элемента. «Липкий» элемент не может выйти за пределы своего «липкого» контейнера.</p> <p>В этом причина, почему в предыдущем примере «липкий» элемент не залипал: он был единственным дочерним элементом контейнера.</p> <p>Наглядный пример:</p> <figure> <figcaption> <a href="https://codepen.io/elad2412/pen/QYLEdK">Пример на CodePen</a>. </figcaption> </figure> <h3>Понимание «липкого» поведения</h3> <p>Как я и говорил, <code>position: sticky</code> ведёт себя не так, как другие типы позиционирования. Но, с другой стороны, у них есть определённые сходства. Позвольте мне пояснить:</p> <p>Относительное (или статичное) — «липкий» элемент похож на элемент со статическим или относительным позиционированием поскольку сохраняет свою естественную позицию в DOM (остаётся в потоке). Фиксированное — когда элемент залипает, то ведёт себя как будто у него заданы стили <code>position: fixed</code>, остаётся на той же позиции в области видимости и вырывается из потока документа. Абсолютное — в конце доступной для перемещений области элемент останавливается и остаётся поверх другого элемента. Точно также, как ведёт себя абсолютно спозиционированный элемент в контейнере с <code>position: relative</code>.</p> <h2>Залипает внизу?!</h2> <p>В большинстве случаев вы будете использовать <code>position: sticky</code> чтобы прикрепить элемент к верхнему краю страницы. Что-то вроде этого:</p> <pre><code tabindex="0" class="language-css">.component { position: sticky; top: 0; } </code></pre> <p>Именно для таких сценариев и был создан этот тип позиционирования. До его появления такой трюк приходилось проворачивать с помощью JavaScript.</p> <p>Но вы с тем же успехом можете использовать это свойство для того, чтобы прилепить элемент к нижней границе. Это значит, что футеру можно задать «липкое» позиционирование и при скролле он всегда будет залипать у нижнего края. И когда мы дойдём до конца «липкого» контейнера наш элемент остановится на своей естественной позиции. Лучше использовать эту особенность для элементов, находящихся в самом конце контейнера.</p> <p>Полный пример:</p> <p>HTML</p> <pre><code tabindex="0" class="language-html"><main class="main-container"> <header class="main-header">HEADER</header> <div class="main-content">MAIN CONTENT</div> <footer class="main-footer">FOOTER</footer> </main> </code></pre> <p>CSS</p> <pre><code tabindex="0" class="language-css">.main-footer { position: sticky; bottom: 0; } </code></pre> <figure> <figcaption> <a href="https://codepen.io/elad2412/pen/MZZVjw">Пример на CodePen</a>. </figcaption> </figure> <p>В реальной жизни я использую такое поведение для сводных таблиц. И, я думаю, с помощью этого приёма можно реализовать «липкую» навигацию в футере.</p> <h2>Браузерная поддержка</h2> <ul> <li>«Липкое» позиционирование поддерживается всеми основными современными браузерами. Исключение: старый-добрый IE.</li> <li>Для Safari потребуется префикс <code>-webkit</code></li> </ul> <pre><code tabindex="0">position: -webkit-sticky; /* Safari */ position: sticky; </code></pre> <figure> <figcaption> Более 86% браузеров поддерживает sticky по данным <a href="https://caniuse.com/#search=sticky">Can I Use</a>. </figcaption> </figure> <h2>В заключение</h2> <p>Вот и всё. Я надеюсь, что вам понравилась эта статья и мне удалось поделиться своим опытом. Я буду признателен, если вы поделитесь этим постом и поаплодируйте.</p> <h3>Другие мои посты о CSS</h3> <ul> <li><a href="https://medium.com/@elad/new-css-logical-properties-bc6945311ce7">New CSS Logical Properties!</a></li> <li><a href="https://medium.com/@elad/becoming-a-css-grid-ninja-f4c6db018cc1">Becoming a CSS Grid Ninja!</a></li> <li><a href="https://medium.com/@elad/the-new-responsive-design-evolution-2bfb9b504a4e">The New Responsive Design Evolution</a></li> <li><a href="https://medium.com/@elad/the-best-way-to-rtl-your-website-with-sass-105e34a4298a">The Best Way to RTL Websites with Sass!</a></li> <li><a href="https://medium.com/@elad/css-architecture-for-multiple-websites-with-sass-7e923fc53f7a">CSS Architecture for Multiple Websites With Sass</a></li> </ul> </article> <article> <h1>Что нового в JavaScript 2019</h1> <p>Wed, 30 Jan 2019 00:00:00 GMT</p> <p>На протяжении последних лет JavaScript развивался и получал новые фичи. Если вам любопытно, чего ждать от новой версии JavaScript, то этот пост для вас!</p> <p>Перед тем, как мы поговорим о новых возможностях, важно понять как новые идеи становятся частью языка JavaScript.</p> <h2>Процесс для новых возможностей JavaScript</h2> <p>Если коротко, то спецификация языка, которая управляет JavaScript, называется <a href="https://www.ecma-international.org/publications/standards/Ecma-262.htm">ECMAScript</a>. Группа Ecma International, которая рассматривает и принимает изменения в спецификацию языка, называется Технический комитет 39 или <a href="https://www.ecma-international.org/memento/tc39.htm">TC39</a>. Изменения в спецификацию ECMAScript проходят через <a href="https://tc39.github.io/process-document/">стандартизированный процесс</a>, включая стадии становления.</p> <ul> <li>Этап 0: идеи</li> <li>Этап 1: официальное предложение</li> <li>Этап 2: черновики</li> <li>Этап 3: кандидаты</li> <li>Этап 4: одобренные</li> </ul> <p>До тех пор, пока нововведение не достигнет 4 этапа, нет никаких гарантий, что оно станет частью спецификации ECMAScript. Тем не менее, некоторые JavaScript-движки, такие, как <a href="https://v8.dev/">V8</a> (используется в Сhrome and Node.js) и <a href="https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey">SpiderMonkey</a> от Firefox, могут добавить поддержку предложенных возможностей <em>до того</em>, как они перешли на этап 4. Так разработчики могут протестировать их и дать фидбэк.</p> <h2>Текущие кандидаты в ECMAScript2019</h2> <p>В момент написания этой статьи уже существует список <a href="https://github.com/tc39/proposals">предложений TC39</a>, которые находятся на 4 этапе. И тем не менее есть несколько кандидатов на 3 этапе.</p> <p><em><strong>Дисклеймер:</strong> поскольку есть несколько кандидатов на этапе 3, финальный вариант ECMAScript2019 может не включать в себя все перечисленные предложения. По факту некоторые из этих предложений находятся на рассмотрении годами. Кроме того, реализации новых возможностей могут выглядеть или вести себя не так, как описано в текущих кандидатах.</em></p> <h2>Изменения в классах JavaScript</h2> <p>Есть несколько предложений по изменениям, которые следует внести в классы, включая <a href="https://github.com/tc39/proposal-class-fields">строковую декларацию</a>, <a href="https://github.com/tc39/proposal-private-methods">приватные методы и поля</a> и <a href="https://github.com/tc39/proposal-static-class-features/">статические методы и поля</a>.</p> <pre><code tabindex="0" class="language-js">class Truck extends Automobile { model = 'Очень мощный'; // Объявление публичного поля #numberOfSeats = 5; // Объявление приватного поля #isCrewCab = true; static #name = 'Грузовик'; // Статическое приватное поле // Статичный метод static formattedName() { // Обратите внимание, что имя класса Truck используется // вместо this чтобы получить доступ к статическому полю return `Это автомобиль ${ Truck.#name }.`; } constructor( model, seats = 2 ) { super(); this.seats = seats; } // Приватный метод #getBodyType() { return this.#isCrewCab ? 'Двойная кабина' : 'Стандартная кабина'; } bodyType() { return `${ this.#numberOfSeats }-passenger ${ this.model } ${ this.#getBodyType() }`; } get seats() { return this.#numberOfSeats; } set seats( value ) { if ( value >= 1 && value < 7 ) { this.#numberOfSeats = value; this.#isCrewCab = value > 3; } } } </code></pre> <p>Лично мне не очень нравится синтаксис <code>#</code> для приватных полей и методов. Я бы предпочёл чтобы в спецификации JavaScript использовалось ключевое слово <code>private</code> для этих целей по аналогии с другими языками.</p> <h2>Строковые методы <code>trimStart()</code> и <code>trimEnd()</code></h2> <p>У типа данных <code>String</code> существует метод <code>trim()</code>, с помощью которого можно удалить пробелы с обоих концов строки. <a href="https://github.com/tc39/proposal-string-left-right-trim">Предложено</a> ввести методы <code>trimStart()</code> и <code>trimEnd()</code>, которые дадут больше контроля над удалением пробелов.</p> <pre><code tabindex="0" class="language-js">const one = ' Привет и позвольте '; const two = 'нам начать. '; console.log( one.trimStart() + two.trimEnd() ) // "Привет и позвольте нам начать." </code></pre> <p>Интересный факт: эта возможность языка <a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/String/trimEnd#Browser_compatibility">уже реализована</a> во многих JavaScript-движках. Один из случаев когда браузеры помогают развивать язык.</p> <h2>Большие числа с <code>BigInt</code></h2> <p>Мы видим примитив <a href="https://github.com/tc39/proposal-bigint">BigInt</a> для целых чисел, превышающих текущее максимальное значение 253. <code>BigInt</code> может быть объявлен несколькими различными способами.</p> <pre><code tabindex="0" class="language-js">// Референс const theBiggestIntegerToday = Number.MAX_SAFE_INTEGER; // 9007199254740991 // Используем синтаксис 'n' для объявления BigInt const ABiggerInteger = 9100000000000001n; // Используем конструктор BigInt() const EvenBigger = BigInt( 9100000000000002 ); // 9100000000000002n // Используем конструктор BigInt() со строкой const SuchBigWow = BigInt( '9100000000000003' ); // 9100000000000003n </code></pre> <p><a href="https://developers.google.com/web/updates/2018/05/bigint">Узнайте больше</a> о вариантах использования и фишках <code>BigInt</code>.</p> <h2>Одномерные массивы с <code>flat()</code> и <code>flatMap()</code></h2> <p>Если вы изучали функциональное программирование, то <a href="https://github.com/tc39/proposal-flatMap">вы точно узнаете</a> <code>flat()</code> и <code>flatMap()</code>. <code>flat()</code> принимает массив значений, который может состоять в том числе из других массивов, и возвращает новый одномерный массив.</p> <pre><code tabindex="0" class="language-js">const nestedArraysOhMy = ['a', ['b', 'c'], ['d', ['e', 'f']]]; // .flat() принимает необязательный аргумент глубины const ahhThatsBetter = nestedArraysOhMy.flat(2); console.log( ahhThatsBetter ); // ['a', 'b', 'c', 'd', 'e', 'f'] </code></pre> <p><code>flatMap()</code> похож на <code>map()</code>, но колбэк может вернуть массив и в результате получится плоский одномерный массив вместо вложенных массивов.</p> <pre><code tabindex="0" class="language-js">const scattered = ['мой любимый', 'бутерброд', 'это', 'сэндвич с курицей']; // Обычный map() вернёт вложенные массивы const huh = scattered.map(chunk => chunk.split(' ')); console.log(huh); // [['мой', 'любимый'], ['бутерброд'], ['это'], ['сэндвич', 'с', 'курицей']] // flatMap() объединяет возвращаемые массивы const better = scattered.flatMap( chunk => chunk.split( ' ' ) ); console.log(better); // ['мой', 'любимый', 'бутерброд', 'это', 'сэндвич', 'с', 'курицей'] </code></pre> <h2>Другие предложения-кандидаты в ES2019</h2> <p>Ниже представлен список дополнительных кандидатов, которые находятся на 3 этапе в момент написания статьи.</p> <ul> <li>Стандартизированный объект <a href="https://github.com/tc39/proposal-global"><code>globalThis</code></a></li> <li>Динамический <a href="https://github.com/tc39/proposal-dynamic-import"><code>import()</code></a></li> <li>Нововведения в <a href="https://github.com/tc39/proposal-regexp-legacy-features">устаревший RegExp</a></li> <li><a href="https://github.com/tc39/proposal-import-meta"><code>import.meta</code></a></li> <li>Строковый метод <a href="https://github.com/tc39/proposal-string-matchall"><code>matchAll()</code></a></li> <li><a href="https://github.com/tc39/proposal-object-from-entries"><code>Object.fromEntries()</code></a></li> <li>Правильный <a href="https://github.com/tc39/proposal-well-formed-stringify"><code>JSON.stringify</code></a></li> <li>Стандартизированный <a href="https://github.com/tc39/proposal-hashbang">Hashbang</a> для приложений с интерфейсом командной строки (CLI)</li> </ul> <h2>Когда ожидать ES2019</h2> <p>В последние годы TC39 выпускает обновлённую спецификацию ECMA-262 языка ECMAScript в июне. Всё говорит о том, что и ES2019 мы увидим в июне.</p> <h2>Попробуйте новинки ES2019 уже сегодня</h2> <p>Некоторые из описанных выше новинок языка уже реализованы в JavaScript-движках и утилитах. Они могут быть отключены по умолчанию, но легко включаются в настройках.</p> <h2>Потестируйте в последней версии Node.js</h2> <p><a href="https://nodejs.org/">Node.js</a> использует движок Chrome V8. Некоторые кандидаты могут быть использованы в Node.js потому что V8 уже поддерживает их (например, <code>Array.prototype.flat</code> и <code>String.prototype.trimEnd</code>).</p> <p>Вы можете включить другие фичи языка при помощи <code>--harmony-{feature-flag}</code> в параметрах командной строки. Чтобы проверить, какие флаги поддерживает ваша версия Node.js, используйте опцию <code>--v8-options</code> для получения списка. Некоторые кандидаты будут помечены «in progress» <em>(прим. переводчика: в процессе).</em></p> <p>MacOS или Linux:</p> <pre><code tabindex="0" class="language-sh">node --v8-options | grep "in progress" </code></pre> <p>Windows:</p> <pre><code tabindex="0" class="language-sh">node --v8-options | find "in progress" </code></pre> <p>Например, чтобы запустить приложение Node.js с поддержкой строковой декларации и статических методов, вы можете использовать следующие опции CLI.</p> <pre><code tabindex="0" class="language-sh">node --harmony-class-fields --harmony-static-fields index.js </code></pre> <h2>Тестируйте с Babel 7.0+</h2> <p><a href="https://babeljs.io/">Babel</a> это утилита JavaScript, которая позволяет вам использовать последние возможности языка, даже если они ещё не поддерживаются всеми браузерами и окружающими средами. Вы пишите «современный» JavaScript, а Babel переводит ваш код в синтаксис, который поддерживается старыми движками.</p> <p>Babel поддерживает экспериментальные возможности языка при помощи <a href="https://babeljs.io/docs/en/plugins">плагинов</a>. Babel публикует список поддерживаемых возможностей ECMAScript в своём официальном репозитории.</p> <h2>Что ещё почитать о JavaScript и ES Next</h2> <p>Хотите знать больше о JavaScript? Посетите некоторые из этих полезных ресурсов.</p> <ul> <li><a href="https://developer.okta.com/blog/2018/12/19/learn-javascript-in-2019">Learn JavaScript in 2019!</a></li> <li><a href="https://developer.okta.com/blog/2019/01/16/history-and-future-of-async-javascript">The History (and Future) of Asynchronous JavaScript</a></li> <li><a href="https://scotch.io/tutorials/build-a-secure-nodejs-application-with-javascript-async-await-using-hapi">Build a Secure Node.js Application with JavaScript Async Await Using Hapi</a></li> <li><a href="https://developer.okta.com/blog/2018/11/15/node-express-typescript">Use TypeScript to Build a Node API with Express</a></li> </ul> <p>Если вам будет интересно, то вы можете почитать <a href="https://www.ecma-international.org/publications/standards/Ecma-262-arch.htm">предыдущие версии</a> ECMAScript, например, ES2015, ES2016 и ES2017.</p> </article> <article> <h1>Text-transform и копирование</h1> <p>Thu, 24 Jan 2019 00:00:00 GMT</p> <p>Что происходит при копировании текста с <code>text-transform</code>.</p> <figure> <figcaption> Alphabet, Le Bistronome (CC BY-NC 2.0) </figcaption> </figure> <p>В CSS есть свойство <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/text-transform"><code>text-transform</code></a>. С помощью него можно менять регистр текста: можно преобразовать текст в ПРОПИСНЫЕ, строчные или Капитализировать Только Первые Буквы Слов. Это делается значениями <code>uppercase</code>, <code>lowercase</code> и <code>capitalize</code>, соответственно. Помимо них есть значения <code>full-width</code> и <code>full-size-kana</code>, про которые мы в этот раз говорить не будем.</p> <p style="text-transform: uppercase">Пример текста с <code>text-transform: uppercase</code></p> <p style="text-transform: lowercase">Пример текста с <code>text-transform: lowercase</code></p> <p style="text-transform: capitalize">Пример текста с <code>text-transform: capitalize</code></p> <p>Выше приведен пример использования свойства <code>text-transform</code>. Попробуйте скопировать любой из них и вставить куда-нибудь. Результат будет отличаться в зависимости от вашего браузера:</p> <ul> <li>Если у вас браузер на WebKit или Blink (Chrome, Safari, Opera 15+, Яндекс.Браузер и вскоре даже Edge), то вставится измененный текст — тот, который вы видите в браузере.</li> <li>В остальных браузерах (Firefox, IE и пока Edge) вставится исходный текст — тот, который написан в HTML.</li> </ul> <p>Стандарт до недавнего времени не определял, какое поведение является верным, поэтому оно стало предметом споров в баг-трекерах. <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=35148">Баг для Firefox</a> завели еще в 2000 году, <a href="https://bugs.webkit.org/show_bug.cgi?id=43202">баг для WebKit</a> с противоположным смыслом — в 2010. У сторонников обоих вариантов есть аргументы.</p> <p>Главный аргумент за копирование измененного текста, как в WebKit — соответствие ожиданиям пользователя. Человек не может понять, в результате чего текст отображается заглавными буквами. Может быть, он прописан таким образом в исходном коде, а может быть, к нему применено <code>text-trasform: uppercase</code>. Если пользователь будет копировать текст в верхнем регистре, а потом вставлять его и иногда видеть что-то другое, ему будет казаться, что веб сломался и глючит.</p> <p>Аргумент другой стороны в том, что такое поведение нарушает принцип разделения содержимого и оформления. CSS не должен влиять на контент страницы. А раз создатели сайта решили менять регистр через CSS, то они относятся к этому как к стилизации, и у пользователя должен быть доступ к изначальному варианту текста.</p> <p><a href="https://github.com/w3c/csswg-drafts/issues/627">В 2016 году</a> за этот вопрос взялась Рабочая группа CSS (CSSWG). При обсуждении <a href="https://github.com/w3c/csswg-drafts/issues/627#issuecomment-255279958">выделили</a> основные сценарии использования <code>text-transform</code>:</p> <ul> <li><code>p::first-line { text-transform: uppercase }</code> — первую строку набирают прописными буквами, как это иногда делают в англоязычной художественной литературе. В этом случае лучше копировать исходный текст, иначе он будет выглядеть странно.</li> <li><code>abbr { text-transform: lowercase; font-variant: small-caps }</code> — аббревиатуры в тексте набирают капителью. Свойство <code>font-variant: small-caps</code> берёт специальное начертание для капители из шрифта или отображает строчные буквы как прописные, только уменьшенного размера, если их нет. В этом случае тоже лучше копировать исходный текст, иначе аббревиатуры будут набраны строчными буквами.</li> <li><code>h1 { text-transform: uppercase }</code> — стилизуют заголовки с помощью прописных букв. Здесь применимы аргументы за оба варианта поведения.</li> <li><code>em { font-style: normal; text-transform: uppercase }</code> — используют прописные буквы для выделения важных фрагментов. Здесь тоже применимы оба аргумента.</li> </ul> <p>В результате обсуждений в рабочей группе, в 2018 году было принято решение: <a href="https://github.com/w3c/csswg-drafts/commit/f736e8e1b9812a9e854d03328a0acca827310801">дополнить стандарт CSS</a> указанием, что свойство <code>text-transform</code> не должно влиять на копируемый текст.</p> <figure> <figcaption> Коммит, который вносит изменения в стандарт. </figcaption> </figure> <p>Сейчас баг в Firefox закрыт как «wontfix», баг в WebKit по-прежнему открыт. Но уже можно надеяться, что скоро его поправят, и копирование текста с <code>text-transform</code> начнет работать во всех браузерах одинаково.</p> </article> <article> <h1>«Исправление» списков</h1> <p>Mon, 21 Jan 2019 00:00:00 GMT</p> <p><a href="https://twitter.com/gerardkcohen">Джерард К. Коэн</a> в сентябре 2017 опубликовал на Unfettered Thoughts <a href="https://unfetteredthoughts.net/2017/09/26/voiceover-and-list-style-type-none/">статью о том</a>, как пропадает семантика у списков в VoiceOver и Safari (WebKit; macOS и iOS), когда используется свойство <code>list-style: none</code>. И это происходит не только из-за <code>list-style: none</code>, но и при использования любых CSS-свойств, которые убирают маркеры или нумерацию у элементов списка.</p> <p>Это не единственный случай, когда изменения в CSS влияют на то, как элементы обрабатываются вспомогательными технологиями вроде скринридеров. Изменяя значения свойств <code>display</code> и <code>visibility</code> на <code>none</code> или <code>hidden</code> соответственно, мы не только визуально скроем такой контент, но и сделаем его недоступным для скринридеров. Однако эта проблема с изменением стиля списка уникальна только для Safari. В других браузерах и для других вспомогательных технологий эти свойства будут всегда скрывать и показывать контент.</p> <p>Почему WebKit — это единственный браузерный движок, который ведёт себя таким образом?</p> <h2>Когда «баг — это фича» на самом деле баг?</h2> <p>В марте 2017 <a href="https://bugs.webkit.org/show_bug.cgi?id=170179">был обнаружен баг</a>, связанный с влиянием <code>list-style: none</code> на семантику списка. В итоге был дан такой ответ:</p> <blockquote> <p>Это было осознанное решение из-за повсеместного использования списков веб-разработчиками. […] По сути, если вы удаляете все видимые по умолчанию признаки списка, то у зрячего пользователя или пользователя скринридера не будет никаких оснований считать, что контент им является. Если вы хотите изменить эту эвристику для доступности, то нужно всегда задавать явную ARIA-роль <code>role="list"</code>.</p> </blockquote> <p>Я могу это понять. Семантика сложная, и люди часто неправильно используют HTML. Тем не менее, эта проблема может возникнуть при использовании распространённого метода, когда нужно удалить стиль списка по умолчанию, но сохранить при этом его семантику. Особенно если список оформляется так, что он всё ещё похож на список.</p> <p>Кроме того, идея о том, что стоит рассчитывать на повторную установку семантики для списка при использовании ARIA, противоречит <a href="https://www.w3.org/TR/using-aria/#rule1">первому правилу использования ARIA</a>. Оно гласит:</p> <blockquote> <p>Если вы можете использовать стандартные HTML-элементы или атрибуты с уже <strong>встроенной в них</strong> необходимой семантикой и поведением, <strong>сделайте это</strong> вместо того, чтобы повторно использовать элемент и добавлять роль ARIA, состояние или значение, чтобы сделать его доступным.</p> </blockquote> <p>Другая <a href="https://www.w3.org/TR/using-aria/#aria-does-nothing">цитата оттуда же</a>:</p> <blockquote> <p>Ни один элемент в HTML4 не нуждается в добавлении ролей ARIA для того, чтобы раскрыть их семантику, уже встроенную по умолчанию. […] В большинстве случаев ARIA-роль и ARIA-атрибуты, семантика которых соответствует семантике стандартных элементов, не нужны. Их не рекомендуются использовать, так как эти свойства уже установлены браузером.</p> </blockquote> <p>В процессе обучения разработчиков, плохо знакомых с доступностью, это вечная проблема. Им часто говорят, что «не нужно использовать ARIA, если вы используете правильные HTML-элементы». После чего со вздохом объясняют:</p> <blockquote> <p>Вам нужно использовать ARIA для того, чтобы вернуть семантику списку в случае именно этого сочетания браузера и скринридера. Нет, вам не нужно это делать для других браузеров и скринридеров. Нет, этого не происходит с Chrome (Blink) и VoiceOver. Нет, вам нужно просто игнорировать предупреждения валидаторов «не дублируйте при помощи ролей ARIA роли стандартных элементов». Нет, это не нужно для Internet Explorer…</p> </blockquote> <h2>Когда вы даёте разработчику ARIA-роль</h2> <p>Немного отойду от темы, но считаю важным акцентировать внимание на этом. Когда вы советуете использовать ARIA, то это застревает в голове. Люди, которые плохо разбираются в тонкостях ARIA, «усвоят», что это «делает контент более доступным» и будут это использовать даже <a href="https://css-tricks.com/aria-spackle-not-rebar/">тогда, когда в этом нет необходимости</a>.</p> <p>Я ранее отмечал в <a href="https://www.scottohara.me/blog/2018/05/26/aria-lists.html">«ARIA Lists»</a>, что не нужно проходить через огонь, воду и медные трубы, чтобы создать неупорядоченный или упорядоченный список с помощью ARIA и CSS-счётчиков. Марси Саттон в 2016 написала статью <a href="https://marcysutton.com/links-vs-buttons-in-modern-web-applications/">«Links vs Buttons»</a>, которая, вероятно, не потеряет свою актуальность в ближайшие годы. Люди, чтобы избежать странного поведения элементов, которое они не понимают, будут делать лишнюю работу, чтобы создать элементы с помощью ARIA. Пожалуйста, давайте не увязать в этом.</p> <p>Другая интересная деталь, связанная с ARIA: если вы посмотрите на мою статью про использование ARIA для списков в режиме чтения в Firefox, то мой пример списка с ARIA исчезнет.</p> <p>Почему? Это же просто список, разве нет? Хм-м-м…</p> <p>Я обнаружил разное поведение и у другой разметки с ARIA в некоторых <a href="https://medium.com/@mandy.michael/building-websites-for-safari-reader-mode-and-other-reading-apps-1562913c86c9">режимах для чтения браузера</a>. Иногда такая разметка пропадает, иногда всё работает нормально, но этих странностей не бывает, когда используешь стандартные HTML-элементы без ARIA. Это то, о чём нужно думать при тестировании своего контента.</p> <p>Ладно, давайте вернёмся к разговору о WebKit и VoiceOver…</p> <h2>Исправление ради исправления</h2> <p>К счастью, ARIA не единственный способ вернуть списку его семантику. В статье на Unfettered Thoughts рассмотрен случай добавления пробела нулевой ширины через псевдоэлемент <code>::before</code> для элементов списка. Это восстанавливает семантику списка.</p> <p>Пример CSS-кода:</p> <pre><code tabindex="0" class="language-css">.list li { list-style-type: none; /* убираем маркеры списка */ } .list li::before { content: "\200B"; /* добавляем пробел нулевой ширины */ position: absolute; /* и ещё кое-что */ } </code></pre> <p>Используя этот код на практике, я обнаружил, что добавление <code>position: absolute</code> для псевдоэлемента может быть полезным. В проектах, над которыми я работал, бывало, что пробел с нулевой шириной не вёл себя так, как нужно. Из-за хака появлялись странные отступы или ненужные разрывы строк. Эти визуальные странности были в значительной степени связаны с другими стилями, которые наследовались <code>::before</code> от других нужных классов. С помощью <code>position: absolute</code> мы удаляем псевдоэлемент из потока элементов, что уменьшает вероятность возникновения такой проблемы.</p> <p>Ещё нужно быть осторожным, если псевдоэлемент <code>::before</code> уже использован для других целей, и добавление неразрывного пробела может навредить другим стилям. Изменение стилей и разметки могли бы помочь это исправить, но усилия должны быть сопоставимы с необходимостью поддержки Safari.</p> <p><a href="https://twitter.com/aardrian/status/1083889915417559040">Адриан Роселл заметил</a>, что отсутствие семантики у списка <em>«может не иметь большого значения, если тестирование пользователей не показывает, что список вам действительно необходим».</em> Хотя такое поведение может быть в некоторых ситуациях нежелательным, давайте не будем прилагать слишком много усилий для исправления того, что уже слишком активно пытались исправить, используя ненужную семантику. Проводите тестирование с реальными людьми!</p> <h2>Новая альтернатива</h2> <p><a href="https://twitter.com/jon_neal/status/1083829750072836096">Джонатан Нил</a> предложил на Unfettered Thoughts альтернативное решение на CSS. В документации к <a href="https://github.com/jonathantneal/postcss-list-style-safari-fix">PostCSS List Style Safari Fix</a> Джонатана сказано, что он обнаружил, что использование следующего CSS устранит необходимость в псевдоэлементе и снова вернёт семантику списку в Safari и VoiceOver:</p> <pre><code tabindex="0" class="language-css">/* Сокращённая версия селекторов Джонатана */ ol, ul { list-style: none; } ol, ul { list-style: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg'/%3E"); } </code></pre> <p>Я обнаружил, что <code>url(#!)</code> тоже будет возвращать необходимую семантику, но нужно будет дополнительно всё протестировать и убедиться, что это не приводит ни к каким негативным последствиям в других браузерах.</p> <p>Это выглядит многообещающе. При тестировании список был корректно объявлен VoiceOver на WebKit, не помешал другим скринридерам (тестировался на NVDA 2018.4 и на последнем JAWS 2019) и небольшие тестовые примеры корректно отображаются в большинстве современных браузеров.</p> <p>Я обнаружил единственную проблему у этой техники, когда попытался использовать её для своей навигации по сайту (в данный момент не использую ни один из хаков; пусть браузерные эвристики делают с моей навигацией то, что делают).</p> <p>После добавления <code>list-style: url(…)</code> для существующего селектора списка навигации, в верхней части каждого пункта в Internet Explorer 11 и Edge 42 появился отступ:</p> <p>При отключении <code>list-style</code> отступ исчезает и навигация отображается так, как нужно.</p> <p>Я предполагаю, что в моём CSS есть что-то другое, что приводит к появлению этих отступов. При <a href="https://codepen.io/scottohara/pen/JweKEp">использовании этой техники</a> в более простых, но похожих наборах правил, он не появляется.</p> <h2>Подводя итоги</h2> <p>Я слегка в замешательстве. Решение об отмене семантики у списка, если он больше не выглядит как список, имеет для меня смысл. Обычно я думаю, что внешний вид элементов должен отражать их содержание. Но такое поверхностное решение категорично. Оно также не учитывается тот факт, что существуют другие способы оформления списков, кроме использования маркеров по умолчанию. Следовательно, хотя я понимаю смысл этого решения, не думаю, что поведение Safari правильное в этой ситуации.</p> <p>Такое решение движется в другом направлении и нарушает форму того, как представляют другие браузеры стилизованные списки, а скринридеры их интерпретируют. Обычно разработчики не ожидают, что CSS влияет на семантику HTML. Это был своего рода способ устранения таких элементов, как: <code><center></code>, <code><big></code>, <code><font></code> и т. д. HTML предназначен для семантики, а CSS — для стиля.</p> <p>Но, как я писал в своей статье <a href="https://www.scottohara.me/blog/2018/10/03/unbutton-buttons.html">«Unbuttoning Buttons»</a>, а также Адриан Розелли в <a href="https://adrianroselli.com/2018/05/display-contents-is-not-a-css-reset.html">«Display: Contents Is Not a CSS Reset»</a> и <a href="https://adrianroselli.com/2018/02/tables-css-display-properties-and-aria.html">«Tables, CSS Display Properties, and ARIA»</a>, CSS может оказать негативный эффект на семантику, и разработчики могут не поступить мудрее.</p> <p>Просто посмотрите на количество ответов, ретвитов и лайков к твиту Сары Суайдан:</p> <blockquote> <p><code>#TIL</code> that removing list bullets with <code>list-style: none</code> removes <code><ul/ol></code> semantics in VoiceOver. Adding zero-width space fixes this; so this is yet another thing to add to our base <code>#CSS</code> files. <a href="https://twitter.com/SaraSoueidan/status/1083734801952182272">Sara Soueidan @SaraSoueidan</a></p> </blockquote> <blockquote> <p>Сегодня я узнала, что, если убрать маркеры списка с помощью <code>list-style: none</code>, то это отменит семантику <code><ul/ol></code> в VoiceOver. Добавление пробела нулевой ширины исправит это; так что это ещё одна вещь, которую надо добавить в наш базовый файл. <a href="https://unfetteredthoughts.net/2017/09/26/voiceover-and-list-style-type-none/">https://unfetteredthoughts.net/2017/09/26/voiceover-and-list-style-type-none/</a></p> </blockquote> <p>Было много фронтенд-разработчиков и тех, кто специализируется на доступности, но не знает об этой особенности в Safari.</p> <p>Эрик Эггерт воскликнул:</p> <blockquote> <p>We really need an open conversation on what CSS is allowed to overwrite semantics. Apart from <code>display: none</code>/<code>visibility: hidden</code>, I personally think no CSS should alter the semantics of the page. <a href="https://twitter.com/yatil/status/1083738608593448963">Eric Eggert @yatil</a></p> </blockquote> <blockquote> <p>Нам действительно необходимо открытое обсуждение того, что CSS позволяет переопределять семантику. Лично я считаю, что CSS не должен изменять семантику страницы, кроме <code>display: none</code> или <code>visibility: hidden</code>.</p> </blockquote> <p>А так отвечает Джеймс Крейг:</p> <blockquote> <p>I realize this decision upsets some web authors, but remember the first rule of the Web: Consider the needs of:</p> <ul> <li>Users before,</li> <li>Web Authors/Devs before,</li> <li>Browser Implementers before,</li> <li>Spec authors. <a href="https://twitter.com/cookiecrook/status/1084141791580905472">James Craig @cookiecrook</a></li> </ul> </blockquote> <blockquote> <p>This decision was all about the users’ experience on the majority of pages where web developers are not paying attention to the screen reader experience. Definitely open to change suggestions (including updating the heuristic) that make it better for authors w/o penalizing users. <a href="https://twitter.com/cookiecrook/status/1084142936583892992">James Craig @cookiecrook</a></p> </blockquote> <blockquote> <p>Я понимаю, что это решение расстраивает некоторых авторов, но помните про первое правило интернета. Учитывайте потребности:</p> <ul> <li>пользователей</li> <li>до авторов и разработчиков,</li> <li>до авторов и разработчиков,</li> <li>до разработчиков браузеров,</li> <li>до авторов спецификаций. Это всё нужно для удобства пользователей, ведь сегодня на большинстве сайтов разработчики не уделяют внимание удобству скринридеров. Разумеется, я открыт для предложений по внесению изменений (включая обновление эвристики), которые сделают жизнь авторов лучше без ухудшения положения пользователей.</li> </ul> </blockquote> <p>Так что замечания и комментарии приветствуются :)</p> </article> <article> <h1>Puppeteer для краулинга страниц сайта и сохранения их в Markdown</h1> <p>Thu, 17 Jan 2019 00:00:00 GMT</p> <p>Одна из моих целей на 2019: закончить редизайн <a href="https://justmarkup.com/">моего сайта</a>, и, что гораздо важнее, превратить его из сайта на WordPress в обычный статический сайт. Чтобы это сделать, мне надо сохранить все мои посты в формате Markdown. Попытки найти для этой задачи подходящий плагин для WordPress не увенчались успехом. С другой стороны, я бы мог использовать WordPress REST API или даже RSS-фид, чтобы получить данные, но и это не показалось мне вполне правильным решением. Потом я прочёл <a href="https://24ways.org/2018/dynamic-social-sharing-images/">статью</a>, написанную <a href="https://twitter.com/drewm">Дрю МакЛиланом</a>, в которой он использует Puppeteer для динамического создания скриншотов страниц, которые потом использует в превью постов для социальных сетей. И тогда у меня созрел план.</p> <p>В этой статье я опишу, как с помощью Puppeteer найти все статьи на странице, открыть их одну за другой, извлечь контент, сконвертировать в Markdown и сохранить в отдельных файлах.</p> <h2>Запуск Puppeteer</h2> <p><a href="https://github.com/GoogleChrome/puppeteer">Puppeteer</a> — это «безголовый» Google Chrome на Node.js, который предоставляет понятный API для работы. Это означает, что вы можете запустить Chrome из командной строки, даже не открывая окна браузера. Вы можете открывать страницы, на которых будет рендериться CSS, выполняться JavaScript — всё то же, что делает десктопный Chrome, но без интерфейса для пользователя.</p> <p>Для начала — у вас должен быть установлен <a href="https://nodejs.org/en/download/package-manager/">Node.js</a>. Для установки Puppeteer запустите в консоли:</p> <pre><code tabindex="0" class="language-sh">npm i puppeteer </code></pre> <p>Эта команда установит API вместе с Chromium (около 200 МБ). На моей Linux-подсистеме на Windows возникли проблемы во время установки, так как некоторые зависимости не подтянулись. Поэтому мне пришлось установить несколько дополнительных библиотек, чтобы всё заработало. Если у вас возникнут трудности на этом этапе, почитайте <a href="https://github.com/GoogleChrome/puppeteer/blob/master/docs/troubleshooting.md">советы по решению проблем</a>.</p> <h2>Получение данных</h2> <p>Сначала мы запустим новый браузер с Puppeteer и откроем новую страницу. Для этого, создадим новый файл index.js с таким содержимым</p> <pre><code tabindex="0" class="language-js">const puppeteer = require('puppeteer'); (async() => { // Запустим браузер const browser = await puppeteer.launch({ args: ['--no-sandbox'] } ); // Откроем новую страницу const page = await browser.newPage(); const pageURL = 'https://justmarkup.com'; try { // Попробуем перейти по URL await page.goto(pageURL); console.log(`Открываю страницу: ${pageURL}`); } catch (error) { console.log(`Не удалось открыть страницу: ${pageURL} из-за ошибки: ${error}`); } // Всё сделано, закроем браузер await browser.close(); process.exit() })(); </code></pre> <p>На первой строке мы подключаем библиотеку Puppeteer. Потом открываем браузер — <code>puppeteer.launch()</code>, создаём новую страницу — <code>browser.newPage()</code>, и переходим по нужному адресу — <code>page.goto(URL)</code>.</p> <p>Если мы запустим наш файл — <code>node index.js</code>, и всё сработает без ошибок, то в консоли должно появится сообщение <code>Открываю страницу https://justmarkup.com</code>. Либо что-то может пойти не так: неправильный URL, ошибка SSL, превышено время ожидания, ресурс недоступен… Поэтому мы обернули переход по URL в блок <code>try/catch</code> для обработки возможных <a href="https://github.com/GoogleChrome/puppeteer/blob/v1.11.0/docs/api.md#pagegotourl-options">ошибок</a>.</p> <p>Теперь, когда мы знаем как открыть браузер и перейти по URL, давайте посмотрим, как получить данные из DOM.</p> <pre><code tabindex="0" class="language-js">const puppeteer = require('puppeteer'); (async() => { // Запустим браузер const browser = await puppeteer.launch({ args: ['--no-sandbox'] } ); // Откроем новую страницу const page = await browser.newPage(); const pageURL = 'https://justmarkup.com'; try { // Попробуем перейти по URL await page.goto(pageURL); console.log(`Открываю страницу: ${pageURL}`); } catch (error) { console.log(`Не удалось открыть страницу: ${pageURL} из-за ошибки: ${error}`); } // Найдём все ссылки на статьи const postsSelector = '.main .article h2 a'; await page.waitForSelector(postsSelector, { timeout: 0 }); const postUrls = await page.$$eval( postsSelector, postLinks => postLinks.map(link => link.href) ); // Перейдём по каждой из них for (let postUrl of postUrls) { // Откроем страницу try { await page.goto(postUrl); console.log('Открываю страницу: ', postUrl); } catch (error) { console.log(error); console.log('Не удалось открыть страницу: ', postUrl); } // Получим pathname let pagePathname = await page.evaluate(() => location.pathname); pagePathname = pagePathname.replace(/\//g, '-'); console.log('Нашёл pathname:', pagePathname); // Получим заголовок статьи const titleSelector = '.article h1'; await page.waitForSelector(titleSelector); const pageTitle = await page.$eval( titleSelector, titleSelector => titleSelector.outerHTML ); console.log('Нашёл заголовок статьи: ', pageTitle); // Получим контент статьи const contentSelector = '.article .entry-content'; await page.waitForSelector(contentSelector, { timeout: 0 }); const pageContent = await page.$eval(contentSelector, contentSelector => contentSelector.innerHTML); console.log('Нашёл контент: ', pageContent); } // Всё сделано, закроем браузер await browser.close(); process.exit() })(); </code></pre> <p>Сначала мы получим все ссылки на наши посты, которые есть на начальной странице. В моём случае, их можно собрать по селектору <code>.main .article h2 a</code>.</p> <pre><code tabindex="0" class="language-js">// Найдём все ссылки на посты const postsSelector = '.main .article h2 a'; await page.waitForSelector(postsSelector, { timeout: 0 }); const postUrls = await page.$$eval( postsSelector, postLinks => postLinks.map(link => link.href) ); </code></pre> <p>Мы определяем селектор и используем <code>waitForSelector()</code> чтобы все DOM-узлы были доступны. После, мы используем <a href="https://github.com/GoogleChrome/puppeteer/blob/v1.11.0/docs/api.md#pageevalselector-pagefunction-args"><code>page.$$eval(selector, pageFunction[,...args])</code></a>, который запускает <code>Array.from(document.querySelectorAll(selector))</code> для всей страницы и передаёт полученное первым аргументом в <code>pageFunction</code>. И наконец, мы используем метод <code>map()</code> для получения ссылок на страницы из атрибута <code>href</code>. Отлично, у нас есть массив со всеми нужными ссылками!</p> <p>Теперь, самое время для того, чтобы открыть все ссылки, одну за другой, и получить данные (заголовок, контент, <code>pathname</code>), которые нам нужны.</p> <pre><code tabindex="0" class="language-js">for (let postUrl of postUrls) { // Откроем страницу try { await page.goto(postUrl); console.log('Открываю страницу: ', postUrl); } catch (error) { console.log(error); console.log('Не удалось открыть страницу: ', postUrl); } // Получим pathname let pagePathname = await page.evaluate(() => location.pathname); pagePathname = pagePathname.replace(/\//g, '-'); console.log('Нашёл pathname:', pagePathname); // Получим заголовок статьи const titleSelector = '.article h1'; await page.waitForSelector(titleSelector); const pageTitle = await page.$eval( titleSelector, titleSelector => titleSelector.outerHTML ); console.log('Нашёл заголовок статьи: ', pageTitle); // Получим контент статьи const contentSelector = '.article .entry-content'; await page.waitForSelector(contentSelector, { timeout: 0 }); const pageContent = await page.$eval( contentSelector, contentSelector => contentSelector.innerHTML ); console.log('Нашёл контент: ', pageContent); } </code></pre> <p>Мы перебираем массив ссылок <code>postUrls</code> и используем <code>page.goto()</code> для перехода по каждому URL. Чтобы получить <code>pathname</code> которое мы будем использовать позже, для того, чтобы сохранить файл, мы используем <code>page.evaluate()</code> чтобы получить <code>pathname</code> из <code>window.location</code>. Мы также заменяем слэши <code>/</code> на дефисы <code>-</code>, чтобы имена файлов были валидными.</p> <p>Следующий этап — заголовок статьи. Определяем селектор (в моём случае, это — <code>.article h</code>), и, снова используя <code>page.waitForSelector()</code>, ждём, чтобы всё загрузилось и получаем <code>outerHTML</code> заголовка с помощью <code>page.$eval()</code>. Позже мы сможем преобразовать этот HTML в markdown, с помощью HTML-to-Markdown API.</p> <p>Ну и наконец, мы можем получить основной контент статьи. Определяем ещё одни селектор (в моём случае, это — <code>.article .entry-content</code>), снова используем <code>page.waitForSelector()</code>, и получаем <code>innerHTML</code> контента статьи с помощью <code>page.$eval()</code>.</p> <p>Отлично, теперь мы знаем, как найти ссылки, перейти по каждой из них и получить данные со страницы.</p> <h2>Конвертация в Markdown</h2> <p>Что же, у нас есть все необходимые данные. На следующем шаге, мы будем использовать <a href="https://github.com/domchristie/turndown">Turndown</a> для конвертации HTML в Markdown.</p> <pre><code tabindex="0" class="language-js">const puppeteer = require('puppeteer'); const TurndownService = require('turndown'); const turndownService = new TurndownService(); (async() => { // Запустим браузер const browser = await puppeteer.launch({ args: ['--no-sandbox'] } ); // Откроем новую страницу const page = await browser.newPage(); const pageURL = 'https://justmarkup.com'; try { // Попробуем перейти по URL await page.goto(pageURL); console.log(`Открываю страницу: ${pageURL}`); } catch (error) { console.log(`Не удалось открыть страницу: ${pageURL} из-за ошибки: ${error}`); } // Найдём все ссылки на статьи const postsSelector = '.main .article h2 a'; await page.waitForSelector(postsSelector, { timeout: 0 }); const postUrls = await page.$$eval( postsSelector, postLinks => postLinks.map(link => link.href) ); // Перейдём по каждой из них for (let postUrl of postUrls) { // Откроем страницу try { await page.goto(postUrl); console.log('Открываю страницу: ', postUrl); } catch (error) { console.log(error); console.log('Не удалось открыть страницу: ', postUrl); } // Получим pathname let pagePathname = await page.evaluate(() => location.pathname); pagePathname = pagePathname.replace(/\//g, '-'); console.log('Нашёл pathname:', pagePathname); // Получим заголовок статьи const titleSelector = '.article h1'; await page.waitForSelector(titleSelector); const pageTitle = await page.$eval( titleSelector, titleSelector => titleSelector.outerHTML ); console.log('Нашёл заголовок статьи: ', pageTitle); // Получим контент статьи const contentSelector = '.article .entry-content'; await page.waitForSelector(contentSelector, { timeout: 0 }); const pageContent = await page.$eval( contentSelector, contentSelector => contentSelector.innerHTML ); console.log('Нашёл контент: ', pageContent); // Преобразуем HTML в Markdown let pageContentMarkdown = turndownService.turndown( pageTitle + pageContent ); console.log( 'Да это заголовок статьи и её контент в Markdown', pageContentMarkdown ); } // Всё сделано, закроем браузер await browser.close(); process.exit() })(); </code></pre> <p>Сначала, нам нужно установить Turndow, запустив в консоли <code>npm install turndown</code>. Потом мы подключаем его в начале index.js и определяем как сервис <code>const turndownService = new TurndownService();</code> Теперь, нам всего лишь надо добавить <code>let pageContentMarkdown = turndownService.turndown(pageTitle + pageContent);</code> после той части, где мы определили <code>pageTitle</code> и <code>pageContent</code>, и вуаля: у нас есть наш HTML преобразованный в Markdown</p> <h3>Сохранение файлов Markdown</h3> <p>Итак, нам осталось сохранить сконвертированный Markdown в файлы — по одному для каждой статьи.</p> <pre><code tabindex="0" class="language-js">const puppeteer = require('puppeteer'); const TurndownService = require('turndown'); const fs = require('fs'); const turndownService = new TurndownService(); (async() => { // Запустим браузер const browser = await puppeteer.launch({ args: ['--no-sandbox'] } ); // Откроем новую страницу const page = await browser.newPage(); const pageURL = 'https://justmarkup.com'; try { // Попробуем перейти по URL await page.goto(pageURL); console.log(`Открываю страницу: ${pageURL}`); } catch (error) { console.log(`Не удалось открыть страницу: ${pageURL} из-за ошибки: ${error}`); } // Найдём все ссылки на статьи const postsSelector = '.main .article h2 a'; await page.waitForSelector(postsSelector, { timeout: 0 }); const postUrls = await page.$$eval( postsSelector, postLinks => postLinks.map(link => link.href) ); // Перейдём по каждой из них for (let postUrl of postUrls) { // Откроем страницу try { await page.goto(postUrl); console.log('Открываю страницу: ', postUrl); } catch (error) { console.log(error); console.log('Не удалось открыть страницу: ', postUrl); } // Получим pathname let pagePathname = await page.evaluate(() => location.pathname); pagePathname = pagePathname.replace(/\//g, '-'); console.log('Нашёл pathname:', pagePathname); // Получим заголовок статьи const titleSelector = '.article h1'; await page.waitForSelector(titleSelector); const pageTitle = await page.$eval( titleSelector, titleSelector => titleSelector.outerHTML ); console.log('Нашёл заголовок статьи: ', pageTitle); // Получим контент статьи const contentSelector = '.article .entry-content'; await page.waitForSelector(contentSelector, { timeout: 0 }); const pageContent = await page.$eval( contentSelector, contentSelector => contentSelector.innerHTML ); console.log('Нашёл контент: ', pageContent); // Преобразуем HTML в Markdown let pageContentMarkdown = turndownService.turndown( pageTitle + pageContent ); // Проверим, существует ли папка, если нет — создадим её const postsDirectory = '/posts/'; if (!fs.existsSync(postsDirectory)) { fs.mkdirSync(postsDirectory); } // Сохраним файл в формате ${pathname}.md fs.writeFile( postsDirectory + pagePathname + '.md', pageContentMarkdown, (err) => { if (err) { console.log(err); } // Если ошибки нет — значит статья сохранена console.log('Сохранил статью!'); } ); } // Всё сделано, закроем браузер await browser.close(); process.exit() })(); </code></pre> <p>Здесь мы используем <a href="https://nodejs.org/api/fs.html">API файловой системы — модуль <code>fs</code> из Node.js</a>, поэтому подключим этот модуль начале нашего index.js. Я хочу сохранить все статьи в папке с именем <code>posts</code>. Поэтому, сначала проверим, существует ли папка с таким названием и если нет — создадим её с помощью:</p> <pre><code tabindex="0" class="language-js">// Проверим, существует ли папка, если нет — создадим её const postsDirectory = '/posts/'; if (!fs.existsSync(postsDirectory)) { fs.mkdirSync(postsDirectory); } </code></pre> <p>И в завершении, сохраним каждую статью в формате Markdown.</p> <pre><code tabindex="0" class="language-js">// Сохраним файл в формате ${pathname}.md fs.writeFile(postsDirectory + pagePathname + '.md', pageContentMarkdown, (err) => { if (err) { console.log(err); } // Если ошибки нет — значит статья сохранена console.log('Сохранил статью!'); }); </code></pre> <p>Здесь мы используем <code>fs.writeFile()</code>. Мы хотим сохранить наши файлы в папке <code>/posts/</code>, используя <code>pathname</code> из переменной <code>pagePathname</code> как имена файлов, и <code>.md</code> как расширение. Это будет первым аргументом в функции <code>writeFile()</code>. Вторым аргументом мы передадим <code>pageContentMarkdown</code>, в котором лежит полученный Markdown в формате <code>String</code>. Если всё пройдёт без ошибок, мы получими статьи в формате Markdown, сохранённые одна за другой. Да, мы сделали это!</p> <p>Я надеюсь, эта статья вас чему-то научила, и, возможно, вы в будущем тоже решите использовать Puppeteer для чего-нибудь интересного. Если вам любопытно, посмотрите финальный код на <a href="https://github.com/justmarkup/html-posts-to-markdown/blob/master/index.js">Гитхабе</a>.</p> </article> <article> <h1>JavaScript: топ тем и фреймворков для изучения в 2019 году</h1> <p>Wed, 16 Jan 2019 00:00:00 GMT</p> <p>Снова пришло время сделать обзор экосистемы JavaScript за год. Моя цель — определить области и технологии с наивысшим потенциалом для поиска работы. Какие технологии используются? Какие тренды развития существуют? Я не буду говорить <em>о лучших</em>, вместо этого предлагаю сфокусироваться на самых востребованных. Тех, которые помогут пройти собеседование и не ударить в грязь лицом, когда интервьюер спросит _«а знаете ли вы ___<em>?»</em> (пустую графу заполните сами). Для достижения цели я использую доступные в сети данные.</p> <p>Я не буду искать самую быструю технологию. Или оптимальную по качеству кода. Предлагаю сделать допущение, что все они самые быстрые и все делают свою работу. Важно другое: их востребованность.</p> <h2>Компонентные фреймворки</h2> <p>Вопрос, требующий внимания — компонентные фреймворки, а именно React, Angular и Vue.js, ведь по популярности эта тройка оставила конкурентов далеко позади.</p> <p>Я уже писал в прошлом году, как быстро растет Vue.js, и что он имеет шансы в 2018 догнать Angular. Этого не случилось, хотя динамика по-прежнему отличная. Я также говорил, что бороться за сердца разработчиков на React им будет сложнее, поскольку уровень удовлетворенности у React значительно выше, чем у Angular. У них просто нет причин менять стек. Мое предсказание подтвердилось, библиотека Facebook в 2018 году сохранила лидерство.</p> <p>Что примечательно, популярность всех трёх растет по экспоненте, год за годом.</p> <h3>Прогноз: в 2019 React продолжит доминировать</h3> <p>React сохраняет лидерство <a href="https://2018.stateofjs.com/front-end-frameworks/overview/">в рейтинге удовлетворенности</a> технологиями. Третий год подряд с тех пор, как мы учитываем его, React не отдаёт и пяди земли конкурентам. Причин для перемен в этом году я не вижу. Только нечто экстраординарное сможет подорвать его позиции.</p> <p>Впрочем, React становится только лучше. <a href="https://reactjs.org/docs/hooks-reference.html">Hooks API</a> пришли на смену классам, которые я терпел с версии 0.14. Классы все ещё работают, но хуки — намного, намного лучше! Это и другие нововведения, такие как улучшение поддержки код-сплитинга и <a href="https://reactjs.org/blog/2018/11/13/react-conf-recap.html">параллельного рендеринга</a>, делают его практически непобедимым. На сегодняшний день React — без сомнений наиболее дружелюбный фреймворк во всей экосистеме. А фактора важнее я не знаю.</p> <h3>Источники данных</h3> <p>Для оценки интереса к технологиям в нашей отрасли, используем следующие метрики:</p> <ol> <li><strong>Тренды поиска Google.</strong> Не назову их лучшим показателем, но он подходит для широкой картины.</li> <li><strong>Число скачиваний.</strong> Как способ оценки количества реальных пользователей через действие, которое они производят используя фреймворк.</li> <li><strong>Вакансии на <a href="https://indeed.com/">Indeed</a>.</strong> Используя ту же методику, что и в предыдущие годы для сохранения последовательности.</li> </ol> <h3>Тренды поиска Google</h3> <p><strong>Поисковые запросы по фреймворкам: январь 2014 — декабрь 2018.</strong></p> <figure> </figure> <p>По поисковым запросам React обогнал Angular в январе 2018 и сохранял лидерство на протяжении всего года. Vue.js стал занимать видимую, но все еще относительно незначительную позицию. Для сравнения, прошлогодние результаты:</p> <p><strong>Поисковые запросы по фреймворкам: январь 2014 — декабрь 2017.</strong></p> <figure> </figure> <h3>Число скачиваний</h3> <p>Этот параметр позволяет оценить <em>реальное</em> использование: установка пакета, как правило, означает его необходимость для рабочего процесса.</p> <p>Кто-то из читателей заметит, что поставить пакет можно и из внутрикорпоративных репозиториев. Отвечу: да, такое возможно, но для всех трех сравниваемых фреймворков. Все они вполне прижились в энтерпрайзе, поэтому имеют сравнимые показатели.</p> <p><strong>React, количество скачиваний в месяц: 2014–2018</strong></p> <figure> </figure> <p><strong>Angular, количество скачиваний в месяц: 2014–2018</strong></p> <figure> </figure> <p><strong>Vue.js, количество скачиваний в месяц: 2014–2018</strong></p> <figure> </figure> <p><strong>Визуализация по всем трём одновременно:</strong></p> <figure> </figure> <h1>Но вы забыли про Angular 1.0! Он все еще значителен в энтерпрайзе!</h1> <p>Нет, не забыл. Angular 1.0 используется во многих проектах, так же как используется Windows XP. Эта версия всё ещё актуальная для заметного количества проектов, но новые — давно превзошли её по популярности, что делает Angular 1.0 гораздо менее востребованным, чем другие фреймворки.</p> <p>Как так вышло? Потому что разработка в целом, как и повсеместное распространение JavaScript, во <em>всех секторах (включая энтерпрайз),</em> развивается настолько быстро, что новые технологии заменяют старые с невероятной скоростью. Пусть даже некоторые проекты <em>никогда</em> не обновятся.</p> <p>Примите за доказательство приведенные выше графики скачиваний. В одном 2018 их было больше, чем за все прошлые годы <em>вместе взятые.</em></p> <h3>Вакансии</h3> <p>Indeed агрегирует данные разных сервисов по поиску работы. Раз в год мы подсчитываем количество упоминаний того или иного фреймворка, чтобы понять, чего хотят работодатели. В этом году результаты выглядят так:</p> <p><strong>Вакансии для фреймворков, декабрь 2018.</strong></p> <figure> <figcaption>Вакансии для фреймворков, декабрь 2018</figcaption> </figure> <ol> <li>React: 24 640</li> <li>Angular: 19 032</li> <li>jQuery: 14 272</li> <li>Vue.js: 2 816</li> <li>Ember: 2 397 (нет на графике)</li> </ol> <p>Традиционно, вакансий значительно больше, чем годом ранее. Ember я исключил из списка, так как его показатели не растут, в отличие от показателей конкурентов. Я бы не рекомендовал изучать его, если задумываетесь о смене работы. Схожая ситуация с jQuery, спрос на который практически не изменился.</p> <p>К счастью, число разработчиков в индустрии также выросло. Тем не менее, нам нужно нанимать и обучать новичков (не забывая про <a href="https://devanywhere.io">синьоров-менторов</a>). Иначе мы просто не успеем за ростом спроса. Ниже, для сравнения, прошлогодний график:</p> <figure> </figure> <p>Средняя зарплата продолжила рост: с 110 до 111 тысяч долларов в год <em>(с 9166 до 9250 $ в месяц — прим. редактора).</em> Забавно, но зарплаты при этом отстают от ожиданий соискателей. Рекрутерам будет сложнее нанимать новых и удерживать текущих разработчиков, если они не пойдут навстречу. Удерживание и переманивание кадров остается огромной проблемой. Люди стремятся туда, где больше платят.</p> <p><strong>Методология:</strong> использованы данные сервиса <a href="http://indeed.com">Indeed</a>. Чтобы отфильтровать ложные вхождения, использован запрос со словом «software». Это повышает релевантность результатов. Затем полученные значения помножил на коэффициент ≈1,5 (приближенное соотношение вакансий со словом «software» и без него). Все данные были отсортированы по дате и проверены по выборке. Конечно, они точны не на 100%, но достаточно для анализа в рамках статьи.</p> <h2>Основы JavaScript</h2> <p>Я все время повторяю: сосредоточьтесь на основах. В этом году — я вам немного помогу. Процесс разработки основан на композиции — разделении сложных проблем на мелкие и простые и объединении их решений в полноценную программу.</p> <p>Однако, когда на интервью я спрашиваю: «что такое функциональная композиция?» или «что такое композиция объектов?» разработчики не могут ответить. Несмотря на то, что используют их каждый день.</p> <p>Я всегда считал это серьезной проблемой, поэтому написал книгу: <a href="https://leanpub.com/composingsoftware">«Composing Software</a>». Если вам нечего учить в 2019, учитесь правильной композиции.</p> <h3>TypeScript</h3> <p>TypeScript растёт. Это по-прежнему переоценённый инструмент, так как <a href="https://medium.com/javascript-scene/the-shocking-secret-about-static-types-514d39bf30a3">безопасность типизированного код преувеличена</a> и не сильно снижает вероятность ошибок, а <a href="https://medium.com/javascript-scene/you-might-not-need-typescript-or-static-types-aa7cb670a77b">работа с типами</a> в JavaScript без TypeScript и так неплоха. Можно даже использовать движок последнего с нативным JS в Visual Studio Code. Или установить Tern.js для вашего редактора.</p> <p>TypeScript подводит при работе с функциями высшего порядка. Или, возможно, это я не научился пользоваться за все годы работы с ним. В этом случае авторам стоит поразмыслить над удобством или документацией (или обоими). Так или иначе, я до сих пор не понимаю, как нормально обрабатывать map-операции. TypeScript как будто вообще не понимает, что происходит в <a href="https://medium.com/javascript-scene/transducers-efficient-data-processing-pipelines-in-javascript-7985330fe73d">трансдьюсерах</a>. Кроме того, он плохо отлавливает ошибки и часто жалуется на ошибки которые ими не являются вовсе.</p> <p>Попросту говоря, TypeScript не хватает гибкости и функциональности, чтобы соответствовать моему преставлению о написании кода. Но я продолжаю верить, что когда-нибудь он обрастет недостающими возможностями. Идея управления типами (там, где это необходимо), даже несмотря на все сложности внедрения на реальных проектах, мне нравится.</p> <p>Мое мнение: очень классная технология для узких случаев. При этом она переоценена и имеет низкий КПД на больших проектах. В этом вся ирония: TypeScript позиционирует себя как «JavaScript, который масштабируется», но кажется они забыли одно слово: «JavaScript, который <em>странно</em> масштабируется».</p> <p>Что нам нужно, так это система типов больше похожая на Huskell, меньше — на Java.</p> <h3>Другие темы для изучения по JavaScript</h3> <ul> <li><a href="https://graphql.org/">GraphQL</a> для запросов</li> <li><a href="https://redux.js.org/">Redux</a> для управления состоянием приложения</li> <li><a href="https://github.com/redux-saga/redux-saga">Redux-saga</a> для работы с сайд-эффектами</li> <li><a href="https://github.com/paralleldrive/react-feature-toggles">React-feature-toggles</a> для непрерывной интеграции и тестирования</li> <li><a href="https://github.com/ericelliott/riteway">RITEway</a> для прекрасных читаемых юнит-тестов</li> </ul> <h2>Расцвет криптоиндустрии</h2> <p>Год назад я говорил, что блокчейн и финтех станут значимыми в 2018. Мои слова подтвердились. Одной из важнейших тем последних двух лет стал расцвет криптоиндустрии и появление понятия <em>интернет ценностей</em> (Internet of Value). Запомните его. Скоро вы о нем услышите.</p> <p>Если вы, подобно мне, следите за децентрализованными приложениями со времен P2P, то знаете, процесс не был быстрым. Теперь, когда Биткоин «поджёг фитиль», доказав самодостаточность технологии на примере криптовалюты, взрыва не остановить.</p> <p>Биткоин вырос в несколько раз всего за несколько лет. Вы могли слышать, что 2018 стал «зимой для криптовалют», и наверняка думаете, что эта сфера столкнулась с проблемами. Ерунда. Что случилось на самом деле: в конце 2017 Биткоин достиг очередного пика, и рынок немного отыграл назад. Такое происходит при каждом достижении десятикратного рубежа стоимости.</p> <p><strong>Точки десятикратного роста Биткоина</strong></p> <figure> </figure> <p>Здесь видно, вершина стрелки графика находится на десятикратной позиции, относительно предыдущей, и уходит вниз для коррекции.</p> <p>Фандрайзинг для ICO достиг пика в начале 2018. Пузырь инвестиций в эту сферу привел к взрывному росту спроса на специалистов, который подошел к отметке в 10 000 открытых вакансий в январе 2018. По данным Indeed, после этого значение опустилась до 2 400. Но мы лишь в начале пути.</p> <figure> </figure> <p>О криптоиндустрии можно говорить много, но это заслуживает отдельной публикации. Если интересно, читайте «<a href="https://medium.com/the-challenge/blockchain-platforms-tech-to-watch-in-2019-f2bfefc5c23">Blockchain Platforms and Tech to Watch in 2019</a>».</p> <h3>Другие интересные технологии</h3> <p>Как я и предсказывал, эти технологии продолжили расти в 2018:</p> <p><strong>Искусственный интеллект/машинное обучение</strong> раскручивается вовсю: 30 000 вакансий на конец 2018 года, <a href="https://en.wikipedia.org/wiki/Deepfake">deepfake</a>, генеративное искусство, потрясающие примеры работы с видео от исследовательских команд таких компаний как Adobe. Еще не было столь подходящего времени для изучения AI.</p> <p><strong>Прогрессивные веб-приложения</strong>, теперь поддерживаемые Google, Apple, Microsoft, Amazon и другими гигантами, становятся стандартом. Невероятно, как быстро я стал относиться к PWA на моем телефоне как к должному. У меня больше не стоит приложение Twitter для Android, вместо него я использую <a href="http://mobile.twitter.com/home">Twitter PWA</a>.</p> <p><strong>AR</strong> (augmented reality — дополненная реальность), <strong>VR</strong> (virtual reality — виртуальная реальность), <strong>MR</strong> (mixed reality — смешанная реальность), словно Вольтрон, объединились в <strong>XR</strong> (eXtended reality — расширенная реальность). На пороге — полное погружение. Прогнозирую, что через 5–10 лет XR-очки станут массовым товаром. В течение 20 лет — контактные линзы. Тысячи новых вакансий в 2018 году и взрывной рост в 2019.</p> <p><strong>Роботы, дроны и беспилотные машины.</strong> Самоуправляемые дроны уже с нами, работы продолжают развиваться, все больше машин на автопилоте. Эти технологии продолжат развиваться и менять мир в 2019 и в течение 20 следующих лет.</p> <p><strong>Квантовые вычисления</strong> развивались, но мейнстримом не стали. Пока. Очевидно, мой прогноз, что «перелом произойдет в 2019 году или позже», звучит слишком оптимистично.</p> <p>В криптоиндустрии большое внимание уделяется квантово-устойчивому шифрованию (квантовые вычисления ломают современные представления о «дорогих» алгоритмах, тогда как блокчейн базируется на «дорогих» вычислениях). Но несмотря на череду интересных исследований, реальное положение дел такое, как описано в <a href="https://www.theregister.co.uk/2018/12/06/quantum_computing_slow/">этом докладе</a>:</p> <blockquote> <p>В период с 2000 по 2017 годы квантовые вычисления попадали в <a href="https://www.gartner.com/en/research/methodologies/gartner-hype-cycle">Перспективный список Гартнера</a> одиннадцать раз. Каждый раз их оценивали, как находящиеся на начальном этапе и требующих как минимум 10 лет для прохождения цикла зрелости.</p> </blockquote> <p>Это напоминает историю развития искусственного интеллекта. Первые разработки появились в 1950-х. Достигли ограниченного, но интересного результата в 1980-х и 1990-х. Но про настоящий прорыв можно говорить где-то с 2010.</p> <p><strong>Эрик Эллиот</strong> — эксперт по распределённым системам, автор книг «<a href="https://leanpub.com/composingsoftware">Composing Software</a>» и «<a href="https://ericelliottjs.com/product/programming-javascript-applications-ebook/">Programming JavaScript Applications</a>». Как сооснователь <a href="https://devanywhere.io/">DevAnywhere.io,</a> обучает разработчиков навыкам, необходимым для удалённой работы и сохранения баланса работа-жизнь. Создаёт и консультирует команды по разработке криптопроектов, участвовал в разработке проектов для Adobe Systems, Zumba Fitness, The Wall Street Journal, ESPN, BBC и популярных музыкантов, включая Usher, Frank Ocean, Metallica и многих других.</p> </article> <article> <h1>Та же история, только с CSS</h1> <p>Wed, 16 Jan 2019 00:00:00 GMT</p> <p>Мы видим ту же ситуацию с CSS, которую видели с HTML и JS раньше — она привела к текущей ситуацией с JS-фреймворками. Тред 👇</p> <p>📱Соперничество с нативными интерфейсами приложений.</p> <p>🐘 Большие команды, работающие над более сложными приложениями, с потребностями, которые не обеспечиваются текущими стандартизированными технологиями.</p> <p>🚀 Культура «двигайся быстро, ломай дрова».</p> <p>🏰 Недоверие к организациям по стандартизации, которые как будто заперлись в своих башнях из слоновой кости и не понимают потребностей разработчиков.</p> <p>⚔️ Поляризованное сообщество, где прагматизм конфликтует с лучшими практиками.</p> <p>Как и с JS, последствия самые плохие: взрыв разнообразия инструментов и конкурирующих решений, которые чрезмерно усложняют написание кода для веба, а также возрастающая нагрузка загружаемых ресурсов, вредящая удобству пользователей.</p> <p>Как нам это исправить?</p> <p>☮️ Предложить места за столом стандартизации разработчикам популярных альтернативных CSS-решений.</p> <p>💰 Если они не поддерживаются крупными компаниями, то покрыть их расходы и даже заплатить за их время.</p> <p>👂 Выслушать, что им есть сказать и очень постараться понять проблемы, которые они пытаются решить и причины выбора решений, которые они нашли.</p> <p>✋ Прекратить считать, что эти JS-решения для CSS — всего лишь неспособность разработчиков понять CSS, и попробовать разобраться, как исправить текущую ситуацию. Это то, что мы должны делать, согласно <a href="https://www.w3.org/TR/html-design-principles/#priority-of-constituencies">приоритету групп</a>.</p> <p>🤝 Выбрать комплексный подход для проблем, затрагивающих JS, HTML и CSS (загрузка ресурсов, сборка, изоляция и др.) и улучшить коммуникацию между организациями по стандартизации (<a href="https://twitter.com/TC39">@TC39</a>, <a href="https://twitter.com/csswg">@csswg</a>, <a href="https://twitter.com/WHATWG">@WHATWG</a>, <a href="https://twitter.com/wicg_">@wicg_</a>, <a href="https://twitter.com/w3c">@w3c</a>, и т.д.) Может быть через <a href="https://twitter.com/w3ctag">@w3ctag</a>?</p> <p>🏭 Убедиться, что за столом стандартизации сидят разработчики больших проектов, чтобы их требования были поняты и потребности учтены.</p> <p>🏆 Помнить, что сам факт существования различных JS-решений сегодня — это демонстрация успеха <a href="https://github.com/extensibleweb/manifesto">Манифеста расширяемого веба</a>.</p> <p>🐄 Не забывать, что Манифест расширяемого веба состоит из двух частей: первая — про примитивы, которые позволяют разработчикам экспериментировать и двигаться быстрее, второй — про необходимость определять общие решения и «асфальтировать тропинки».</p> </article> <article> <h1>Инклюзивные компоненты: переключатели</h1> <p>Sat, 05 Jan 2019 00:00:00 GMT</p> <p>Некоторые вещи либо включены, либо выключены. Когда что-то не включено, то оно обязательно выключено, и наоборот. Эта идея настолько элементарна, что я всё усложнил этим объяснением. Однако не все переключатели одинаковы: хотя они выполняют простые функции, их практическое применение и формы сильно различаются.</p> <p>В этой статье я объясню, как сделать переключатели инклюзивными <em>(включающими, доступными для всех — прим. редактора).</em> Нет единого способа решения этой проблемы, как и в случае любого другого компонента, особенно когда подобные контролы рассматриваются в разных контекстах. Многое можно испортить или просто забыть сделать, так что попробуем этого избежать.</p> <h2>Изменение состояния</h2> <p>Если веб-приложение не изменилось так, как ожидал пользователь, такое взаимодействие будет негативным. При этом возможность моментально изменять содержимое страниц, без их обновления, существовала не всегда.</p> <p>К сожалению, в какой-то момент мы решили, что доступными страницами были те, где мало что происходит: это статические документы, созданные только для чтения. То есть мы прикладывали мало усилий для того, чтобы сделать взаимодействие с ними более богатым, с <em>сохранением выбора для пользователей.</em></p> <p>Есть распространённое заблуждение о том, что скринридеры <em>не понимают</em> JavaScript. Это совершенно неверно. Все популярные скринридеры реагируют на изменения в DOM по мере их возникновения. Но изменения основных состояний (визуально и для вспомогательных технологий) не обязательно связаны с JavaScript.</p> <h2>Чекбоксы и радиокнопки</h2> <p>Элементы форм — базовые элементы страниц. Когда мы не используем их напрямую, то всё равно должны уделять пристальное внимание тому, как они себя ведут. Проработка смены состояний у таких элементов установлена принципами юзабилити, которыми глупо было бы пренебрегать.</p> <p>В принципе, нативный <code><input></code> с типом checkbox идеально подходит для любых ситуаций, когда нужно что-то включить или выключить. Он обладает всеми основными составляющими доступного контрола при наличии правильного <code><label></code>: к нему есть доступ у скринридера и клавиатуры на разных платформах и устройствах. Об изменении его состояния с <em>«установлен» (checked)</em> на <em>«не установлен» (unchecked)</em> и наоборот сообщается сразу же.</p> <p>В примере ниже с помощью чекбокса можно включить или выключить уведомления по электронной почте.</p> <pre><code tabindex="0" class="language-html"><input type="checkbox" id="notify" name="notify" value="on"> <label for="notify">Уведомлять по почте</label> </code></pre> <p>Скринридеры примерно одинаково интерпретируют этот контрол. При фокусе на нём (если перемещаться по странице с помощью клавиши <kbd>Tab</kbd>) будет объявлено что-то вроде <em>«Уведомлять по почте, флажок не установлен».</em> В этом объявлении есть содержимое <code><label></code>, роль и состояние элемента.</p> <p>При выборе чекбокса большинство скринридеров сразу же объявит, что состояние изменилось на <em>«установлен»</em> (иногда повторяя информацию о содержимом <code><label></code> и роли). Состояние элемента будет обработано без использования JavaScript, а скринридер сообщит пользователю информацию об изменениях контрола.</p> <h3>Примечание: скринридеры нужны не только слепым</h3> <p>Некоторые работают со скринридерами, чтобы было легче понять интерфейс. У других может быть дислексия или низкий уровень грамотности. Есть даже те, у кого имеются незначительные физические или когнитивные проблемы, затрудняющие понимание интерфейса, и кто просто иногда хочет, чтобы им читали вслух.</p> <p><strong>Поддержка скринридеров — это поддержка скринридеров, а не только слепых пользователей.</strong> Это инструменты для большого числа разных людей, которым нравится ими пользоваться.</p> <p>В этом случае часть переключателя, в которой содержатся значения <code>on</code> или <code>off</code>, не связана с <code><label></code>, но зато отражает состояние элемента. Напротив, содержимое <code><label></code> нужно для определения того, что именно мы выключаем или включаем. Если вы считаете, что пользователям необходима более очевидная аналогия с включением и выключением, можно использовать группу радиокнопок.</p> <pre><code tabindex="0" class="language-html"><fieldset> <legend>Уведомлять по почте</legend> <input type="radio" id="notify-on" name="notify" value="on" checked> <label for="notify-on">включить</label> <input type="radio" id="notify-off" name="notify" value="off"> <label for="notify-off">выключить</label> </fieldset> </code></pre> <p>Заголовок группы элементов — это мощный инструмент. Как следует из названия, он является общей подписью для связанных (сгруппированных) элементов. В этом случае элемент <code><fieldset></code> работает вместе с <code><legend></code> и даёт возможность задать для двух радиокнопок одно описание «Уведомлять по почте». Эти кнопки объединены общим значением атрибута <code>name</code>. Благодаря этому можно переключаться между ними при помощи стрелок на клавиатуре. Использование семантического HTML не только сообщает информацию об элементах, но и влияет на их поведение.</p> <p>В Windows, когда пользователь установил фокус на первом контроле, скринридеры JAWS и NVDA добавляют заголовок группы к отдельному <code><label></code> этого контрола и считают количество радиокнопок в группе. NVDA ещё добавляет термин «группировка», чтобы стало более очевидно, что это группа радиокнопок. В примере выше фокус сделан на первой (выбранной по умолчанию) радиокнопке. Скринридеры сделают из этого такой вывод: <em>«Уведомлять по почте, группировка, переключатель выделен, один из двух».</em></p> <p>Несмотря на то, что выбран первый элемент (некоторые скринридеры объявят <em>«выделено»),</em> пользователь может переключаться между ним и второй радиокнопкой. «Включить» и «выключить» — это два возможных, если хотите, <em>лексических состояния</em> у такого составного контрола.</p> <h3>Примечание: стилизация элементов форм</h3> <p>Печально известно, что элементы форм сложно стилизовать. Однако есть хорошо поддерживаемые CSS-техники для стилизации радиокнопок и чекбоксов, которые я описал в <a href="https://www.sitepoint.com/replacing-radio-buttons-without-replacing-radio-buttons/">«Replacing Radio Buttons Without Replacing Radio Buttons»</a>. Если нужны советы о том, как стилизовать контролы и поля для загрузки файлов, посмотрите гайдлайн <a href="http://wtfforms.com/">«WTF Forms?»</a> Марка Отто.</p> <h2>Что-то здесь не так</h2> <p>Логично реализовывать контролы, которые что-то включают и выключают, в виде чекбоксов и радиокнопок. Они доступны для мыши, сенсорных дисплеев, клавиатуры и вспомогательных технологий на разных устройствах, в браузерах и в операционных системах.</p> <p>Но доступность — это лишь одна из частей инклюзивного дизайна. Эти контролы также должны <em>иметь смысл</em> для пользователей и восприниматься ими однозначно.</p> <p>Одна из проблем элементов форм — их давняя связь со сбором данных. То есть чекбоксы и радиокнопки воспринимаются как контролы для установки <em>значений.</em> Когда пользователь устанавливает чекбокс, он просто переключает состояние, но также ему может <em>показаться</em>, что он выбирает значения для отправки на сервер.</p> <p>Будь то зрячий пользователь, который видит чекбокс, или пользователь скринридера, который слышит информацию об элементе, поведение такого контрола сложно предсказать. Мы ожидаем, что переключатель — это кнопка, а чекбокс и радиокнопка на самом деле части формы.</p> <h2>Настоящий переключатель</h2> <p>Иногда мы используем элемент <code><button></code> для отправки форм. Для того, чтобы эти кнопки были полностью совместимы и надёжны, стоит задать им в атрибуте <code>type</code> значение <code>submit</code>.</p> <pre><code tabindex="0" class="language-html"><button type="submit">Отправить</button> </code></pre> <p>Но это только один вид кнопки, который встречается в определённом сценарии использования. На самом деле элемент с классом <code><button></code> может использоваться для всего, что угодно, а не только в формах. Это же просто <em>кнопки.</em> Мы напоминаем себе об этом, задавая им в <code>type</code> значение <code>button</code>.</p> <pre><code tabindex="0" class="language-html"><button type="button">Отправить</button> </code></pre> <p>Типовая кнопка — это твой ключевой элемент для изменения чего угодно в интерфейсе (используя JavaScript и без обновления страницы). Кроме случаев, когда нужно переместиться внутри одной страницы или перейти на другую. Это уже задача ссылок.</p> <p>Кнопки, как и ссылки — это интерактивные элементы, которые стоит активно использовать в веб-приложениях. У них уже есть роль <code>button</code> и они по умолчанию доступны для клавиатуры и скринридера. И, в отличие от элементов форм, их просто стилизовать.</p> <p>Так как нам сделать <code><button></code> переключателем? Это ситуация, в которой потребуется WAI-ARIA как часть прогрессивного улучшения. Состояний из WAI-ARIA нет в базовом HTML, например, состояния «нажата» (pressed). Представьте себе кнопку включения компьютера. Когда она нажата, то компьютер включён, когда не нажата, то компьютер должен быть выключен.</p> <pre><code tabindex="0" class="language-html"><button type="button" aria-pressed="true"> Уведомление по почте </button> </code></pre> <p>Атрибут состояния из WAI-ARIA вроде <code>aria-pressed</code> ведёт себя как булевый тип данных. Однако, в отличие от стандартных атрибутов состояний из HTML, например, <code>checked</code>, такие атрибуты должны иметь явно заданные значения <code>true</code> или <code>false</code>. Недостаточно просто добавить <code>aria-pressed</code>. Кроме того, в отсутствие атрибута не будет объявлено <em>«не нажата» (unpressed).</em> Кнопка без атрибута — это просто стандартная кнопка.</p> <p>Вы можете использовать этот элемент управления внутри формы или за её пределами, в зависимости от ваших целей. Но если вы используете их внутри формы, то важно задать им <code>type="button"</code>. Если этого не указать, то некоторые браузеры по умолчанию установят <code>type="submit"</code> и попытаются отправить форму.</p> <p>Переключить состояние с <code>true</code> (включён) на <code>false</code> (выключен) можно с помощью простого обработчика кликов. Поскольку мы используем <code><button></code>, то этот вид события может быть запущен по щелчку мыши, нажатию на клавиши <kbd>Space</kbd> или <kbd>Enter</kbd> или по тапу на сенсорном экране. Отзывчивость для каждого из этих действий — это то, что по умолчанию встроено в элементы <code><button></code>. Если вы загляните в <a href="https://developer.mozilla.org/en/docs/Web/API/HTMLButtonElement">HTMLButtonElement</a>, то увидите другие значения, такие как <code>disabled</code>. Это состояние также доступно из коробки. Если элементы <code><button></code> не используются, то их поведение нужно воспроизводить с помощью скриптов.</p> <pre><code tabindex="0" class="language-js">const toggle = document.querySelector('[aria-pressed]'); toggle.addEventListener('click', (e) => { let pressed = e.target.getAttribute('aria-pressed') === 'true'; e.target.setAttribute('aria-pressed', String(!pressed)); }); </code></pre> <h2>Более очевидное состояние</h2> <p>Интересное происходит, когда на кнопку с атрибутом <code>aria-pressed</code> наталкиваются какие-то скринридеры: они определяют её как <em>«переключатель»</em> или, в некоторых случаях, <em>«кнопка нажата».</em> Наличие атрибута состояния изменяет сущность кнопки.</p> <p>Когда скринридер NVDA сделает фокус на кнопке с <code>aria-pressed="true"</code> из примера, он объявит: <em>«Уведомлять по почте, переключатель, включено».</em> Состояние <em>«включено» (pressed)</em> подходит в данном случае больше, чем <em>«установлено» (checked).</em> Плюс мы избегаем неоднозначного понимания контрола. Когда по кнопке кликнут, то сразу же будет объявлено <em>«отключено».</em></p> <h2>Стилизация</h2> <p>Мы выполняем важную часть работы над дизайном и создаём разные вещи для веба с помощью HTML. Я уверен, что если вы создаёте Первый HTML-прототип™, то можете быть уверены в том, что у вас есть надёжная основа для продукта с фирменным стилем.</p> <p>В случае с нашим переключателем в его основе лежат семантика и поведение, которые делают кнопку совместимой с разными типами ввода данных (например, с программой активации голосом) и их вывода (например, со скринридером) на разных устройствах. Это возможно благодаря HTML. CSS необходим, чтобы сделать управление интерфейсом понятным визуально.</p> <p>Форма должна соответствовать определённым функциям, чего просто добиться в CSS: всё, что в нашем HTML добавляет для кнопки функцию простого переключателя, также можно использовать для придания ему определённого внешнего вида.</p> <ul> <li><code><button></code> → селектор элемента <code>button</code>.</li> <li><code>aria-pressed="true"</code> → селектор атрибута <code>[aria-pressed="true"]</code>.</li> </ul> <p>В согласованных и, поэтому, лёгких для понимания интерфейсах, кнопки должны иметь конкретный внешний вид и выглядеть как кнопки. Так что стили нашего базового переключателя, вероятно, должны наследоваться от блочного элемента <code>button</code>:</p> <pre><code tabindex="0" class="language-css">/* Например… */ button { color: white; background-color: #000; border-radius: 0.5rem; padding: 1em 2em; } </code></pre> <p>Есть несколько способов для визуального обозначения того, что кнопка нажата. При буквальной интерпретации, мы могли бы сделать кнопку выглядящей вжатой с помощью <code>inset</code> в <code>box-shadow</code>. Давайте используем селектор атрибута для этого:</p> <pre><code tabindex="0" class="language-css">[aria-pressed="true"] { box-shadow: inset 0 0 0 0.15rem #000, inset 0.25em 0.25em 0 #fff; } </code></pre> <p>Чтобы закончить с аналогией с нажатием и его отсутствием, мы можем использовать позиционирование и <code>box-shadow</code>, чтобы сделать ненажатую кнопку выпуклой. В каскаде этот блок должен располагаться над блоком <code>[aria-prressed="true"]</code>.</p> <pre><code tabindex="0" class="language-css">[aria-pressed] { position: relative; top: -0.25rem; left: -0.25rem; box-shadow: 0.125em 0.125em 0 #fff, 0.25em 0.25em #000; } </code></pre> <p><strong>Примечание:</strong> это лишь один из многих методов стилизации такой кнопки. Вы можете найти что-то более очевидное, вроде использования текста «включить» и «выключить» как в следующем примере. Это будет понятно большинству пользователей.</p> <h3>Примечание: не полагайтесь только на цвет</h3> <p>«Включить» часто обозначается зелёным цветом, а «выключить» — красным. Это общепринятое соглашение, и нет ничего плохого в том, чтобы следовать ему. Однако будьте осторожны, когда используете только цвет для описания двух состояний кнопки. В этом случае дальтоники не заметят разницы между ними.</p> <figure> <figcaption> Эти варианты контрола не соответствуют требованиям <a href="https://www.w3.org/TR/2008/REC-WCAG20-20081211/#visual-audio-contrast-without-color">WCAG 2.0 1.4.1 Use Of Color (Level A)</a>. </figcaption> </figure> <h2>Стили фокуса</h2> <p>Это важно для кнопок, как и для <em>всех</em> других интерактивных элементов, у которых есть стили фокуса. Если их не будет, то люди, которые используют клавиатуру для навигации, не увидят какой элемент выбран и что с ним можно взаимодействовать.</p> <p>Лучшие стили фокуса — это те, которые не влияют на расположение (при переходе от одного элемента к другому элементы вокруг них не должны смещаться и отвлекать внимание). Можно использовать <code>outline</code>, но, в большинстве браузеров, <code>outline</code> — это просто рамка вокруг элемента. Для того, чтобы стиль фокуса повторял закруглённые углы нашей кнопки, лучше подходит свойство <code>box-shadow</code>. Если мы уже используем <code>box-shadow</code>, то нужно быть осторожными: учитывать два значения <code>box-shadow</code>, разделённые запятой, при одновременном нажатии кнопки и фокусе на ней.</p> <pre><code tabindex="0" class="language-css">/* Удаляет outline по умолчанию и добавляет внешнюю тень */ [aria-pressed]:focus { outline: none; box-shadow: 0 0 0 0.25rem yellow; } /* Отображает и внутреннюю, и внешнюю тени */ [aria-pressed="true"]:focus { box-shadow: 0 0 0 0.25rem yellow, inset 0 0 0 0.15rem #000, inset 0.25em 0.25em 0 #fff; } </code></pre> <h2>Изменение подписей</h2> <p>В дизайне предыдущего переключателя есть отдельная и уникальная подпись к нему. Разница между двумя состояниями зависит от изменений в атрибуте, которые влияют и на его стиль. Что если нам понадобится сделать кнопку, текст которой изменится с «включён» на «выключен» или с «пауза» на «воспроизведение»?</p> <p>Это очень просто сделать на JavaScript, но есть пара нюансов, которые нужно учесть.</p> <ol> <li>Если подпись изменяется, то что происходит с состоянием элемента?</li> <li>Если текст просто «включён» или «выключен» («воспроизведение» или «пауза», «активен» или «неактивен»), то как мы узнаем, что кнопка на самом деле контрол?</li> </ol> <p>В примере с предыдущим переключателем подпись к нему описывает, что именно будет включено или выключено. Там, где не указано, что включается и выключается, сразу же возникает путаница: нужно ли после того, как я нажал на кнопку и включил что-то, снова на неё нажать, чтобы опять это выключить?</p> <p>В соответствии с правилом большого пальца <em>(это общее правило, которое основано на практическом опыте и почти всегда работает — прим. переводчика)</em> никогда не нужно изменять одновременно состояние «нажата» и текст кнопки. Если текст изменился, то и состояние кнопки тоже в некотором смысле изменилось, но не благодаря явному управлению состоянием с помощью WAI-ARIA.</p> <p>В примере ниже изменяется только текст кнопки.</p> <pre><code tabindex="0" class="language-js">const button = document.querySelector('button'); button.addEventListener('click', (e) => { let text = e.target.textContent === 'Play' ? 'Pause' : 'Play'; e.target.textContent = text; }); </code></pre> <p>Проблема этого метода заключается в том, об изменениях в тексте не объявляется в тот же момент, когда они происходят. Поэтому, когда вы кликаете по кнопке воспроизведения, нет сообщения о том, что она <em>«нажата».</em> Вместо этого вам нужно сначала вручную убрать с неё фокус, а потом выбрать снова, чтобы услышать, что она изменилась. Для зрячих пользователей это не составит труда, но вызовет неудобства у слепых.</p> <p>Часто у кнопок воспроизведения и паузы изменяются иконки: значок воспроизведения (треугольник, стоящий на одной из граней) заменяется на значок паузы (две вертикальные линии). Мы могли бы при этом сохранить скрытый текст кнопки и одновременно изменить состояние элемента.</p> <pre><code tabindex="0" class="language-html"> <button type="button" aria-pressed="false" aria-label="play"> ▶ </button>  <button type="button" aria-pressed="true" aria-label="play"> ⏸ </button> </code></pre> <p>Так как атрибут <code>aria-label</code> перезаписывает содержание текстового узла, в котором находятся символы Юникода, то кнопка паузы будет объявлена так: <em>«Воспроизведение, кнопка не нажата».</em> И, в случае с кнопкой воспроизведения, скринридер произнесёт: <em>«Воспроизведение, кнопка нажата».</em></p> <p>Это везде хорошо работает, кроме случаев, когда идёт речь о распознавании речи и голосовом управлении. В режиме распознавания речи обычно нужно произносить названия кнопок вслух. И, если пользователь увидел кнопку паузы, то его первой мыслью будет произнести «пауза», а не «воспроизведение». Поэтому более надёжный способ — это изменение подписей к элементам, а не переключение их состояния.</p> <figure> <figcaption> Никогда не меняйте одновременно подпись и состояние элемента. В этом примере это приведёт к тому, что состояние паузы станет «нажата». Поскольку видео или аудио в этот момент будут воспроизводиться, с точки зрения языка кнопка паузы не может быть нажата в данный момент. </figcaption> </figure> <h2>Добавление дополнительных подписей</h2> <p>В некоторых случаях может понадобиться добавить в переключатель слова «включить» и «выключить». Нужно убедиться в том, что есть чёткая связь между каждым переключателем и соответствующей ему дополнительной подписью.</p> <p>Представьте настройки уведомления по почте, которые сгруппированы в один список вместе с похожими настройками. Каждый элемент списка содержит описание настройки и выглядит как переключатель. Выражения «включён» и «выключен» — это часть их дизайна. Некоторые элементы <code><span></code> тут нужны для стилизации.</p> <pre><code tabindex="0" class="language-html"><h2>Уведомления</h2> <ul> <li> Уведомлять по почте <button> <span>вкл.</span> <span>выкл.</span> </button> </li> <li> Уведомлять по SMS <button> <span>вкл.</span> <span>выкл.</span> </button> </li> <li> Уведомлять по факсу <button> <span>вкл.</span> <span>выкл.</span> </button> </li> <li> Уведомлять сигнальным огнём <button> <span>вкл.</span> <span>выкл.</span> </button> </li> </ul> </code></pre> <p>Преимущество списка заключается в том, что как видимые, так и скрытые элементы группируются вместе, поэтому видна связь между ними. Списки не только помогают понять взаимосвязь элементов, но и полезны для некоторых скринридеров, которые могут быстро перемещаться как внутри одного списка, так и между несколькими. Например, в JAWS есть горячие клавиши для списков (L) и элементов списков (I).</p> <p>Каждая кнопка и подпись к ней связаны общим элементом списка. Однако отсутствие явного и уникального <code><label></code> — это опасная ситуация, особенно в тех случаях, когда включён режим распознавания речи. Мы можем связать каждую кнопку с текстом элементов списка, используя атрибут <code>aria-labelledby</code>:</p> <pre><code tabindex="0" class="language-html"><h2>Уведомления</h2> <ul> <li> <span id="notify-email">Уведомлять по почте</span> <button aria-labelledby="notify-email"> <span">вкл.</span> <span>выкл.</span> </button> </li> <li> <span id="notify-sms">Уведомлять по SMS</span> <button aria-labelledby="notify-sms"> <span>вкл.</span> <span>выкл.</span> </button> </li> <li> <span id="notify-fax">Уведомлять по факсу</span> <button aria-labelledby="notify-fax"> <span>вкл.</span> <span>выкл.</span> </button> </li> <li> <span id="notify-smoke">Уведомлять сигнальным огнём</span> <button aria-labelledby="notify-smoke"> <span>вкл.</span> <span>выкл.</span> </button> </li> </ul> </code></pre> <p>Каждое значение <code>aria-labelledby</code> соответствует значению атрибута <code>id</code> у элементов с тегом <code><span></code> и устанавливает связь между ними и уникальными подписями у кнопок. Это работает также, как атрибут <code>for</code> элемента <code><label></code> для <code>id</code> в <code><input></code>.</p> <h2>Роль switch</h2> <p>Важно отметить, что атрибут <code>aria-label</code> из ARIA переопределяет содержимое каждой кнопки. Это значит, что мы можем снова использовать <code>aria-pressed</code> для того, чтобы сообщить о состоянии элемента. Однако, если эти кнопки являются переключателями, то мы можем вместо этого использовать роль switch <a href="https://www.w3.org/TR/wai-aria-1.1/#switch">из WAI-ARIA</a>, которая сообщает о состоянии через атрибут <code>aria-checked</code>.</p> <pre><code tabindex="0" class="language-html"><h2>Уведомления</h2> <ul> <li> <span id="notify-email">Уведомлять по почте</span> <button role="switch" aria-checked="true" aria-labelledby="notify-email"> <span>вкл.</span> <span>выкл.</span> </button> </li> <li> <span id="notify-sms">Уведомлять по SMS</span> <button role="switch" aria-checked="true" aria-labelledby="notify-sms"> <span>вкл.</span> <span>выкл.</span> </button> </li> <li> <span id="notify-fax">Уведомлять по факсу</span> <button role="switch" aria-checked="false" aria-labelledby="notify-fax"> <span>вкл.</span> <span>выкл.</span> </button> </li> <li> <span id="notify-smoke">Уведомлять сигнальным огнём</span> <button role="switch" aria-checked="false" aria-labelledby="notify-smoke"> <span>вкл.</span> <span>выкл.</span> </button> </li> </ul> </code></pre> <p>Как вы будете стилизовать активное состояние контрола зависит от вас. Лично я бы не тратил время на запись классов для <code><span></code> с помощью JavaScript. Вместо этого лучше использовать пару CSS-псевдоклассов для поиска элементов <code><span></code> с нужными состояниями.</p> <pre><code tabindex="0" class="language-css">[role="switch"][aria-checked="true"] :first-child, [role="switch"][aria-checked="false"] :last-child { background: #000; color: #fff; } </code></pre> <h3>Перемещаясь по настройкам</h3> <p>Давайте сейчас поговорим о навигации по этому блоку с настройками, используя два разных способа: с помощью клавиши <kbd>Tab</kbd> (перемещаясь только по элементам с фокусом) и с помощью скринридера (проходя через каждый элемент).</p> <p>Даже если вы используете клавишу <kbd>Tab</kbd>, скринридеры объявят не только о сущности и состоянии интерактивных элементов, на которых вы устанавливаете фокус. Например, когда вы выберете первый элемент с классом <code><button></code>, вы услышите, что это переключатель «оповещать по почте» и что он включён. Состояние элемента с ролью <code>switch</code> и <code>aria-checked="true"</code> будет определено как <em>«включено».</em></p> <h3>Примечание: поддержка <code>switch</code></h3> <p>Роль <code>switch</code> поддерживается не так хорошо, как <code>aria-pressed</code>. Например, её не распознаёт ChromeVox — скринридер, который можно установить для Chrome.</p> <p>Однако ChromeVox <em>не поддерживает</em> и <code>aria-checked</code>. Это означает, что он, вместо <em>«Переключатель, уведомлять по почте, включено»</em> объявит <em>«Кнопка, уведомлять по почте, нажата».</em> Это вполне корректно, хотя и не так очевидно. Скорее всего, пользователи просто ошибочно примут переключатель за чекбокс.</p> <p>Любопытно, что NVDA определяет кнопку с <code>role="switch"</code> и <code>aria-checked="true"</code> как переключатель, если она нажата. Так как включение и выключение и нажатие и не нажатие равносильны, это вполне допустимо (хотя немного не соответствует ожиданиям).</p> <p>Однако большинство скринридеров объявит, что вы находитесь в списке из четырёх пунктов и в данный момент выбран первый из них: полезная информация о контексте. Принцип работы примерно такой же, как у заголовка группы элементов, о котором я упоминал выше.</p> <p>Это важно, потому что мы используем <code>aria-labelledby</code> для того, чтобы связать уточняющий текст с кнопкой, по аналогии с использованием <code><label></code>. Это доступно также когда выбран этот режим навигации.</p> <p>Когда вы перемещаетесь от пункта к пункту (например, с помощью клавиши со стрелкой вниз, когда NVDA включён), будет объявлено всё, что встретится на пути, в том числе заголовки <em>(«уведомления, заголовок второго уровня»).</em> Конечно, когда перемещаешься по странице таким образом, текст <em>«уведомлять по почте»</em> объявляется как отдельно, так и вместе с соседней кнопкой. В какой-то степени это повтор, но в данном случае он имеет смысл: «здесь название настройки, а вот здесь её можно включить или выключить».</p> <p>Проблема того, насколько явно нужно связать элементы управления с объектами, которыми они управляют, это один из аспектов UX-дизайна, и ему нужно уделить пристальное внимание. В случае, рассмотренном в этом посте, мы сохраняем наш классический переключатель для зрячих пользователей, при этом не запутывая и не вводя в заблуждение пользователей скринридеров вне зависимости от того, какой режим работы клавиатуры они используют. Это достаточно надёжное решение.</p> <h2>Заключение</h2> <p>Какой дизайн вы выберите и каким образом реализуете переключатели — это ваше дело. Но, надеюсь, вы вспомните этот пост, когда придёт время добавить подобный контрол в вашу библиотеку компонентов. Не вижу причин для того, чтобы переключатели или любой другой элемент интерфейса стали препятствием для пользователей, как это часто бывает.</p> <p>Вы можете изучить здесь основы и добавить разные штрихи в свой дизайн, включая анимацию. Но, в первую очередь, важно заложить прочный фундамент.</p> <h2>Чек-лист</h2> <ul> <li>Используйте элементы форм для переключателей, такие как чекбоксы, если уверены, что пользователь понимает, что они не нужны для отправки данных.</li> <li>Используйте элементы <code><button></code> с атрибутами <code>aria-pressed</code> или <code>aria-checked</code>, а не ссылки.</li> <li>Не меняйте одновременно подпись к элементу и его состояние.</li> <li>Когда используете в подписи текст «включён» и «выключен» (или что-то подобное), можете переопределить их с помощью атрибута <code>aria-labelledby</code>.</li> <li>Будьте осторожны и убедитесь, что уровень контраста между текстом кнопки и её фоновым цветом соответствует рекомендациям WCAG 2.0 <em>(сейчас уже актуальна <a href="https://www.w3.org/TR/WCAG21/#contrast-minimum">WCAG 2.1</a> — прим. переводчика).</em></li> </ul> </article> <article> <h1>WebP сегодня: зачем и как?</h1> <p>Tue, 25 Dec 2018 00:00:00 GMT</p> <p><a href="https://developers.google.com/speed/webp/">WebP</a> — формат графики, разработанный Google в 2010. Он был создан, как альтернатива PNG и JPG, и отличается от них гораздо меньшим размером при том же качестве изображения.</p> <figure> <figcaption> Интерфейс оптимизатора <a href="https://squoosh.app/">Squoosh</a>. </figcaption> </figure> <h2>Почему WebP?</h2> <p>WebP — крайне полезный формат, ведь он даёт и производительность и возможности. В отличие от других форматов, WebP поддерживает сжатие как с потерями так и без, а также полупрозрачность и анимацию.</p> <figure> <figcaption> Сравнение возможностей форматов WebP, PNG, JPG, GIF. </figcaption> </figure> <p>И даже со всеми этими возможностями, WebP обеспечивает меньший размер чем его конкуренты. В <a href="https://developers.google.com/speed/webp/docs/c_study#results">сравнительном исследовании формата</a> было установлено, что изображения в формате WebP, сжатые с потерями, в среднем на 30% меньше, чем в формате JPG, а сжатые без потерь — в среднем на 25% меньше чем в формате PNG.</p> <h2>Как сконвертировать картинки в WebP?</h2> <p>Есть несколько инструментов, которыми можно конвертировать JPG, PNG и другие форматы в WebP.</p> <h3>Онлайн-инструменты</h3> <ul> <li><a href="https://squoosh.app/">Squoosh</a> — конвертация и сжатие онлайн</li> <li><a href="http://online-convert.com/">Online-Convert.com</a> — конвертация онлайн</li> </ul> <h3>Инструменты командной строки</h3> <p><a href="https://www.npmjs.com/package/cwebp">Cwebp</a> — самая популярная утилита для командной строки, для преобразовать изображения в формат WebP. После установки, мы можем конвертировать изображения указав качество, входной и выходной файлы.</p> <pre><code tabindex="0" class="language-sh"># cwebp -q [quality] [input_file] -o [output_file] cwebp -q 75 image.png -o image.webp </code></pre> <h3>Инструменты для Node.js</h3> <p><a href="https://github.com/imagemin/imagemin">Imagemin</a>, вместе с плагином <a href="https://github.com/imagemin/imagemin-webp">imagemin-webp</a> — самая популярная библиотека для конвертации изображений в формат WebP. Вот пример скрипта, который преобразует в WebP все PNG- и JPG-файлы в папке.</p> <pre><code tabindex="0" class="language-js">/* convert-to-webp.js */ const imagemin = require('imagemin'); const webp = require('imagemin-webp'); imagemin(['*.png', '*.jpg'], 'images', { use: [ webp({ quality: 75}) ] }); </code></pre> <p>Теперь, мы можем использовать этот скрипт из командной строки или с помощью сборщика:</p> <pre><code tabindex="0" class="language-sh">node convert-to-webp.js </code></pre> <h3>Sketch</h3> <p>В Sketch мы можем экспортировать любой слой в формате WebP.</p> <figure> <figcaption> Интерфейс экспорта графики в <a href="https://www.sketchapp.com/">Sketch</a>. </figcaption> </figure> <h2>Что с поддержкой?</h2> <p>На момент написания статьи <em>(21 ноября 2018 — прим. редактора),</em> WebP поддерживается в 72% браузеров.</p> <figure> <figcaption> <a href="https://caniuse.com/#feat=webp">Поддержка WebP на Can I use</a>. </figcaption> </figure> <p>Хотя всего этого вполне достаточно чтобы убедиться в преимуществах WebP, всё же не стоит просто полагаться на формат без фолбэка. В браузерах, которые не поддерживают WebP, картинки будут поломаны.</p> <p>Мы можем сделать фолбэк для WebP используя элемент <code></code>. Этот HTML5-элемент позволяет нам добавлять несколько форматов для одной картинки.</p> <pre><code tabindex="0" class="language-html"> </picture> </code></pre> <p>Для добавления альтернативных форматов, мы используем элемент <code></code> вместе с <code></code>. У элемента <code></code> есть несколько атрибутов, которые мы можем использовать, чтобы определить изображение и когда оно будет использовано.</p> <ul> <li><code>type</code> для <a href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Basics_of_HTTP/MIME_types/Complete_list_of_MIME_types">MIME-типа</a> формата</li> <li><code>srcset</code> для пути к файлу изображения. Несколько файлов могут быть использованы для изображений разных размеров и плотности пикселей.</li> <li><code>sizes</code> для перечня размеров каждого файла.</li> <li><code>media</code> для медиавыражения, которое определяет, какое изображение будет использовано.</li> </ul> <p><em>Подробнее об этих атрибутах и адаптивных картинках читайте в статье Ире «<a href="https://bitsofco.de/the-srcset-and-sizes-attributes/">Responsive Images — The srcset and sizes Attributes</a>» — прим. редактора.</em></p> <p>В дополнение к различным <code></code>, также нужно добавить обычный элемент <code></code>, как фолбэк для браузеров, которые не поддерживают множественные форматы и <code></code>.</p> </article> <article> <h1>Доступные SVG-иконки с инлайновыми спрайтами</h1> <p>Mon, 17 Dec 2018 00:00:00 GMT</p> <p>Если вы ищете повод использовать иконки в проекте, то далеко ходить не надо. Как хорошо заметил <a href="https://ia.net">Оливер Рейхенштейн</a> в своём докладе <a href="https://vimeo.com/184776819">«Об иконках»</a> на Smashing Conf во Фрайбурге: <em>«На определённом этапе проекта кто-нибудь обязательно приходит и говорит: нам нужны иконки!».</em> Так зачем они нужны людям?</p> <ul> <li>Иконки помогают заполнять небольшие пространства, где сложно использовать текст.</li> <li>У них может быть общепринятое значение, которое не зависит от языка.</li> <li>Они — средство индивидуализации.</li> <li>Они могут привлечь внимание к важным элементам пользовательского интерфейса.</li> </ul> <p>Вне зависимости от аргументации, нам нужно быть уверенными в том, что люди, которые не могут видеть или распознать иконки, понимают их назначение.</p> <figure> <figcaption>Нажать кнопку, получить бекон — это же очевидно.</figcaption> </figure> <p>Сами по себе иконки могут неправильно интерпретироваться, что продемонстрировала Мэлори ван Ахтерберг во время своего доклада на Fronteers в 2017. Их самая главная проблема — отсутствие текста. <a href="https://www.w3.org/TR/WCAG20/#guidelines">Текст — самый доступный вид информации в вебе</a>. Скринридеры понимают его лучше всего. Это относится к большинству вспомогательных технологий, например, к приложениям для переводов и брайлевским дисплеям. Поэтому, если на нашей странице есть нетекстовая информация, например, иконки, мы должны добавить текст, который дублирует для пользователей её значение. Иначе мы можем сделать наши интерфейсы сложными для понимания.</p> <figure> <figcaption>Что вы сделаете в первую очередь, если увидите, что кто-то тонет? LOL.</figcaption> </figure> <h2>Как использовать SVG-графику для иконок</h2> <p>SVG или масштабируемая векторная графика (Scalable Vector Graphic) — это часть спецификации расширяемого языка разметки (Extensible Markup Languag, XML), которая может быть встроена в HTML-документ при помощи элемента <code><svg></code>, как в примере кода ниже (в нём SVG — стрелка в браузере, указывающая вниз):</p> <pre><code tabindex="0" class="language-html"><body> <svg viewBox="0 0 10 10"> <path d="m5 9-3-4h2v-4h2v4h2z"/> </svg> </body> </code></pre> <p>В этом простом примере есть всё, что нужно для отображения SVG в <a href="https://caniuse.com/#feat=svg">браузерах, которые её поддерживают</a>. Однако, без указания высоты и ширины, SVG будет отображаться настолько большой, насколько это позволит доступная область просмотра. В примере ниже показано как это исправить:</p> <pre><code tabindex="0" class="language-html"><body> <svg width="10" height="10" viewBox="0 0 10 10"> <path d="m5 9-3-4h2v-4h2v4h2z"/> </svg> </body> </code></pre> <p>Одиночный вспомогательный CSS-класс, присвоенный нашим SVG-иконкам, задаёт им нужное поведение. Затем он переопределяет эти значения и отлично масштабирует иконки в соответствии с размером текста.</p> <pre><code tabindex="0" class="language-css">.svg-icon { /* Разместить иконку выше базового текста. */ position: relative; top: 0.125em; /* Не дать иконке сжаться внутри flex-контейнера. */ flex-shrink: 0; /* * Масштабировать иконку до размера шрифта родительского * элемента. */ height: 1em; width: 1em; /* Установить для иконки любой цвет, который задан родителю. */ fill: currentColor; /* * Если иконка используется в ссылке, для которой задан цветовой * переход, мы можем также задать для fill нужное значение * transition. */ transition: fill 0.3s; } </code></pre> <p>Ниже пример HTML-кода:</p> <pre><code tabindex="0" class="language-html"><body> <svg class="svg-icon" width="10" height="10" viewBox="0 0 10 10"> <path d="m5 9-3-4h2v-4h2v4h2z"/> </svg> </body> </code></pre> <p><a href="https://codepen.io/Nice2MeatU/pen/YNEXMj">Я сделал демо на CodePen</a>, чтобы показать, на что способен этот одиночный CSS-селектор. Мы можем увеличить или уменьшить значение <code>font-size</code> для параграфа в инспекторе CSS и увидеть, как иконка увеличивается вместе с текстом. Мы также можем изменить значение <code>color</code> и посмотреть, как это повлияет на неё. При наведении курсора на ссылку или при фокусе на ней одновременно изменяется как цвет ссылки, так и цвет заливки иконки.</p> <p>Решая эту проблему, мы сталкиваемся с другой: нам не хватает текстового эквивалента для графики, которую мы добавили на нашу страницу.</p> <h2>Делаем SVG-иконку доступной</h2> <p>Давайте предположим, что нам нужно создать кнопку, которая переключает видимость навигации по сайту. При первом нажатии на неё навигация будет показана, а при повторном снова скрыта. Надеюсь, что все согласны, что кнопка — это кнопка, и <a href="https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_button_role">поэтому она должна быть</a> <code><button></code>. В нашем случае дизайн-макета недостаточно. Всё, что дал нам дизайнер — это иконка гамбургера, без текста. Переключаемся на редактор: добавляем в кнопку SVG.</p> <pre><code tabindex="0" class="language-html"><button type="button"> <svg class="svg-icon" width="10" height="10" viewBox="0 0 10 10" role="img"> <path d="m1 7h8v2h-8zm0-3h8v2h-8zm0-3h8v2h-8z"/> </svg> </button> </code></pre> <p>Теперь нужно добавить немного текста, с которым могли бы взаимодействовать вспомогательные технологии. Используя инлайновый SVG, мы можем добавить элемент <code><title></code> для первого дочернего элемента <code><svg></code> и присвоить ему ID. Затем нам нужно сослаться на нужное значение ID с помощью атрибута <code>aria-labelledby</code>, который задан открывающему тегу <code><svg></code>:</p> <pre><code tabindex="0" class="language-html"><button type="button"> <svg class="svg-icon" width="10" height="10" viewBox="0 0 10 10" role="img" focusable="false" aria-labelledby="menu-icon-title"> <title id="menu-icon-title">Меню</title> <path d="m1 7h8v2h-8zm0-3h8v2h-8zm0-3h8v2h-8z"/> </svg> </button> </code></pre> <p>Теперь, когда кто-то установит фокус на кнопке, будет объявлен текст заголовка (некоторые браузеры даже показывают текст внутри <code><title></code> в виде всплывающей подсказки). Обратите внимание на сочетание атрибута и значения <code>focusable="false"</code> в SVG! Это помешает установить фокус на SVG в Internet Explorer и Microsoft Edge. <a href="https://github.com/PolymerElements/iron-icon/issues/71">Это баг</a>, который не исправлен для 10 и 11 версий Internet Explorer.</p> <h3>У нас есть варианты</h3> <p>Есть другой способ добавить скрытый текст рядом с иконкой. Для него HTML и вспомогательный CSS-класс нужны чуть меньше, и он работает так же как в примере выше.</p> <p>Вы можете использовать элемент <code><span></code>, чтобы обернуть текст и визуально скрыть от пользователя. С помощью этого мы предоставляем вспомогательным технологиям описание иконки в текстовом виде, не изменяя дизайна кнопки.</p> <pre><code tabindex="0" class="language-html"><button type="button"> <svg class="svg-icon" width="10" height="10" viewBox="0 0 10 10" role="img" focusable="false" aria-hidden="true"> <path d="m1 7h8v2h-8zm0-3h8v2h-8zm0-3h8v2h-8z"/> </svg> <span class="visually-hidden"> Меню </span> </button> </code></pre> <p>Вспомогательный CSS-класс выглядит так:</p> <pre><code tabindex="0" class="language-css">.visually-hidden { /* Убрать текст из потока */ position: absolute; /* Уменьшить его высоту и ширину до одного пикселя */ height: 1px; width: 1px; /* Скрыть выходящие за пределы контейнера элементы или текст */ overflow: hidden; /* Установить для clip нулевое значение */ clip: rect(0, 0, 0, 0); /* Текст не будет перенесён на вторую строку */ white-space: nowrap; } </code></pre> <h3>Не сильно отличающийся пример</h3> <p>И вот наши дизайнеры решили добавить другую кнопку с <em>текстом</em> и <em>иконкой</em> рядом с ним. Если у вас есть текст рядом с иконкой, то не добавляйте заголовок и описание, а замените <code>role="img"</code> у SVG на <code>aria-hidden="true"</code>. Добавление к элементу атрибута <code>aria-hidden="true"</code> полностью удаляет его и его дочерние элементы из дерева доступности. Такой элемент не будет доступен для Accessibility API:</p> <pre><code tabindex="0" class="language-html"><button type="button"> Меню <svg class="svg-icon" viewBox="0 0 10 10" focusable="false" aria-hidden="true"> <path d="m1 7h8v2h-8zm0-3h8v2h-8zm0-3h8v2h-8z"/> </svg> </button> </code></pre> <p>Поскольку у нас есть текст, который объясняет назначение кнопки, иконка стала просто декоративным элементом. Когда мы имеем дело с декоративными изображениями или графикой, нам нужно скрыть их из дерева доступности.</p> <p>Вот демо, которое демонстрирует все четыре варианта кнопки: <a href="https://codepen.io/Nice2MeatU/pen/dqmypX">создание кнопки с доступной SVG-иконкой</a>.</p> <p>Установив фокус на кнопке, скринридер объявит: <em>«Меню, кнопка».</em> Прекрасно. Однако теперь, визуально, мы получили тот же SVG, но с другим кодом. Представьте, что вам нужно добавить иконки в другом контексте, в котором подписи из первого варианта не используются. А потом ещё в одном. И ещё. Этот вариант не идеален.</p> <p>Нам нужно быть осторожными, и не задать <code>aria-hidden="true"</code> для элемента с <code>role="none"</code>! У них разные сценарии использования и конечные результаты. <a href="https://www.scottohara.me">Скотт Охара</a> написал <a href="https://medium.com/p/ab1241ea9166">замечательную статью</a> о том, когда и какой из атрибутов использовать.</p> <h2>Пишите меньше кода — используйте спрайт</h2> <p>Процитирую слова <a href="https://www.heydonworks.com">Хейдона Пикеринга</a> из его доклада <a href="https://vimeo.com/190834530">«Пишите меньше чёртового кода»</a> с <a href="https://beyondtellerrand.com/events/berlin-2016/speakers">Beyond Tellerrand Berlin 2016</a>: <em>«Чем меньше кода, тем код лучше! Меньше кода, над которым нужно думать. Меньше кода поддерживать. Меньше данных передавать по сети».</em></p> <p>Представьте следующую ситуацию: спустя несколько недель наш дизайнер добавил все необходимые иконки в дизайн-макет. У нас есть много разных иконок, с которыми нужно что-то делать, и разные варианты использования: некоторым нужен заголовок и описание, а другие должны быть скрыты. Понадобится много времени, чтобы создать иконки с разными атрибутами и текстовыми описаниями. И поэтому появился SVG-спрайт и сэкономил нам кучу времени!</p> <p>Разместив пустой <code><svg></svg></code> в качестве первого потомка открывающего тега <code><body></code> и скрыв его от всех (зрячих или нет) при помощи инлайнового <code>display: none</code>, мы создали пространство для вставки наших иконок. Важно именно инлайново задать <code>display: none</code>, потому что мы не хотим, чтобы спрайт был видим при загрузке наших таблиц стилей браузером! Если у вас есть критические стили для сайта, вы можете добавить свойство туда, и не трогать спрайт.</p> <pre><code tabindex="0" class="language-html"> <body> <svg style="display: none"></svg> </body> </code></pre> <p><strong>Примечание</strong>: это только <em>один</em> из множества вариантов создания SVG-спрайта! Есть несколько способов сделать это, но в этой статье невозможно объяснить их все. <a href="https://www.sarasoueidan.com">Сара Суайдан</a> очень подробно рассказывает о различных <a href="https://www.sarasoueidan.com/blog/overview-of-svg-sprite-creation-techniques/">вариантах создания SVG-спрайта</a> со всеми преимуществами и проблемами, которые имеются в каждом из подходов.</p> <p>При использовании SVG-спрайта для системы иконок можете не трогать SVG. Поскольку вы собираетесь использовать одну иконку в элементе <code><svg></code>, вам понадобится подписать её или вообще скрыть, если она декоративная.</p> <p>В общем, всегда следует оптимизировать SVG-код независимо от сценария использования. К счастью для нас, поскольку это интернет и в нём есть миллион инструментов, созданных миллионами людей, нам не нужно самим выполнять эту тяжёлую работу.</p> <h2>SVGO(MG)</h2> <p>Есть много способов оптимизировать и упростить SVG-код перед тем, как добавить его в HTML-документ. Первый и наиболее результативный — открыть SVG в редакторе и удалить всё ненужное вручную. Это также и самый трудоёмкий вариант, и высока вероятность удалить то, что нам могло бы пригодиться потом. Я советую сделать это один или два раза, чтобы лучше понять структуру SVG-файла, но не рекомендую постоянно так делать.</p> <p>Для тех, кто предпочитает командную строку графическому интерфейсу, есть <a href="https://github.com/svg/svgo">svgo</a>. Мы можем добавить массу параметров для оптимизации SVG: что удалить, что оставить и даже что оставить принудительно. Для тех, кто предпочитает таск-менеджеры, есть <a href="https://github.com/sindresorhus/grunt-svgmin">grunt-svgmin</a> и точно такой же <a href="https://github.com/ben-eb/gulp-svgmin">gulp-svgmin</a>, в которых используется SVGO. Сара Суайдан сделала <a href="https://www.sarasoueidan.com/blog/svgo-tools/">отличный обзор существующих инструментов</a> с их преимуществами и недостатками.</p> <p>Если вам больше нравятся инструменты с графическим интерфейсом, есть <a href="https://jakearchibald.github.io/svgomg/">SVGOMG,</a> который сделал <a href="https://jakearchibald.com">Джейк Арчибальд</a>. Он такой же мощный как вариант с командной строкой и сразу показывает результат (код и изображение). Вместо того, чтобы писать параметры в нашем терминале, мы можем на правой панели выбрать нужную опцию или убрать её. Единственная оговорка: может быть довольно утомительно загружать и оптимизировать каждую иконку по отдельности.</p> <h2>Создание спрайта</h2> <p>До использования SVGOMG наши иконки могут выглядеть как в примере ниже. Это зависит от того, какими программами для создания графики вы пользуетесь (в примере показан SVG-код, который был создан в Adobe Illustrator при выборе параметра «Сохранить как»):</p> <pre><code tabindex="0" class="language-xml"><?xml version="1.0" encoding="utf-8"?>  <svg version="1.1" id="Layer_1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" x="0px" y="0px" width="24px" height="24px" viewBox="0 0 24 24" enable-background="new 0 0 24 24" xml:space="preserve"> <path d="M7.41,8.59L12,13.17l4.59-4.58L18,10l-6,6l-6-6L7.41,8.59z"/> <path fill="none" d="M0,0h24v24H0V0z"/> </svg> </code></pre> <p><strong>Примечание:</strong> если выбрать в Adobe Illustrator параметр «Экспорт», то получится более чистый SVG-код!</p> <p>Открывая SVG в браузере, мы видим угол 90 градусов, направленный вниз. Пропустив этот код через SVGOMG со всеми выбранными чекбоксами, мы получим хороший минифицированный SVG-файл.</p> <p><strong>Примечание</strong>: единственная опция, которую не надо выбирать — это «Remove ViewBox»! Нам часто требуется сохранить для иконок <a href="https://www.sarasoueidan.com/blog/svg-coordinate-systems/#svg-viewbox">атрибут viewBox</a>, чтобы они правильно отображались!</p> <p>Посмотрим, что осталось после оптимизации:</p> <pre><code tabindex="0" class="language-xml"><svg viewBox="0 0 24 24"> <path d="M7.41 8.59L12 13.17l4.59-4.58L18 10l-6 6-6-6 1.41-1.41z"/> <path fill="none" d="M0 0h24v24H0V0z"/> </svg> </code></pre> <p>После добавления SVG-кода в спрайт, нам только осталось слегка его изменить (я добавил переносы строк для того, чтобы код стал более читаемым):</p> <pre><code tabindex="0" class="language-xml"><svg style="display: none"> <symbol id="icon-angle-down" viewBox="0 0 24 24"> <path d="M7.41 8.59L12 13.17l4.59-4.58L18 10l-6 6-6-6 1.41-1.41z"/> <path fill="none" d="M0 0h24v24H0V0z"/> </symbol> </svg> </code></pre> <p>Мы заменили <code><svg></code> на <code><symbol></code> и задали иконке уникальный ID, поэтому можем использовать её в другой части нашей страницы. Самым большим преимуществом этого подхода является возможность бесконечно использовать одну иконку и задавать ей подпись для каждого случая использования. Нет необходимости создавать иконку больше одного раза:</p> <pre><code tabindex="0" class="language-html"><button type="button"> <svg class="svg-icon" role="img" focusable="false" aria-labelledby="toggle-nav-icon-title"> <title id="toggle-nav-icon-title">Меню</title> <use xlink:href="#icon-angle-down"/> </svg> </button> <a href="#next-section"> <svg class="svg-icon" role="img" focusable="false" aria-labelledby="next-section-icon"> <title id="next-section-icon">Перейти к следующему разделу.</title> <use xlink:href="#icon-angle-down"/> </svg> </a> <button type="button"> <svg class="svg-icon" aria-hidden="true" focusable="false"> <use xlink:href="#icon-angle-down"/> </svg> Нажмите на кнопку вниз! </button> <p> Прокрутите вниз для получения дополнительной информации! <svg class="svg-icon" aria-hidden="true" focusable="false"> <use xlink:href="#icon-angle-down"/> </svg> </p> </code></pre> <p>С помощью одиночного тега <code><use></code> мы можем ссылаться на ID этого SVG в спрайте. В примере выше у нас есть четыре разных сценария использования, все с одной и той же иконкой. Мы можем скрыть их, когда они используются как декоративные элементы, или подписать, когда это нужно. Круто!</p> <p><a href="https://codepen.io/Nice2MeatU/pen/dqmyaR">Взгляните на демо</a>. Нет никакой разницы между тем, как выглядят иконки, но разница в количестве кода, используемого для их отображения, огромна.</p> <h2>Заключение</h2> <p>Надеюсь, что этот материал был вам полезен, и вы прямо сейчас готовы использовать SVG-иконки в своих проектах. В этой маленькой статье невозможно объяснить все основные идеи. Чтобы помочь вам глубже погрузиться в океан SVG, я собрал здесь несколько ссылок на другие статьи и книги по этой теме.</p> <h2>Дополнительные источники</h2> <ul> <li><a href="https://www.sarasoueidan.com">Сара Суайдан</a> написала <a href="https://www.sarasoueidan.com/blog/overview-of-svg-sprite-creation-techniques/">«An overview of SVG Sprite Creation Techniques»</a>.</li> <li>Она также объясняет, как перейти от иконочного шрифта к SVG-спрайтам в <a href="https://www.sarasoueidan.com/blog/icon-fonts-to-svg/">«Making the Switch Away from Icon Fonts to SVG»</a>.</li> <li><a href="https://www.hmig.me">Хезер Мильориси</a> рассказывает обо всех упущенных здесь подробностях, как сделать SVG доступным для всех в <a href="https://css-tricks.com/accessible-svgs/">«Accessible SVG»</a>.</li> <li><a href="https://sarahdrasnerdesign.com">Сара Дрэснер</a> написала замечательную книгу об <a href="http://shop.oreilly.com/product/0636920045335.do">SVG-анимации</a>. В ней есть все советы, которые могут понадобиться для анимации SVG-графики.</li> <li><a href="https://www.scottohara.me">Скотт Охара</a> написал <a href="https://medium.com/p/ab1241ea9166">подробную статью</a> о том, когда использовать <code>role="none"</code> или <code>role="presentation"</code>, а когда <code>aria-hidden="true"</code>.</li> <li><a href="https://chriscoyier.net">Крис Койер</a> собрал вместе довольно много полезной информации и статей на эту тему в <a href="https://css-tricks.com/mega-list-svg-information/">«SVG Compendium»</a>.</li> <li>Он также написал книгу <a href="https://abookapart.com/products/practical-svg">«Practical SVG»</a> для <a href="https://abookapart.com/">A Book Apart</a>.</li> </ul> <h2>Благодарность</h2> <p>Знания, накопленные мной за то время, которое мы говорим об SVG, а также о доступности, получены из книг, постов в блогах и учебных пособий. Также я слежу за профилями людей в социальных сетях, которые работают в этой области и написали эти самые книги, посты и пособия. Конечно же помогли в этом и бесконечные ковыряния в коде, а также написание разных вещей и их ломание.</p> <p>Итак, без лишних слов, спасибо Леони Уотсон, Лоре Калбаг, Лии Веру, Саре Суайдан, Саре Дрэснер, Вал Хед, Серене Дэвис, Марси Саттон, Кэри Фишер, Зоуи Гилленуотер, Хезер Мильориси, Мэлори ван Ахтерберг, Стиву Фолкнеру, Патрику Лауке, Хейдону Пикерингу, Нилу Милликену, Николасу Стинхауту, Марко Цехе, Хьюго Жироделю, Гуннару Биттерсману, Эрику Бэйли, Алану Далтону, Крису Койеру, Брюсу Лоусону, Аарону Густавсону, Скотту Охаре, всей Paciello Group, A List Apart и A Book Apart, Khan Academy, командам Pa11y и tenon.io, а также тем, кого я забыл здесь упомянуть.</p> <p>Спасибо всем тем, кто (надеюсь) никогда не сдаётся, и объясняет другим (и мне), почему доступность важна, и как сделать интернет более инклюзивным местом.</p> </article> <article> <h1>Просто используйте стили для :focus, чёрт возьми</h1> <p>Mon, 10 Dec 2018 00:00:00 GMT</p> <p>За последнее время появилось несколько статей и рекомендаций от разных людей о том, как использовать псевдокласс <code>:focus-visible</code>, чтобы показать стили для <code>:focus</code>, когда кто-то пользуется клавиатурой, и скрывать их, если пользователь использует мышь.</p> <p>Лучшее из того, что я видел, <a href="https://twitter.com/LeaVerou/status/1045768279753666562">предложила Лия Веру</a>:</p> <blockquote> <p>Я собираюсь начать добавлять следующее правило во все мои таблицы стилей: <code>:focus:not(:focus-visible) { outline: none }</code> Избавляет пользователей мыши от раздражающего <code>outline</code>, но сохраняет его для пользователей клавиатуры и не учитывается браузерами, которые не поддерживают <code>:focus-visible</code>.</p> </blockquote> <p>Аргументация всегда одинаковая: обводка фокуса (эти рамки вокруг ссылок, кнопок и других элементов, на которых можно сделать фокус) — отстой. Нам нужно добавлять их только потому, что они нужны пользователям клавиатуры.</p> <p>Чушь собачья.</p> <p>Стили фокуса действительно потрясающие. У моего друга Эрика Бэйли есть отличная презентация об этом:</p> <p><a href="https://noti.st/ericwbailey/TcMJFP/embed">If it’s interactive, it needs a focus style. October 15, 2018. #a11yTOConf</a></p> <p>Лично мне они нравятся по той же причине, по которой мне нравятся стили для :visited на перегруженных ссылками страницах.</p> <p>Даже если ты пользуешься мышью, полезно знать, на чём сейчас сделан фокус, потому что я <em>иногда ещё использую и клавиатуру.</em> Часто они взаимозаменяемы. Может быть мой пример притянут, но знаете ли вы, как каждый из пользователей пользуется вашими сайтами и приложениями?</p> <p>Мы продолжаем совершать одинаковую ошибку снова и снова, предполагая, что знаем, как наши пользователи хотят использовать то, что мы создаём, или что они такие же, как мы.</p> <p>К тому же стили фокуса не обязательно должны быть уродливыми. Я думаю, что стили по умолчанию замечательные, но вы можете принимать какие угодно творческие решения, чтобы они выглядели лучше.</p> <p>Моя позиция: просто используйте стили фокуса на своём сайте. Для всего, на чём можно сделать фокус. Для каждого пользователя.</p> </article> <article> <h1>Полезные правила доступности, которые останутся в памяти</h1> <p>Wed, 28 Nov 2018 00:00:00 GMT</p> <figure> <figcaption> «Параолимпийские игры изменяют наше восприятие мира», Стивен Хокинг. То же можно сказать о доступности. </figcaption> </figure> <p>Впервые я столкнулся с доступностью ещё в 2015, когда работал на американского розничного гиганта. Тогда компания получила огромный иск из-за сайта, который нарушал Закон об американцах-инвалидах (Americans with Disabilities Act, ADA). После этого мы с командой много работали над приведением сайта в соответствие с нормами ADA. Тогда я и познакомился со многими принципами доступности.</p> <p>Однако в последующие годы, я постоянно нарушал эти принципы, хотя регулярно с ними сталкивался. Почему-то я не помнил о них во время кодинга. Не хотелось признавать, но я определённо не полностью их усвоил.</p> <p>В конце концов я решил, что пора найти время и свести все эти принципы к простым и полезным правилам, которые просто держать в уме. Наконец, я сделал это, и с тех пор они неплохо для меня работают.</p> <p>Эта статья состоит из двух частей: что такое доступность и три полезных правила доступности. В первой части я напомню, что такое доступность, и поделюсь своим опытом. Если хотите перейти к главному, то можете сразу начать со второй части.</p> <h2>Что такое доступность?</h2> <p>Как я уже упоминал, в 2015 году моя компания получила иск за несоблюдение ADA.</p> <p><a href="https://www.ada.gov">ADA</a> — закон о гражданских правах, который:</p> <blockquote> <p>Запрещает дискриминацию людей с инвалидностью во всех сферах жизни общества, включая работу, школы, транспорт и все публичные и частные места, которые доступны для широкого круга граждан.</p> </blockquote> <p>Таким образом, ADA требует, чтобы фирмы, государственные и местные органы власти, а также некоммерческие организации предоставляли инвалидам доступ к сервисам наравне с трудоспособными гражданами. Аналогичным образом федеральные органы власти должны соблюдать федеральный закон, который называется <a href="https://www.section508.gov">Section 508</a>.</p> <p>В контексте интернета все публичные сайты США, которые не соблюдают ADA или Section 508, исключают из числа своих посетителей большие группы пользователей с разной степенью нарушений.</p> <p>С другой стороны, инклюзивный подход к созданию контента сайта, доступного для всех вне зависимости от их функциональных возможностей, называется <a href="https://en.wikipedia.org/wiki/Web_accessibility">доступностью</a> или просто <a href="https://a11yproject.com/posts/a11y-and-other-numeronyms/">a11y</a>.</p> <h3>От переводчика</h3> <p>В России доступность регулируется тремя документами:</p> <ol> <li>Государственный стандарт <a href="http://docs.cntd.ru/document/1200103663">«ГОСТ Р 52872–2012 Интернет-ресурсы. Требования доступности для инвалидов по зрению»</a>. Был введён в 2014. Содержит рекомендации, а не жёсткие требования, как и любой другой ГОСТ.</li> <li><a href="https://minsvyaz.ru/ru/documents/4985/">Приказ министерства связи и массовых коммуникаций России № 483</a> «Об установлении порядка обеспечения условий доступности для инвалидов по зрению официальных сайтов федеральных органов государственной власти, органов государственной власти субъектов Российской Федерации и органов местного самоуправления в сети интернет». Принят в ноябре 2015.</li> <li><a href="http://www.consultant.ru/document/cons_doc_LAW_171577/">Федеральный закон № 419-ФЗ</a> «О внесении изменений в отдельные законодательные акты Российской Федерации по вопросам социальной защиты инвалидов в связи с ратификацией конвенции о правах инвалидов». Вступил в силу в январе 2016.</li> </ol> <h3>Кому нужна доступность?</h3> <p>Согласно <a href="http://www.who.int/disabilities/world_report/2011/report/en/">Всемирному докладу об инвалидности</a> <em>(есть версия на русском — прим. редактора),</em> опубликованному в 2011 году <a href="http://www.who.int">Всемирной организацией здравоохранения (ВОЗ)</a>, примерно 15% мирового населения живёт с той или иной формой инвалидности. Из них примерно 2–4% испытывают серьёзные трудности с нормальным функционированием.</p> <p>В превосходной статье замечательного Эдди Османи <a href="https://medium.com/@addyosmani/accessible-ui-components-for-the-web-39e727101a67">«Доступные UI-компоненты для веба»</a>, речь идёт о четырёх основных видах нарушений, которые рассматриваются в контексте доступности:</p> <ol> <li><strong>Проблемы со зрением</strong>: могут варьироваться от неспособности различать цвета до полного отсутствия зрения.</li> <li><strong>Проблемы со слухом</strong>: означают, что у пользователя проблемы с распознаванием звуков, которые звучат со страницы.</li> <li><strong>Проблемы с мобильностью</strong>: могут включать невозможность управлять мышью, клавиатурой или сенсорным экраном.</li> <li><strong>Когнитивные проблемы</strong>: означают, что пользователю могут потребоваться вспомогательные технологии для чтения текста, так что важно использовать альтернативы для текстовой информации.</li> </ol> <p>Имейте в виду, что диапазон нарушений обширен. Это означает, что совсем не обязательно иметь серьёзные нарушения для того, чтобы нужна была доступность.</p> <p>Если хотите больше об этом узнать, то рекомендую пройти на Udacity бесплатный курс <a href="https://www.udacity.com/course/web-accessibility--ud891">Web Accessibility</a> от Google. Это видео из курса, которое рассказывает об этих видах нарушений:</p> <h3>Хорошо, как обеспечить поддержку доступности?</h3> <p>К тому моменту, как мы получили иск в 2015, уже был проведён аудит, который выявил множество проблем с доступностью. Наша команда прошла однодневный курс по доступности, на котором мы узнали о <a href="https://www.w3.org/TR/WCAG21/">Web Content Accessibility Guidelines</a> (сокращённо WCAG, сейчас в версии 2.1). Это руководство считается стандартом по доступности.</p> <p>WCAG разработан группой <a href="https://www.w3.org/WAI/">Web Accessibility Initiative</a> (WAI), которая входит в <a href="https://www.w3.org">W3C</a>. Она же разработала <a href="https://www.w3.org/TR/wai-aria-1.1/">Accessible Rich Internet Applications</a> (WAI-ARIA или просто ARIA, актуальная версия 1.1). Это спецификация о том, как сделать страницы доступными путём добавления ролей и атрибутов ARIA в HTML-разметку.</p> <p>Эти спецификации включают три уровня соответствия и приоритетов:</p> <ul> <li>A (можно поддерживать, низший).</li> <li>AA (следует поддерживать, средний).</li> <li>AAA (нужно поддерживать, наивысший).</li> </ul> <p>Многие законы о доступности во всём мире основаны на критериях выполнения WCAG. Например, в январе 2017 года Section 508 был принят в соответствии с критерием AA WCAG 2.0.</p> <p><em>Прим. переводчика: Не исключение и «ГОСТ Р 52872–2012 Интернет-ресурсы. Требования доступности для инвалидов по зрению». Он разработан на основе WCAG.</em></p> <p>Отлично обобщает все рекомендации <a href="https://webaim.org/standards/wcag/checklist">чек-лист WebAIM WCGA</a>. В нём для каждого критерия указан уровень соответствия.</p> <h3>Насколько сложно выучить WCAG и WAI-ARIA?</h3> <p>Я хотел бы поделиться своим опытом в изучении доступности.</p> <p>Хотя наш курс был довольно комплексным и его проводили чрезвычайно компетентные люди, мы просто сидели на нём часами и слушали детальные обзоры WCAG, пункт за пунктом. Презентация была огромной, и мы быстро переходили от одного слайда к другому. Если честно, она была перегружена, ведь WCAG нельзя назвать маленьким документом.</p> <p>Короче говоря, мы были готовы решить много задач, и сразу же начали работать над исправлениями. Однако скоро это стало чем-то повторяющимся, механическим, просто ответом на стимулы. Мы тонули в море доступности.</p> <p>Каждый знал как хорошо мы стали разбираться в доступности, поэтому никто не критиковал нашу работу. История с доступностью подходила к концу, и у нас появились новые приоритеты. Ожидалось, что мы вынесем многое из проделанной работы. Какое-то время так и было.</p> <p>Со временем кто-то ушёл из команды, присоединились новые люди, а ещё появилось новое руководство. Рынок быстро развивается. Мы изменили наши приоритеты и командный дух, не говоря уже о том, что были заняты новыми задачами, которые отодвинули доступность на второй план.</p> <p>Всё было настолько плохо, что шесть месяцев спустя у нас был новый аудит, который показал, что мы всё ещё сидим на огромной куче проблем с доступностью! Скоро мы осознали, что, хотя старые ошибки исправлены, у большей части нового кода — проблемы. Кроме того, мы никогда не включали доступность в наш регламент разработки и новые члены команды не обучались этому.</p> <p>Вывод: мы просто позволили этому случиться. Доступность проигнорировали и её ключевые идеи не укоренились в нас.</p> <p>Другими словами, мы оказались изолированы в пузыре наших представлений. Такое случается, когда мы решаем проблемы, руководствуясь своими предубеждениями, как отмечено в методологии <a href="https://www.microsoft.com/design/inclusive/">Microsoft Inclusive Design</a>.</p> <h3>Оказываясь в изоляции</h3> <figure> <figcaption> «Изоляция никогда не даёт двигаться вперёд по общему пути к свободе и справедливости», Десмонд Туту. </figcaption> </figure> <p>Иногда вам нужно что-то испытать на собственном опыте, чтобы лучше это понять. Это и случилось со мной.</p> <p>Я регулярно сдаю кровь на тромбоциты. У меня первая положительная группа крови, так что я могу помочь многим людям. Один раз в мою вену неправильно вставили катетер, и в этом месте на левой руке появился большой болезненный синяк.</p> <p>Обычно сдача донорской крови занимает 10 минут, но забор тромбоцитов длится примерно 90. Так как моя рука была накрыта одеялами (потому что при заборе крови становится холодно), персоналу потребовалось около 20 минут, чтобы заметить, что моя вена повреждена.</p> <p>После того, как это обнаружилось, сдачу тромбоцитов прервали. Мою левую руку раздуло, она стала очень чувствительной на несколько дней. Настолько, что я просто не мог заставить себя ей пользоваться.</p> <p>После этого я пытался всё делать правой рукой. Неожиданно я заметил, что переключаться с клавиатуры на мышь неудобно, и мне было бы проще выполнять все задачи, используя что-то одного.</p> <p>Вскоре я обнаружил, что использую только клавиатуру, и обратил внимание, как много сайтов просто не поддерживают её. Тогда до меня дошло: я столкнулся с изоляцией, хотя мои трудности были просто временными.</p> <p>И тогда, именно в этот момент, я вспомнил как раньше работал над доступностью и не думал о поддержке клавиатуры. Блин!</p> <h3>Уровни изоляции</h3> <p>В соответствии с <a href="https://www.microsoft.com/design/inclusive/">Microsoft’s Inclusive 101 Toolkit</a> существует три уровня изоляции:</p> <ol> <li><strong>Постоянная:</strong> в ней оказываются люди с такими нарушениями как потеря конечностей, зрения, слуха или речи.</li> <li><strong>Временная:</strong> переживают те, у кого временная травма или трудности, с которыми они сталкиваются непродолжительное время. Например, они посмотрели на яркий свет, носят гипс или заказывают обед в другой стране.</li> <li><strong>Ситуативная:</strong> испытывают те, у кого резко изменились доступные возможности из-за специфичной обстановки, например, плохо слышно из-за шумной толпы, снижен обзор в машине или это молодые родители, у которых свободна только одна рука.</li> </ol> <p>Мои временные ограничения раскрыли мне глаза, ведь я никогда не сталкивался с такой проблемой во время работы.</p> <p>Тем не менее, я находился в невероятно выгодном положении, ведь мои трудности длились всего пару дней, тогда как миллионы людей во всём мире изолированы в течение всей жизни.</p> <h3>Пишем код во имя перемен</h3> <p>Наконец, до меня дошло: реализация доступности вносит вклад в более инклюзивный мир! Вот несколько вещей, которые мы можем сделать как разработчики:</p> <ul> <li>Научиться писать код, поддерживающий доступность.</li> <li>Сделать доступность частью регламента разработки своей команды (так же, как вы планируете работать над юнит-тестами или документацией).</li> <li>Обсуждать доступность со своей командой, повышать осведомлённость её участников.</li> <li>Оценивать, пишет ли команда код, отвечающий требованиям доступности, и фиксировать проблемы, которые можно решить.</li> <li>Узнавать у бизнеса о требованиях, которые не отвечают принципам доступности или для которых нужны альтернативные решения.</li> <li>Делиться своим опытом и показывать другим как внедрить доступность в свою практику. Поэтому я и пишу эту статью :)</li> </ul> <h2>Три полезных правила доступности</h2> <p>Это моя попытка свести доступность к трём простым правилам, которые вы запомните. Из этих правил можно вынести основные идеи и найти рекомендации по внедрению доступности в ваш проект.</p> <p><strong>Внимание!</strong> Эти правила не заменят необходимости изучения доступности. Они не исчерпывающие и станут только основой для того, что вы дальше будете изучать самостоятельно.</p> <p>Повторюсь, чтобы научиться доступности, рекомендую ознакомиться на Udacity с бесплатным курсом <a href="https://www.udacity.com/course/web-accessibility--ud891">Web Accessibility</a> от Google.</p> <p>Итак, три полезных правила доступности. Надеюсь, вы сможете взять их на вооружение и использовать каждый день в своей работе:</p> <p><strong>1. Настаивайте на семантических HTML-элементах, или DIY</strong></p> <figure> <figcaption> «Семантическай веб несложен по своей природе. Язык семантического веба, по своей сути, очень, очень простой. Речь идёт только о взаимосвязях между вещами». Тим Бернерс-Ли. </figcaption> </figure> <p>Для меня это золотое правило доступности, для этого не нужно прикладывать никаких усилий.</p> <p><strong>Семантические элементы</strong> — те, которые передают определённое значение с помощью содержимого, которое они представляют. Например, <code><button></code>, <code><input></code>, <code><a></code>, <code><h1></code> и <code><p></code>. Они передают контекст агенту пользователя (браузеру, устройству или вспомогательной технологии вроде скринридера), поэтому он будет знать как взаимодействовать с такими элементами и чего от них ждать.</p> <p>Они отличаются от семантически нейтральных элементов, таких как <code><div></code> и <code><span></code>, или от презентационных, вроде <code><center></code> и <code><big></code>, которые не дают агентам представления о контексте.</p> <p>В большинстве случаев семантические теги уже доступны (и дружественны для SEO). Это означает, что они отвечают многим принципам доступности прямо из коробки, например:</p> <ul> <li>Обрабатывают события фокуса при нажатии на клавишу <kbd>Tab</kbd>.</li> <li>Реагируют на события клавиатуры при нажатии на <kbd>Enter</kbd>, <kbd>Esc</kbd>, пробела, стрелок.</li> <li>Содержат семантическую информацию (имя, роль, состояние и значение), поэтому их распознают вспомогательные технологии.</li> <li>Их стили по умолчанию соответствуют минимальному контрасту.</li> </ul> <p>Когда вы не используете семантические элементы, вам нужно вручную задать ему всё это, чтобы сделать доступным.</p> <p>Значит вам потребуется:</p> <ul> <li>Добавить <code>tabindex="0"</code>, чтобы компонент стал частью естественного порядка табуляции, и использовать <code>focus()</code>, <code>display: none</code> или <code>aria-hidden</code> для того, чтобы избежать ловушек для фокуса. Про атрибут <code>tabindex</code> читайте в <a href="https://developers.google.com/web/fundamentals/accessibility/focus/using-tabindex">Using Tabindex</a>».</li> <li>Следить за событиями клавиатуры. Проверьте требования для ваших компонентов в <a href="https://www.w3.org/TR/wai-aria-practices-1.1/#aria_ex">WAI-ARIA Design Patterns and Widgets</a>.</li> <li>Использовать атрибут <code>role</code>, чтобы придать семантическое значение элементу и улучшить SEO-значимость. Узнайте обо всех возможных значениях <code>role</code> в <a href="https://www.w3.org/TR/wai-aria-1.1/#roles_categorization">WAI-ARIA Categorization of Roles</a>.</li> <li>Использовать атрибуты ARIA для описания состояний и значений. Узнайте, как используются атрибуты ARIA в <a href="https://www.w3.org/TR/wai-aria-1.1/#role_definitions">WAI-ARIA Definition of Roles</a>.</li> <li>Следить за контрастом и фокусом, особенно если используете <code>outline: 0</code> (что не рекомендуется).</li> </ul> <p>Продолжаем разговор о семантических элементах. Вот ещё несколько вещей, которые нужно иметь в виду:</p> <ul> <li>Используйте <a href="https://www.w3.org/TR/wai-aria-practices/examples/landmarks/HTML5.html">секционные элементы</a>, чтобы разбить страницу на отдельные части. В противном случае нужно использовать роли ориентиров.</li> <li>Используйте <a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Heading_Elements">заголовки</a>, чтобы организовать текстовое содержимое. Так вы опишите связь между секциями и их иерархию. На заметку: на каждой странице может быть только один заголовок первого уровня <code><h1></code>.</li> <li>Используйте <code><label for="…"></code> для элементов форм <code><input></code>, <code><select></code> и <code><textarea></code>.</li> <li>Выбирайте правильные инструменты, например, если это ссылка, то используйте <code><a href=""></code> и никогда <code><span onclick="…"></code>. А если это кнопка, то <code><button></code>, а не <code><a href="#" onclick="…"></code>.</li> </ul> <p>Что ж, семантические элементы кажутся более удобными, не так ли?</p> <p><strong>2. Обеспечьте альтернативу для картинок, цветов, звуков и движения</strong></p> <figure> <figcaption> «Живопись — это просто другой способ ведения дневника», Пабло Пикассо. </figcaption> </figure> <p>Вспомогательные технологии лучше всего работают с текстом. Когда вы используете что-то ещё, всегда добавляйте для них текстовые эквиваленты, например:</p> <ul> <li>Для картинок предусмотрите альтернативный текст. Вы можете использовать <code>alt="description" </code>для информативных изображений (которые несут смысл, как фотографии или иконки без текста) и <code>alt=""</code> для декоративных изображений (которые не несут смысловой нагрузки, например иконки внутри кнопок или дополненные текстом). Это особенно важно для ссылок в виде картинок.</li> <li>Продолжая про изображения: когда пользователи должны взаимодействовать с ними, добавьте звук или объясните, как обойтись без картинок. К примеру, можете взглянуть на <a href="https://www.google.com/recaptcha/intro/v3beta.html">Google reCaptcha</a>.</li> <li>Добавьте дополнительный индикатор для цветов, когда они обозначают состояние элементов форм, определённый элемент в выпадающем списке или другие элементы, которые надо выделить. Это может быть информационный текст, иконка или даже подсказка.</li> <li>Ещё про цвета. Проверьте контрастность текста и убедитесь, соответствует ли она стандарту. Например, уровень AA в WCAG требует минимум 4.5:1 для текста стандартного размера и 3:1 для большого.</li> <li>Для звуковых дорожек и видео добавьте подписи или расшифруйте их. Используйте визуальную альтернативу для звуков интерфейса.</li> <li>Если пользователь перемещается по странице, и мы ждём, что он совершит специфические жесты (например, движение мышью), сделайте их необязательными или предоставьте альтернативу таким взаимодействиям через клавиатуру.</li> <li>Для автоматических изменений на странице избегайте вспышек, миганий, смещения контента и новых окон. Когда это неизбежно, добавьте элементы управления, с помощью которых можно настроить время, сделать паузу или скрыть этот контент. Также используйте значение <a href="https://www.w3.org/TR/wai-aria-1.1/#aria-live">aria-live</a>, чтобы скринридер мог уведомлять пользователя о том, что действие прервано.</li> </ul> <p><strong>3) Привыкните использовать инструменты для проверки доступности в повседневной работе</strong></p> <figure> <figcaption> «Мы формируем наши инструменты, а затем наши инструменты формируют нас», Маршалл Маклюэн. </figcaption> </figure> <p>Это, пожалуй, самое полезное правило, которое поможет понять, что вы упустили что-то в двух предыдущих.</p> <p>Я перечислю здесь несколько инструментов для проверки доступности. Попробуйте их использовать, запустите на своём сайте, посмотрите, что вы можете узнать благодаря им и попробуйте остановиться на каком-то из них. В основном встречается три типа инструментов, которые я рекомендую использовать:</p> <p><strong>а. Для вашего регламента разработки</strong></p> <ul> <li><a href="https://chrome.google.com/webstore/detail/lhdoppojpmngadmnindnejefpokejbdd">Плагин</a><a href="https://chrome.google.com/webstore/detail/lhdoppojpmngadmnindnejefpokejbdd"> aXe</a><a href="https://chrome.google.com/webstore/detail/lhdoppojpmngadmnindnejefpokejbdd"> для Chrome</a>: лёгкий в использовании плагин, проверяющий доступность. Находит проблемы и даёт рекомендации о том, как их исправить.</li> <li><a href="https://chrome.google.com/webstore/detail/wave-evaluation-tool/jbbplnpkjmmeebjpijfedlgcdilocofh?hl=en-US">Wave</a>: инструмент для оценки доступности, который визуализирует доступность контента, добавляя иконки и индикаторы прямо на страницу.</li> <li><a href="https://developers.google.com/web/updates/2018/01/devtools#a11y">Панель Accessibility, Audits и контрастность цветов в Chrome DevTools</a>: три инструмента, функции которых позволяют перемещаться по дереву доступности и видеть значения каждого элемента, определять контрастность текстовых элементов и выполнять полностраничный аудит доступности и других параметров.</li> <li><a href="https://chrome.google.com/webstore/detail/nocoffee/jjeeggmbnhckmgdhmgdckeigabjfbddl">Плагин NoCoffee</a><a href="https://chrome.google.com/webstore/detail/nocoffee/jjeeggmbnhckmgdhmgdckeigabjfbddl"> для Chrome</a>: имитирует проблемы, с которыми сталкиваются люди c нарушениями зрения от лёгких до серьёзных.</li> <li><a href="https://chrome.google.com/webstore/detail/high-contrast/djcfdncoelnlbldjfhinnjlhdjlikmph">Плагин High Contrast</a><a href="https://chrome.google.com/webstore/detail/high-contrast/djcfdncoelnlbldjfhinnjlhdjlikmph"> для Chrome</a>: позволяет просматривать страницы с цветовыми фильтрами с высокой контрастностью, упрощающими чтение текста. Так вы можете проверить, как выглядит ваш сайт для пользователей, которым нужен высокий уровень контраста.</li> </ul> <p><strong>б. Для ручного тестирования с реальными скринридерами</strong></p> <ul> <li><a href="https://www.apple.com/voiceover/info/guide/_1124.html">VoiceOver</a> на Mac (встроен в macOS).</li> <li><a href="https://www.nvaccess.org/download/">NVDA</a> (бесплатный) и <a href="http://www.freedomscientific.com/Products/Blindness/JAWS?gclid=CjwKCAiA8vPUBRAyEiwA8F1oDDzHAjW9-GfooiNT3sCDcTg_7LNXvHz4XL7osONDyf3Y4k9KRbcuihoCKGMQAvD_BwE">JAWS</a> (платный) на Windows.</li> </ul> <p><strong>в. Для автоматического аудита</strong></p> <ul> <li><a href="https://www.npmjs.com/package/lighthouse">Google Lighthouse</a>: автоматический аудитор, похож на панель Audits в DevTools.</li> <li><a href="https://www.npmjs.com/package/axe-core">aXe</a>: автоматический сервис проверки правил доступности, тех же, что и в расширении aXe.</li> <li><a href="https://github.com/pa11y/pa11y-dashboard">Pa11y Dashboard</a>: веб-интерфейс, который поможет отслеживать состояние доступности на сайтах.</li> </ul> <h2>Читать дальше</h2> <ul> <li><a href="https://www.logicsolutions.com/508-ada-wcag-accessibility-difference/">508, ADA, WCAG: What’s the difference?</a></li> <li><a href="http://www.who.int/disabilities/world_report/2011/report/en/">WHO’s World Report on Disability</a></li> <li><a href="https://medium.com/@addyosmani/accessible-ui-components-for-the-web-39e727101a67">Accessible UI Components For The Web</a></li> <li><a href="https://www.microsoft.com/design/inclusive/">Microsoft Inclusive Design</a></li> <li><a href="https://www.udacity.com/course/web-accessibility--ud891">Web Accessibility free course on Udacity, by Google</a></li> <li><a href="https://webaim.org/standards/wcag/checklist">WebAIM’s WCGA 2 checklist</a></li> <li><a href="https://developers.google.com/web/fundamentals/accessibility/focus/using-tabindex">Using Tabindex</a></li> <li><a href="https://www.w3.org/TR/wai-aria-practices-1.1/#aria_ex">WAI-ARIA Design Patterns and Widgets</a></li> <li><a href="https://www.w3.org/TR/wai-aria-1.1/#roles_categorization">WAI-ARIA Categorization of Roles</a></li> <li><a href="https://www.w3.org/TR/wai-aria-practices/examples/landmarks/HTML5.html">HTML5 Sectioning Elements</a></li> </ul> </article> <article> <h1>Важность уровней заголовков для вспомогательных технологий</h1> <p>Tue, 13 Nov 2018 00:00:00 GMT</p> <p><a href="https://www.w3.org/TR/html52/sections.html#the-h1-h2-h3-h4-h5-and-h6-elements">Спецификация HTML</a> описывает шесть видов заголовков: <code><h1></code>, <code><h2></code>, <code><h3></code>, <code><h4></code>, <code><h5></code> и <code><h6></code>. Число в названии элемента отражает его приоритет. При этом <code><h1></code> самый общий, а <code><h6></code> наиболее специфичный.</p> <p>Это важно знать! WebAIM провела в 2017 году <a href="https://webaim.org/projects/screenreadersurvey7/#finding">опрос пользователей скринридеров</a>, и он показал, что навигация по заголовкам — это самый важный способ навигации для людей, которые пользуются вспомогательными технологиями для поиска информации. Именно поэтому так важно правильно организовать заголовки на вашем сайте.</p> <h2>Познание</h2> <p>Прежде чем мы подробно рассмотрим как работают вспомогательные технологии, надо понять причины, по которым СМИ используют главы, разделы, подразделы и параграфы. Дробление контента на отдельные части облегчает его понимание, усвоение, запоминание и работу со ссылками.</p> <figure> <figcaption> <a href="https://medium.com/@nkuepper/the-guardian-with-a-new-design-in-print-web-and-app-30fab6c97529"> Части контента в газете The Guardian </a> </figcaption> </figure> <p>Несмотря на то, что интернет не печатное издание, он заимствует у типографики все хорошие практики. Заголовки в HTML аналогичны соглашениям в типографике. Это одна из тех вещей, которую каждый считает чем-то очевидным, но она на самом деле помогают огромному количеству людей. <a href="https://webaim.org/articles/cognitive/">Когнитивные нарушения</a> широко распространены и перевешивают другие виды нарушений. Группировка контента на логические части помогает всем: от людей с патологическим состоянием организма, например, деменцией, до людей с временными ограничениями, такими как бессонница или осваивающими новые навыки.</p> <h2>Навигация с помощью заголовков</h2> <p>Некоторые виды <a href="https://webaim.org/articles/motor/assistive">вспомогательных технологий</a> (не только скринридеры) позволяют людям перескакивать от одного заголовка к другому. Это похоже на опыт людей, которые не пользуются вспомогательными технологиями, а прокручивают страницы, чтобы понять общий смысл, и останавливаются, когда находят нужную информацию.</p> <h3>Создание списков заголовков</h3> <p>Какие-то вспомогательные технологии могут обрабатывать заголовки и представлять их в виде упорядоченного списка. Такой список помогает быстро понять общий смысл страницы.</p> Сгенерированный список заголовков на странице Wikipedia <p>Если вы не соблюдаете логическую последовательность, скажем, переходите от заголовка первого уровня сразу к третьему и пропускаете заголовок второго уровня, это может сбить с толку и вызвать раздражение у человека, которому они необходимы для навигации. Этот пробел в логической последовательности создаст трудности для пользователей и вынудит их использовать другие способы навигации, которые отнимут больше времени и сил на то, чтобы понять общую структуру страницы (если она есть) и определить, есть ли тут нужная информация в принципе.</p> <h3>Заголовки первого уровня</h3> <p>Ещё одна важная вещь, которую мы можем сделать, это убедиться, что на странице только <em>один</em> заголовок первого уровня. Такой заголовок должен описывать <a href="https://webaim.org/projects/screenreadersurvey7/#heading">основную идею содержания страницы</a>. Например, у страницы об истории французской выпечки может быть такой заголовок первого уровня:</p> <pre><code tabindex="0" class="language-html"><h1>История французской выпечки</h1> <p>…</p> </code></pre> <h3>Алгоритм структуры документа (несуществующий)</h3> <p>К сожалению, существует заблуждение о том, что можно использовать заголовки первого уровня для каждого <a href="https://developer.mozilla.org/en-US/docs/Web/HTML/Element#Content_sectioning">элемента секционного контента</a> на странице, а браузер дальше сам во всём разберётся с помощью алгоритма построения структуры документа (Document Outline Algorithm). Этот алгоритм <a href="https://adrianroselli.com/2016/08/there-is-no-document-outline-algorithm.html">спекулятивная фантастика</a>. В момент написания этой статьи алгоритм не поддерживается ни одним браузером. По этой причине мы должны придерживаться подхода <a href="https://www.w3.org/TR/html-design-principles/#priority-of-constituencies">«Priority of Constituencies»</a>», описанного в спецификации, и использовать другие заголовки.</p> <h3>Другие заголовки</h3> <p>Заголовки от второго до шестого уровней должны последовательно размещаться за первым и описывать основные моменты содержимого страницы.</p> <p>Например, вот структура этой статьи:</p> <pre><code tabindex="0">1. Важность уровней заголовков для вспомогательных технологий 1. Познание 2. Навигация с помощью заголовков 1. Создание списков заголовков 2. Заголовки первого уровня 1. Алгоритм структуры документа (несуществующий) 3. Другие заголовки 4. Избыточная описательность 5. Другие сервисы 3. Стилизация 1. Семантика 2. Целесообразность 1. Служебные стили 2. Сброс 3. Именование 4. Подводя итоги: воспользуйтесь моментом </code></pre> <p>Посмотрев на этот список, вы быстро поняли про что статья. Неплохо, да?</p> <p>Ещё нужно отметить, что заголовки, подобно иерархическим форматам вроде JSON, могут содержать внутри другие заголовки, при условии, что они логически связаны. Внутри заголовка второго уровня вы можете использовать несколько заголовков третьего уровня. Каждый из этих подзаголовков может, в свою очередь, иметь внутри подзаголовки четвёртого уровня.</p> <p>Когда вы завершили тему, то можете закрыть вложенные заголовки. Это единственный случай, когда допустимо использовать «пропущенные» уровни: вы закончили описывать конкретную проблему и вернулись к более общей теме.</p> <pre><code tabindex="0" class="language-html"><h1> История французской выпечки <h2> Важные вехи <h3> 16 век <h4> Слоёное тесто <h4> Облатка <h3> 17 век <h4> Выпечка из слоёного теста <h4> Взбитые сливки <h5> Шеф-повар принца Конде <h3> 18 век <h4> Макаруны <h3> 19 век <h3> 20 век <h2> Важные люди <h3> … </code></pre> <p>Этот пример показывает как правильно использовать заголовок пятого уровня («Шеф-повар принца Конде») перед заголовком третьего уровня («18 век»), пока родительские заголовки располагаются последовательно друг за другом. Если бы заголовок третьего уровня шёл перед заголовком пятого, то это было бы уже неправильно.</p> <h3>Избыточная описательность</h3> <p>Если мы используем слишком много заголовков, то перегружаем пользователей вспомогательных технологий информацией. Вы можете подумать, что я противоречу себе, ведь я только что говорил о том, как важны заголовки для навигации.</p> <p>Подумайте об этом так: так же как и слишком большое количество элементов навигации на странице рассеивает внимание пользователей, так и большое количество заголовков создаёт фоновый шум, который запутывает их и отвлекает от идеи, которую вы пытаетесь донести.</p> <p>Нет чётких правил о количестве заголовков, которое считается избыточным. Это напрямую зависит от того, какой это контент и в каком объёме нужно раскрыть его содержание. Например, для рецепта достаточно указать название блюда, его ингредиенты и дать инструкцию по приготовлению. Для научной статьи нужна большая детализация.</p> <h3>Другие сервисы</h3> <p>Хорошая структура заголовков нужна не только людям, которые пользуются вспомогательными технологиями. Так как заголовки имеют семантическое значение, другие сервисы могут взаимодействовать с описанием элементов, интерпретировать его и представлять в удобном виде для пользователей. Например, вот что делает поисковая система Bing со странницами с хорошей структурой:</p> Результат поиска в Bing <p>Как и скринридеры, сервисы вроде <a href="https://support.google.com/docs/answer/6367684?co=GENIE.Platform%3DDesktop&hl=en">Google Docs</a> и <a href="https://blogs.dropbox.com/dropbox/2017/03/paper-hidden-gems/">Dropbox Paper</a> могут автоматически создавать перечни заголовков, чтобы помочь вам быстрое понять содержание документа и перемещаться по нему. Многие текстовые редакторы тоже умеют быстро формировать из заголовков динамически обновляемые оглавления, что делать вручную очень утомительно и трудоёмко. И, благодаря совместимости HTML, мы даже можем воссоздать такую навигацию с помощью <a href="https://chrome.google.com/webstore/detail/headingsmap/flbjommegcjonpdmenkdiocclhjacmbi/">расширения для браузера</a>!</p> <h2>Стилизация</h2> <p>Все слишком часто забывают, что CSS-классы могут применяться к заголовкам, как к любому другому элементу HTML внутри <code><body></code>.</p> <h3>Семантика</h3> <p>Причина, по которой я это упомянул, заключается в том, что элементы заголовков часто используются из-за того, как они <em>выглядят</em> («О, мне нравится цвет и шрифт <code><h3></code>, использую-ка я его!»), а не из-за того, какой приоритет содержимого они <em>описывают</em> (Бриошь — это вид сдобы). Это распространённая ошибка.</p> <p>В идеальном академическом мире мы соблюдаем <a href="https://alistapart.com/article/material-honesty-on-the-web">материальную честность</a> (material honesty) заголовков, определяя их размер и стиль в соответствии с тем, какой уровень иерархии они описывают.</p> <p>Однако мы живём в реальном мире. Современные сайты и веб-приложения — это сложные вещи. Их разрабатывают люди с разным уровнем опыта, интересами, знаниями и возможностями при проектировании и написании кода.</p> <h3>Целесообразность</h3> <p>В реальном мире может потребоваться стилизовать заголовок четвёртого уровня как заголовок второго уровня или оформить его как совершенно другой элемент. В этом случае лучше сохранить логическую структуру страницы и изменить только внешний вид заголовка:</p> <pre><code tabindex="0" class="language-html"><h5 class="heading-primary--marketing"> Забота профессионала по разумной цене </h5> </code></pre> <p>Это компромисс и признание того, что реальный мир сложный. Этот подход позволяет сохранить важную составляющую: интуитивную и эффективную навигацию для вспомогательных технологий.</p> <h3>Служебные стили</h3> <p>Такие методологии как <a href="https://frontstuff.io/in-defense-of-utility-first-css">Utility-First CSS</a> помогают более гибко настраивать внешний вид заголовков:</p> <pre><code tabindex="0" class="language-html"><h2 class="u-font-size-tiny u-color-gray u-line-height-tight"> Правила и соглашения </h2> </code></pre> <p>В примере я объявляю несколько классов, которые будут изменять внешний вид заголовков до тех пор, пока я не получу желаемый результат. Вы можете столкнуться с этой методологией на крупных сайтах и в приложениях, где низкая <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity">специфичность</a> классов помогает сохранить согласованность кода (консистентность).</p> <h3>Сброс</h3> <p>Чтобы закрепить правильный порядок и вложенность заголовков, можно сбросить их стили. Это поможет избежать использования дополнительного класса, который приводит заголовки к одному виду.</p> <pre><code tabindex="0" class="language-css">h1, h2, h3, h4, h5, h6 { color: inherit; font-size: 1em; line-height: inherit; margin: 0; padding: 0; vertical-align: baseline; } </code></pre> <p>Этот небольшой пример <a href="https://www.smashingmagazine.com/2011/05/getting-started-with-defensive-web-design/">оборонительного дизайна</a> (defensive design) заставляет задуматься над тем, как структура документа формируется в зависимости от его внешнего вида. Эти стили объявляются после импорта <a href="https://cssreset.com/what-is-a-css-reset/">CSS-сброса</a>, так как могут переопределить стили из файла со сбросом.</p> <h3>Именование</h3> <p>Одна из сложнейших проблем информатики — это именование сущностей. Она признаёт, что вы ничего не знаете. Я не берусь утверждать, что знаю лучший способ именования классов заголовков для вашего сайта или приложения. Однако, если вы используете подход, который не основан на служебных стилях, я не рекомендую называть их .h1, .h2, .h3 и так далее.</p> <p>Проблема этого подхода в том, что люди, которые не знакомы с кодовой базой, могут принять такое именование классов за инструкцию, требующую соответствия названия класса уровню заголовка. Это усилит проблему преимущества внешнего вида элемента над его содержанием.</p> <p>Я также встречал случаи, когда такой подход допускал вообще не использовать для некоторых заголовков семантические теги («А, я могу сделать этот <code><div></code> похожим на <code><h5></code>!»). Не надо так!</p> <h2>Подводя итоги: воспользуйтесь моментом</h2> <p>Опрос пользователей скринридеров, который WebAIM провела в 2017 году, также показал, что пропуск или неподходящие заголовки <a href="https://webaim.org/projects/screenreadersurvey7/#problematic">одна из 10 наиболее распространённых проблем</a>, с которыми сталкиваются пользователи вспомогательных технологий.</p> <p>И это одна из самых распространённых проблем с доступностью, которую легко решить. Потратьте немного времени и посмотрите на свой сайт или приложение ещё раз. Структура заголовков точно описывает страницу? Соблюдается ли логический порядок? Очень просто поменять пару цифр местами!</p> <p>Стоит обратить внимание и на то, что заголовки, подобно иерархическим форматам данных, таким как JSON, могут быть вложены в другие, если они логически связаны. Внутри заголовка второго уровня вы можете использовать заголовки третьего. Каждый из этих подзаголовков может, в свою очередь, иметь вложенные подзаголовки четвёртого уровня.</p> </article> <article> <h1>CSS: новый вид JavaScript</h1> <p>Fri, 13 Jul 2018 00:00:00 GMT</p> <p>Те из вас, кто знаком с веб-платформой, наверняка наслышаны и о двух дополнительных технологиях: <strong>HTML</strong> для структуризации документов и <strong>JavaScript</strong> для интерактивности и стилизации.</p> <p>Сколько мы себя помним, стилизация документов (то есть, влияние на их внешний вид) всегда производилась с помощью JavaScript-свойства <code>style</code>, доступного на каждом поддерживаемом DOM-узле.</p> <pre><code tabindex="0" class="language-js">node.style.color = 'red'; </code></pre> <p>До изобретения этого API для стилизации авторам HTML приходилось писать атрибуты <code>style</code> вручную прямо в DOM, что затрудняло процесс редактирования.</p> <p>Используя выборку узлов по селектору из JS, мы можем стилизовать несколько элементов одновременно. В примере ниже текст во всех <code><p></code> стилизован красным цветом.</p> <pre><code tabindex="0" class="language-js">const nodes = document.querySelectorAll('p'); Array.prototype.forEach.call(nodes, node => { node.style.color = 'red'; }); </code></pre> <p>Отличная возможность выборки по селектору — обращение к нескольким элементам, перечисленным в списке через запятую.</p> <pre><code tabindex="0" class="language-js">const nodes = document.querySelectorAll('p, li, dd'); </code></pre> <p>Гораздо менее удобно применять несколько стилей к одному узлу. Такой подход быстро становится слишком многословным:</p> <pre><code tabindex="0" class="language-js">node.style.color = 'red'; node.style.backgroundColor = 'black'; node.style.padding = '1rem'; // и т.д. </code></pre> <p>Единственная стандартная альтернатива — использовать свойство cssText:</p> <pre><code tabindex="0" class="language-js">node.style.cssText = 'color: red; background-color: black; padding: 1rem;'; </code></pre> <p>Управлять несколькими стилями в одной строке проблематично. В будущем будет сложно обновлять, удалять или заменять отдельные стили.</p> <p>Для этого авторы придумали способы управления информацией о стилях с помощью объектов, часто при помощи прототипа интерфейса Element.</p> <pre><code tabindex="0" class="language-js">Element.prototype.styles = function(attrs) { Object.keys(attrs).forEach(attr => { this.style[attr] = attrs[attr]; }); } </code></pre> <p>Теперь стили к узлу можно добавлять вот так:</p> <pre><code tabindex="0" class="language-js">node.styles({ 'color': 'red', 'backgroundColor': 'black', 'padding': '1rem' }); </code></pre> <p>Использование подобного подхода приобрело <em>довольно большую</em> популярность в приложениях и их жизненных циклах. Однако это привело к печально известной проблеме — непониманию, где всё это хранить и как явно отделить стили от интерактивной части, ещё одной области ответственности JavaScript.</p> <p>А есть и другая, более фундаментальная проблема: эти стили не реактивны. К примеру, у меня есть некоторые стили для неактивных кнопок:</p> <pre><code tabindex="0" class="language-js">const disableds = document.querySelectorAll('[disabled]'); Array.prototype.forEach.call(disableds, disabled => { disabled.styles({ 'opacity': '0.5', 'cursor': 'not-allowed' }); </code></pre> <p>Эти стили применяются только к неактивным кнопкам, которые уже есть в DOM. Любые кнопки, добавленные в DOM или, что более вероятно, любые кнопки, которые приобретут свойство или атрибут <code>disabled</code>, не получат автоматически подходящую стилизацию.</p> <pre><code tabindex="0" class="language-js">button.disabled = true; button.style // ничего нового </code></pre> <p>Можно, конечно, слушать изменение атрибутов и реагировать на него с помощью <code>mutationObserver</code>:</p> <pre><code tabindex="0" class="language-js">const button = document.querySelector('button'); var config = { attributes: true } var callback = function(mutationsList) { for(var mutation of mutationsList) { if (mutation.type == 'attributes') { if (button.disabled) { button.styles({ 'opacity': '0.5', 'cursor': 'not-allowed' }); } } } } var observer = new MutationObserver(callback); observer.observe(button, config); </code></pre> <p>Думаю, что все согласятся, что это — <em>довольно много</em> кода, с учётом того, что он всего лишь заставляет один экземпляр элемента одного типа реагировать на изменение единственного атрибута. Также это меняет стилизацию только в одном направлении: нам бы пришлось обрабатывать отмену стилей при удалении свойства <code>disabled</code>. Это не так уж и просто, учитывая, что мы не знаем изначальных значений свойств <code>opacity</code> или <code>cursor</code>.</p> <p>Как бы я ни любил JavaScript, я не думаю, что он хорошо спроектирован для задач стилизации. В конце концов, это процедурный и событийный язык, тогда как стили — это то, что у вас либо есть, либо нет.</p> <p>Мы тратим слишком много времени впустую, когда пишем и поддерживаем стили с помощью JavaScript. Пришло время это менять. Поэтому я с большим удовольствием представляю вам новый стандарт, который называется CSS.</p> <h2>CSS</h2> <p>CSS — это декларативное подмножество JavaScript, оптимизированное для задач стилизации. CSS-файл имеет расширение .css и, что важно, парсится независимо от стандартных JS-файлов. С помощью CSS наконец-то стало возможно отделить стили от поведения. Вы можете брендировать своё приложение, не трогая бизнес-логику!</p> <h3>Синтаксический сахар</h3> <p>Первое, что вы заметите — это более чистый синтаксис, фанаты CoffeeScript оценят:</p> <pre><code tabindex="0" class="language-css">[disabled] { opacity: 0.5; cursor: not-allowed; } </code></pre> <p>Структура, похожая на объектную, сохраняется, но теперь вам не нужно явно вызывать <code>querySelectorAll</code> для перебора DOM-узлов. Вместо этого перебор происходит внутри, и это, конечно же, производительнее.</p> <p>Пример выше автоматически применяется ко всем DOM-узлам с атрибутом <code>disabled</code>. Более того, все <em>новые</em> кнопки с атрибутом <code>disabled</code> автоматически приобретут связанные стили. Реактивность из коробки!</p> <h3>Каскад</h3> <p>CSS расшифровывается как <strong>каскадные таблицы стилей.</strong> Каскадность здесь, пожалуй, самая лучшая особенность. Взгляните на следующий CSS:</p> <pre><code tabindex="0" class="language-css">button { background-color: blue; cursor: pointer; } [disabled] { cursor: not-allowed; } </code></pre> <p>Стили для блока <code>[disabled]</code> идут после блока <code>button</code> в стилях. Любые стили, описанные в блоке <code>[disabled]</code> с такими же ключами (именами свойств), что и в предшествующем <code>button</code>, будут перезаписаны. Самое замечательное заключается в том, что добавление атрибута или свойства <code>disabled</code> кнопке обновит только соответствующие стили. В примере выше свойство cursor обновится, но <code>background-color</code> останется тем же. Своего рода система фильтрации.</p> <p>Ко всему прочему, если атрибут или свойство <code>disabled</code> удалено, стили по умолчанию будут автоматически возвращены — ведь узел теперь соответствует блоку <code>button</code> выше по каскаду. Не нужно «вспоминать», какие стили и при каких условиях были применены ранее.</p> <h3>Устойчивость</h3> <p>При стилизации с помощью JavaScript любое неизвестное свойство или синтаксическая ошибка остановят парсинг скрипта. Все последующие стили или поведение будут отброшены целиком и всё ваше приложение просто рухнет.</p> <p>CSS гораздо надёжнее. В большинстве случаев любое неизвестное свойство или синтаксическая ошибка приведут только к тому, что только декларация (пара свойство: значение) с ошибкой будет отброшена.</p> <p>Эта инновация учитывает, что разные браузеры поддерживают разные свойства стилизации, и что отдельные стили не критичны для всей задачи. Устойчивость CSS значит, что больше пользователей получат доступ к функционирующему интерфейсу.</p> <h2>Заключение</h2> <p>Явный признак того, что технология не подходит для определённых целей — если для обхода сложностей нам приходится сильно полагаться на трюки и лучшие практики. Другой признак — насколько много кода нам приходится писать, чтобы сделать простые вещи. Когда речь заходит про стилизацию, JavaScript — как раз та самая неподходящая технология.</p> <p>CSS решает проблемы JavaScript со стилизацией, причём элегантно. Вопрос в том, готовы ли вы принять изменения или вы завязли в неудачной методологии?</p> <p>Больше информации про CSS и советы для быстрого старта <a href="https://en.wikipedia.org/wiki/Campus_SuperStar">вы найдете здесь</a>.</p> </article> <article> <h1>Функции-декораторы, которые можно написать с нуля</h1> <p>Wed, 13 Jun 2018 00:00:00 GMT</p> <figure> <figcaption> Фото <a href="https://unsplash.com/photos/rkT_TG5NKF8">Calum Lewis</a>. </figcaption> </figure> <blockquote> <p>Декораторы — это функции высшего порядка, которые принимают в качестве аргумента одну функцию и возвращают другую. Возвращаемая функция является преобразованным вариантом функции-аргумента <a href="https://leanpub.com/javascript-allonge/read#decorators">Javascript Allongé</a></p> </blockquote> <p>Давайте самостоятельно напишем некоторые базовые дектораторы, представленные в таких библиотеках, как <a href="http://underscorejs.org/#functions">underscore.js</a>, <a href="https://lodash.com/docs/4.17.5">lodash.js</a>, <a href="http://ramdajs.com/docs/">ramda.js</a>.</p> <h2><code>once()</code></h2> <ul> <li><a href="https://jsfiddle.net/cristi_salcescu/zpLeLp0v/">once(fn)</a> создает экземпляр функции, которая должна быть выполнена только один раз. Паттерн может быть использован, например, для инициализации, когда нужно быть уверенным в единичном запуске функциональности, даже если сама функция вызвана в нескольких местах.</li> </ul> <pre><code tabindex="0" class="language-js">function once(fn){ let returnValue; let canRun = true; return function runOnce(){ if(canRun) { returnValue = fn.apply(this, arguments); canRun = false; } return returnValue; } } var processonce = once(process); processonce(); // process processonce(); // </code></pre> <p>Функция once() возвращает другую функцию — runOnce(), использующую <a href="https://medium.freecodecamp.org/why-you-should-give-the-closure-function-another-chance-31253e44cfa0">замыкание</a>. Обратите также внимание, как осуществлен вызов оригинальной функции, а именно через передачу this и arguments в метод apply: fn.apply(this, arguments).</p> <p>Если хотите узнать замыкания глубже, обратите внимание на статью «<a href="https://medium.com/p/31253e44cfa0">Why you should give the Closure function another chance</a>».</p> <h2>after()</h2> <ul> <li><a href="https://jsfiddle.net/cristi_salcescu/4evuoxe6/">after(count, fn)</a> создает вариант функции, которая будет выполнена только после определенного количества вызовов. Функция полезна, например, если должна быть выполнена <em>только</em> по завершению асинхронных операций.</li> </ul> <pre><code tabindex="0" class="language-js">function after(count, fn) { let runCount = 0; return function runAfter() { runCount = runCount + 1; if (runCount >= count) { return fn.apply(this, arguments); } } } function logResult() { console.log('calls have finished'); } let logResultAfter2Calls = after(2, logResult); setTimeout(function logFirstCall() { console.log('1st call has finished'); logResultAfter2Calls(); }, 3000); setTimeout(function logSecondCall() { console.log('2nd call has finished'); logResultAfter2Calls(); }, 4000); </code></pre> <p>В примере выше при помощи after() я создаю функцию logResultAfter2Calls(). Она в свою очередь выполняет logResult() только после второго вызова.</p> <h2>throttle()</h2> <ul> <li><a href="https://jsfiddle.net/cristi_salcescu/5tdv0eq6/">throttle(fn, wait)</a> создает вариант функции, которая при повторяющихся вызовах выполняется через указанный временной интервал (аргумент wait). Декоратор эффективен для обработки быстро повторяющихся событий.</li> </ul> <pre><code tabindex="0" class="language-js">function throttle(fn, interval) { let lastTime; return function throttled() { let timeSinceLastExecution = Date.now() - lastTime; if(!lastTime || (timeSinceLastExecution >= interval)) { fn.apply(this, arguments); lastTime = Date.now(); } }; } let throttledProcess = throttle(process, 1000); $(window).mousemove(throttledProcess); </code></pre> <p>Здесь движение мыши генерирует множество событий mousemove, тогда как оригинальная функция process() вызывается лишь раз в секунду.</p> <h2>debounce()</h2> <ul> <li><a href="https://jsfiddle.net/cristi_salcescu/424unsa7/">debounce(fn, wait)</a> создает вариант функции, которая выполняет <em>оригинальную</em> функцию спустя wait миллисекунд <em>после</em> предыдущего вызова <em>декорированной</em> функции. Паттерн также применяется в работе с повторяющимися событиями. Он полезен, если функциональность должна быть выполнена по завершению очереди событий.</li> </ul> <pre><code tabindex="0" class="language-js">function debounce(fn, interval) { let timer; return function debounced() { clearTimeout(timer); let args = arguments; let that = this; timer = setTimeout(function callOriginalFn() { fn.apply(that, args); }, interval); }; } let delayProcess = debounce(process, 400); $(window).resize(delayProcess); </code></pre> <p>Функция debounce() часто используется вместе с событиями scroll, resize, mousemove и keypress.</p> <h2>Частичное применение</h2> <p>Частичное применение преобразует функцию за счет изменения количества параметров. Это один из примеров движения от общего к частному.</p> <h2>partial()</h2> <p>На этот раз <a href="https://jsfiddle.net/cristi_salcescu/sbborekp/">создадим метод partial()</a> и сделаем его доступным для всех функций. В данном примере я использую синтаксис ECMAScript 6, а именно оператор rest. С его помощью набор аргументов функции преобразуется в массив <code>...leftArguments</code>. Это нужно для конкатенации массивов, тогда как специальный объект arguments массивом не является.</p> <pre><code tabindex="0" class="language-js">function.prototype.partial = function(...leftArguments){ let fn = this; return function partialFn(...rightArguments){ let args = leftArguments.concat(rightArguments); return fn.apply(this, args); } } function log(level, message){ console.log(level + ' : ' + message); } let logInfo = log.partial('Info'); logInfo('here is a message'); </code></pre> <p>Обратите внимание, созданная таким образом logInfo() использует лишь один аргумент message.</p> <h2>Заключение</h2> <p>Применение указанных функций помогает понять принципы работы декораторов и саму идею инкапсуляции логики внутри них.</p> <p>Декораторы — мощный инструмент расширения функциональности без изменения исходной функции. Это отличный путь переиспользовать код, и он соответствует функциональной парадигме программирования.</p> <h3>Больше о ФП в JavaScript</h3> <ul> <li><a href="https://medium.com/p/33dcb910303a">How point-free composition will make you a better functional programmer</a></li> <li><a href="https://medium.com/p/13ba11825319">You will finally understand what Closure is</a></li> <li><a href="https://medium.com/p/73258b6a8d15">Class vs Factory function: exploring the way forward</a> (см. <a href="https://medium.com/@kanby/%D0%BA%D0%BB%D0%B0%D1%81%D1%81-vs-%D1%84%D0%B0%D0%B1%D1%80%D0%B8%D0%BA%D0%B0-%D0%BE%D0%B1%D1%8A%D0%B5%D0%BA%D1%82%D0%BE%D0%B2-%D0%BF%D0%B5%D1%80%D1%81%D0%BF%D0%B5%D0%BA%D1%82%D0%B8%D0%B2%D1%8B-9b4c696823c8">перевод</a>).</li> <li><a href="https://medium.com/p/94fb8cc69f9d">Make your code easier to read with Functional Programming</a></li> </ul> </article> <article> <h1>Глубокое погружение в ES-модули в картинках</h1> <p>Fri, 30 Mar 2018 00:00:00 GMT</p> <p>ES-модули приносят в JavaScript официальную, унифицированную модульную систему. Однако, чтобы прийти к этому, потребовалось почти 10 лет работы по стандартизации.</p> <p>Но ожидание почти закончилось. С выходом Firefox 60 в мае (пока в бете) все основные браузеры будут поддерживать ES-модули, а Рабочая группа Node Modules сейчас работает над добавлением поддержки ES-модулей в Node.js. Также идет интеграция ES-модулей в WebAssembly.</p> <p>Многие JavaScript-разработчики знают, что ES-модули были противоречивыми. Но мало кто действительно понимает, как они работают. Давайте рассмотрим, какую проблему решают ES-модули и чем они отличаются от модулей в других модульных системах.</p> <h2>Какую проблему решают модули?</h2> <p>Написание кода на JavaScript состоит в работе с переменными — в присвоении значений переменным или добавлении чисел в переменные или объединении двух переменных вместе и помещении их в другую переменную.</p> <p>Поскольку большая часть вашего кода связана с изменением переменных, то их организация будет напрямую влиять на качество вашего кода… и на то, насколько хорошо вы сможете поддерживать его в дальнейшем.</p> <p>Небольшое количества переменных, о которых вам нужно думать, значительно упростило бы ситуацию. У JavaScript есть способ помочь вам в этом — область видимости (scope). Из-за того, как области видимости работают в JavaScript, функции не могут обращаться к переменным, определенным в других функциях.</p> <p>Это хорошо. Значит когда вы работаете над одной функцией, вы можете сосредоточиться только на ней. Вам не нужно беспокоиться о том, что другие функции могут делать с вашими переменными.</p> <p>Однако у такого подхода есть и недостаток. Он затрудняет обмен переменными между различными функциями.</p> <p>Что делать, если вы захотите использовать переменную вне текущей области видимости? Обычно способ справиться с этим заключается в том, чтобы положить её в область выше, например, в глобальную область видимости.</p> <p>Это работает, но появляются некоторые проблемы.</p> <p>Во-первых, все ваши скрипты должны быть расположены в определенном порядке. И вы должны будете внимательно следить за тем, чтобы никто не испортил этот порядок.</p> <p>Если этот порядок нарушится, то в середине работы ваше приложение выдаст ошибку. Когда функция ищет jQuery там, где она ожидает его — на глобальном уровне — и не находит его, она выбрасывает ошибку и прекращает выполнение.</p> <p>Это делает поддержку кода сложным, а удаление старого кода или скриптов игрой в рулетку. Вы не знаете, что может сломаться. Зависимости между этими различными частями кода неявны. Любая функция может использовать что угодно на глобальном уровне, поэтому вы точно не можете знать, какие функции от чего зависят.</p> <p>Вторая проблема заключается в том, что поскольку эти переменные находятся в глобальной области видимости, каждая часть кода, находящаяся внутри этой области, может изменить переменную. Вредоносный код может изменить эту переменную специально с целью изменения работы функций или другой код может случайно удалить вашу переменную.</p> <h2>Как нам помогут модули?</h2> <p>Модули дают вам лучший способ организовать эти переменные и функции. С модулями вы группируете переменные и функции, которые имеет смысл объединить.</p> <p>Это помещает эти функции и переменные в область видимости модуля. Область модуля может использоваться для обмена переменными между функциями в модуле.</p> <p>Но в отличие от областей видимости функций, области модулей позволяют сделать их переменные доступными и для других модулей. Они могут явно указать, какие переменные, классы или функции в модуле должны быть доступны.</p> <p>Когда что-то становится доступным для других модулей, это называется export. После экспорта другие модули могут явно сказать, что они зависят от этой переменной, класса или функции.</p> <p>Поскольку экспорт указывается явно, это позволяет определить, какие модули будут нарушены при удалении другого.</p> <p>Когда у вас появляется возможность экспортировать и импортировать переменные между модулями, это значительно облегчает разбиение вашего кода на небольшие куски, которые могут работать независимо друг от друга. Затем вы можете комбинировать и рекомбинировать эти куски, вроде блоков Lego, для создания любых приложений из одного и того же набора модулей.</p> <p>Поскольку модули настолько полезны, было несколько попыток добавить модульность в JavaScript. Сегодня активно используются две системы</p> <ol> <li>CommonJS (CJS) — это то, что Node.js использовал изначально.</li> <li>ESM (модули ECMAScript) — это более новая система, добавленная в спецификацию JavaScript. Браузеры уже поддерживают ES-модули, а Node.js добавляет поддержку.</li> </ol> <p>Давайте подробно рассмотрим, как работает эта новая модульная система.</p> <h2>Как работают ES-модули</h2> <p>При разработке с помощью модулей, вы строите граф зависимостей. Связи между различными зависимостями берутся из любых инструкций import, которые вы используете.</p> <p>Эти операторы импорта определяют, какой код браузеру или Node.js нужно загрузить. Вы даете ему файл для использования в качестве точки входа в граф. Оттуда он просто следует за любым из операторов импорта, чтобы найти остальную часть кода.</p> <p>Но сами файлы не являются тем, что браузер может использовать. Ему необходимо разобрать все эти файлы, чтобы превратить их в структуры данных, называемые записями модулей (module records). Таким образом, он действительно узнает, что происходит в файле.</p> <p>После этого запись модуля необходимо превратить в экземпляр модуля. Экземпляр объединяет две вещи: код и состояние.</p> <p>Код обычно представляет собой набор инструкций. Это как рецепт, как сделать что-то. Но вы не можете просто использовать этот код. Вам нужны исходные материалы для использования с этими инструкциями.</p> <p>Что такое состояние? Состояние дает вам эти исходные материалы. Состояние — это фактические значения переменных в любой момент времени. Конечно, эти переменные — это просто псевдонимы для ячеек памяти, которые содержат значения.</p> <p>Таким образом, экземпляр модуля объединяет код (список инструкций) с состоянием (значениями всех переменных).</p> <p>Нам нужен экземпляр для каждого модуля. Процесс загрузки модуля происходит от файла точки входа к полному графу экземпляров модуля.</p> <p>Для ES-модулей это происходит в три этапа.</p> <ol> <li>Построение (construction) — поиск, загрузка и парсинг всех файлов в записях модулей.</li> <li>Создание экземпляра (instantiation) — поиск ячеек в памяти для размещения всех экспортируемых значений (но пока без заполнения их значениями) Затем связывание — экспорт и импорт этих полей в памяти.</li> <li>Оценка (evaluation) — запуск кода для заполнения этих полей фактическими значениями переменных.</li> </ol> <p>Люди говорят о том, что ES-модули являются асинхронными. Вы можете думать об этом как о асинхронном процессе, т.к работа делится на три разные фазы:</p> <ol> <li>Построение</li> <li>Создание экземпляров</li> <li>Оценка</li> </ol> <p>Все эти этапы могут выполняться отдельно. Это означает, что спецификация вводит какую-то асинхронность, которой не было в CommonJS. Я объясню это позже, но в CJS-модуль и его зависимости загружаются, создаются и анализируются сразу, без каких-либо перерывов.</p> <p>Однако сами по себе действия не обязательно являются асинхронными. Они могут быть выполнены синхронным способом — зависит от того, что делает загрузка. Это потому, что не все контролируется спецификацией ESM. На самом деле есть два этапа работы, которые покрываются различными спецификациями.</p> <p>Спецификация ES-модулей говорит о том, как следует анализировать файлы в записях модулей, и как следует создавать экземпляры и оценивать этот модуль. Тем не менее, в спецификации не описывается, как изначально получить эти файлы.</p> <p>Это загрузчик, который извлекает файлы. И загрузчик указан в другой спецификации. Для браузеров он описан спецификацией HTML. Но у вас могут быть разные загрузчики, основанные на той платформе, которую вы используете.</p> <p>Загрузчик также точно контролирует загрузку модулей. Он вызывает методы ES-модуля: <code>ParseModule</code>, <code>Module.Instantiate</code> и <code>Module.Evaluate</code>.</p> <p>Теперь давайте пройдемся по каждому шагу более подробно.</p> <h3>Построение (Construction)</h3> <p>Во время этапа построения для каждого модуля происходят три вещи:</p> <ol> <li>Определение, где загрузить файл, содержащий модуль (module resolution).</li> <li>Загрузка файла (по URL или из файловой системы).</li> <li>Синтаксический анализ файла в записи модуля.</li> </ol> <h3>Поиск и получение файла (fetching)</h3> <p>Загрузчик позаботится о поиске файла и его загрузке. Сначала ему необходимо найти файл точки входа. В HTML вы указываете загрузчику, где его найти, используя тег <code><script></code>.</p> <p>Но как он найдет следующую группу модулей — от которых напрямую зависят модули main.js?</p> <p>В этом случае используются операторы import. Одна часть оператора импорта называется спецификатором модуля. Он сообщает загрузчику, где он может найти каждый следующий модуль.</p> <p>Одно замечание о спецификаторах модулей: иногда их нужно обрабатывать по-разному в браузере и Node.js. Каждый хост имеет свой собственный способ интерпретации спецификатора модуля. Для этого он использует решение, называемое алгоритмом разрешения модулей, которое отличается между платформами. В настоящее время некоторые спецификаторы модулей, которые работают в Node.js, не будут работать в браузере, но сейчас ведутся <a href="https://github.com/domenic/package-name-maps">работы по устранению этой проблемы</a>.</p> <p>Пока это не исправлено, браузеры принимают только URL в качестве спецификаторов модуля. Они загружают файл модуля с этого URL. Но это не происходит для всего графа одновременно. Вы не знаете, какие зависимости модуль должен получить, пока вы не проанализировали файл… и вы не сможете проанализировать файл, пока не получите его.</p> <p>Это означает, что мы должны пройти через дерево поэтапно, слой за слоем, анализировать один файл, выяснить его зависимости, а затем найти и загрузить их.</p> <p>Если бы основной поток ожидал загрузки каждого из этих файлов, в его очереди скопилось бы много других задач. Это потому, что, когда вы работаете в браузере, загрузка занимает большую часть времени.</p> <p>Блокировка основного потока сделает использование модулей в вашем приложении очень медленным. Это одна из причин того, что спецификация ES-модулей разбивает алгоритм на несколько этапов. Разбиение на фазы позволяет браузерам извлекать файлы и строить свое понимание графа модуля перед тем, как приступить к синхронной работе по созданию экземпляров.</p> <p>Этот подход — разделение алгоритма на фазы — является одним из ключевых различий между ES-модулями и модулями CommonJS.</p> <p>CommonJS может делать всё по-другому, потому что загрузка файлов из файловой системы занимает гораздо меньше времени, чем загрузка через интернет. Это означает, что Node.js может блокировать основной поток при загрузке файла. И раз файл уже загружен, есть смысл сразу провести построение (construction) и создание экземпляров (без разбивки на фазы). Это также означает, что вы идёте по всему графу, загружаете, создаете экземпляры и оцениваете зависимости перед возвратом экземпляра модуля.</p> <p>Подход CommonJS имеет несколько последствий, и я расскажу об этом позже. Но одно это означает, что в Node.js с модулями CommonJS вы можете использовать переменные в вашем спецификаторе модуля. Вы выполняете весь код в этом модуле (до инструкции <code>require</code>), прежде чем искать следующий модуль. Это означает, что переменная будет иметь значение при переходе к определению модулей.</p> <p>Но с ES-модулями вы заранее строите весь этот граф модулей, прежде чем выполнять какую-либо оценку. Это означает, что вы не можете использовать переменные в своих спецификаторах модулей, поскольку эти переменные еще не имеют значений.</p> <p>Но иногда очень полезно использовать переменные для путей модулей. Например, может потребоваться переключить загружаемый модуль в зависимости от того, что делает код или в какой среде он выполняется.</p> <p>Чтобы сделать это возможным для ES модулей, есть <a href="https://github.com/tc39/proposal-dynamic-import">предложение под названием динамический импорт</a>. С его помощью можно использовать импорт вида import(<code>${path}/foo.js</code>).</p> <p>Это работает так: любой файл, загруженный с помощью import(), обрабатывается как точка входа в отдельный граф. Динамически импортируемый модуль запускает новый граф, который обрабатывается отдельно.</p> <p>Однако следует отметить, что любой модуль, который находится в обоих этих графах, будет совместно использовать экземпляр модуля. Это происходит потому, что загрузчик кэширует экземпляры модулей. Для каждого модуля в определенной глобальной области будет только один экземпляр модуля.</p> <p>Это уменьшает объём работы для движка. Например, это означает, что файл модуля будет извлечен только один раз, даже если несколько модулей зависят от него (это одна из причин для кэширования модулей. Мы увидим другой в разделе оценки.)</p> <p>Загрузчик управляет этим кэшем с помощью так называемой <a href="https://html.spec.whatwg.org/multipage/webappapis.html#module-map">карты модулей</a>. Каждый глобальный модуль отслеживает свои модули в отдельной карте.</p> <p>Когда загрузчик получает URL, он помещает этот URL в карту модуля и отмечает, что он в настоящее время извлекает файл (fetching). Затем он отправит запрос и перейдет к следующему файлу.</p> <p>Что произойдет, если другой модуль зависит от того же файла? Загрузчик будет искать каждый URL в карте модуля. Если он увидит там <code>fetching</code>, он просто перейдет к следующему URL.</p> <p>Но карта модуля не просто отслеживает, какие файлы извлекаются. Карта модуля также служит в качестве кэша для модулей, как мы увидим далее.</p> <h3>Парсинг</h3> <p>Теперь, когда мы извлекли этот файл, нам нужно распарсить его в записи модуля. Это помогает браузеру понять, что представляют собой различные части модуля.</p> <p>После создания запись модуля помещается в карту модуля. Это означает, что всякий раз, когда он запрашивается, загрузчик может вытащить его из этой карты.</p> <p>Есть одна деталь в парсинге, которая может показаться тривиальной, но на самом деле имеет довольно большие последствия. Все модули анализируются так, как если бы они имели <code>use strict</code> вверху. Есть и другие незначительные отличия. Например, ключевое слово <code>await</code> зарезервировано в коде верхнего уровня модуля, а значение <code>this</code> — <code>undefined</code>.</p> <p>Другой способ парсинга называется целью парсинга (parse goal). Если вы анализируете один и тот же файл, но используете разные цели, вы получите разные результаты. Таким образом, вы хотите знать, прежде чем начать парсинг, какой файл вы анализируете — является ли он модулем или нет.</p> <p>В браузерах это довольно легко. Вы просто добавляете <code>type="module"</code> в тег <code><script></code>. Это говорит браузеру, что этот файл должен быть проанализирован как модуль. И поскольку импортировать можно только модули, браузер знает, что любой импорт также является модулем.</p> <p>Но в Node.js вы не можете использовать HTML-теги, поэтому у вас нет возможности использовать атрибут type. Сообщество пыталось решить эту проблему с помощью расширения .mjs. Это расширение говорит Node.js что этот файл является модулем. Сообщество говорит об этом, как о метке для цели парсинга. Обсуждение в настоящее время продолжается, поэтому неясно, какую метку сообщество решит использовать в конце.</p> <p>В любом случае загрузчик определит, следует ли анализировать файл как модуль или нет. Если это модуль и есть импорт, он начнет процесс снова, пока все файлы не будут извлечены и распарсены.</p> <p>И все готово! По окончании процесса загрузки вы перешли от простого файла точки входа к множеству записей модуля.</p> <p>Следующий шаг — создать экземпляр этого модуля и связать Все экземпляры вместе.</p> <h3>Создание экземпляра</h3> <p>Последний шаг — заполнение этих ячеек памяти. JS-движок делает это, выполняя код верхнего уровня — код, который находится вне функций.</p> <p>Помимо простого заполнения этих ячеек памяти, оценка кода также может вызывать различные сайд-эффекты. Например, модуль может сделать запрос на сервер.</p> <p>Из-за потенциальных побочных эффектов вы хотите только один раз оценить модуль. В отличие от линковки, которая происходит при создании экземпляра, которая может выполняться несколько раз с точно таким же результатом, оценка может иметь разные результаты в зависимости от того, сколько раз вы это делаете.</p> <p>Это одна из причин наличия карты модулей. Карта модуля кэширует модуль по каноническому URL, так что для каждого модуля имеется только одна запись модуля. Это гарантирует, что каждый модуль выполняется только один раз.</p> <p>А как насчет тех циклов, о которых мы говорили раньше?</p> <p>В циклической зависимости вы в конечном итоге получаете цикл в графе. Обычно это длинная петля. Но чтобы объяснить проблему, я буду использовать пример с коротким циклом.</p> <p>Давайте посмотрим, как это будет работать с модулями CommonJS. Во-первых, основной модуль выполнит оператор require. Затем будет загружен модуль counter.</p> <p>Модуль <code>counter</code> попытается получить доступ к <code>message</code> из объекта <code>exports</code>. Но так как он еще не был оценен в основном модуле, вернется <code>undefined</code>. JS-движок выделит пространство в памяти для локальной переменной и установит значение <code>undefined</code>.</p> <p>Оценка продолжается до конца кода верхнего уровня counter. Мы хотим узнать, получим ли мы правильное значение для сообщения в конце концов (после оценки main.js), поэтому мы настроим таймаут. Затем оценка возобновляется на main.js.</p> <p>Переменная message будет инициализирована и добавлена в память. Но поскольку между ними нет никакой связи, она останется неопределенной в требуемом модуле.</p> <p>Если экспорт будет обработан с использованием привязок в реальном времени, в конце концов counter увидит правильное значение. К моменту истечения таймаута оценка main.js завершиться и в переменную присвоится значение.</p> <p>Поддержка этих циклов является большим основанием для разработки ES-модулей. Именно эта трехфазная архитектура и сделает её возможной.</p> <h3>Каков текущий статус ES-модулей ?</h3> <p>С выходом Firefox 60 в начале мая, все основные браузеры будут поддерживать ES-модули по умолчанию. Node.js также добавляет поддержку, создана рабочая группа, занимающаяся выяснением проблем совместимости между CommonJS и ES-модулями.</p> <p>Это означает, что вы сможете использовать тег <code><script type="module"></code>, <code>import</code> и <code>export</code>. Однако еще больше возможностей впереди. <a href="https://github.com/tc39/proposal-dynamic-import">Dynamic imports proposal</a> находится на Stage 3 в процессе спецификации, также есть <a href="https://github.com/tc39/proposal-import-meta"><code>import.meta</code></a>, а <a href="https://github.com/domenic/package-name-maps">module resolution proposal</a> поможет сгладить различия между браузерами и Node.js. Поэтому работа с модулями станет еще лучше в будущем.</p> <h2>Благодарность</h2> <p>Спасибо всем, кто дал обратную связь на этот пост, или чьи письма или дискуссии прошлого года, в том числе Акселю Раухшмаеру, Бредли Фариасу, Дейву Хернану, Доменику Дениколе, Хави Хоффману, Джейсону Везерсби, Джей-Эф Бастьену, Йону Копперду, Люку Вагнеру, Майлсу Боринсу, Тиллю Шнайдериту, Тобаясу Копперсу, Йехуде Кацу, участникам сообщества WebAssembly, Рабочей группе Node Modules, а также TC39.</p> </article> </main></body></html>