<divelopers>

описание

Рандомные мысли про HTML, CSS, доступность, пользовательские интерфейсы, производительность, браузеры и веб-стандарты. Автор: @alexnozer

← к каналу @alexnozer_dev

1 183

подписчиков

Охват к подписчикам

57,8%

ERR

Реакции к просмотрам

2,30%

394 на 25 постов

Пересылки к просмотрам

1,77%

304

Постов в день

0,4

всего 25

Где отзываются чаще

доля реакций к просмотрам

14 авг.без подписи5,98%
12 авг.без подписи5,03%
17 июн.Пример приложения на чистом Node.js и Web API Я не так давно делился мнением по поводу высказывания Тимура Шемсединова о том, что фронтенд фреймворки не нужны и это инерция. Я неоднократно видел, что подход разработки с использованием встроенных Web API вполне возможен. Тимур поделился репозиторием с proof of concept своей мысли. Это приложение редактирования профиля: простой сервер с роутером на чистом Node.js и фронтенд в SPA-стиле на ES-модулях, веб-компонентах c Shadow DOM и шаблонами. Приложение позволяет смотреть, искать, создавать, изменять и удалять профили экспертов с валидацией данных на клиенте и сервере, вычисляемыми полями и общей выделенной доменной логикой для клиента и сервера, не простой CRUD. Особенность проекта в том, что он целиком построен на чистом Node.js и браузерных API и не использует рантайм-зависимости, фреймворки и сборщики. Это пример ровно того подхода, о котором говорил Тимур. Ограничения прописаны в репозитории: - Запросы данных напрямую из компонентов запрещены; - Только встроенные API; - Никаких рантайм-зависимостей из npm, dev-зависимости допустимы, но опциональны (проект использует ESLint и Prettier); - Чистый Node.js для серверной части; - Стандартные ES-модули на клиенте; - Веб-компоненты, Template API и Navigation API на клиенте; - <template> для фрагментов UI и веб-компонентов с Shadow DOM, где уместно. В репозитории проекта есть подробный README с описанием архитектуры сервера и клиента, выделенной доменной логики, валидации, роутинга, декларативного рендеринга, шаблонов, сборки страниц, API, хранилища, пользовательских сценариев. Я изучил код. Мне всё понятно, код аккуратный и лаконичный, есть чёткая структура, понятно, где что находится и как это расширять. И нет никаких монструозных абстракций, которых все боятся, когда речь о разработке на чистом Web API. Да, это не похоже на общепринятый «индустриальный стандарт». Тут нет декларативных шаблонов с реактивностью, сложного клиентского состояния, а само приложение ориентировано на сервер. Зато ноль зависимостей, не нужно думать о tree shaking, смотреть bundle analyzer, искать дубликаты, регулярно обновляться, следить за релизами и уязвимостями, слать issue и ждать релиз с исправлением бага, бороться с ограничениями, конфигурировать сборку. Весь код полностью доступен, его можно доработать под потребности, он решает только проектные задачи, лишнее можно удалить, чтобы не висело мёртвым грузом, недостающие абстракции можно дописать, с LLM это довольно быстро. Многие команды застревают в поддержке. Проект работает на старых версиях, уходят месяцы на обновления и оптимизацию бандлов, выделяются отдельные специалисты или инфраструктурные команды (кто-то называет их FrontOps). Я вижу тут компромисс и trade off: DX, некоторые удобства, синтаксический сахар и «индустриальный стандарт» меняется на простоту поддержки, устойчивость, долговечность и полное владение кодовой базой. Снижается паразитная сложность, система становится менее громоздкой, упрощается деплой и поддержка. Сложность становится контролируемой. Но это требует опыта, дисциплины, хорошего знания стандартов и Web API. В процессе возникает «фреймворк», хотя это набор специфичных для проекта решений, что лично я бы фреймворком не назвал. Пусть будет «свой велосипед». React тоже был «своим велосипедом» для решения проблем команды Facebook. Возможно, я предвзят, потому что сам предпочитаю работать со стандартными API и не люблю лишние зависимости. В любом случае, советую посмотреть проект и заложенные там идеи. Без фреймворков писать можно и это не так страшно, сколько непривычно. #js #web_api #architecture4,12%
13 июл.Язык документа и его частей В посте, посвящённому всемирному дню осведомлённости о доступности, упоминалось, что на 13.5% сайтов не задан язык документа. Радует, что это не много по сравнению с другими проблемами. Не радует, что это всё ещё 13.5%. Исправление крайне простое: нужно задать у корневого элемента страницы <html> атрибут lang со значением, которое соответствует основному языку контента на странице в формате BCP 47.  <html lang="ru"></html>  <html lang="ru-RU"></html>  <html lang="en"></html>  <html lang="en-GB"></html>  <html lang="en-US"></html> На этом можно было бы и закончить пост. Просто добавьте атрибут и это исправит одну из топ 6 ошибок доступности, которую обнаруживает WAVE. Но я расскажу ещё некоторые особенности и фишки вокруг языка страницы. От языка страницы зависит отображение некоторых элементов, в частности <q>. Он предназначен для встроенных цитат и обрамляет текст в кавычки. Вид кавычек меняется в зависимости от языка (ёлочки или лапки). Если сайт мультиязычный и хочется что-то менять в CSS в зависимости от языка, есть селектор :lang(). Он более мощный, чем селектор по атрибуту html[lang="..."] из-за масок и работы с вычисленным языком, а не значением в атрибуте. ol:lang(en-US) > li::marker { /* Маркеры списка 1) 2) 3) для американскго английского */ content: counter(list-item) ') '; } ol:lang(ru, by, uk) > li::marker { /* Маркеры списка 1. 2. 3. для восточнославянских языков */ content: counter(list-item) '. '; } На странице могут быть элементы, контент которых не соответствует основному языку страницы: цитаты, термины, названия или переключатель языка. Такие элементы также нужно пометить соответствующим атрибутом lang. Вообще lang — глобальный атрибут и его можно указывать у любых элементов. Язык наследуется вглубь по дереву от ближайшего родителя с lang. Сам атрибут переопределяет унаследованный язык. <html lang="ru"> ... <body> ... <button type="button" popovertarget="langs" > Язык </button> <dialog id="langs" popover> <ul> <li> <a href="/ru" aria-current="true" > Русский </a> </li> <li> <a href="/en" lang="en" hreflang="en" > English </a> </li> <li> <a href="/es" lang="es" hreflang="es" > Español </a> </li> ... </ul> </dialog> </body> </html> Атрибут hreflang помогает роботам понять, что страница по ссылке на другом языке. Это важно при SEO-продвижении мультиязычного сайта. К этому ещё стоит добавить ссылки на альтернативные версии текущей страницы на других языках. <head> ... <link rel="alternate" href="/en/catalog" hreflang="en" lang="en" title="Catalog" > <link rel="alternate" href="/es/catalog" hreflang="es" lang="es" title="Catalogar" > ... </head> Среди контента могут быть общепринятые термины, названия брендов или фразы, которые написаны на другом языке, но не должны переводиться автоматическими переводчиками. На этот случай существует атрибут translate со значением no. <p><span lang="fr" translate="no">Vite</span> позволяет быстро собирать <span lang="en" translate="no">frontend</span>-проекты различной сложности.</p> #html #css #a11y2,97%
3 авг.без подписи2,93%
22 июл.без подписи2,77%
28 июл.без подписи2,75%
20 июл.без подписи2,74%
5 авг.без подписи2,69%
10 авг.без подписи2,67%
10 июл.Эффект съезда с тротуара Читая материал о доступности, встретился с феноменом «эффект съезда с тротуара» (Curb cut effect). Его суть показалась мне интересной, чтобы написать и поделиться своими мыслями в виде поста. Представьте проезжую часть и тротуар с бордюром вдоль неё. В некоторых местах есть съезды: бордюр спущен на уровень проезжей части, а сам тротуар немного наклонён. Это сделано для устранения барьеров людям на инвалидных колясках. Но также это помогает людям с детской коляской, сумкой на колёсиках, тележкой, велосипедом, самокатом, скейтбордом и другими средствами личной мобильности или вещами с колёсами. Ещё это помогает пожилым людям. Эффект съезда с тротуара — это социально-экономический феномен, суть которого в том, что решения, изначально созданные для узкой группы людей, в конечном итоге оказываются полезными и эффективными для более широкой группы. Доступность сайтов и приложений часто воспринимается как специфическая работа ради малой группы пользователей, которой можно пренебречь. Тут как раз действует эффект съезда с тротуара. Улучшение доступности сайта даст больший эффект. Внедрение практик доступности окажет положительный эффект на всех. Причём эффект распространяется не только на людей, но и на машины. Отмечено влияние на поисковые роботы, агенты ИИ, разные парсеры и программы. Вот несколько примеров: - Хороший шрифт с достаточным размером и контрастными цветами улучшает читабельность сайта, пользователям удобнее читать; - Субтитры позволят пользователям смотреть видео без звука и читать субтитры в шумном помещении, если нет наушников; - Достаточно большие интерактивные элементы легче нажимать пальцами или стилусом на смартфоне или планшете с сенсорным экраном; - Подписи, подсказки и автодополнение у полей ввода помогут пользователям быстрее заполнять формы с меньшим количеством ошибок; - Хорошо размеченная с помощью семантического HTML страница более понятна поисковым работам, агентам, лучше разбирается в режиме чтения; - Текстовая расшифровка видео позволяет использовать поиск по тексту, переводить его на другой язык и копировать для различных целей; - Правильно заданный язык страницы и элементов помогает программе-переводчику определить язык и предложить перевод. Примеров можно ещё много придумать. Суть в том, что доступность можно и нужно рассматривать не как специальную задачу по адаптации сайта, а как общее улучшение качества, которое скажется на разных его аспектах и пользователях. #a11y2,65%
17:22без подписи2,37%