Рабочая группа CSS в TPAC: Что нового в CSS?

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

Что такое ТПАК?

TPAC — это неделя технических пленарных заседаний/совещаний консультативного комитета W3C. Шанс для всех различных рабочих групп, входящих в состав W3C, собраться под одной крышей. Мероприятие каждый год проводится в разных частях мира, в этом году оно состоялось в Лионе, Франция. В TPAC рабочие группы, такие как рабочая группа CSS, проводят свои встречи, как и мы в другое время года. Однако, поскольку мы все находимся в одном здании, это означает, что людям из других групп легче приходить в качестве наблюдателей, и можно обсуждать интересы сквозных групп.

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

Рабочая группа CSS

Рабочая группа CSS встречается лицом к лицу на TPAC и по крайней мере еще два раза в течение года; это в дополнение к нашим еженедельным телефонным звонкам. На всех наших встречах обсуждаются различные вопросы, возникающие в связи со спецификациями, и принимаются решения. Некоторые вопросы оставлены для обсуждения лицом к лицу из-за преимуществ возможности обсудить их со всей группой или просто возможности обойти доску или просмотреть демонстрацию на экране.

Когда вопрос обсуждается на каком-либо собрании (будь то очное или телеконференция), соответствующая проблема GitHub обновляется протоколом обсуждения. Это означает, что если у вас есть проблема, которую вы хотите отслеживать, вы можете пометить ее и посмотреть, когда она будет обновлена. Полные протоколы IRC также публикуются в списке рассылки в стиле www.

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

CSS-полосы прокрутки

Спецификация полос прокрутки CSS стремится предоставить стандартный способ стилизации размера и цвета полос прокрутки. Если у вас есть Firefox Nightly, вы можете протестировать его. Чтобы увидеть приведенные ниже примеры, используйте Firefox Nightly и включите флаги layout.css.scrollbar-width.enabled и layout.css.scrollbar-color.enabled , посетив https://about:config в Firefox Nightly.

Спецификация дает нам два новых свойства: scrollbar-width и scrollbar-color . Свойство scrollbar-width может принимать значения auto , thin , none или length (например, 1em ). Похоже, что значение length может быть удалено из спецификации. Как вы можете себе представить, веб-разработчик мог бы сделать очень непригодную полосу прокрутки, играя с шириной, поэтому может быть лучше позволить браузеру определять точную ширину, которая имеет смысл, но вместо этого показывать либо тонкую, либо толстую полосу прокрутки. полосы прокрутки. Firefox не реализовал параметр длины.

Если вы используете auto в качестве значения, тогда браузер будет использовать полосы прокрутки по умолчанию: thin даст вам тонкую полосу прокрутки, а none будет отображать видимую полосу прокрутки (но элемент по-прежнему будет прокручиваться).

В браузере с поддержкой полос прокрутки CSS вы можете увидеть это в действии в демоверсии:

Как и следовало ожидать, свойство scrollbar-color имеет дело с цветами полосы прокрутки. Полоса прокрутки состоит из двух частей, которые вы можете раскрасить независимо друг от друга:

• большой палец
  Ползунок, который перемещается вверх и вниз при прокрутке.
• отслеживать
  Фон полосы прокрутки.

Значения свойства scrollbar-color : auto , dark , light и <color> <color> .

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

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

В браузере с поддержкой полос прокрутки CSS вы можете увидеть это в демо:

Единицы соотношения сторон

Мы использовали хак padding в CSS для получения полей с соотношением сторон в течение некоторого времени, однако с появлением Grid Layout и лучших способов изменения размера контента наличие реального способа сделать соотношение сторон в CSS стало более насущной потребностью. .

На GitHub возникли две проблемы, связанные с этим требованием:

• Требуемые единицы соотношения сторон
• Соотношение сторон.

В настоящее время существует предварительная спецификация на уровне 4 размера CSS, и собрание решило, что это требует дальнейшего обсуждения на GitHub, прежде чем можно будет принимать какие-либо решения. Итак, если вы заинтересованы в этом или у вас есть дополнительные варианты использования, рабочая группа CSS будет заинтересована в ваших комментариях по этим вопросам.

Функциональный псевдокласс :where()

В прошлом году CSSWG решила добавить псевдокласс, который действовал бы как :matches() , но с нулевой специфичностью, что упростило переопределение без необходимости искусственно завышать специфичность более поздних элементов, чтобы переопределить что-то в таблице стилей по умолчанию.

Псевдокласс :matches() может быть для вас новым, так как это селектор уровня 4, однако он позволяет указать группу селекторов, к которым нужно применить CSS. Например, вы можете написать:

 .foo a:hover, pa:hover { color: green; }

Или с помощью :matches()

 :matches(.foo, p) a:hover { color: green; }

Если у вас когда-либо был большой стек селекторов только для того, чтобы установить одну и ту же пару правил, вы увидите, насколько это будет полезно. Следующий код CodePen использует имена с префиксом webkit-any и -moz-any для демонстрации функциональности match matches() . Вы также можете узнать больше о match() на MDN.

Где мы часто делаем такое наложение селекторов, и, следовательно, где :matches() будет наиболее полезным, так это в какой-то исходной таблице стилей по умолчанию. Однако затем нам нужно быть осторожными при перезаписи этих значений по умолчанию, чтобы любая перезапись выполнялась таким образом, чтобы гарантировать, что она будет более конкретной, чем значения по умолчанию. Именно по этой причине была предложена версия с нулевой специфичностью.

Вопрос, который обсуждался на собрании, касался именования этого псевдокласса, вы можете увидеть окончательное решение здесь, и если вам интересно, почему были исключены различные имена, посмотрите полную ветку. Давать имена в CSS очень сложно, потому что нам всем придется жить с этим вечно! После долгих дебатов группа проголосовала и решила назвать этот селектор :where() .

После встречи и пока я писал этот пост, было выдвинуто предложение переименовать matches() в is() . Взгляните на проблему и прокомментируйте, если у вас есть какие-то сильные чувства в любом случае!

Логические сокращения для полей и отступов

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

Например, для физических полей у нас есть:

• margin-top
• margin-right
• margin-bottom
• margin-left

Логические сопоставления для них (при условии горизонтального-tb):

• margin-block-start
• margin-inline-end
• margin-block-end
• margin-inline-start

У нас может быть два сокращения значений. Например, чтобы установить и margin-block-start и margin-block-end в качестве сокращения, мы можем использовать margin-block: 20px 1em . Первое значение представляет начальное ребро в блочном измерении, второе значение — конечное ребро в блочном измерении.

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

 @mode "logical";

Или, чтобы использовать блок, который немного похож на медиа-запрос:

 @mode (flow-mode: relative) { }

Затем различные предложения по модификаторам ключевых слов, использованию некоторых знаков пунктуации или созданию нового имени свойства:

 margin: relative 1em 2em 3em 4em; margin: 1em 2em 3em 4em !relative; margin-relative: 1em 2em 3em 4em; ~margin: 1em 2em 3em 4em;

Вы можете прочитать выпуск, чтобы увидеть различные вещи, которые рассматриваются. Обсуждаемые проблемы заключались в следующем: хотя логическая версия вполне может в конечном итоге оказаться по умолчанию, иногда вам может понадобиться, чтобы вещи были связаны с геометрией экрана; нам нужно иметь возможность иметь оба варианта в одной таблице стилей. Наличие параметра @mode в верхней части CSS может сбивать с толку; это потерпит неудачу, если кто-то скопирует и вставит кусок таблицы стилей.

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

Нам не удалось решить эту проблему, поэтому, если у вас есть мысли о том, какие из них могут быть лучшими, или вы видите проблемы с ними, которые мы не описали, прокомментируйте проблему на GitHub.

Обсуждение тестов веб-платформы

На собрании рабочей группы CSS, а затем во время технического пленарного дня в стиле неконференций я участвовал в обсуждении того, как привлечь больше людей к написанию тестов для спецификаций CSS. Проект «Тесты веб-платформы» направлен на предоставление тестов для всей веб-платформы. Затем эти тесты помогают производителям браузеров проверить, соответствует ли их браузер спецификации. В Рабочей группе CSS цель состоит в том, чтобы любое нормативное изменение спецификации, достигшей статуса кандидата в рекомендации (CR), сопровождалось тестированием. Это имеет смысл, так как после того, как спецификация находится в CR, мы просим браузеры реализовать эту спецификацию и предоставить отзыв. Им нужно знать, если что-то изменится в спецификации, чтобы они могли обновить свой код.

Проблема в том, что у нас очень мало людей, пишущих спецификации, поэтому необходимость писать все тесты для авторов спецификаций замедлит продвижение CSS. Нам бы хотелось, чтобы другие люди писали тесты, так как это способ внести свой вклад в веб-платформу и получить глубокие знания о том, как работают спецификации. Поэтому мы встретились, чтобы подумать о том, как мы могли бы поощрить людей к участию в наших усилиях. Я писал на эту тему в прошлом; если вас интересует идея написания тестов для платформы, взгляните на мою статью «24 способа» «Тестирование веб-платформы».

На работу!

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

Если вам интересно, как работает Рабочая группа CSS, как изобретаются новые CSS и как они попадают в браузеры, ознакомьтесь с моей презентацией CSSConf.eu 2017 года «Откуда взялся CSS?» и информацию от fantasai в ее сообщениях «Взгляд изнутри на рабочую группу CSS в W3C».