Re: [csswg-drafts] [cssom] Properties that allow access to parsed-but-invalid syntactic constructs (declarations, rules, etc) as a low-fi way to make polyfills easier (#13186)

> Then, we end up designing entire new complex APIs to solve this problem such as the one presented in Paris in August (which I've failed to find now despite looking for a while, any help welcome).

I assume you're referring to @bramus' presentation related to [CSS parser extensions](https://slidr.io/bramus/css-parser-extensions). He and I also had a conversation about the presented idea and a general parser API last year. He wanted to write up an explainer afterwards, though I think he didn't get around to do that, I guess. Or did you, Bramus? For reference, here are the API suggestions I had in mind when discussing this:

```css
CSS.registerDataType(options);

// name, syntax

CSS.registerDataType({
 name: 'single-animation-timeline',
 syntax: 'auto | none | <dashed-ident> | <scroll()> | <view()>'
});

CSS.registerFunction(options);

// name, syntax, body, result

CSS.registerFunction({
 name: 'scroll',
 syntax: '[ <scroller> || <axis> ]?',
 body: (args) => {
  // ...
 },
 result: '<single-animation-timeline>'
});

CSS.registerProperty({
 name: 'size',
 syntax: '[<length-percentage [0,∞]> | auto]{1,2}',
 inherits: false,
 initialValue: 'auto',
 computedValue: (matchedElement, args) => {
  // ...
 },
});

CSS.extendProperty(options);

// name, syntax, computedValue

CSS.extendProperty({
 name: 'justify-self',
 syntax: 'anchor-center',
 computedValue: (matchedElement, args) => {
  // ...
 },
});

CSS.extendDataType(options);

// name, syntax, computedValue

CSS.extendDataType({
 name: 'number',
 syntax: 'random',
 computedValue: (matchedElement, args) => {
  // ...
 },
});
```

The general idea behind this is to provide hooks into the parser and extend or overwrite the functionality without having to do the parsing themselves.

There's also a [CSS Parser API](https://drafts.css-houdini.org/css-parser-api/) in the CSS Houdini repo, which refers to a [WICG repo](https://github.com/wicg/css-parser-api/) defining an initial draft of a general parser API.
And there are also some related discussions like in #10002.

A main point regarding polyfills is also how to handle features when they are implemented vs. when they are not. If I recall @bramus' argument correctly, the polyfill version should overrule the implemented version to avoid breaking a feature when it gets implemented with slightly different behavior.

-----

The proposed extensions to existing CSSOM interfaces might be a first step to make polyfills easier. Though polyfill authors would still need to do most of the heavy lifting by checking all the different sources, react to changes to them, and parse them to finally apply their functionality on top.

So I believe, an approach that hooks directly into the parser and lets it hand off unrecognized features to custom functions would be the best way to go.

That said, I'm neither an implementer nor a polyfill author. So people like @emilio, @andruud, @bramus, @mirisuzanne, @philipwalton, and others can possibly provide better input than me here.

Sebastian

Sebastian

-- 
GitHub Notification of comment by SebastianZ
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13186#issuecomment-3765767059 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Sunday, 18 January 2026 21:29:23 UTC