import sheet from './card.css' with { type: 'css' };
It seems that we need to give the ability to backfill this capability especially if we want to promote this capability on the new website, which involve a couple things
Give user's the ability to opt-in to Greenwood doing the polyfilling
And then polyfill (technically downgrade to standard ESM)
// strip the offending syntax
import sheet from './card.css';
// and have Greenwood return a Constructable Stylesheet for card.css
const sheet = new CSSStyleSheet();sheet.replaceSync(`p { color: red }`);
export default sheet;
One thing to keep in mind as part of exposing this polyfill configuration is draw a line on what can go behind this, as it should only be a way to bridge the gap for a spec that is not baseline yet. So it should just be based on a matter of when this feature lands, not if it's still in the if stage, otherwise it would be better off as a plugin. Eventually, user's should be able to just disable the polyfill since eventually it will just be in all browsers.
Based on some initial testing, I noticed is that our use of es-module-shims is getting in the way, giving false positives in development since it seems to enable CSS and JSON modules that make these work in development for Safari / FF, which is obviously not desirable, so we should put that behind a flag as well.
So we should also disable import maps by default as well since it's now so widely available having now landing in Safari >= 16.4 now, and instead should probably cancel #1115 and just create a new issue moving it to our polyfills plugin.
Summary
Shockingly, it was only just recently learned that import attributes are not baseline across browsers and using the
with
syntax will just break outright in anything but Chrome at the moment.It seems that we need to give the ability to backfill this capability especially if we want to promote this capability on the new website, which involve a couple things
And then polyfill (technically downgrade to standard ESM)
Details
Interestingly, returning a
CSSStyleSheet
was our original implementation, but then we in hindsight, mistakingly went all in on thewith
syntax, not realizing it was not supported yet. 😅One thing to keep in mind as part of exposing this
polyfill
configuration is draw a line on what can go behind this, as it should only be a way to bridge the gap for a spec that is not baseline yet. So it should just be based on a matter of when this feature lands, not if it's still in the if stage, otherwise it would be better off as a plugin. Eventually, user's should be able to just disable the polyfill since eventually it will just be in all browsers.Based on some initial testing, I noticed is that our use of es-module-shims is getting in the way, giving false positives in development since it seems to enable CSS and JSON modules that make these work in development for Safari / FF, which is obviously not desirable, so we should put that behind a flag as well.
So we should also disable import maps by default as well since it's now so widely available having now landing in Safari >= 16.4 now, and instead should probably cancel #1115 and just create a new issue moving it to our polyfills plugin.