- From: Bramus via GitHub <noreply@w3.org>
- Date: Mon, 19 Jan 2026 08:03:40 +0000
- To: public-css-archive@w3.org
> > 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](https://github.com/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? I currently have https://github.com/bramus/css-parser-extensions which is still WIP but also not entirely up-to-date with the current line of thinking. We’ve had some good internal chats about this, and @tabatkins has a some things figured out _(such as desugaring a bunch of these things to custom functions/mixins instead of relying on script)_, which currently aren’t documented in https://github.com/bramus/css-parser-extensions. > > A main point regarding polyfills is also how to handle features when they are implemented vs. when they are not. If I recall [@bramus](https://github.com/bramus)' argument correctly, the polyfill version should overrule the implemented version to avoid breaking a feature when it gets implemented with slightly different behavior. > > I'm thinking the polyfill author should probably be the one in charge of deciding that, not the API. The default should be overwriting, though. You don’t want to have another [SmooshGate](https://developer.chrome.com/blog/smooshgate). -- GitHub Notification of comment by bramus Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13186#issuecomment-3766978497 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 19 January 2026 08:03:41 UTC