SelenIT: статьи и переводы

Поводом для этой заметки стал недавний твит нашего давнего знакомого Зака Лезермана, лучшего в мире знатока веб-шрифтов:

Сегодня у меня возникла потребность в условных операциях с кастомными свойствами CSS.

flex-basis: (—my-variable ? 0 : 4px)

Я не смог сделать это с фолбэками в var(). Это возможно или обсуждается где-нибудь среди стандартистов? (CSS-in-JS — ответ не на тот вопрос)

Другими словами, нужно выбирать ту или иную величину в зависимости от наличия переменной, независимо от ее значения.

И я решил поделиться несколькими находками, связанными с неочевидными (по крайней мере для меня:) особенностями CSS-переменных. Можно считать это еще одним уроком CSSbattle – именно там я на них впервые наткнулся. Возможно, и вам они где-нибудь пригодятся:)

Многие разработчики, что уж скрывать, недолюбливают спецификации. Одни считают их скучными. Другим они вообще кажутся монстрами, не иначе как порожденными мифической Ехидной (невероятно, но это отчасти правда: именно так — Echidna — называется система автопубликации, используемая в W3C). Новичка они могут запутать, как лешие, заманить в ловушку, как сирены, и озадачить неразрешимыми загадками, как Сфинкс. Зато о тех, кто проник в их тайны и подчинил себе их мощь, порой слагают легенды фронтенда.

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

Сегодня на сайте W3C появилась знаменательная новость: W3C и WHATWG подписали общий меморандум о совместной работе над едиными спецификациями HTML и DOM. То есть многолетний раскол, результатом которого были две разные версии главного стандарта веба и постоянная путаница между ними, должен вот-вот закончиться!

Родительский селектор, т.е. возможность стилизовать элементы в зависимости от их содержимого — давняя, но пока несбыточная мечта многих верстальщиков. Предложения такого селектора, в том или ином виде, бродят по черновикам W3C с начала двухтысячных. Но он получается очень ресурсоемким и медленным. Поэтому в черновике модуля CSS-селекторов 4 уровня изначально селекторы делились по «профилям»: «живой», отражающий состояние интерфейса в реальном времени и используемый для оформления, и «мгновенный снимок» (ранее «статичный»), для одного конкретного момента и доступный только в JS-методах типа querySelector(). До последнего времени селектор :has() был единственным исключением из «живого» профиля. Что значило, что даже когда (и если) браузеры его реализуют, использовать его для оформления будет нельзя.

В начале апреля появилась затягивающая и познавательная онлайн-игра для верстальщиков — CSSbattle.dev. Вашего покорного слугу угораздило «влипнуть» в нее практически с самого начала (и даже пару раз какое-то время побыть в самом топе:). Это был интересный и поучительный опыт, которым хочется поделиться.

Написать эту статью меня подтолкнула относительно недавняя статья на CSS-tricks (скорее всего, вы ее уже видели, ссылку не дам из вредности:). Ее автор проделал большую и замечательную работу — нарисовал красивую наглядную схему-«шпаргалку», написал объяснение простым языком, привел кучу примеров, не забыл даже про презентационные атрибуты, тоже влияющие на стили (в SVG)… Увы, даже та статья подтвердила два печальных правила: 1) никто не знает CSS, 2) никто не читает спецификаций. Так что первая ее редакция транслировала одно из популярных заблуждений о каскаде. К чести автора, он оперативно исправил и схему, и статью — но если бы он заглянул в стандарт, этого могло бы и не понадобиться…

Вот я и решил бесстыже позаимствовать идею простой и наглядной визуальной «шпаргалки» из той статьи — но сразу сделать ее правильной, отражающей не только личный опыт автора, но и стандарт.

Оформление элементов форм — пожалуй, главный источник боли в современной верстке. Каждое поле ввода, каждая кнопка — «вещь в себе», причем в каждом браузере реализованная чуть по-своему. И управлять их стилями тоже часто приходится в каждом браузере по-своему. А некоторые задачи (например, отобразить кнопку как обычный элемент с display: inline, с переносом на новую строку, если надо) и вовсе никак не решаются (внешне такой эффект дает display: contents, но в теперешних реализациях это ломает доступность, так что это не решение). Много надежд на избавление от этой боли возлагалось на свойство appearance, но судьба этого свойства оказалась сложной и запутанной. Сейчас в браузерах есть лишь старые его реализации с префиксами, тоже везде свои, и ни одна из них не решает задачу полностью.

И вот, пока все браузеры с досады не скопировали «в лоб» -webkit-appearance и не пополнили список «нестандартных стандартов» де-факто, после долгого обсуждения в ишью на Гитхабе давний активист веб-стандартизации Саймон Питерс решил взять дело в свои руки и набросать «правильный» черновик спецификации для этого свойства — учитывающий и пожелания верстальщиков, и браузерную реальность. И стандартизировать наконец и сами браузерные стили для элементов форм, и способ их сброса.

Работа предстоит громадная, но темп взят неплохой. За считанные дни заготовка документа на Google Docs выросла до внушительных 19 страниц. Учитывая опыт Саймона в работе над спецификациями WHATWG, где как раз много приходилось «приводить к общему знаменателю» разнобраузерные зоопарки реализаций, есть надежда, что в этот раз всё получится!

Перевод статьи Why don’t we add a <lovely> element to HTML? с сайта www.brucelawson.co.uk, опубликовано на css-live.ru с разрешения автора — Брюса Лоусона

Вчера был интересный разговор, который начала Сара Суайдан:

твит Сары Суайдан (@SaraSoueidan), 8 октября 2018 г. в 16:36:

Вот что я хотела бы увидеть в HTML:
<color value=“” />
Просто. Чрезвычайно полезно, особ. для дизайн-систем сегодня.

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

На правах Древнего Старожила Веба, я сел и пораздумывал над этим.

Несколько часов назад в спецификацию CSS-селекторов 4 уровня внесли малозаметное, но существенное изменение. По-новому определили полезный псевдокласс :empty: если раньше — в селекторах 3 уровня, что были стандартом с 2011 г. — он соответствовал только совсем пустым элементам, не содержащим даже пробелов и HTML-комментариев, то теперь элементы с одними пробельными символами и HTML-комментариями внутри будут тоже считаться пустыми. А псевдокласс :blank, который раньше предлагался именно для таких элементов, теперь будет соответствовать элементам форм с пустым value.

Хотя новое поведение :empty выглядит логичным (пробелы в HTML часто служат лишь для форматирования кода и не воспринимаются как контент), оно нарушает обратную совместимость, поэтому не все ему рады. В ишью на гитхабе рабочей группы CSS, хотя его и закрыли как решенное, обсуждение продолжается. Так что, если у вас есть возражения и примеры, где новое поведение :empty будет «не в тему», смело подключайтесь и аргументируйте — редакторы спецификации готовы пересмотреть своё решение, если надо, и будущее CSS в ваших руках!

25 сентября Рабочая группа CSS в W3C выпустила первый публичный черновик модуля скроллбаров (CSS Scrollbars) 1 уровня. По замыслу, он должен предоставить стандартные средства для того, чтобы можно было органично вписывать скроллбары в разные темы оформления (темные, контрастные, компактные и т.д.), не ломая при этом «родной» функциональности платформы. Но выбор средств, которые предлагает этот черновик, многих может удивить.

Пролог (в котором едва обошлось без драки)

Прошедшие выходные ознаменовались небольшой драмой в веб-сообществе. Началась она с безобидного «теста» по CSS в твиттере Макса Штойбера, разработчика styled-components и react-boilerplate:

Насколько хорошо вы знаете CSS? (эмодзи: ученик у доски)

При таких классах:

.red { color: red; }
.blue { color: blue; }

какого цвета будут эти дивы?

<div class="red blue">
<div class="blue red">

28 августа модуль CSS Display 3 уровня, за развитием которого мы наблюдаем с его появления, следя за его новинками и хорошо забытыми старыми секретами, стал кандидатом в рекомендации. То есть спецификация считается полностью теоретически проработанной и готовой к реализации. Отличий от предыдущего черновика совсем немного: уточнено, что для «особых» элементов, для которых display:contents работает как none, оно будет и вычисляться как none, а также уточнено определение контекста форматирования и оговорено, что display не анимируется (даже дискретно).

Вдогонку статье о нестандартных (но иногда полезных) штуках с префиксом -webkit- пришла новость от разработчиков Firefox: они собираются изменить свой парсер CSS, чтобы любые псевдоэлементы вида ::-webkit-что-угодно считались валидными селекторами и не заставляли весь блок правил игнорироваться. Причина всё та же — совместимость: так делают WebKit и Blink, многие авторы пишут код в расчете на это поведение, и в Firefox этот код предсказуемо ломается (хотя по текущему стандарту так и должно быть). Так что не полагайтесь на хаки вида ::-webkit-nonsense, .something-useful {/*код только для «вебкитят»*/} и на всякий случай проверьте, не осталось ли подобного в ваших проектах!

Добавлено 28.08.2018: это требование совместимости пришлось закрепить в спецификации CSS-селекторов 4 уровня.

Многое из того, чем люди активно пользуются в вебе, почему-то не охвачено стандартами. Часто соблазн быстро решить задачу одной-двумя нестандартными строчками слишком велик. Особенно если по этой строчке не видно, что она нестандартная. Когда-то давно, в эпоху префиксов, некоторые браузеры любили выпускать свою отсебятину под видом экспериментальных новинок. А в самых запущенных случаях браузеры и вовсе годами тихо саботируют стандарт, принятый остальными, не оставляя разработчикам другого выбора.

Чтобы не отстать от конкурентов, другим браузерам пришлось понемногу внедрять эту отсебятину и у себя. Со временем она стала стандартом де-факто. И практикам из WHATWG ничего не осталось, как описать ее в особом стандарте — стандарте совместимости (Compatibility Standard). Давайте посмотрим, что там есть и где оно нам может пригодиться!

Рабочая группа CSS выпустила первый публичный черновик модуля величин и единиц 4 уровня (CSS Values and Units Module Level 4). Вот главные его новинки по сравнению с тем, что было:

• Новые единицы длины относительно шрифта: cap, lh, rlh и ic. Единица cap равна высоте заглавных букв текущего шрифта (удобно для стыковки иконок с текстом, без такой «магии»), lh — вычисленной высоте строки текущего элемента, rlh — вычисленной высоте строки корневого элемента, а ic — ширине иероглифа 水 («вода»), принятого за «эталон» полноширинного символа для текстов на восточноазиатских языках;
• Новые единицы длины относительно вьюпорта — vi и vb. Это аналоги vw и vh, но с учетом направления текста: vi — по инлайновой оси (как идет текст в строках), vb — по блочной (как идут абзацы);
• Новые функции min() — выбрать наименьшее значение из списка, max() — выбрать наибольшее, и clamp() — ограничить значение нижним и верхним пределами;
• Функция toggle() для циклического перебора нескольких значений (напр., для оформления разных уровней вложенности древовидного списка);
• Более «умная» функция calc(). Например, наконец станет можно делить длину на длину (скажем, calc(75% / 10em)), а при подстановке результата calc() туда, где нужно целое число (напр. в grid-template-columns), этот результат будет автоматически округляться.

Кроме того, уточнены правила преобразования CSS-размерностей при математических операциях с ними, а также сериализации математических функций при чтении CSS-значений скриптом.

Теперь, когда черновик официально опубликован, можно смело требовать от браузеров всё это реализовать, так что не стесняйтесь писать им в багтрекеры! :)