#инструмент дня

Для понимания того, как работает 3D в CSS, очень важно иметь перед глазами что-то более наглядное, чем бесконечные красивые CodePen’ы. И теперь такая наглядная шутка есть. Встречайте: генератор кубов на CSS. Ну и параллелепипедов.

Экспорт в Pug+SCSS, HTML+CSS. Ну и их комбинация, очевидно.

На мобильных, конечно, грустно :) Впрочем, разработке всегда можно помочь.

👉 @htmlshit
#css #3d #generator

#фишка дня

Наверняка вы встречали подобные (на иллюстраци) предложения по генерации пароля. Заставить браузер предложить подобное на форме регистрации довольно просто: достаточно установить значение атрибута autocomplete как new-password.

Это не первый раз, когда у нас заходит речь об этом зачастую раздражающем атрибуте. Например, не так давно я писал заметку о том, как заставить Safari перестать пытаться исправить ваш одноразовый код: https://t.me/htmlshit/477

Но нелишним будет ещё раз напомнить: не забывайте про MDN. Все возможные значения автодополнения там отлично расписаны: https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete#Values

#css #autocomplete #password

#заметка дня

CSS очень хочет заменить JS в декларативном описании реакции интерфейса на действия пользователя.

Очень хочет, страшно старается, но пока что получается так себе. Тем не менее, плавный скроллинг до якоря, наконец, можно сделать. Ну и меню, пожалуй.

Ну ладно, анимации по наведении и клику ещё. А по скроллу?

Вы не поверите, тоже можно! Ну, почти.

Но обо всём по порядку. Заметка здоровая, будет две части.

Давайте сначала набросаем простой пример: пользователь прокручивает блоки и в определённые моменты начинают выезжать панели. Не просто появляются, а реагируют на положение полосы прокрутки. Проще показать уже: https://codepen.io/alinaki/pen/LYWVeBV

Для упрощения демонстрации каждая секция занимает целый экран, но можете мне поверить, приведённый пример будет работать даже в случае, когда у вас секций много и они разной высоты. Если интересно, как такие вещи рассчитываются — пишите в @htmlshitchat ваши комментарии, попробую после разложить немного геометрии.

Отдельно хочу заметить, что лет пять назад Safari останавливал event loop на время прокрутки страницы. Приведённая техника просто бы не заработала!

Да, инженеры Apple таким образом очень хитро решили уменьшить энергопотребление своего браузера.

Но на любую гайку найдётся свой хитрый болт, и тогда таким болтом стал... requestAnimationFrame! Неожиданно, не правда ли? И всё ещё актуально если анимации очень тяжёлые!

Итак, секрет в том, что мы запускаем запрос кадра и внутри него слушаем всё тот же window.pageYOffset.

Почему его? Потому что document.documentElement.scrollTop тогда в Safari не обновлялся, вспоминаем остановленный event loop.

И вот выходит рабочий вариант: https://codepen.io/alinaki/pen/QWpwXNN

У него есть одна достаточно серьёзная проблема, попробуйте отгадать, какая. Но она очень и очень легко решается.

А через пару дней мы с вами проделаем то же самое на самых современных API 😉 И тогда я поясню, что же такое имелось в виду в самом начале заметки.

#css #js #scroll #animation

#ссылка дня

Учиться на чужих ошибках достаточно сложно, чаще всего приходится на своих. Но представьте себе, что ошибка, совершённая лет двадцать назад будет вас преследовать всю жизнь там, где вы этого меньше всего ждёте.

А вот создатели CSS таких ошибок наделали достаточно много. Есть даже список: https://wiki.csswg.org/ideas/mistakes

Трагизм ситуации в том, что любую из них достаточно просто исправить... казалось бы. Но не забывайте об обратной совместимости, которую приходится поддерживать. Вот и расплачиваемся мы за странные решения до сих пор.

Ну ок, не всё в этом списке стоит квалифицировать как ошибки. Что-то просто можно было сделать лучше, а что-то вообще выстрелило случайно.

Вот краткий список того, что там есть:
1. white-space: nowrap должен был быть no-wrap
2. box-sizing должен был border-box (прим. больно, да?)
3. border-radius должен был называться corner-radius (прим. правда что, какое отношение к границе оно вообще имеет?)
4. взаимодействие flex-basis и width/height слишком сложное (прим. потребовалось две версии флексбокса чтобы всё равно сделать сложную хрень)
5. нынешнему :empty стоило бы именоваться :void, а сам :empty должен был бы игнорировать пробелы (и вот это, кстати, уже исправлено в спецификации!)

Вообще, почитайте. Там много интересного, очень круто.

#css #specification

#вопрос дня

#заметка дня

Ну что, настало время второй части заметки про анимацию по скроллу: https://t.me/htmlshit/614

На сей раз в дело идут самые современные API.

Давайте определим, что же нам нужно, чтобы связать прокрутку с элементом?

Да в общем, не так много: высота документа, высота видимой области экрана, координаты "начала" и "конца" элемента относительно документа и видимой высоты экрана, статус прокрутки.

Теперь можно составить пропорцию и анимировать любое нужное нам свойство элемента, что мы и делали в прошлый раз.

Но ведь браузеру и так это всё уже известно! Неужели нельзя упростить? Так вот, можно. Ну, почти. И для этого создаются новые браузерные API под общим именем ScrollTimeline: https://wicg.github.io/scroll-animations/

Черновик, понятное дело.

Выражаясь формальным языком, роль временной шкалы для нашей анимации будет выполнять, собственно, скроллбар. Точнее, процесс его прокрутки. Контроль — в руках пользователя.

Набросаем код для логики, описанной выше. Самое интересное: никакого псевдокода! Итак:

@scroll-timeline fill {
source: selector(body);
scroll-offsets: selector(#id) end 0, selector(#id) end 1;
time-range: 1s;
}

Давайте разбираться, что же здесь написано:

@-правило scroll-timeline сообщает браузеру, что мы собираемся использовать состояние прокрутки документа и передаём набор правил с именем fill.

source: источник данных о скролле, в данном случае, тело документа, но можно передать или body или id элемента. С классами не выйдет. Тем не менее, как вы могли догадаться, следить за скроллом можно где угодно.

scroll-offsets: здесь происходит вся магия. Используя селектор нужного нам элемента (или нескольких) мы можем указать, в какой же конкретно момент начинать и заканчивать нашу анимацию. Вырезать только нужную часть временной шкалы, если желаете.

Причём, start и end обозначают состояние полосы прокрутки (сверху вниз), а числовые значения — состояние видимости элемента, где 0 — находится за пределами видимой области экрана и 1 — хоть немного виден.

Конечно, можно и просто указать абсолютные значения, например: 100vh, 200vh.

Только такое дело... В Chrome сейчас это не работает, нужно указывать отдельно правила start и end. Баг уже заявлен.

time-range: отображение длительности нужной анимации на скролл. В сухом остатке, если ваша @keyframes-анимация длится 1 секунду, а time-range равен 2 секундам, то ваша анимация закончится ровно на половине указанного интервала прокрутки.

Ну и всё, что нам остаётся, это указать имя нашего таймлайна в анимации. Очевидно, это должно поддерживаться браузером:

animation: 1s linear forwards fill;
animation-timeline: fill;

Если вы сейчас такие довольные побежали это всё пробовать, спешу вас разочаровать: всё это в глубокой бете. Чтобы потестировать в Chrome, нужно пройти на страницу скрытых настроек и включить Experimental Web Platform Features: chrome://flags/#enable-experimental-web-platform-features

И вот теперь можно посмотреть пример: https://codepen.io/alinaki/pen/NWpqyrO

По-моему, прекрасно. Было бы, если бы работало везде.

Но не всё так грустно! Ведь помимо черновика CSS-спецификации готовится и JavaScript API. А что это значит? Что можно найти полифилл!

И ведь правда можно: https://github.com/flackr/scroll-timeline

Одна проблема: на этот полифилл нужен ещё один полифилл, потому что не все браузеры поддерживают современную объектную модель CSS. А ещё нужен Web Animations API... чота сложно.

Тем не менее, вуаля: https://codepen.io/alinaki/pen/XWMbGRa (подключение полифилла там не самое простое, задавайте ваши вопросы в @htmlshitchat; интересующий вас код — с 55 строки).

Разбираться с API оставляю вам в качестве домашнего задания. А вот в следующий раз попробуем сделать то же самое на GSAP, чтобы быть ближе к народу.

#css #animation #timeline #scroll

#wtf дня

Только что обнаружил, что открытые Chrome DevTools предотвращают выключение экрана на MacBook. Учитывая, сколько окон инспектора у меня открыто каждый день — немудрено, что ноутбук не выключает экран с некоторых пор.

Это, мягко говоря, раздражает.

Если кто знает, как это исправить — буду очень рад предложениям.

Upd. 1

Есть открытый баг для Windows, не я один страдаю: https://bugs.chromium.org/p/chromium/issues/detail?id=1208711&q=prevent&can=2

Upd. 2

Если инспектор открывается внутри основного окна – запрета выключения экрана не происходит.

#codepen дня

Невероятно! Apple iMac стал настолько тонкий, что уместился в один CodePen: https://codepen.io/Adir-SL/pen/JjWXZEq

Крутится вокруг своей оси, из интерактива — смена набора цветов.

К слову, чтобы научиться создавать такие же примеры — стоит понять, как делать параллелепипеды на CSS, а об этом я писал совсем недавно: https://t.me/htmlshit/612

#css #3d

#заметка дня

А давайте сегодня стилизуем выбор файла. Ну то бишь input[type="file"]. С чего вдруг? Да просто в целом это можно делать как минимум двумя способами! Два лучше чем один, очевидно.

Итак, классический способ: label>input+span.

Я не очень люблю атрибут for, ибо он заставляет меня придумывать id, но for может дать вам больше гибкости в размещении элементов и/или избавить от дополнительных span-ов.

Поехали:

1. Скрываем input техникой visually hidden, чтобы скринридеры его не потеряли.

2. Вешаем на span атрибут tabindex для фокуса с клавиатуры и role=“button” чтобы указать, что он будет интерактивным. Почему не кнопка? Потому что кнопка перехватит на себя клик по label, нам это не надо.

3. Оформляем span.

Собственно, это всё. Но оформляя таким способом, мы теряем мета-информацию. Как минимум, хотелось бы иметь название файла. Значит, добавляем пункт номер…

4. Вешаем слушатель события change на наш выбор файла и демонстрируем пользователю информацию о файле.

Итак, что же получилось: https://codepen.io/alinaki/pen/poeNzqd

Но вся проблема в том, что для отображения дополнительной информации нам нужен JavaScript. Да, мы можем вытащить ещё больше данных, но зачем? Стандартное поле загрузки файла и без всего этого даёт нам, как минимум, название.

Так вот, с некоторых пор мы можем обращаться к псевдоэлементу ::file-seleсtor-button! Вот и MDN по этому поводу: https://developer.mozilla.org/en-US/docs/Web/CSS/::file-selector-button

Поддержка пока так себе — Safari брыкается. Но давайте попробуем, ведь худшее, что случится — пользователи Safari увидят стандартное поле выбора файла.

Впрочем, когда-то кнопка называлась -webkit-file-upload-button, так что допишем и этот вариант, тогда и в старых Chrome и нынешнем Safari тоже заработает.

Описывать тут нечего, сразу результат: https://codepen.io/alinaki/pen/NWpbgGg

Ну ладно, на самом деле есть чего: с состоянием фокуса приходится помучаться, но возможно, у вас будет иное оформление. И пока нет возможности поменять текст на кнопке (на самом деле, можно, через псевдоэлементы). В общем, ждём дополнений к спецификации.

#css #file #upload

#фишка дня

Используя такие атрибуты input[type="file"] как capture и accept можно дать пользователю возможность сделать фото или снять видео на своём мобильном устройстве и сразу загрузить на сервер.

Атрибут capture может принимать значения user (для фронтальной) или environment (для основной камеры, или оставить пустым). Но на Android 10 (Chrome 90) такой выбор не работает.

Если не указать capture вообще, Android и iOS дадут варианты: включить камеру или выбрать из файловой системы.

А вот с accept всё ещё более интересно. Передавать в него нужно точный или универсальный (wildcard) MIME-тип. И вот тут есть нюанс.

И Android и iOS правильно обрабатывают image/* или video/*, соответственно выбирая нужный режим съёмки. Но вот если опустить accept вообще, iOS даст выбрать режим, а Android — просто включит фото.

В любом случае, я уже давно использую это в проектах и вам советую.

P. S. это не работает на десктопах 🚫

#file #upload #capture

Было бы интересно узнать, как на ваших мобильных устройствах работают выбор камеры и режима съёмки. Давайте попробуем:

https://codepen.io/alinaki/pen/yLMVGer

Пишите в комментариях версии ОС и браузера.

#фишка дня

Вы же уже наверняка в курсе, что Google запустил свой вечнозелёный курс по CSS? Если нет, вот он: https://web.dev/learn/css/

Наиболее внимательные могут обратить внимание, что все примеры сделаны через нашу любимую песочницу — CodePen.io. И примеров там более 200 штук.

А теперь, собственно, взрывающий мозг факт: они все используют библиотеку компонентов, которая тоже размещена как CodePen-сниппет!

Вот она: https://codepen.io/web-dot-dev/pen/abpoXGZ

Как же они это делают? Очень просто, добавьте к URL интересующее вас расширение — html, css или js — и вы получите нужный файл!

Вот как-то так: https://codepen.io/web-dot-dev/pen/abpoXGZ.css 🤯

Я, конечно, в восторге от CodePen, ведь нагрузка от гуглового курса должна быть очень немаленькой.

#codepen #google

В @htmlshitchat разгорелась интересная дискуссия на тему, нужно ли запихивать логотип в nav. Ведь многие делают логотип частью сквозной навигации и ставят на него ссылку на главную страницу.

Давайте устроим неожиданный воскресный опрос и узнаем глас народа.

#вопрос дня ⬆️

Сегодня против вас играет Лия Веру (Lea Verou).

#заметка дня

Вчерашний опрос вызвал много бурления в чате, что неудивительно.

Помните ошибки рабочей группы CSS? Вот inherit, initial, unset и revert можно смело в них записывать.

Потому что это какой-то ад. Смотрите сами:

inherit

Тут всё достаточно просто. Значение свойства будет отнаследовано от ближайшего родителя и так далее вверх по DOM, пока не найдёт. Если не найдёт — применит значение заданное по-умолчанию в браузере (user-agent styles).

Если и там не найдёт — то возьмёт значение, определённое для этого свойства в спецификации CSS, и это будет…

initial

Давайте откроем MDN для свойства display и пролистаем до раздела «Formal definition».

Мы увидим там нечто под названием «Initial value». И оно равно inline. Вот и наш ответ: initial это значение, определённое в спецификации CSS. Вот только оно не всегда очевидно.

Небольшой взрыв мозга: значение initial свойства display для тега div равно… тоже inline. Потому что поведение элементов в потоке и CSS-свойства — это разные сущности и связь их прописана на более высоких уровнях.

Например, в таблице стилей по-умолчанию, которая поставляется с любым браузером. И тут мы плавно подходим к значению…

revert

И уже эта прелестная штучка сбросит свойство до значений, установленных в таблице стилей браузера. Да, свойство display элемента div примет значение block.

Кстати, предыдущее название — default. Вы видите разницу между default и initial? А она, оказывается, есть.

unset

Тут мы на развилке. Свойство работает как inherit для наследуемых свойств (тех, которые применятся к потомкам, вроде color) и как initial для ненаследуемых (они, соответственно, не применятся к потомкам, вроде border).

Вроде как и не нужно оно выходит, не правда ли?

Но с его помощью можно сбросить все установленные значения, благодаря свойству all:

.element {
  all: unset;
}

Таким образом все свойства наследуемые свойства сбросятся до inherit, а ненаследуемые — до initial.

Вместо итога

Честное слово, я стараюсь проектировать архитектуру так, чтобы избегать откат значений свойств, но могу себе представить ситуации, когда это может быть очень удобно.

#css #unset #initial #revert

#статья дня

Помните мы обсуждали свежие контейнерные запросы и полифилл для них?

Вот Ахмад Шадид решил подойти к задаче немного с другой стороны, а именно со стороны дизайнера: https://ishadeed.com/article/container-queries-for-designers/

Какие возможности открывают контейнерные запросы, когда уместно использовать их, а когда — запросы медиа? Эта фраза на русском языке звучит странно в любом виде, простите.

Покажите статью, или хотя бы иллюстрации из неё (очень хорошие, кстати), вашим дизайнерам. Не оставайтесь в стороне и избежите многих проблем в будущем.

#css #containerqueries

#заметка дня

Я откладывал публикацию заметки по этой теме в долгий ящик, но время пришло.

Итак, давайте сразу панч: верстальщику в 2021 году нельзя ориентироваться на физическое разрешение матрицы экрана устройства. Точка.

Если вам заказчик говорит, что у него ноутбук с FullHD разрешением и ваша прекрасная вёрстка поехала к чертям, а у вас на 24” мониторе с тем же разрешением всё отлично — ответ прост. И имя ему масштаб.

Нетрудно догадаться, что объекты на разрешении 1920x1080 на 14” выглядят гораздо меньше, чем на пресловутых 24”. Это простая физика — размер пикселя меньше.

Но о чём почему-то никто не задумывается, так это о том, что люди не роботы и хотят видеть объекты покрупнее. И операционные системы это пытаются предугадать.

В итоге, на таком ноутбуке Windows выставит вам размер шрифта в 125%. Вот только о чём настройки Windows почему-то молчат, так это о том, что все элементы интерфейса станут крупнее, а не только шрифт. И это прям максимально странно.

В итоге интерфейс на 14” экране станет отображаться в эквивалентном разрешении 1536x864 (делите на 1.25). А это совсем не FullHD, не правда ли? А вот настройки монитора упорно скажут вам: «FullHD, чо докопался?». Во многих программах интерфейс ещё и размытый станет…

Второй пример: MacBook с ретина-экраном.

Рекламные материалы Apple упорно твердят нам: разрешение экрана MacBook Pro 13” — 2560x1600. Вот только о чём молчит Apple так это о том, что изображение будет иметь виртуальное разрешение 1280x800 для моделей до 2015 года и 1440x900 — после. Это коэффициенты масштабирования 2 и 1.77 соответственно.

Правда, в macOS, в отличие от Windows и Linux, это масштабирование сделано правильно и шрифты с векторными изображениями будут видны максимально чётко, почти как на бумаге. Их рендеринг происходит по физическим пикселям матрицы.

Растровые изображения будут отображены в реальном разрешении – рендеринг в физические пиксели. Именно по этой причине для ретина-экранов фотографии готовить нужно в двукратном размере (x2 по ширине и высоте, так что формально — четырёхкратном, но так говорить неудобно).

Третий пример. Посмотрите на свой мобильный телефон. Если производитель заявляет разрешение экрана 1080x1920 (вертикально), то в реальности в большинстве случаев это 360x640. С той же логикой, что и в macOS и ровно по тем же самым причинам.

Естественно, иногда люди восстанавливают настоящее разрешение экрана, ибо им нравится чёткость и устраивает размер элементов. Но в таком случае всё равно многие из них включат масштаб в браузере.

Чтобы не попадать в дурацкие ситуации, я могу разве что предложить сразу проверять масштабирование не только в браузере, но и в системе. Ну или использовать #инструмент вроде https://screensizemap.com/ чтобы заранее смотреть разрешение экранов разных устройств.

Кстати, если откроете этот сайт и посмотрите на пример для ThinkPad — получите как раз 1536x864. Потому что Windows на подобных ноутбуках ставит 125% по-умолчанию, из коробки. И да, у меня есть такой ноутбук и именно на нём я впервые и осознал подобную боль.

А чтобы узнать своё разрешение экрана, рекомендую вот этот сервис: http://whatismyscreenresolution.net/

Надеюсь, данные вас не удивят.

Вместо итога

Физические пиксели и пиксели в CSS это не одно и то же. И я не прошу вас кидаться использовать относительные единицы: без понимания, что же такое виртуальное разрешение экрана они вам не помогут.

В общем, удачи 😉

#screen #css #tool