Дэниэл Апплкуист — член W3C Technical Architecture Group — призывает сообщество присоединиться к разработке стандартов — "Why Get Involved in Web Standards?"

Дэниэл пишет о том, что он работает над улучшением прозрачности разработки web-стандартов и вовлечением в процесс большего числа разработчиков. Если вы думали над тем, чтобы присоединиться к разработке стандартов, но не знали с чего начать, то вам поможет Web Platform Contribution Guide. В нём рассказывается о процессе разработки стандартов и о том, как можно помочь. Также можно присоединиться к TPAC брейкаутам — докладам на тему разработки разных web-стандартов. Обычно брейкауты проводятся среди членов рабочих групп W3C, но в этом году в них может поучаствовать любой разработчик.

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

#announcement #spec

https://dev.to/torgo/why-get-involved-in-web-standards-1p4h

Томас Штейнер в блоге web.dev написал статью про текстовые фрагменты — "Boldly link where no one has linked before: Text Fragments".

В url страницы после символа # можно подставить идентификатор элемента, к которому браузер должен подкрутить страницу. Эта фича появилась очень давно, но у неё есть недостаток — на странице должен существовать элемент с необходимым идентификатором.

С помощью текстового фрагмента (text fragment) можно задать любой текст, который нужно "подсветить" на странице. Текстовый фрагмент задаётся в url страницы с помощью конструкций #:~:text=textStart или #:~:text=textStart,textEnd. Также можно указать необходимый контекст с помощью префиксов и суффиксов #:~:text=somePrefix-,text,-someSuffix.

Текстовый фрагмент — экспериментальная фича, её поддержка есть только в браузерах на базе Chromium. На данный момент участники W3C скептически относятся к изменению формата url, но Google уже начал использовать текстовые фрагменты в production-коде поисковых сниппетов.

#spec #experimental #chromium

https://web.dev/text-fragments/

Пару дней назад был опубликован черновик спецификации CSS Cascading and Inheritance Level 5. Главное изменение спеки — добавление директивы @layer для гибкого управления каскадом. София Валитова разобралась с новой директивой и написала про неё статью в своём блоге — "Пара слов о layer".

С помощью CSS-директивы @layer создаётся именованная группа стилей, которая подчиняется особым правилам каскадности. Обычно, когда для одного и того же элемента находится несколько разных правил, побеждает то правило, которое было определено ниже (без учёта специфичности), или правило с большей специфичностью. То есть каскад правил, который будет применяться к элементам, формируется неявно, разработчик может влиять на него косвенно, изменив порядок правил или повысив специфичность. Директива @layer предоставляет явный механизм для управления этим приоритетом. Например, в примере ниже цвет текста кнопки будет красным, а не зелёным, хотя правило с зелёным цветом было определено по коду ниже:

@layer components, common;

@layer common {
  button {
    color: red;
  }
}

@layer components {
  button {
    color: green;
  }
}

Директива layer может пригодиться для структурирования стилей, при рефакторинге и темизации. Но на данный момент её поддержки нет ни в одном браузере.

#spec #css

https://ariarzer.dev/css-cascade-layer.html

P.S. София ведёт телеграм-канал с разбором спек CSS. Если хотите углубить свои знания в этой теме, очень рекомендую подписаться @css_mind.

Эмили Старк из команды Google Chrome поделилась советами о том, как эффективно читать спецификации web-стандартов — "Tips for reading web standards".

Многие стандарты обновляются часто по мере развития браузеров. Поэтому в первую очередь нужно смотреть последние черновики спецификаций (editor’s/latest draft), которые включают в себя все последние нововведения. Очень помогает в понимании спецификации вводная часть (explainer). Её Эмили советует читать от начала до конца, так как она содержит информацию для упрощения понимание спеки в целом. С другой стороны, чтобы разобраться в поведении какой-либо фичи, читать саму спецификацию от начала до конца не обязательно.

Статья небольшая, но полезная. Рекомендую почитать.

#spec

https://emilymstark.com/2021/03/14/tips-for-reading-web-standards.html

Марк Ноттингем — участвует в разработке протоколов HTTP — написал статью о том, как читать RFC — "How to Read an RFC".

Любой RFC-документ — архивный документ. Это означает, что при исправлении ошибок и опечаток должен быть выпущен новый RFC под новым номером, а предыдущий RFC должен быть объявлен устаревшим. Для проверки статуса любого RFC-документа Марк советует использовать сайт tools.ietf.org. RFC-документы очень часто подробно описывают поведение протоколов. Поэтому попытка прочитать спецификацию "между строк" может привести к неправильной имплементации протокола.

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

#spec

https://www.mnot.net/blog/2018/07/31/read_rfc

Мэттью Гауде — разработчик SpiderMonkey — написал статью про опыт имплементации приватных полей класса в JavaScript-движке — "Implementing Private Fields for JavaScript".

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

Также в статье разбираются нюансы работы c приватными полями. Оказывается, приватные поля могут быть добавлены к любому объекту, даже если он был явно закрыт от изменений с помощью Oblect.seal(). Насколько я понимаю, это "побочный эффект" спецификации, и его не стоит использовать для решения своих задач.

Очень интересная статья. Рекомендую почитать.

#js #internals #spec #firefox

https://www.mgaudet.ca/technical/2021/5/4/implementing-private-fields-for-javascript

Новые возможности управления кешом в HTTP

Тим Пэрри написал статью про новые HTTP-заголовки для управления кешом и упрощения отладки проблем кеширования — "New HTTP standards for caching on the modern web".

Современные веб-приложения используют разные уровни кеширования, начиная кешом браузера и заканчивая кешами балансера и CDN. Для упрощения отладки проблем кеширования был добавлен HTTP-заголовок Cache-Status, с помощью которого можно отследить прохождение запроса через все уровни кеширования.

Для более тонкого управления кешом в стандарт был добавлен Targeted Cache-Control. По сути это обычный Cache-Control, который можно использовать для точечного управления кешами. Akamai и Cloudflare уже поддерживают CDN-Cache-Control, Akamai-Cache-Control и Cloudflare-CDN-Cache-Control. В будущем возможно появление Client-Cache-Control и других подобных заголовков.

Тим пишет, что Cache-Status и Targeted Cache-Control находятся на стадии черновика, но спецификации уже не будут меняться кардинально.

#http #cache #spec

https://httptoolkit.tech/blog/status-targeted-caching-headers/

Новые единицы измерения CSS, зависящие от области просмотра

Брамус Ван Дамм рассказал про новые единицы измерения, которые недавно были добавлены в спецификацию CSS Values and Units Level 4 — "The Large, Small, and Dynamic Viewports".

Довольно давно в браузерах появилась поддержка единиц измерений vw, vh, vmax, vmin. Их используют для ограничения размера элемента размером доступной области просмотра и для заполнения вьюпорта содержимым на мобилках. Когда создавалась спецификация, всё было логично. Однако ситуация изменилась, когда Safari стал скрывать части интерфейса во время прокрутки. Размер вьюпорта стал меняться динамически, и страницы, использующие vh, стали перекрываться интерфейсом браузера.

Для решения этой проблемы были придуманы разные хаки, а CSSWG разработала новые единицы измерения, более тонко учитывающие поведение вьюпорта:

— lvw, lvh, lvmax, lvmin — единицы относительно вьюпорта браузера со скрытыми элементами интерфейса (префикс "l" — large viewport)
— svw, svh, svmax, svmin — единицы относительно вьюпорта браузера без скрытых элементов интерфейса (префикс "s" — small viewport)
— dvw, dvh, dvmax, dvmin — единицы относительно вьюпорта, учитывающие динамическое изменение интерфейса (префикс "d" — dynamic viewport)

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

#css #spec #mobile

https://www.bram.us/2021/07/08/the-large-small-and-dynamic-viewports/