Илья Стрельцын (один из редакторов css-live) опубликовал хорошую статью — "Фантастические веб-спецификации и где они обитают".

Статья рассказывает про спецификации и всё, что надо знать для того, чтобы начать с ними эффективно работать. В начале статьи рассказывается про логику формирования адресов на страницы документов. Самые последние версии спецификаций находятся по таким адресам: https://www.w3.org/TR/<название_технологии>/. При этом все ранее опубликованные спецификации (технические отчёты — technical reports) хранятся вечно, их адреса выглядят так: https://www.w3.org/TR/2008/WD-html5-20080610. Хранить документы вечно по зафиксированным адресам необходимо для защиты от патентных троллей. На страницах всех спецификаций есть ссылка на Editor's Draft (ED), именно там находится самая свежая версия документа с исправлениями неточностей, опечаток и т.п.

В статье ещё рассказывается про разные статусы документов, и что они обозначают. Немного затрагивается история непростых взаимоотношений W3C и WHATWG.

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

#specification #web #css #html

https://css-live.ru/css/fantasticheskie-veb-specifikacii-i-gde-oni-obitayut.html

Аксель Раушмайер в прошлом месяце написал неплохую статью о том, как работают глобальные переменные в JS — "How do JavaScript’s global variables really work?"

Перед объяснением нюансов работы с глобальными переменными в статье рассказывается, что такое область видимости (scope) и как она определяется на уровне спецификации. В спеке области видимости "реализуются" с помощью lexical environments, которые состоят из environment record (нечто похожее на словарь с ключами и значениями) и ссылки на внешний scope. Таким образом дерево вложенных друг в друга областей видимости представляется деревом связанных между собой lexical environments.

На самом верхнем уровне этого дерева находится "global environment", состоящий из двух компонент: "object environment record", который поддерживает связь с свойствами глобального объекта ( window / self в браузере и global в node.js), и "declarative environment record", который создаётся с помощью const, let, class. Эти части существуют независимо, что даёт возможность создавать биндинги с одинаковыми ключами в разных записях. При обращении к таким биндингам из кода будет побеждать declarative environment record. Если очень упростить, то можно сказать, что начиная со спецификации ES2015 в JavaScript появились два разных вида глобальных переменных.

Рекомендую почитать статью и посмотреть на примеры того, как это всё работает.

#specification #js #es2015

https://2ality.com/2019/07/global-scope.html

В посте про релиз Firefox 70 был интересный пункт про то, что в display появилась поддержка значений, состоящих из двух ключевых слов. Рейчел Эндрю на Mozilla Hacks написала статью про это нововведение — "The two-value syntax of the CSS Display property".

Правила, которые определяют распределение элементов на странице, задаются с помощью контекста форматирования (Formatting Context), которое, в свою очередь, можно установить с помощью свойства display. Например, Flex Formatting Context устанавливается с помощью декларации display: flex. Но это ещё не всё. Спецификация CSS определяет поведение самого блока и его потомков. В примере выше <div>, у которого будет выставлен display: flex, будет иметь блочный тип относительно своих соседей в нормальном потоке документа, но у потомков будет задан Flex Formatting Context. То есть у блока существует внешний (для нормального потока документа) и внутренний (для потомков) типы отображения. Обновлённая спецификация для display теперь явно описывает эту особенность. Например, display: flex эквивалентно display: block flex, а display: inline-flex — display: inline flex.

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

#css #specification

https://hacks.mozilla.org/2019/10/the-two-value-syntax-of-the-css-display-property/

В блоге 2ality Аксель Раушмайер написал статью про атрибуты свойств объектов — "Attributes of object properties in JavaScript".

В спецификации ECMAScript объекты описываются с помощью internal slots (хранилище, которое используется только на уровне спецификации) и с помощью properties (старые-добрые свойства объектов). С каждым свойством объекта, ассоциирован ключ и атрибуты ( value, writable, configurable, enumerable и т.п.). Для работы с атрибутами используются методы defineProperty, defineProperties, getOwnPropertyDescriptor, getOwnPropertyDescriptors.

В статье описывается несколько неочевидных особенностей работы с объектами. Например, если объект наследует read only свойство, то у дочернего объекта нельзя создать свойство с таким же именем. Для того чтобы сделать копию объекта, в котором есть геттер и сеттер, нужно использовать методы Object.defineProperties и Object.getOwnPropertyDescriptors. Object.assign для этого случая не подходит, так как под капотом он использует присваивание, поэтому в новом объекте будет результат геттера, но не функция, которая его определяет.

Статья хорошая. Рекомендую почитать, если хотите получше разобраться с работой объектов.

#js #specification

https://2ality.com/2019/11/object-property-attributes.html

В последнем подкасте HTTP 203 Джек Арчибальд и Сурма рассказали, почему из спецификации HTTP Modules была удалена возможность импорта JSON-файлов.

В Node.js есть возможность зареквайрить json в JavaScript-файл. Это очень удобно, если нужно зафолбечиться на какие-то данные в случае проблем с API или просто для чтения конфигов. Похожий механизм импортов был предложен для добавления в web-платформу в спецификации HTTP Modules: import json from 'some.json'. Проблема в том, что в web расширение файла не влияет на интерпретацию загружаемых данных, тип ресурса определяется HTTP-заголовком content-type. Это означает, что если мы импортируем json с чужого домена import json from 'https://example.com/some.json' и если этот сайт будет компроментирован таким образом, что вместо application/json в заголовке будет отправляться application/javascript, это открывает дыру в безопасности, так как содержимое json-файла может быть заменено на любой JavaScript-код. Теперь разработчики спецификации думают над тем, как добавлять метаинформацию на уровне модульной системы, чтобы избавиться от таких случаев.

Webpack решает проблему с метаинформацией, добавляя свои расширения в спецификатор импорта. Разработчики Rollup и Parcel тоже размышляют над этой проблемой. В любом случае код может получиться непереносимым между бандлерами, если все будут работать над этой задачей независимо. Таким образом решение возникшей проблемы в импорте json на уровне спецификации, позволит унифицировать использование метаинформации и в бандлерах.

#esm #security #specification

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

На Mozilla Hacks пару дней назад появилась статья Рейчел Эндрю про column-span — "Multiple-column Layout and column-span in Firefox 71".

В многоколоночной разметке контент непрерывно "перетекает" из одной колонки в другую. Эта разметка очень популярна в газетах и журналах, так как улучшает читабельность текста. Спецификация Multiple-column Layout описывает необходимые свойства для создания такой разметки. В рамках этой спецификации описывается свойство column-span, с помощью которого можно стилизовать элементы так, чтобы они занимали несколько колонок сразу, например, как заголовок в газете. С релизом Firefox 71 column-span будет поддерживаться во всех современных браузерах.

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

#css #specification #layout

https://hacks.mozilla.org/2019/11/multiple-column-layout-and-column-span-in-firefox-71/

Илья Стрельцын написал небольшой пост про развитие CSS — "CSS4 не будет… потому что он давно прошел. Встречайте CSS8!".

На данный момент не существует такого понятия как "версия CSS", потому что спецификация для упрощения поддержки была разбита на модули с независимым версионированием. Но было бы неплохо иметь какой-нибудь неофициальный ориентир для отслеживания развития спецификации в целом. Таким ориентиром Илья предлагает взять раздел "The Official Definition" документа "CSS Snapshot". У этого документа есть пять редакций c 2007 года. До разбития на модули у CSS было две версии, поэтому можно сказать, что актуальная на данный момент версия CSS — "CSS7".

В статье описаны основные вехи, которые происходили при развитии спецификации. Рекомендую почитать, если интересно узнать про историю развития стандарта.

#musings #css #specification

https://css-live.ru/css/css4-ne-budet-potomu-chto-on-davno-proshel-vstrechajte-css8.html

Medium и похожие сайты при добавление ссылок в пост магическим образом превращают их в виджеты. Например, ссылка на твит может превратиться в текст из твита, а ссылка на youtube — в видеоплеер. Дрю Маклеллан рассказал, как это работает — "Programmatically Discovering Sharing Code With oEmbed".

Некоторые ресурсы дают возможность встраивания своего контента на других сайтах, предоставляя специальный код. Если мы хотим "разворачивать" ссылки в виджеты на своём сайте, можно взять этот код и немного его доработать так, чтобы он формировался динамически. Но это неудобный вариант, если надо обрабатывать ссылки с большого количества сервисов. Для решения этой проблемы была разработана спецификация oEmbed. Суть её простая. Если вы запросите страницу с youtube-видео (или с другим ресурсом, который поддерживает oEmbed), там в теге link будет ссылка на json, в котором будет вся необходимая информация для встраивания на страницу: <link rel="alternate" type="application/json+oembed" href="http://www.youtube.com/oembed..." title="Some video">.

Про oEmbed узнал сегодня впервые, хотя он существует с 2008 года.

#web #specification

https://www.smashingmagazine.com/2019/11/programmatically-discovering-sharing-code-oembed/

Скорее всего мы все сталкивались с эффектом "прыгающей страницы", когда при чтении статьи на экране смартфона текст прыгает из-за загружающихся изображений. Как этого избежать, Крейг Баклер рассказал в статье "Jank-free page loading with media aspect ratios".

Страница сдвигается из-за того, что в макетах с отзывчивым дизайном мы не можем задать жёсткие размеры у изображений, чтобы браузер зарезервировал для них место, так как размер может быть любым. Но браузер может рассчитать размер изображения, зная пропорции изображения и его ширину или высоту. В будущих версиях Chrome и Firefox появится поддержка определения пропорций на основе атрибутов width и height. Также разрабатывается спецификация для нового CSS-свойства aspect-ratio. Но пока поддержка пропорций не появится во всех браузерах, можно использовать трюк с пропорциональным отступом (если для padding использовать проценты, то отступ будет высчитываться на базе ширины элемента).

Концептуально проблема с "прыгающей страницей" решена в спецификации Scroll Anchoring. Проблема в том, что на данный момент эта спека не поддерживается Safari и, соответственно, всеми браузерами на iOS.

Статья на удивление очень подробная для такой специфичной темы. Очень рекомендую почитать.

#css #specification #ui

https://blog.logrocket.com/jank-free-page-loading-with-media-aspect-ratios/

В блоге v8 появилась статья о том, как читать спецификацию ECMAScript — "Understanding the ECMAScript spec, part 1".

В статье разбирается спецификация метода Object.prototype.hasOwnProperty. Рассматривается отличие типов языка (могут использоваться обычными программистами, например, null, undefined, Boolean, Number, String) от типов спецификации (используются только для описания спеки, например, Completion Records). Разбирается понятие слотов (slots), которые обозначаются в спецификации с помощью двойных квадратных скобок: o.[[Prototype]], o.[[GetOwnProperty]](). Описывается конструкция, которая выглядят как вызов функции в языке, но на самом деле ей не является.

Очень клёвая статья. Must read для тех, кто хочет научиться понимать спецификацию. Жду вторую часть.

#js #specification #tutorial

https://v8.dev/blog/understanding-ecmascript-part-1

Сегодня в блоге v8 появилась вторая часть статьи про структуру спецификацию ECMAScript от Марьи Хёлтэ — "Understanding the ECMAScript spec, part 2".

В этой части Марья разбирает то, как в спецификации определён обход цепочки прототипов для получения значения свойства объекта. Объясняется всё в довольно доходчивой форме. Используя описанный подход, можно разобрать любую другую фичу языка на уровне спецификации. В статье дополнительно затрагивается понятие runtime semantics: грамматика спецификации определяет синтаксис языка, runtime semnatics определяет смысл этих синтаксических конструкций. В самом конце статьи есть ссылка на бонусную статью про то, почему obj.foo при передаче как аргумент, например, в console.log(obj.foo) становится AssignmentExpression.

Очень клёвая статья. Теперь жду третью часть.

#js #specification #tutorial

https://v8.dev/blog/understanding-ecmascript-part-2

Берт Бос — можно сказать один из отцов CSS (участвует в разработке стандартов с 1996 года) — поделился своими мыслями по поводу версионирования CSS в статье "CSS X".

Последняя пронумерованная версия CSS была CSS3. CSS3 — это неофициальное название набора независимых спецификаций (модулей), которые были извлечены из монолитной спеки CSS2.1 с добавлением новых модулей. Такое разделение было удобно для рабочей группы и разработчикам браузеров, но стало неудобно для разработчиков: что было добавлено после CSS3, где можно найти систематизированную информацию в удобном виде и т.п.

В статье Берт пишет о том, что рабочая группа не будет брать на себя обязанности по определению того, что должно входить в CSS4. Если брать работу по версионированию, то возникает много вопросов: какие модули должны попасть в новую версию, с какой частотой подымать версию, как взаимодействовать с разработчиками браузеров и т.п. Он предлагает сообществу (будь это комитет из участников разных организаций или недавно сформированная CSS4 Community Group) независимо от рабочей группы сформировать независимый набор спецификаций — CSS4. Он не видит в этом ничего плохого.

CSS4 Community Group начала свою работу с февраля этого года. Вполне возможно, что эта инициатива будет успешна.

#css #specification #musings

https://www.w3.org/blog/2020/03/css-x/

Росс Кирслинг — участвует в разработке спецификации ECMAScript — написал статью про самую ужасающую часть спецификации — "Tales from "Ecma's Crypt": Annex B.3.3".

В JavaScript всегда была возможность использовать блоки ( {} ) не только с операторами if, while, for, но и как обособленную синтаксическую конструкцию (standalone block). Спецификация не описывала ситуацию, когда внутри блока определялась функция, поэтому исторически в разных браузерах этот сценарий был реализован по-разному. Для исправления этой проблемы в спецификацию был добавлен раздел, который фактически говорит о том, что определение функции внутри блока должно себя вести одновременно как var и let. Например, вот этот код не в strict-режиме выведет в консоль 1:

var a = -1;
(function () {
  const printOuter = () => console.log(a);
  {
    a = 1;
    function a() {}
    a = 2;
    printOuter();
  }
})();

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

#js #specification

https://dev.to/rkirsling/tales-from-ecma-s-crypt-annex-b-3-3-56go

В блоге v8 была опубликована третья часть из серии статей Марьи Хёлтэ про структуру спецификации ECMAScript — "Understanding the ECMAScript spec, part 3".

В этой статье объясняется несколько тем: разница между лексической и синтаксической грамматикой, принцип разворачивания сокращений ( [+In, ?Yield, ?Await] и другие) в полноценные продукции. Всё разбирается на примере того, как в спецификации описывается возможность использования ключевого слова await в качестве идентификатора в обычных функциях, и каким образом await становится недоступен в асинхронных функциях. Для полного понимания статьи нужно быть знакомым с базовыми принципами построения контекстно-свободных грамматик — будет достаточно почитать несколько абзацев на википедии.

Эта статья не последняя в серии — в следующей части обещают рассказать, как в спеке описывается automatic semicolon insertion (ASI).

#js #specification

https://v8.dev/blog/understanding-ecmascript-part-3

Спецификация ECMAScript 2020 будет официально выпущена в июне. Набор новых фич и улучшений утверждён и уже не будет меняться. Среди нововведений можно найти улучшенный раздел про порядок перечисления свойств объекта с помощью цикла for-in, над которым работал Кевин Гиббонс

Исторически спецификация практически не накладывала ограничения на порядок перечисления свойств при использовании for-in, так как не удавалось достичь консенсуса по этой теме. Одна из причин разногласий была в том, что у каждого движка есть свои особенности реализации. Большие изменения в этой части спецификации означали бы большой объём работы для разработчиков всех движков. Тем не менее есть негласные правила при работе c for-in, которым должны следовать разработчики браузеров, чтобы не сломать web. Эти правила и были закреплены в ES2020.

Теперь спецификация гарантирует, что при использовании for-in сначала будут идти свойства, ключи которых обычные числа (в порядке возрастания ключа). Затем свойства, ключи которых строки (в хронологическом порядке их добавления). А затем свойства, созданные с помощью Symbol (в хронологическом порядке их добавления). Это поведение не гарантируется для случаев, когда во время перечисления свойств изменяется прототип, удаляются или добавляются новые свойства в объект или его прототип, изменяется прототип или когда у свойства изменяется параметр enumerable. Также спецификация гарантирует порядок только для обычных объектов, то есть порядок не гарантируется для Proxy, Array, arguments и т.п.

#js #specification #es2020 #history

https://github.com/tc39/proposal-for-in-order
https://tc39.es/ecma262/#sec-enumerate-object-properties
https://tc39.es/ecma262/#sec-ordinaryownpropertykeys

В блоге v8 была опубликована четвёртая часть серии статей про структуру спецификации ECMAScript — "Understanding the ECMAScript spec, part 4".

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

Для обработки подобных ситуаций в спеке используется покрывающая грамматика (cover grammar). Она вводит дополнительные символы, которые учитывают все возможные синтаксические конструкции и которые можно временно использовать как плейсхолдеры. Эти символы уточняются после парсинга проблемной части текста программы. Для списка аргументов и выражения в скобках в спеке используется символ CoverParenthesizedExpressionAndArrowParameterList (CPEAAPL).

Очень интересная статья. Рекомендую почитать, если хотите ещё лучше понимать спецификацию ECMAScript.

#js #specification #tutorial

https://v8.dev/blog/understanding-ecmascript-part-4#using-cpeaapl-in-productions

Эверт Пот написал статью про синтаксис ECMAScript 4 — "ECMAScript 4: The missing version".

ECMAScript 4 бы очень большим проектом по модернизации JavaScript. Работа над этой спецификацией шла 9 лет (1999-2008), но была полностью переосмыслена, переродившись в ES5 и ES2015.

В ECMAScript 4 хотели добавить стогую систему типов с поддержкой классов (в итоге они появились в ES2015) и интерфейсов. Было запланировано добавление новых типов: byte, int, unit, double, decimal. Практически ни один из этих типов не попал в последующие версии языка, но на данный момент ведётся работа над пропозалом для добавления в JS типа decimal. Планировали добавить пакеты (packages) для организации кода. Но вместо пакетов в ES2015 решили добавить модульную систему. Существовало расширение ES4 — E4X, которое позволяло работать с XML прямо в JavaScript. Можно сказать, что E4X стал прародителем современного JSX.

Интересная статья. Рекомендую почитать, если интересуетесь историей JavaScript.

#js #history #specification

https://evertpot.com/ecmascript-4-the-missing-version/

Маниш Горегаокар — разработчик Servo — написал статью про сложности имплементации свойства font-size — "Font-size: An Unexpectedly Complex CSS Property".

Маниш разрабатывал Stylo — CSS-движок, написанный на Rust, который стал частью Firefox. Одной из его задач было добавление поддержки свойства font-size.

Проблема в том, что на размер шрифта влияют очень много факторов. Размер может быть задан разными юнитами и ключевыми словами. На него влияет выбранное семейство шрифтов, например, font-size: medium в рубленных шрифтах это 16 пикселей, а в моноширинных шрифтах — 13 пикселей. Также Firefox (из коробки) и Chrome (с помощью расширения) позволяют задавать размер шрифта в зависимости от текущего языка текста. Есть свои нюансы для задания размеров шрифта в MathML и при его использовании c аннотациями ruby.

Интересно, что в некоторых случаях разработчики не следуют полностью спецификации, а делают good enough приближение, потому что точно реализовать фичу по спеке бывает очень сложно.

В общем, хорошая статья. Рекомендую почитать всем, кто интересуется внутренней работой браузеров.

#css #internals #firefox #specification

https://manishearth.github.io/blog/2017/08/10/font-size-an-unexpectedly-complex-css-property/

Антуан Квин в блоге WebKit рассказал о преимуществах использования индивидуальных CSS-свойств для трансформации объектов — "CSS Individual Transform Properties".

Все современные браузеры поддерживают трансформацию объектов с помощью CSS-свойства transform и CCS-функций translate(), rotate(), scale(), skew(), matrix(). Первые три используются в разработке чаще всего. Для упрощения работы с ними в спецификацию CSS Transform Level 2 были добавлены CSS-свойства translate, rotate, scale. Ими удобнее пользоваться по сравнению с transform, а также они облегчают создание и переопределение сложных анимаций.

Индивидуальные свойства для трансформации — это новая фича. На данный момент её поддержка есть в Firefox, Chrome Canary и Safari Technology Preview 117.

#css #specification

https://webkit.org/blog/11420/css-individual-transform-properties/

В прошлом году самой горячей темой стало усилившееся разногласие в отношении будущего веба между Apple, Google и Mozilla. Google продвигает идею "нативного" веба, добавляя в Chromium экспериментальные API для доступа К Bluetooth/USB-устройствам, файловой системе пользователя и т.п. Apple и Mozilla придерживаются консервативной позиции и не хотят добавлять некоторые API, предлагаемые Google, объясняя это заботой о приватности и безопасности пользователей.

Ноам Розенталь — участвует в разработке стандартов и движков браузеров — постарался объективно разобраться в этой теме и поделился своим видением решения возникшей проблемы — "Should The Web Expose Hardware Capabilities?".

В первой части статьи Ноам пытается понять обе стороны спора и пишет о том, что по-своему правы и Google, и Apple с Mozilla. С одной стороны мы хотим видеть развитие платформы, с другой стороны мы не хотим жертвовать безопасностью пользователей. Это очень серьёзный вопрос, например, в 2018 году исследователи в области безопасности рассказали о способе компроментации USB-ключей доступа с помощью WebUSB (Google эту проблему устранил). Чтобы избежать подобных проблем в будущем во второй части статьи автор предлагает внедрить модель доверия, в которой разработчики железа и браузеров могут ограничить урон, который может быть нанесён потенциально небезопасными API.

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

#web #specification

https://www.smashingmagazine.com/2021/01/web-expose-hardware-capabilities/