Делает, но поддержка Invoker Commands пока не такая хорошая. Применение Popover API к <dialog> позволяет создавать только немодальные диалоги, которые не блокируют остальной интерфейс. Чтобы создать модальный диалог, его нужно открыть в соответствующем режиме через вызов showModal() или декларативно через command="show-modal". Тогда браузер сам поставит inert, вынесет окно в отдельный слой и так далее.
Отчасти решаемые, отчасти нет. Можно заставить чекбокс быть кнопкой меню, обвешав его с ног до головы ARIA-атрибутами и JS-ом, который будет делать всё то, что чекбокс не делает, а кнопка меню должна.
Что касается работоспособности без JS, то есть как минимум три стратегии:
Прогрессивное улучшение. Без JS меню просто всегда отображается и не скрывается. С JS скрыто и переключается честно, с помощью кнопки со всеми нужными состояниями.
nojs + <noscript>. На body висит класс nojs и удаляется скриптом при загрузке страницы. Соответственно, если скрипт отработал, значит JS есть и класса не будет. Если нет, класс останется и от него в CSS можно скрыть элементы, которые зависят от JS. А <noscript> отображает содержимое только когда JS нет. В него помещается упрощённый резервный вариант, который работает без JS.
Ссылки и формы. Любое действие — это переход на другую страницу или отправка формы с обработкой на сервере. Меню может быть отдельной лёгкой страницей с набором ссылок, а кнопка раскрытия меню — ссылка на эту страницу. Вот статья об этом. С View Transition очень даже неплохо получается.
В современных браузерах кое какие элементы UI можно реализовать средствами HTML/CSS и это работает без JS: <details> + <summary>, Popover API, Invoker Commands, <dialog>, Scroll Snap. Это честные способы реализовать что-то, например меню через Popover API, вместо хаков на чекбоксах.
Потому что семантика, свойства, состояния и поведение не соответствуют требованиям виджета и ожиданиям пользователей. Поясню на примере чекбокса и кнопки раскрытия меню.
Чекбокс — это элемент формы, который предназначен для выбора одной или нескольких опций. У него есть устоявшийся аффорданс (внешний вид, который намекает на назначение элемента, подпись и квадрат с пустотой или галочкой внутри). Пользователи видит это и понимают, что можно нажать, галочка появится/исчезнет, опция будет выбрана/не выбрана, это не приведёт ни к каким лишним действиям и где-то рядом будет форма с кнопкой отправки.
Пользователи мыши ожидают, что нажатие по тексту также меняет состояние чекбокса. Пользователи клавиатуры ожидают, что на элемент можно сфокусироваться и появится рамка фокуса, а нажатие пробела переключит состояние. Пользователи программ чтения с экрана слышат подпись, роль и состояние элемента и из этого понимают, что это чекбокс и что с ним можно делать. Пользователи программ голосового управления ожидают, что голосовая команда «отметь такой-то флажок» сработает. И так далее, таковы ожидания.
Кнопка меню работает иначе и там другие ожидания. Использование чекбокса для меню не соответствует ожиданиям:
Если чекбокс скрыт (часто при реализации меню его скрывают и оставляют <label>), то пользователи клавиатуры и программ чтения с экрана не смогут сфокусироваться и активировать его;
Если чекбокс скрыт визуально, но доступен для клавиатуры, это приводит либо к тому, что пользователи не видят, где находится фокус, либо состояние фокуса не соответствует тому, что отображается. Обе ситуации запутывают;
Пользователи программ чтения с экрана слышат про чекбокс и не понимают, что происходит. Почему тут чекбокс? Это какая-то форма? Как чекбокс связан с меню? Что нужно сделать?
Пользователи программ голосового управления могут озвучивать команду и не получать никакой обратной связи, ничего не произойдёт;
При открытии меню, пользователи программ чтения с экрана услышат «отмечено» вместо «развёрнуто»;
При открытии с помощью клавиатуры фокус не будет помещён на первый интерактивный элемент внутри меню, нажатие Esc не приведёт к закрытию меню и возврату фокуса на элемент, табуляция внутри меню не будет зациклена;
И так далее...
Чекбокс просто не соответствует тому, как должно себя вести меню.
Здравый подход, побольше бы разработчиков ему следовало. Однако по поводу п.2 сделаю оговорку. Фанатичное использование CSS только ради того, чтобы не писать JS может привести к хакам.
Одно дело подсчёт элементов (в комментариях ниже писали). CSS-счётчики и вывод в content. Это нормально. Другое дело всякие «меню» на чекбоксах и «вкладки» на радио-кнопках с :checked. Вот так лучше не делать, потому что это портит UX, доступность и это хак.
Инициатива Baseline отводит 30 месяцев (2.5 года) с момента появления фичи во всех основных браузерах (Chrome, Edge, Firefox, Safari и их мобильных версиях). Спустя это время фича получает статус Baseline Widely Available, то есть по исследованиям группы WebDX этого времени достаточно для широкого распространения. Так что ваш подход и временной диапазон близок к статусам Baseline.
«Без JS» действительно не получится. Иногда эта догма приводит к разного рода хакам на чекбоксах и прочему, что лучше было бы реализовать на JS. Но то, что платформа предлагает некоторые примитивы, которые позволяют сократить объём JS — это хорошо на мой взгляд.
Для Lit подойдут как любые библиотекии веб-компонентов (сделанные на любом фреймворке или без), так и одиночные веб-компоненты. Обычно достаточно загуглить «x web component», где x — название того, что вам нужно. Посмотреть подборку библиотек веб-компонентов можно в этом репозитории. Ещё недавно релизнулись Web Awesome, наследник Shoelace от тех же авторов.
Чем-то напомнило мне расширение стандарта ESM aka import assertion или же import attributes. styles.css.js лично для меня выглядит немного противоестественно, а писать стили в шаблонных строках не всегда удобно. Да, есть расширения для IDE с подсветкой синтаксиса и автокомплитом в шаблонных строках, но на моей практике они не работают так же хорошо, как нативные файлы. Import Attributes позволяют импортировать CSS и JSON, а в будущем HTML напрямую. Кажется, этот стандарт станет хорошим дополнением к вашей идее
В целом выглядит интересно, мне всегда любопытно наблюдать за standard-based решениями без лишних абстракций и кастомного синтаксиса на каждом углу. Поэтому удачи в развитии идеи!
За веб-компоненты однозначно плюс, закинул себе в закладки, чтоб подробнее посмотреть. По поводу автокомплита в браузере, подсказок и прочего советую посмотреть в сторону генерации Custom Elements Manifest и набор инструментов Web Components Toolkit.
На самом деле уже давно нет никаких стандартных разрешений. Да, есть статистически более распространённые, но в реальности огромное многообразие устройств, настроек, режимов и т.д.
В этой статье, как и во многих вводных статьях про веб-компоненты, есть важное допущение. Веб-компоненты сравниваются и напрямую противопоставляются популярным JS-фреймворкам. Если смотреть с такой стороны, то веб-компоненты во многом будут уступать фреймворкам по функциональности и удобству разработки.
Например, нет декларативного синтаксиса шаблонов для привязки данных, циклов и условной отрисовки. Нет реактивных данных. Не хватает многих привычных вещей из фреймворков. С помощью современного JS и Web API всё недостающее можно реализовать, но для многих это будет созданием велосипеда и тратой времени.
Поэтому мне кажется, что правильнее смотреть на веб-компоненты, как на набор низкоуровневых примитивов браузера, расширений DOM API, которые позволяют создавать собственные DOM-элементы с логикой и стилями. Как эти примитивы использовать и что из них можно построить — уже другой вопрос. А создать можно много чего.
Ну и проводить какие-то аналогии и сравнения с тем же React или Vue не голых веб-компонентов, а таких же надстроек над DOM и веб-компонентами, как, например, Lit.
Потому что веб-компоненты — всего лишь набор стандартов/DOM API/примитивов. Фьюзор, как я понял, это библиотека/фреймворк с дополнительной логикой и, судя по JSX, с компилятором. Поэтому фьюзор (или что-либо ещё) нужно сравнивать не с голыми веб-компонентами, которые работают в браузере как есть без сборщиков, компиляторов и кастомного синтаксиса, а с соответствующими библиотеками/фреймворками, в основе которых веб-компоненты: Lit, Stencil, Symbiote и так далее. Они как раз решают проблему многословности стандартного API.
В будущем, когда поддержка селектора :has() станет лучше, плавающие подписи можно будет делать с сохранением порядка <label> - <input>. Сейчас это обусловлено реализацией через + или ~. Со временем можно будет делать так:
А что насчёт проектов, которые не используют фронтовые фреймворки с компонентным подходом? Мир ими не ограничивается, есть огромное количество альтернативный технологических стеков. БЭМ ни разу не устарел и всё ещё отличный способ общаться на одном языке, писать консистентный и понятный код.
Здесь стоят упоминания Web Components — веб-нативный эквивалент библиотек компонентов JS. Но они появились слишком поздно и не стали популярными.
На самом деле не эквивалент. Компоненты JS-библиотек — это абстракции, единицы организации кода для объединения разметки, стилей и логики. <UserList> не существует в DOM. Веб-компоненты — это полноценные HTML-элементы, которые существуют в рамках DOM, завязаны на жизненный цикл элементов и парсер.
Появились веб-компоненты примерно в одно время с React. Последний публично презентовали в 2013 году, на год позже, чем показали веб-компоненты.
Что касается популярности, то правильнее было бы сказать не стали хайповыми. При этом они используются много где и много кем. По статистике хрома ~17% страниц используют как минимум один веб-компонент. Многие крупные компании создают дизайн-системы на веб-компонентах и используют их в своих продуктах.
Делает, но поддержка Invoker Commands пока не такая хорошая. Применение Popover API к
<dialog>позволяет создавать только немодальные диалоги, которые не блокируют остальной интерфейс. Чтобы создать модальный диалог, его нужно открыть в соответствующем режиме через вызовshowModal()или декларативно черезcommand="show-modal". Тогда браузер сам поставитinert, вынесет окно в отдельный слой и так далее.Отчасти решаемые, отчасти нет. Можно заставить чекбокс быть кнопкой меню, обвешав его с ног до головы ARIA-атрибутами и JS-ом, который будет делать всё то, что чекбокс не делает, а кнопка меню должна.
Что касается работоспособности без JS, то есть как минимум три стратегии:
Прогрессивное улучшение. Без JS меню просто всегда отображается и не скрывается. С JS скрыто и переключается честно, с помощью кнопки со всеми нужными состояниями.
nojs+<noscript>. Наbodyвисит классnojsи удаляется скриптом при загрузке страницы. Соответственно, если скрипт отработал, значит JS есть и класса не будет. Если нет, класс останется и от него в CSS можно скрыть элементы, которые зависят от JS. А<noscript>отображает содержимое только когда JS нет. В него помещается упрощённый резервный вариант, который работает без JS.Ссылки и формы. Любое действие — это переход на другую страницу или отправка формы с обработкой на сервере. Меню может быть отдельной лёгкой страницей с набором ссылок, а кнопка раскрытия меню — ссылка на эту страницу. Вот статья об этом. С View Transition очень даже неплохо получается.
В современных браузерах кое какие элементы UI можно реализовать средствами HTML/CSS и это работает без JS:
<details>+<summary>, Popover API, Invoker Commands,<dialog>, Scroll Snap. Это честные способы реализовать что-то, например меню через Popover API, вместо хаков на чекбоксах.Потому что семантика, свойства, состояния и поведение не соответствуют требованиям виджета и ожиданиям пользователей. Поясню на примере чекбокса и кнопки раскрытия меню.
Чекбокс — это элемент формы, который предназначен для выбора одной или нескольких опций. У него есть устоявшийся аффорданс (внешний вид, который намекает на назначение элемента, подпись и квадрат с пустотой или галочкой внутри). Пользователи видит это и понимают, что можно нажать, галочка появится/исчезнет, опция будет выбрана/не выбрана, это не приведёт ни к каким лишним действиям и где-то рядом будет форма с кнопкой отправки.
Пользователи мыши ожидают, что нажатие по тексту также меняет состояние чекбокса. Пользователи клавиатуры ожидают, что на элемент можно сфокусироваться и появится рамка фокуса, а нажатие пробела переключит состояние. Пользователи программ чтения с экрана слышат подпись, роль и состояние элемента и из этого понимают, что это чекбокс и что с ним можно делать. Пользователи программ голосового управления ожидают, что голосовая команда «отметь такой-то флажок» сработает. И так далее, таковы ожидания.
Кнопка меню работает иначе и там другие ожидания. Использование чекбокса для меню не соответствует ожиданиям:
Если чекбокс скрыт (часто при реализации меню его скрывают и оставляют
<label>), то пользователи клавиатуры и программ чтения с экрана не смогут сфокусироваться и активировать его;Если чекбокс скрыт визуально, но доступен для клавиатуры, это приводит либо к тому, что пользователи не видят, где находится фокус, либо состояние фокуса не соответствует тому, что отображается. Обе ситуации запутывают;
Пользователи программ чтения с экрана слышат про чекбокс и не понимают, что происходит. Почему тут чекбокс? Это какая-то форма? Как чекбокс связан с меню? Что нужно сделать?
Пользователи программ голосового управления могут озвучивать команду и не получать никакой обратной связи, ничего не произойдёт;
При открытии меню, пользователи программ чтения с экрана услышат «отмечено» вместо «развёрнуто»;
При открытии с помощью клавиатуры фокус не будет помещён на первый интерактивный элемент внутри меню, нажатие Esc не приведёт к закрытию меню и возврату фокуса на элемент, табуляция внутри меню не будет зациклена;
И так далее...
Чекбокс просто не соответствует тому, как должно себя вести меню.
Здравый подход, побольше бы разработчиков ему следовало. Однако по поводу п.2 сделаю оговорку. Фанатичное использование CSS только ради того, чтобы не писать JS может привести к хакам.
Одно дело подсчёт элементов (в комментариях ниже писали). CSS-счётчики и вывод в
content. Это нормально. Другое дело всякие «меню» на чекбоксах и «вкладки» на радио-кнопках с:checked. Вот так лучше не делать, потому что это портит UX, доступность и это хак.Инициатива Baseline отводит 30 месяцев (2.5 года) с момента появления фичи во всех основных браузерах (Chrome, Edge, Firefox, Safari и их мобильных версиях). Спустя это время фича получает статус Baseline Widely Available, то есть по исследованиям группы WebDX этого времени достаточно для широкого распространения. Так что ваш подход и временной диапазон близок к статусам Baseline.
Это одно из базовых требований доступности и некоторые люди таким образом взаимодействуют с интерфейсом.
«Без JS» действительно не получится. Иногда эта догма приводит к разного рода хакам на чекбоксах и прочему, что лучше было бы реализовать на JS. Но то, что платформа предлагает некоторые примитивы, которые позволяют сократить объём JS — это хорошо на мой взгляд.
Для Lit подойдут как любые библиотекии веб-компонентов (сделанные на любом фреймворке или без), так и одиночные веб-компоненты. Обычно достаточно загуглить «x web component», где x — название того, что вам нужно. Посмотреть подборку библиотек веб-компонентов можно в этом репозитории. Ещё недавно релизнулись Web Awesome, наследник Shoelace от тех же авторов.
Разница если и есть, то она такая, что ей можно пренебречь. Иными словами, ощутимой разницы не будет.
Чем-то напомнило мне расширение стандарта ESM aka import assertion или же import attributes.
styles.css.jsлично для меня выглядит немного противоестественно, а писать стили в шаблонных строках не всегда удобно. Да, есть расширения для IDE с подсветкой синтаксиса и автокомплитом в шаблонных строках, но на моей практике они не работают так же хорошо, как нативные файлы. Import Attributes позволяют импортировать CSS и JSON, а в будущем HTML напрямую. Кажется, этот стандарт станет хорошим дополнением к вашей идееВ целом выглядит интересно, мне всегда любопытно наблюдать за standard-based решениями без лишних абстракций и кастомного синтаксиса на каждом углу. Поэтому удачи в развитии идеи!
За веб-компоненты однозначно плюс, закинул себе в закладки, чтоб подробнее посмотреть. По поводу автокомплита в браузере, подсказок и прочего советую посмотреть в сторону генерации Custom Elements Manifest и набор инструментов Web Components Toolkit.
Её, к сожалению, временно забросили, перекинув основную часть команды на другие проекты. Поэтому может лет 10, а может и никогда
На самом деле уже давно нет никаких стандартных разрешений. Да, есть статистически более распространённые, но в реальности огромное многообразие устройств, настроек, режимов и т.д.
Да, согласен, лучше
:focus-visibleиспользоватьТак 2.0 ведь остаётся как есть без изменений, что и означает долговечность. А 4.0, по сути, новое решение с тем же именем.
В этой статье, как и во многих вводных статьях про веб-компоненты, есть важное допущение. Веб-компоненты сравниваются и напрямую противопоставляются популярным JS-фреймворкам. Если смотреть с такой стороны, то веб-компоненты во многом будут уступать фреймворкам по функциональности и удобству разработки.
Например, нет декларативного синтаксиса шаблонов для привязки данных, циклов и условной отрисовки. Нет реактивных данных. Не хватает многих привычных вещей из фреймворков. С помощью современного JS и Web API всё недостающее можно реализовать, но для многих это будет созданием велосипеда и тратой времени.
Поэтому мне кажется, что правильнее смотреть на веб-компоненты, как на набор низкоуровневых примитивов браузера, расширений DOM API, которые позволяют создавать собственные DOM-элементы с логикой и стилями. Как эти примитивы использовать и что из них можно построить — уже другой вопрос. А создать можно много чего.
Ну и проводить какие-то аналогии и сравнения с тем же React или Vue не голых веб-компонентов, а таких же надстроек над DOM и веб-компонентами, как, например, Lit.
Потому что веб-компоненты — всего лишь набор стандартов/DOM API/примитивов. Фьюзор, как я понял, это библиотека/фреймворк с дополнительной логикой и, судя по JSX, с компилятором. Поэтому фьюзор (или что-либо ещё) нужно сравнивать не с голыми веб-компонентами, которые работают в браузере как есть без сборщиков, компиляторов и кастомного синтаксиса, а с соответствующими библиотеками/фреймворками, в основе которых веб-компоненты: Lit, Stencil, Symbiote и так далее. Они как раз решают проблему многословности стандартного API.
В будущем, когда поддержка селектора
:has()станет лучше, плавающие подписи можно будет делать с сохранением порядка<label>-<input>. Сейчас это обусловлено реализацией через+или~. Со временем можно будет делать так:А что насчёт проектов, которые не используют фронтовые фреймворки с компонентным подходом? Мир ими не ограничивается, есть огромное количество альтернативный технологических стеков. БЭМ ни разу не устарел и всё ещё отличный способ общаться на одном языке, писать консистентный и понятный код.
На самом деле не эквивалент. Компоненты JS-библиотек — это абстракции, единицы организации кода для объединения разметки, стилей и логики.
<UserList>не существует в DOM. Веб-компоненты — это полноценные HTML-элементы, которые существуют в рамках DOM, завязаны на жизненный цикл элементов и парсер.Появились веб-компоненты примерно в одно время с React. Последний публично презентовали в 2013 году, на год позже, чем показали веб-компоненты.
Что касается популярности, то правильнее было бы сказать не стали хайповыми. При этом они используются много где и много кем. По статистике хрома ~17% страниц используют как минимум один веб-компонент. Многие крупные компании создают дизайн-системы на веб-компонентах и используют их в своих продуктах.