You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Overall I'm good with the size of the library when I shake out the modes I don't need. CSS named colors are not very useful though, and really that's the only other thing I'd like to shake out. Can we opt-in to named color parsing? I suspect a lot of people are only dealing with hex values for modern experiences.
The text was updated successfully, but these errors were encountered:
Hi @bheston, it would indeed be a nice thing to figure out, but I don’t see a solution given the current way things are organized.
In the meantime, if minimal payload is crucial, it may be worth experimenting with build-time optimizations such as using import maps (or other bundler features such as Rollup Transformers) to replace the content of colors/named.js with a dummy export default {}.
Thanks. Yeah, I didn't see a good way to handle it either. I was considering copying and modifying the modeRgb definition to remove the reference to parseNamed and then only use my local definition. It seems like that would work, though runs the risk of getting out of sync.
I wonder if all of the mode definitions exported all of the pieces if someone could build their own mode definitions without the potential for losing as much as if I were to copy that entire file.
Overall I'm good with the size of the library when I shake out the modes I don't need. CSS named colors are not very useful though, and really that's the only other thing I'd like to shake out. Can we opt-in to named color parsing? I suspect a lot of people are only dealing with hex values for modern experiences.
The text was updated successfully, but these errors were encountered: