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 на максималках. Идея для опенсонс-проекта? 🤔