он отлично подходит и для больших проектов, сложных больших приложений.
Интересно, как будет выглядеть на htmx реализация такой штуки: внутри формы при выборе чекбокса нужно спрятать/показать другой блок, при выборе значения в одном селекте в другом селекте показать определённый список и т.п.
Проблема в htmx в том, что он не заморачивается с сохранением визуального состояния (например, фокус на чекбоксе), так как меняет всё через innerHTML.
как избавиться от соседнего родственного комбинатора + при реализации нестандартных чекбоксов и радиокнопок
Можно вообще без всяких обёрток и комбинаторов просто добавить appearance: none на нативный элемент и стилизовать почти как угодно, используя те же псевдоэлементы. К тому же такой способ позволяет использовать нативный вид фокуса.
Пока останавливает отсутствие гибкости в формировании ссылок при пагинации. Как понимаю, нельзя сделать, чтобы начальная страница была, скажем, `/articles/`, а следующая `/articles/feed/2`, используя один шаблон. В Eleventy с ссылками (permalink) можно делать почти что угодно.
У Google Fonts есть API для тонкой настройки. Например, можно указать url-параметр subset с набором глифов, характерных для того или иного языка. Или можно указать url-параметр text с нужными глифами. Если взять набор символов из вашего сервиса для русского и английского языка, то в Google Fonts также получим один файл размером 8Kb. Причем именно один формат, который сервис определил сам на основе HTTP-заголовков, а не целую россыпь из устаревших otf, ttf, woff, svg, как уже и отметил @dom1n1k.
У Google Fonts, вообщем-то, только один недостаток в плане сетевой производительности – CSS запрашиваются с одного домена, а сами шрифты – с другого домена.
Виртуализация (таблицы, бесконечные ленты и др.) может сильно навредить в плане доступности. Пока нет ничего лучше, чем классическая пагинация.
Интересно, как будет выглядеть на htmx реализация такой штуки: внутри формы при выборе чекбокса нужно спрятать/показать другой блок, при выборе значения в одном селекте в другом селекте показать определённый список и т.п.
Проблема в htmx в том, что он не заморачивается с сохранением визуального состояния (например, фокус на чекбоксе), так как меняет всё через
innerHTML
.нет, вложенность тут не главное. Конкатенация селекторов по типу `&__title` это зло.
Скоро будет работать во всех браузерах:
Гораздо читабельнее.
А где тут React?
Нужно отметить, что статья является переводом https://www.cnblogs.com/coco1s/p/18358267.
Да, но применится только один -
data-size="small"
Вы хотя бы не тупо переводите статьи, а делайте их редактуру/ревью. Например,
Это не так.
Про
must-revalidate
не рассказали. А есть ли смысл использовать эти значенияno-cache
иno-store
вместе?Кажется, были проблемы с псевдоэлементами для
input
в очень старых браузерах. Но во всех современных работает хорошо.Можно вообще без всяких обёрток и комбинаторов просто добавить
appearance: none
на нативный элемент и стилизовать почти как угодно, используя те же псевдоэлементы. К тому же такой способ позволяет использовать нативный вид фокуса.Пример: https://codepen.io/monochromer/pen/xxyMrqQ
А TailwindCSS относится к CSS-in-JS?
Из приведенных примеров не видна разница между использованием операторов
~~
и|
. Выражения ниже приводят к одному результату.https://caniuse.com/details
пример можно?
Пока останавливает отсутствие гибкости в формировании ссылок при пагинации. Как понимаю, нельзя сделать, чтобы начальная страница была, скажем, `/articles/`, а следующая `/articles/feed/2`, используя один шаблон. В Eleventy с ссылками (permalink) можно делать почти что угодно.
В URL есть hash, который обрезает часть символов
У Google Fonts есть API для тонкой настройки. Например, можно указать url-параметр
subset
с набором глифов, характерных для того или иного языка. Или можно указать url-параметрtext
с нужными глифами. Если взять набор символов из вашего сервиса для русского и английского языка, то в Google Fonts также получим один файл размером 8Kb. Причем именно один формат, который сервис определил сам на основе HTTP-заголовков, а не целую россыпь из устаревших otf, ttf, woff, svg, как уже и отметил @dom1n1k.У Google Fonts, вообщем-то, только один недостаток в плане сетевой производительности – CSS запрашиваются с одного домена, а сами шрифты – с другого домена.
Внутри
@font-face
не нужно указыватьtext-rendering
. Это делается на уровне селекторов, например,:root { text-rendering: optimizeLegibility; }
.Заканчивается 2023 год, поэтому форматы woff и ttf не нужны, только если вы не поддерживаете браузеры типа IE9.
Нагло скопированный с https://yoksel.github.io/url-encoder/
Понимаю, что рекламируете свой сервис, но transfonter удобнее.
В рамочку и на стену
Для ReadableStream не хватает примера обработки "обратного давления"