Hello <divelopers>! 👋

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

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

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

В этом канале я буду писать свои мысли по поводу всякого фронтенда. Основные темы, которые стоит ожидать:
- HTML
- Семантика
- OpenUI
- CSS
- Доступность
- UX
- Разработка пользовательских интерфейсов
- Web Components
- Браузерные API
- Производительность

Если вам интересны эти темы, то:
📝 подписывайтесь,
💜 ставьте лайки,
🔔 нажимайте колокольчик
и вот это вот всё.

Контент

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

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

Классическая ситуация в теме доступности

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

да зачем нам сдались эти незрячие пользователи

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

зачем нам делать UX

Мда.

Речь о подходе с базовым размером шрифта через calc, vw и указанием всех остальных размеров в rem. Вроде это CSS-шлюзами называют. Так вот, сайт круто вписывается во viewport при любом зуме и размеры меняются при ресайзе без медиа-запросов. Типа круто, но ломает зум страницы.

Помимо этого лагает при ресайзе на dev-машине из-за кучи перерасчётов стилей и вставляет палки в колеса при реализации некоторых штук. Зато дизайнеру нравится. И пофиг, что зумом пользуются не только незрячие 🤦‍♂️

В общем не делайте так.

Реклама в инстаграме

Закажи сайт до конца февраля и адаптив под мобилку в подарок! А если закажешь в марте, то получишь только десктоп? Скидка на медиа-запросы, спешите! И они собираются делать продающий сайт без мобильной версии? А продавать он 60-ти процентам юзеров как будет? 🤦‍♂️

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

Alt картинки:
Рекламный баннер из Instagram: Вы предприниматель и у вас нет сайта? Самое время заказать продающий сайт! Закажите сайт до конца февраля и получите сайт для мобильного телефона в подарок.

Коллега сделал мемас

Alt картинки:
Рик и Морти перед порталом: Доступность это легко, 2 лейбла и табиндекс. Позже, Рик и Морти в ужасе: разные версии стандартов, баги, схожие роли, навигация по таблицам, разное поведение в VoiceOver и NVDA и другие неочевидные моменты.

Про Gulp 🥤

Посмотрел один видео-гайд от автора с 70к подписчиков. Утверждается, что это полный гайд по gulp 4 с современным синтаксисом. Я понимаю, что контент для новичков и подаётся простыми словами, но гайд не соответствует заявленному и вводит в заблуждение.

1) CommonJS в 18 ноде, когда с 13 поддерживаются стандартизированные ES Modules,
2) минификация стилей за счёт опции в sass-компиляторе вместо csso/cssnano,
3) устаревший gulp-autoprefixer вместо postcss пайплайна
4) склейка js-файлов через gulp-concat вместо модульного js
5) отсутствие транспиляции js,
6) минификация js через uglify-es вместо terser
7) отсутствие задач на обработку графики, обработку noscript, копирование статики, генерацию фавиконок и тд,
8) вставка скриптов в конец body

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

И вообще, кажется, что gulp уже постепенно отмирает. Нет, он все ещё работает, выполняет свои задачи и является верным другом многих верстальщиков. Но последняя версия вышла почти 4 года назад, в мае 19 года. С тех пор никаких обновлений нет, на гитхабе 24 открытых issue, но и помимо них, думаю, там есть что доработать и улучшить. 4 года - это достаточно большой срок. Обновилась нода, обновились зависимости, что-то устарело, что-то переписали, появились новые возможности в js. Gulp при этом не развивается, при установке куча предупреждений об ошибках. Таким же образом дела обстоят с gulp-плагинами.

Значит ли это, что gulp надо выкинуть и взять модную технологию X? Нет. Если есть рабочая сборка, которая решает задачи, можно пользоваться дальше. Но стоит встряхнуть gulpfile, обновить его до современного синтаксиса, пробежаться по плагинам и заменить их на более свежие:
- node-sass ➡️ sass
- gulp-autoprefixer ➡️ gulp-postcss + autoprefixer
- gulp-uglify ➡️ gulp-terser
- imagemin ➡️ sharp
- gulp-cssmin ➡️ gulp-postcss + csso
- js обрабатывать с помощью gulp-esbuild,
- использовать модули
- разнести таски по отдельным файлам
- добавить dev и prod сборку,
- и т.д.

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

Элемент <p>

Согласно спеке <p> - это контейнер для фразового контента, который образует тематический блок текста из одного или нескольких предложений. К фразовому контенту относится текст, элементы семантики текста (<i>, <strong>, <cite>, тд.), аудио, видео, картинки, лейблы и контролы.

Несколько кейсов, где можно использовать <p>:

Кейс 1: классические абзацы.

Набор следующих друг за другом <p> с предложениями внутри. Могут идти вперемешку с <figure>, <blockquote>, <ul>, <ol>, <dl> и т.д. Тем самым формируется структура контента статьи, блогпоста, лонгрида.

Кейс 2: короткие тематические фразы.

Географический адрес, слоган, краткое описание в карточке товара, ошибка под полем ввода, цитата в <blockquote>. В общем заворачиваем в <p> какую-то фразу, может даже из одного слова.

Кейс 3: лейбл и поле

Можно использовать <p> для группировки лейбла и инпута, или любого другого контрола. Это разрешено спецификацией и абсолютно валидно. Сам так очень редко делаю, но встречаю иногда такой вариант использования.

Кейс 4: подзаголовок рядом с заголовком

В этом случае <p> содержит текст подзаголовка, а сам следует сразу после <h*> и вместе с ним располагается внутри <hgroup>, <header> или <div>. Опять же, текст подзаголовка может содержать одно слово.

***

Но вообще надо исходить из вопроса:

это сделает удобнее для пользователей?

Скринридеры не зачитывают <p> особым образом, для них это как <div> с текстом. Поисковые краулеры, вероятно, лучше распознают тексты, размеченные при помощи <p>. По умолчанию у <p> есть отступы. Если сломается CSS, страницу решат распечатать, посмотреть в режиме чтения, то <p> будет лучше отображаться и разрядит текст отступами. Если текст с <p> редактируется в WYSIWYG-редакторе, они лучше парсят и отображают контент с <p>. В остальном какой-то другой пользы или вреда от <p> и длины контента в нем для пользователя нет.

HTML: 25 фич, которые сделают ваш сайт удобнее

Выступил 20 апреля 2023 на MinskCSS! Для меня это первый внешний митап, до этого выступал только на внутренних ивентах компаний. И так вышло, что это был юбилейный, 10й митап 🎉. Огромная благодарность организаторам за это крутое мероприятие и возможность принять в нем участие! 🔥

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

https://www.youtube.com/watch?v=-aeKCwJY6c8&t=64s

"Поделиться" в инстаграме

Кто, вот просто какой сверхразум из инстаграма додумался добавлять аккаунт, публикацию которого я хочу пошарить, на первую позицию в списке моих контактов? Зачем? Это список моих контактов, отсортированных по частоте взаимодействия. Какого хрена там появляется какой-то аккаунт? Я привык, что на первой позиции всегда находился контакт, с которым я больше всего взаимодействую. И машинально я выбираю первый контакт, если хочу ему пошарить публикацию. Вместо этого я шарю публикацию в тот аккаунт, из которого и хочу пошарить. ЗАЧЕМ? Хорошо хоть отмена есть.

Список для карточек

Речь о паттерне, когда создаётся список <ul> и в его элементы <li> вкладываются карточки. Небольшой тред о пользе списков для ассистивных технологий.

Семантика.

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

Количество.

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

Шорткаты.

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

***

В целом списки полезны для ассистивных технологий. Однако я слышал мнение, в том числе от незрячих пользователей, что использовать списки везде тоже не стоит, так как это приводит к переизбытку информацию. Если элементов мало (меньше 3-5), то использовать список не нужно.

В качестве альтернативы списку можно использовать <div role="group">, это тоже сообщает пользователю о группе каких-то элементов, но без информации о количестве и позиции, чтобы не спамить лишней информацией.

Коротко (не очень) о работе над доступностью

Это комбобокс. Да нет же, это поле с автокомплитом. Нет, тут просто фильтрация по листбоксу. Давайте добавим activedescendant? Но мы не можем добавить, нельзя по спеке

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

Это выпадающее меню? Или поповер с кнопками? Или поповер с листбоксом? Или селектбокс?

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

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

Хочется, что-ли, какой-то ресурс, где была бы собрана терминология и паттерны с подробным описанием, как, почему, когда использовать и когда нет, различия между похожими паттернами, хорошие примеры. В общем такой AGP на максималках. Идея для опенсонс-проекта? 🤔

Нативные поповеры!

В Chrome 114, который вышел в конце мая 2023, завезли Popover API. Firefox и Safari поддержали этот API и должны выкатить в ближайшее время. И это крутая новость!

<button popovertarget="note">
  Подробнее
</button>

<div id="note" popover>
  Всплывающая подсказка
</div>

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

Добавляется 3 новых HTML-атрибута:
1) Атрибут popover, popover="auto" или popover="manual" делает элемент поповером. Он вырывается из контекста документа, перемещается на верхний слой (top-layer) и скрывается (display: none)
2) Атрибут popovertarget="{id}" указывается у <button> и содержит id поповера. Тем самым создаётся элемент-триггер, который будет управлять поповером. При клике на элемент, поповер будет показываться или скрываться.
3) Атрибут popovertargetaction также указывается у <button>. Принимает значения show (при клике на триггер будет только показываться), hide (только скрываться) или toggle (переключаться, это значение по умолчанию).

В CSS добавляется псевдокласс :popover-open для стилизации открытого поповера. Можно, например, поиграться с позиционированием или сделать хвостик. У поповера есть псевдоэлемент ::backdrop, который можно стилизовать, например сделать затемненный фон.

В JS добавляется 3 метода для элементов с атрибутом popover: showPopover(), hidePopover() и togglePopover() для программного управления отображением. Добавляется новое событие beforetoggle, которое возникает перед появлением поповера. Можно, например, сделать fetch и подставить данные в поповер. Вместе с событием появляется и новый интерфейс события ToggleEvent, в котором будет состояние поповера.

С точки зрения доступности у кнопки с popovertarget подразумевается встроенный aria-expanded, но не aria-haspopup. Роль самого поповера сохраняется, нужно указывать вручную. Зато есть нативный focus-trap и закрытие по Esc.

Ложка дегтя. Пока не понятно, что там с отображением по hover. В обсуждении есть атрибут popoverhoveraction, но он не стандартизован, поэтому тултипы пока не сделать. Думаю, это вопрос времени. Также хотелось бы встроенные aria. Но начало хорошее, крутая апишка.

Коротко о бигтехах

Холдинг ByteDance Ltd, не может уже который год исправить баг, когда при переходе по ссылке на видео в ТикТок открывается вообще левое видео. И это в проде. Уже пару лет. У бигтеха с 60к сотрудников и 35млрд оборотом. Не баг а фича?

Вечные вопросы

<b> или <strong>? <em> или <i>?

Часто говорят, что нужно использовать <strong> и <em> соответственно, потому что они семантичные, а <b> с <i> - нет. Но на самом деле это не так. Вообще все элементы в HTML имеют семантику, которая определяется спецификацией и встроенной ролью (role). Семантика = смысл, то, что означает контент внутри элемента.

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

<strong> - фрагмент текста, который обозначает важность, срочность или серьезность. Так же выделяется полужирным, потому что так в типографике сложилось, но стили, опять же, можно переопределить. Например, это может быть разного рода предупреждающий текст: "Внимание!", "Вы уверены?", "Осторожно!", "Обращаем ваше внимание...". То есть это такой текст, на который пользователь должен обратить особое внимание и прочесть раньше, чем остальной текст.

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

<em> - это фрагмент текста, на который делается логическое ударение, или иначе это ещё называют эмфазой, от чего и название элемента (em - emphasis). Выделяется курсивом, потому что так принято в типографике. Это слова или фразы, которые произносятся с ударением, экспрессией, восклицанием для повышения эмоциональной выразительности. Часто в таких предложениях присутствует восклицательный знак или же фраза является цитатой (для которых есть свой элемент).

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

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

Поэтому размечайте тексты правильно.

Новое в CSS и UI

На мероприятии Google I/O показали, что нового появилось в CSS и UI за последнее время. На самом деле много всего интересного и кое что даже фундаментальное.

Новый элемент <selectmenu>

OpenUI разрабатывает новый элемент - <selectmenu>. Он уже более года доступен в Chrome за флагом. Этот элемент должен решить давнюю проблему - невозможность кастомизации нативного <select>.

<selectmenu>
  <button 
    slot="button"    
    behavior="button"
  >
    <span 
    behavior="selected-value"
    ></span>
  </button>
  <option>Option 1</option>
  <option>Option 2</option>
</selectmenu>

В чем проблема? Есть нативный <select>, который из коробки доступен, работает с формами и т.д. Но поповер с опциями никак не может быть стилизован, потому что находится на уровне ОС и недоступен для CSS. Да и внешняя часть имеет ограничения стилизации. Это приводит к тому, что вместо нативного <select> используются библиотеки, которые можно подогнать под дизайн и сделать консистентно во всех браузерах. Но это лишний js на клиенте, а во многих решениях доступность вообще не проработана. <selectmenu> - это решение. Это встроенный веб-компонент, который использует Shadow DOM для инкапсуляции разметки и логики внутри себя, slots для проброса произвольной разметки в определённые места и CSS Shadow Parts для стилизации некоторых внутренних частей.

У <selectmenu> есть определённая анатомия. Компонент состоит из кнопки, внутри которой элемент с текстом выбранной опции и иконка-треугольник. За кнопкой располагается поповер, куда попадают опции и который рисуется при открытии селекта. По умолчанию <selectmenu> работает как <select>, а именно служит контейнером для элементов <option>, которые могут быть опционально обернуты в <optgroup>.

<selectmenu>
  <option>Опция 1</option>
  <option>Опция 2</option>
  <optgroup label="Группа">
    <option>Опция 3</option>
    <option>Опция 4</option>
  </optgroup>
</selectmenu>

Благодаря механизму CSS Shadow Parts мы получаем возможность пробиться внутрь Shadow DOM и стилизовать некоторые части <selectmenu> при помощи специального селектора ::part(name), где name - название части: button, selected-value и listbox. Также доступны псевдоклассы :open и :closed для стилизации открытого и закрытого состояний <selectmenu> соответственно. Полезно для стилизации маркера.

selectmenu::part(button) {
  /* стили кнопки */
}

selectmenu::part(selected-value) {
  /* стили выбранного значения */
}

selectmenu::part(listbox) {
  /* стили выпадающего списка */
}

selectmenu:open {
  /* стили при открытом выпадающем списке */
}

selectmenu:closed {
  /* стили при закрытом выпадающем списке */
}

Можно передавать свою разметку, используя слоты. Доступные слоты: button, selected-value, marker и listbox. Браузер заменит стандартную разметку на ту, что была передана в слот. Атрибут behavior сообщает браузеру поведение, которое нужно добавить элементу. Внутри <option> также можно разместить дополнительную разметку, что позволяет добавить иконки, картинки, многострочный текст и все это стилизовать как нужно.

<selectmenu>
  <div slot="button">
    <noscript><!-- ... --></noscript>
    <button 
      behavior="button"
    ></button>
  </div>
  <option>
    <noscript><!-- ... --></noscript>
    <span>Опция 3</span>
  </option>
  <option>
    <noscript><!-- ... --></noscript>
    <span>Опция 4</span>
  </option>
</selectmenu>

В слот listbox можно передать разметку, которая будет использоваться как контейнер для опций. В таком случае нужно указать атрибуты behavior="listbox" и popover="auto" (да, тут используется Popover API). Можно сделать селектор цветов как в MS Word.

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

UPD: компонент переименовали в <selectlist>, чтобы не было путаницы с элементом <menu> и паттерном меню.

UPD2: компонент слегка переделали, заменив селектор ::part() на псевдоклассы, а также добавив новые вспомогательные элементы <listbox> и <selectedoption>. Работа активно идёт.