Open LeaVerou opened 1 year ago
I don't understand "polluting the namespace". Do we really think we're likely to have predefined colorspaces with names that clash with methods/attributes we want on ColorSpace? That seems pretty unlikely, from the current set.
It's unlikely, but can you guarantee there will never be such a conflict?
Also, it's unclear what something like ColorSpace.foo
means.
I don't have a strong opinion, just some second thoughts.
It's unlikely, but can you guarantee there will never be such a conflict?
Of course not, but we don't deal in absolutes, and we can just tweak names as necessary. But I find it exceedingly unlikely that a predefined colorspace (with the names coming from industry, generally) will overlap with the sort of method and attribute names we'll be using here.
Also, it's unclear what something like ColorSpace.foo means.
I think it's pretty clear that ColorSpace.a98RGB
means "the a98-rgb
color space". I literally can't come up with a clearer, more straightforward way to express that.
I think after reading the responses in https://github.com/w3ctag/design-reviews/discussions/817 I’m leaning towards that we shouldn't do this in L1.
@tabatkins suggested we should the predefined color spaces as static properties on
ColorSpace
. We may instead want to expose them on a sub-object, to avoid pollutingColorSpace
as a namespace.Btw the spec should also include an appendix with example code for the predefined (Color 4) color spaces.