Обновить
14

Пользователь

3
Подписчики
Отправить сообщение

Избранное и история живут только в браузере

а когда пользователь зайдёт с другого устройства и откроет избранное, то его ждёт разочарование

На текущей реализации проекта например в /goods/5 визуального layout shift при добавлении и удалении из избранного не заметил. 

сделайте сеть помедленнее, тогда можно заметить

Почему атрибут aria-labelledby находится на div, а не на section?

Меня очень сильно удивляет, что многие фронтендеры скрывают и показывают элемент, добавляя и удаляя самостоятельно свойство display со значением none. Есть же атрибут hidden.

Если в CSS для элемента будет задан, скажем, display: flex, то работать этот атрибут не будет.

Ссылки на картинки неплохо бы обновить

По мере развития css в котором теперь и переменные, и функции, и обсуждается внедрение mixins 

Только всё это сейчас не помогает для изоляции названий пользовательских свойств. Нет гарантий, что, подключая какую-нибудь библиотеку для календаря, там не окажется `--token-color-primary` как у вас в проекте. Библиотеки типа StyleX дают возможность устранить коллизии названий "CSS-переменных". Правда, отлаживать в инспекторе мучительно больно.

От препроцессоров - да, от БЭМ очень сложно отказаться

Можно не ждать и принести свое предложение в https://github.com/w3c/csswg-drafts/issues

А есть proposal?

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

Да, была неплохая статья с объяснением причин и инструментом для подбора значений, которые не ломали бы доступность.

Разве это можно реализовать на препроцессорах?

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

@property --_vw {
  syntax: "<length>";
  initial-value: 0px;
  inherits: false;
}

@function --viewport-scale(--min <number>: 300, --max <number>: 1200) returns <number>  {
  --_vw: 1vw;
  --_unitless-viewport: calc(tan(atan2(var(--_vw) * 100, 1px)));
  --_clamped-viewport: clamp(var(--min), var(--_unitless-viewport), var(--max));  
  --_viewport-scale:
    calc(
      (var(--_clamped-viewport) - var(--min)) /
      (var(--max) - var(--min))
    );
  result: calc(var(--_viewport-scale));
}

body {
  margin: 0;
  min-height: 100dvh;
  background-color: rgb(255 100 50 / --viewport-scale());
  font-size: calc(--viewport-scale(100, 800) * (72px - 20px) + 20px);
}


Мне кажется, что так не очень понятно, в чём же прелесть правила @function. Давайте добавим ещё медиа-запросы.

Не очень удачный пример. Без функции даже проще:

.awesome-container {
  --columns: 1;
  display: grid;
  grid-template-columns: repeat(var(--columns), 1fr);

  @media (width > 640px) {
    --columns: 2;
  }

  @media (width > 1200px) {
    --columns: 3;
  }
}


Можно было бы стилизовать нативные элементы progress и meter. Но там больше дополнительных действий по убиранию оформления по умолчанию

Со "срезами" как-то всё туманно.

height: 100vh; /* ← высота замкнута внутри среза */

Означает растянуть на всю высоту экрана, а не на высоту родительского элемента, что имеет больше смысла в контексте микрофронтов.

Те же табы недоступны с клавиатуры

1
23 ...

Информация

В рейтинге
Не участвует
Зарегистрирован
Активность