Semantics for newbies

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

https://zavsievich.github.io/semantics-for-newbies/

Веб-компоненты

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

Google вкладывается в веб-компоненты с самого их появления. Началось все с библиотеки Polymer, из которой вырос Lit. При помощи Lit сейчас разрабатывается YouTube, DevTools и интерфейс Chrome в целом, а недавно веб-компоненты добавили в Maps API. Кроме того, Angular имеет хорошую поддержку. Можно как использовать сторонние веб-компоненты, так и создавать свои при помощи Angular Elements. Также Google разрабатывает 3ю версию Material Design с использованием веб-компонентов.

Microsoft так же делает ставку на веб-компоненты. Они разработали свою библиотеку FAST и дизайн-систему Fluent UI. Сейчас они используются на таких проектах, как MSN, Bing, VS Code, Edge и некоторых других.

Adobe активно использует веб-компоненты в Photoshop Web. Кроме того, они разработали дизайн систему Spectrum на основе веб-компонентов и используют её в некоторых своих проектах.

Salesforce предлагает партнёрам разрабатывать UI для своих решений при помощи собственной разработки - библиотеки Lightning Web Components, построенной поверх веб-компонентов.

IBM добавила поддержку веб-компонентов в свою дизайн-систему Carbon. Аналогично поступили SAP в своей дизайн-системе UI5. Другие компании тоже используют веб-компоненты: Red Hat, Nord, Siemens, Clever Cloud, GitHub, Netflix и тд.

Некоторые компании строят бизнес на веб-компонентах. Так, финская компания Vaadin предлагает одноимённый фреймворк для разработки enterprise-приложений, в основе которого Java и веб-компоненты.

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

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

CSS4 быть!

Как и CSS5. Идея добавить "версию" к CSS была выдвинута ещё в 2020 году. С тех пор периодически обсуждалась. Но не так давно прошло собрание рабочей группы CSS, на котором было принято решение об утверждении CSS4, CSS5 и CSS Next.

Немного истории

На данный момент у HTML и CSS нет версий. Стандарты являются "живыми" и развиваются постоянно, вместо того, чтобы накапливать фичи и раз в некоторое время делать релиз новой версии. Например, стандарт HTML обновлялся сегодня (14 января 2024). Отсутствие версий позволяет постоянно развивать фичи и делать это параллельно. Так, CSS разделён на модули (Grid Module, Display Module, Font Module и т.д.), которые развиваются независимо и имеют свой уровень. Уровень отражает доработки предыдущего и новые фичи.

Возвращаясь к версиям

Последними стандартами с версиями были HTML5 и CSS3. После сосредоточились на развитии живых стандартов. Но релиз новых версий оказал огромное влияние на веб. Если гуглить HTML и CSS, то увидите знакомый оранжевый логотип с цифрой 5 и синий с цифрой 3. W3C даже сделали целый сайт и рекламную кампанию для HTML5. В это время появилось старое и новое, многие задумались о том, чтобы переписать свои сайты на свежие версии. HTML5 и CSS3 появились в вакансиях и резюме и стали уже нарицательными.

С тех пор в HTML и CSS появилось много нового, но нововведения растянуты по времени и внедрены в рамках живых стандартов. То есть у нас всё ещё HTML5 и CSS3. И вот разработчики стандартов решили заняться техномаркетингом и добавить "новые версии" для привлечения внимания. И так:
- CSS3 - последняя версия (~2009-2012)
- CSS4 - фичи, которые мы уже используем: custom properties, flexbox, grid, calc и т.д. (~2013-2018)
- CSS5 - новые фичи: container queries, цветовые пространства, has, view transition, nesting, и т.д. (~2019-2024)
- CSS Next - будущее.

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

CSS Wrapped 2023

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

Радиокнопки на градиентах

София Валитова в своём блоге рассказывает про стилизацию <input type="radio"> при помощи градиентов, без лайфхаков с псевдо-элементами и <label>.

https://ru.ariarzer.dev/2023/tutorials/gradient-radio/

Доступность и торты

Забавная мультипликация про торты и доступность от команды Microsoft Bing 🎂

https://www.youtube.com/watch?v=HE2R86EZPMA

Вас уже больше сотни! 💯
Всем огромное спасибо!

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

Предотвращение потери данных в формах

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

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

Запрос на перезагрузку страницы.

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

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

Сохранение введённых данных.

При вводе данных в форму подпишитесь на одно из событий (input, change), считывайте все текущие данные с полей и сохраняйте их в локальное хранилище (LocalStorage, IndexedDB). При использовании <form> и стандартных полей ввода, вы можете получить объект FormData, сериализовать его в JSON-строку и сохранить.

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

Режим чтения

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

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

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

Забытый скроллбар

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

Дело в том, что поведение скроллбара на MacOS и Window отличается. На MacOS скроллбар отображается поверх страницы и не занимает места. А на Windows скроллбар при стандартных настройках занимает 17px.

В CSS есть замечательная единица vw — ширина текущего вьюпорта. Разработчики на MacOS используют эту единицу, чтобы растянуть блок на всю ширину экрана. И у них всё хорошо. А на Windows блок растянется на всю ширину и к нему прибавится ещё 17px для вертикального скроллбара. В итоге и появляется тот самый горизонтальный скроллбар, потому что блок превысил ширину вьюпорта на эти 17px.

Как быть? Тестировать проект не только на MacOS, но и в других системах при помощи Browserstack, LambdaTest, виртуальной машины или реальных устройств.

А для CSS есть лайфхак. Ширину скроллбара можно вычислить:

body {
  --sb: calc(100vw - 100%);
}

Мы от ширины текущего вьюпорта (например, 1920px) отнимаем 100% ширины <body>, которая как раз включает всё, кроме скроллбара (1903px). Разница — и есть ширина скроллбара (17px). Чтобы это работало правильно, у <body> не должно быть горизонтальных margin и padding, и width должен быть стандартным, то есть 100%. Все эти условия соблюдаются в 99% случаев, поэтому этот хак можно использовать.

.full-width-block {
  width: calc(100vw - var(--sb));
}

Это будет работать, потому что все элементы вложены в <body> и будут наследовать объявленное в нём кастомное свойство
--sb.

Другой лайфхак заключается в том, чтобы объявить свой настоящий vw, в котором будет учитываться скроллбар:

body {
  --sb: calc(100vw - 100%);
  --vw: calc(100vw - var(--sb));
}

.full-width-block {
  width: var(--vw);
}

На MacOS и мобильных устройствах, где скроллбар плавающий, его ширина будет равна 0, поэтому все эти формулы там тоже будут работать. Ссылка на демку codepen, которую можно открыть на разных устройствах и протестировать.

Дополнение к посту выше ⬆️

В MacOS есть настройка, которая переключает режим отображения скроллбара. Можно сделать так, чтобы он занимал место (16px), как в Windows. Делается это в настройках (Settings →Appearance). При этом подход, приведённый в предыдущем посте, тоже будет работать.

Подключение шрифтов с Google Fonts

Скорее всего, вы подключаете на сайт сторонние шрифты. Если сайт небольшой, то, скорее всего, вы найдёте шрифт на Google Fonts, скопируете сниппет и вставите его в <head>:

<head>
  <!-- ... -->
  <link rel="preconnect" href="https://fonts.googleapis.com">
  <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
  <link href="https://fonts.googleapis.com/css2?family=Roboto:wght@400;500;700&display=swap" rel="stylesheet">
</head>

Шрифт подключится, всё будет работать (при условии указания font-family). Но что на самом деле тут происходит и зачем нужны все эти теги? Тут стоит сделать отступление и разобраться, как работает сеть. Чтобы загрузить что-то с удалённого сервера, браузеру нужно:
1) найти URL
2) определить тип ресурса
3) разбить URL на составляющие (схема, домен, путь, параметры и т.д.)
4) определить IP-адрес сервера по имени домена (DNS Lookup)
5) "поздороваться" с сервером (TLS Handshake)
6) обменяться ключами безопасности (SSL)
7) запросить ресурс
8) подождать ответа от сервера
9) скачать ресурс
10) обработать ресурс

Вернёмся к сниппету.

<link rel="preconnect" href="https://fonts.googleapis.com"> 

Сообщает браузеру, что нужно заранее подключиться к домену fonts.googleapis.com. Выполняются этапы 1-6, чтобы при последующих обращениях к этому домену не делать лишнюю работу и не тратить время. На этом домене расположен сервер, который генерирует шрифты по указанным параметрам и CSS-файл с директивами @font-face, которые и подключают шрифт.

<link rel="preconnect" href="https://fonts.gstatic.com" crossorigin> 

Делает то же самое, но уже к домену fonts.gstatic.com и в режиме CORS. Это домен CDN, на которых лежат сгенерированные файлы шрифтов.

<link href="https://fonts.googleapis.com/css2?family=Roboto:wght@400;500;700&display=swap" rel="stylesheet">

Обращается к серверу за итоговым CSS-файлом. Так как к этому домену мы уже заранее подключились, то запрос происходит быстрее и начинается сразу с 7 этапа. Далее браузер разбирает этот файл, находит URL и делает запрос за каждым подходящим шрифтом. И снова благодаря preconnect это происходит быстрее.

Помимо всего прочего, каждый запрос к доменам Google сопровождается передачей информации об устройстве, браузере, настройках и т.д. С одной стороны, эти данные используются, чтобы сгенерировать оптимальный шрифт (для новых браузеров woff2, для старых woff, ttf, eot). С другой стороны, Google есть Google и их основной доход - продажа данных рекламодателям.

Итого имеем: два запроса на предварительное соединение, один запрос за CSS, запросы за шрифтами и передача данных. Вместо этого сделайте следующее:
1) скачайте CSS-файл с определением @font-face по ссылке, которую сгенерировал Google
2) скачайте нужные шрифты из этого файла
3) положите CSS-файл рядом с другими стилями или скопируйте код в ваш файл стилей
4) положите шрифты рядом с проектом
5) удалите все <link> от Google Fonts

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

Публичный черновик WAI-ARIA 1.3

На днях был опубликован первый публичный черновик спецификации WAI-ARIA 1.3. Эта спецификация описывает все aria-атрибуты и роли, которые можно использовать в HTML и SVG для того, чтобы сделать сайты и приложения более доступными для вспомогательных технологий. На текущий момент актуальная версия спецификации - WAI-ARIA 1.2, которая стала рекомендацией 6 июня 2023 года. WAI-ARIA 1.3 была доступна, но находилась в статусе редакторского черновика. Изменение статуса на публичный черновик означает, что документ в целом готов и теперь представлен публике для обсуждения и ревью. А это, в свою очередь, означает, что после нескольких итераций правок есть все шансы, что документ станет кандидатом в рекомендации, а затем рекомендацией.

Вообще круто, что скорость разработки спецификаций увеличилась. Например, в 2023 году произошло два важных события в мире доступности: рекомендацией стали стандарты WCAG 2.2 и WAI-ARIA-1.2. Если всё и дальше будет двигаться такими темпами, то в ближайшие год-два мы увидим WCAG 3 и WAI-ARIA-1.3 в качестве новых рекомендаций. А вместе с WAI-ARIA-1.3 могут обновятся и несколько вспомогательных, но очень полезных документов - ARIA Authoring Practices Guide (APG), Core Accessibility API Mappings и Accessible Name and Denoscription Computation.

Я планирую разобрать, что нового в WAI-ARIA-1.3 и опубликовать это тут.

Interop 2024

Стартовал Interop 2024. о чём в своих блогах рассказали основные участники этой инициативы. Interop - это проект по улучшению кроссбраузерной совместимости. Начался он с инициативы Web Compat 2021. Основные браузеры (Chrome, Edge, Firefox и Safari) договорились и выбрали несколько направлений, по которым хотели достичь кроссбраузерной совместимости. Для каждого направления пишутся тесты (web platform tests) и браузеры соревнуются, кто больше тестов пройдёт. Дашборд с цифрами доступен всем желающим и обновляется в течении года, а в конце года подводятся результаты. Такой подход стимулирует разработчиков браузеров вкладываться в улучшение фич, чтобы не отставать от конкурентов. Нам же, как разработчикам, это хорошо, потому что достигается кроссбраузерная совместимость и появляются новые фичи.

После Web Compat 2021 эта инициатива продолжилась в следующем году под названием Interop 2022 и с тех пор стала ежегодной. В этом году браузеры выбрали довольно большой список направлений, по которым будут работать:
- Доступность
- Вложенность в CSS
- Custom Properties
- Declarative Shadow DOM
- font-size-adjust
- HTTPS URL для веб сокетов
- IndexedDB
- Layout
- События указателя и мыши
- Popover API
- Относительные цвета
- requestVideoFrameCallback
- Стилизация скроллбара
- @starting-style и transition-behavior
- Направления текста
- text-wrap: balance
- URL

К этому списку добавляются и те тесты, которые не удалось пройти в предыдущих Interop и Compat. Следить за ходом инициативы можно на странице Interop 2024.

jQuery умер, да здравствует jQuery.

Говорят, что jQuery умер. Но на днях анонсировали jQuery 4.0.0 Beta. То есть он жив и активно развивается. В связи с этим событием моё мнение по поводу этой библиотеки и отношения к ней. Мнение может не совпадать с мнением большинства.

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

Прежде всего, jQuery - это библиотека. Сравнивать её с фреймворками не корректно. Да, React тоже библиотека, но в реальном мире к нему прикручивают много обвязки и используют как фреймворк. А фреймворки дают каркас приложения, подход к разработке, добавляют ограничения и снижают уровень проектных знаний. Хорошо про это рассказал Илья Климов в одном из видео на примере Vue. Фреймворки нужны для разработки приложений с большим количеством интеракции и бизнес-логикой на клиенте.

Но не все разработают такие приложения. Более того, таких приложений достаточно мало. По данным Web Almanac 2022, React используется на 8% сайтов, Vue на 3%, Angular на 2%, в то время как jQuery на 81%. Помимо больших проектов на фреймворках, есть огромное количество небольших сайтов и приложений, которые разрабатывают веб-студии, диджитал агентства, маленькие аутсорсинговые компании, фрилансеры и т.д. Большое количество проектов в интернете сделаны по классической модели с рендерингом разметки на сервере, и небольшим количеством JavaScript для интерактивности на клиенте.

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

При этом jQuery - это всего лишь библиотека JavaScript. Никто не запрещает использовать современные фичи: модули, Promise, async/await, шаблонные литералы, классы, современные Web API и сторонние пакеты с npm. Да даже @vue/reactivity туда можно засунуть, если хочется реактивности. Код на jQuery можно писать красиво, структурировать, разделять на модули и раскладывать по папкам, но для этого нужен опыт. А если проект "сделал и забыл", как это бывает на фрилансе и в студиях, то и какая разница?

Есть две проблемы с jQuery: спагетти-код и размер бандла. Спагетти-код тянется со времен, когда фронтенда, как направления, не было, а сам JavaScript много чего не умел, не было никаких сборщиков и пакетных менеджеров. Никто не задумывался об архитектуре, просто брали и писали какую-то логику. Размер бандла же может стать проблемой, если стоит задача иметь хорошие метрики производительности. jQuery весит порядка 30кб min+gzip. Но такая ли это проблема в мире, где мы грузим столько же рантайма фреймворка и ещё пол мегабайта логики на нем? В 4й версии jQuery переписали на ESM, а значит можно будет делать tree shaking и code splitting.

Выводы. jQuery все ещё норм для небольших проектов, где надо быстро или "сделал и забыл". Его можно применить для прототипирования, проверки гипотез, MVP. На jQuery можно писать нормальный структурированный код и использовать современные фичи JavaScript. Не все проекты в мире пишутся на фреймворках, есть много популярных решений с jQuery под капотом, В определённых ситуациях он все ещё может быть неплохим выбором.

"Новый критерий WCAG"

Со мной поделились ссылкой на новый критерий WCAG 2.2. И я считаю, что он очень важен!

P.S. Эта страница выполнена в стиле спецификаций W3C, но является шуткой. Авторы предлагают новый "критерий", который в ироничном виде и с использованием ненормативной лексики призывает делать интерфейсы доступными.