- From: Sebastian Zartner via GitHub <noreply@w3.org>
- Date: Sun, 18 Jan 2026 23:14:17 +0000
- To: public-css-archive@w3.org
> I disagree, the polyfill author has no idea about how the standard feature will end up being, so the polyfill needs to take precedence to avoid a situation of web incompatibility. Well, you're probably right. If the polyfill author isn't called @bramus or @mirisuzanne, we can't expect them to follow the specs closely. 😅 Plus, nobody can predict the future. So it might happen that somebody creates a completely new feature using those APIs unrelated to any standardized feature. And if that _does_ get standardized later on, it might be totally different from that feature. Or it the polyfill implements an early version of a standardized feature, which changes later on. So in most cases it makes sense to let the polyfill take precedence. Though I still wonder whether it makes sense to at least allow polyfill authors to _opt into_ using the built-in feature if available. I mean, if something is quite stable spec-wise and already implemented in one or two engines, it's very unlikely to change. And in those cases a polyfill would benefit from being used as a fallback. Sebastian -- GitHub Notification of comment by SebastianZ Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13186#issuecomment-3765859003 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 23:14:17 UTC