Добавила демки в свою статью про нативную валидацию. Сделала в итоге через iframe.

https://ariarzer.dev/articles/2021/native-css-validation.html

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

Замещаемые элементы и где они обитают

Принято говорить, что замещаемые элементы - это те элементы, на отображение которых мы не можем влиять из css.

В спецификации html написано, что:

"Следующие элементы могут быть замещаемыми: audio, canvas, embed, iframe, img, input, object, и video."

В спецификации css чуть более развернуто:

"Элемент, содержимое которого выходит за рамки модели форматирования CSS, например изображение или iframe. Так, содержимое img заменяется изображением, которое обозначает его атрибут src."

Замещаемые элементы имеют собственные размеры (natural dimensions). Например, растровое изображение имеет собственную ширину и собственную высоту, указанные в абсолютных единицах (из которых, очевидно, можно определить собственное соотношение (ratio)).

Также, замещаемый элемент может и не иметь одного или нескольких, или всех собственных размеров.

Объекты, добавляемые с помощью CSS-свойства content являются анонимными замещаемыми элементами.
Анонимным в css называется то, к чему нельзя напрямую обратится.

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

Версия поста в блоге.

#css_display

Теперь, в догонку к предыдущему посту, еще один, опирающийся на него.

Строчные замещаемые элементы

Если вычисленное значение margin-left или margin-right равно auto, то их используемое значение становится равным 0.

Если height и width имеют вычисленные значения auto и элемент также имеет собственную (natural) ширину, тогда эта ширина является используемым значением width.

Если и height, и width имеют вычисленные значения auto, а элемент не имеет собственной ширины, но имеет собственную высоту и собственное соотношение, или если ширина имеет вычисленное значение auto, а высота нет, и элемент имеет собственное соотношение, тогда ширина вычисляется как:

(used height) * (natural ratio);

Если для высоты и ширины вычисленные значения auto, и элемент имеет собственное соотношение, но не имеет внутренней высоты или ширины, то используемое значение ширины не определено в CSS 2. Однако предполагается, что, если ширина содержащего блока не зависит от ширины замещаемого элемента, то есть используемое значение ширины вычисляется из уравнения ограничения, используемого для незамещенных блочных элементов в нормальном потоке.

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

Если ширина имеет вычисленное значение auto, но ни одно из вышеперечисленных условий не выполняется, то используемое значение ширины становится 300 пикселей.

Если 300 пикселей слишком широкие для устройства, UA должны использовать ширину самого большого прямоугольника, который имеет соотношение 2: 1 и подходит для устройства.

Например, это iframe'ы. Будучи вставленными на страницу без стилей, они имеют ширину 300 и высоту 150 пикселей.

Источник - https://www.w3.org/TR/CSS2/visudet.html#inline-replaced-width

Версия поста в блоге.

#css_display

CSS Level 2 потребовалось 9 лет (2002-2011), чтобы получить статус рекомендации. Чтобы ускорить стандартизацию беспроблемных частей, рабочая группа CSS приняла Пекинскую доктрину, разделившую спецификацию CSS на модули.

Более подробно о причинах и процессах разделения читайте в перевода статьи CSS Modularization, написанной fantasai 2 ноября 2011 года.

https://ariarzer.dev/articles/2022/inside-csswg/css-modularization.html

Тем временем вчера CSSWG решила отложить функцию color-contrast() до следующей версии спецификации из-за сломанного алгоритма вычисления контраста WCAG.

https://github.com/w3c/csswg-drafts/issues/7310#issuecomment-1156687605

Регулярное напоминание, что нужно расширять области ссылок и других контролов.

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

Также нужно добавить, что клик в паддинг или границу - это клик в блок, а клик в марджин - уже нет.

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

Речь идет исключительно о ссылках-контролах, вроде пунтов меню, а не о ссылках в тексте.

Следуя модными течениям и желанию мотивировать себя побольше писать, завела себе boosty.

Сейчас есть шанс получить открытку из Будапешта, а первая статья-туториал о том, как сделать семантичную карточку-ссылку, уже ждёт вас)

https://boosty.to/ariarzer

Написала о том, как делать карточки-ссылки просто и семантично.

https://ru.ariarzer.dev/tutorials/2022/easy-semantic-card-link.html

P.S. русскоязычный сайт переехал на поддомен, rss теперь тоже на нём.

Как и зачем типизировать CSS-переменные?

Подробно рассказываю в новой статье.

А еще как сделать плавные переходы между значениями переменных и как анимировать градиенты.

https://ru.ariarzer.dev/articles/2022/css-variables-typing.html

P.S. Добавила в статьи раздел "Цитирования". Если вы видите ссылки на мой контент в источнике, который еще не указан в этом разделе, сообщите мне, пожалуйста.

Вы уже слышали о вариативных юнитах?

На самом деле это просто синтаксических сахар над calc().
Подробности и возможные способы использования читайте в статье.

https://ru.ariarzer.dev/articles/2022/css-variable-units.html

P.S. Перевод "вариативные юниты" еще не конечный. Обсуждение можно посмотреть здесь.

Долгое и вдумчивое обсуждение перевода variable units, которые я сначала перевела калькой, закончилось в репозитории Веб-Стандартов.

Теперь это переменные единицы.

Интересно почитать аргументы всех сторон.

https://github.com/web-standards-ru/dictionary/pull/457

В спецификации режимов написания приведена очень интересная фотография фрагмента печатной книги на монгольском языке.

Письмо идёт вертикально, при этом английские фрагменты написаны боком.

Очень хорошая иллюстрации ориентации различных глифов относительно направления потока текста.

https://www.w3.org/TR/css-writing-modes-3/#line-directions

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

Рассказываю, какие есть еще и чем они лучше.

https://ru.ariarzer.dev/articles/2022/css-coordinate-system.html

Вопрос о том, как должен подчеркиваться (text-decoration: underline) текст с вертикальным написанием очень похож на "как бы собака носила штаны?"

Только про подчеркивание есть правильный ответ)

Сегодня вечером буду рассказывать про режимы написания и их поддержку в интерфейсах.
Митап проходит онлайн. Присоединяйтесь послушать)

https://gdg-minsk.timepad.ru/event/2147906/

P.S. Да, запись будет.

Слайды моего доклада про режимы написания текста и их поддержку в интерфейсах.

https://ariarzer.github.io/presentation_writing_modes

Теперь есть и запись доклада про режимы написания.

https://www.youtube.com/watch?v=ubDcMQMSoxI

Валитова София, UI-разработчик из Cube расскажет о том, что происходит с вашим кодом после того, как браузер его загрузил и распарсил, почему каскад есть даже если вы вообще не написали стилей и почему специфичность — это только часть каскада

«Значения в CSS: от декларации до отображения»

22 сентября в офисе компании MTS AI, Подсосенский переулок 23 с2.

Регистрация открыта на Timepad: https://moscowcss.timepad.ru/event/2162009/

Хочешь выступить? Подавай заявку на доклад:https://clc.to/moscowcss_cfp