Сегодня в блоге 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/