Для 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% страниц используют как минимум один веб-компонент. Многие крупные компании создают дизайн-системы на веб-компонентах и используют их в своих продуктах.
Если сделано правильно, то не будет. Зум просто пропорционально увеличивает всю страницу. С адаптивностью (а это стандарт де-факто), страница просто скатится в лэйаут для мобилок. Но это на экстремальных значениях зума, типа 400%. Я увеличиваю на 125-150 и в большинстве случаев всё нормально.
Если брать стандарт WCAG, то там есть требование, чтобы страница не разваливалась при 200% зуме. Удовлетворить критерию не сложно, но это делает функцию зума полезной и ничего не ломает.
Ну и для таких нюансов давно придуманы "пользовательские таблицы стилей"
Пользовательские таблицы стилей, всё же, не для рядового пользователя. Не каждый напишет CSS и разберётся, как его подключить к странице. А из браузеров давно выпилили эту возможность, осталась только в виде расширений.
Но это всё и не нужно, потому что высококонтрастные темы и прочее есть в настройках операционной системы. И в CSS с помощью медиа-запросов это можно отслеживать. Автор в статье как раз и пишет о нюансах в этих режимах.
Их поддержка, повторюсь, не такая сложная, хотя и соглашусь, что иногда выглядит как хаки. Но эти мелочи делают ненужными пользовательские таблицы стилей.
Но, как я говорил, Интернет для всех, поэтому в нём должно найтись место и пользователям зума, и тем, кто считает это ненужной функцией.
В этом и заключается суть универсального доступа. Дядя Тим завещал, что веб должен быть для всех. Для тех, кто не любит 100500 вкладок и не пользуется браузерным зумом, и для тех, кто им пользуется.
У меня с рождения не лучшее зрение, поэтому некоторые страницы я немного увеличиваю браузерным зумом. А ещё у людей с возрастом падает зрение, но люди всё равно продолжают пользоваться Интернетом.
Хороший интерфейс без проблем удовлетворяет и тем, и другим. И ничего особого для этого делать не надо.
Не знаю ни одного реального сайта за пределами домена w3.org, где это бы использовалось
Это, отнюдь, не значит, что их нет. Я пункты из статьи стараюсь применять на практике. В моём окружении хватает людей, которые тоже стараются их применять. Также я работаю с крупным SaaS вендором, у которого есть требования и подобные решения есть в кодовой базе их продуктов.
Очень доступно. Что под капотом у AccessibleButton? Пачка <div>-ов с tabindex, onclick, role и прочим? aria-label зачем-то переопределяет встроенный текст кнопки, что как минимум ломает программы голосового управления и нарушает несколько критериев WCAG. Вот такая вот «улучшенная доступность» в UI-библиотеках React.
Для 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, а может и никогда
На самом деле уже давно нет никаких стандартных разрешений. Да, есть статистически более распространённые, но в реальности огромное многообразие устройств, настроек, режимов и т.д.
Я разделяю ваш взгляд. Для себя тоже отказался от SCSS и предпочитаю минимум или полное отсутствие инструментов сборки. С таким подходом всё просто работает ©
Да, согласен, лучше
: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% страниц используют как минимум один веб-компонент. Многие крупные компании создают дизайн-системы на веб-компонентах и используют их в своих продуктах.
Если сделано правильно, то не будет. Зум просто пропорционально увеличивает всю страницу. С адаптивностью (а это стандарт де-факто), страница просто скатится в лэйаут для мобилок. Но это на экстремальных значениях зума, типа 400%. Я увеличиваю на 125-150 и в большинстве случаев всё нормально.
Если брать стандарт WCAG, то там есть требование, чтобы страница не разваливалась при 200% зуме. Удовлетворить критерию не сложно, но это делает функцию зума полезной и ничего не ломает.
Пользовательские таблицы стилей, всё же, не для рядового пользователя. Не каждый напишет CSS и разберётся, как его подключить к странице. А из браузеров давно выпилили эту возможность, осталась только в виде расширений.
Но это всё и не нужно, потому что высококонтрастные темы и прочее есть в настройках операционной системы. И в CSS с помощью медиа-запросов это можно отслеживать. Автор в статье как раз и пишет о нюансах в этих режимах.
Их поддержка, повторюсь, не такая сложная, хотя и соглашусь, что иногда выглядит как хаки. Но эти мелочи делают ненужными пользовательские таблицы стилей.
Но, как я говорил, Интернет для всех, поэтому в нём должно найтись место и пользователям зума, и тем, кто считает это ненужной функцией.
В этом и заключается суть универсального доступа. Дядя Тим завещал, что веб должен быть для всех. Для тех, кто не любит 100500 вкладок и не пользуется браузерным зумом, и для тех, кто им пользуется.
У меня с рождения не лучшее зрение, поэтому некоторые страницы я немного увеличиваю браузерным зумом. А ещё у людей с возрастом падает зрение, но люди всё равно продолжают пользоваться Интернетом.
Хороший интерфейс без проблем удовлетворяет и тем, и другим. И ничего особого для этого делать не надо.
Это, отнюдь, не значит, что их нет. Я пункты из статьи стараюсь применять на практике. В моём окружении хватает людей, которые тоже стараются их применять. Также я работаю с крупным SaaS вендором, у которого есть требования и подобные решения есть в кодовой базе их продуктов.
Очень доступно. Что под капотом у
AccessibleButton? Пачка<div>-ов сtabindex,onclick,roleи прочим?aria-labelзачем-то переопределяет встроенный текст кнопки, что как минимум ломает программы голосового управления и нарушает несколько критериев WCAG. Вот такая вот «улучшенная доступность» в UI-библиотеках React.Потому что автор вдохновлялся идеями React при написании своего микро-фреймворка
Идейно похоже на Webstudio. Может как источник вдохновения подойдёт.