- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 15 Jul 2014 14:29:50 -0700
- To: www-style list <www-style@w3.org>
Rik brought up an issue on Twitter <https://twitter.com/rcabanier/status/489151450958667776> about the naming of the color classes I added to the draft. Specifically, he thinks the named are too short and likely to be used by authors already. So, first, I *think* that if an author defines a new HexColor (say) class, it'll be just fine. It might break code relying on the CSS-defined HexColor class, but it shouldn't break an unmaintained page that doesn't use the new features. Am I right? Second, there is a conflict we definitely need to address in any case - I'm using the name "RGBColor", but that interface name is already taken for one of the DOM Level 2 Style classes (the terrible ones we all agree were mistakes). The only way to get to an object of this class is something like "el.style.getPropertyCSSValue('color').getRGBColorValue()", and that only works if (a) there's actually a color set on the element (inheritance doesn't count!) and (b) you used rgb() or hex notation (named colors, hsl() don't work). And then to actually use it you have to call "color.red.getFloatValue(CSSPrimitiveValue.CSS_NUMBER)" or "color.red.setFloatValue(CSSPrimitiveValue.CSS_NUMBER, 127)", because this is the worst API ever and OMIGOD. So what I'm trying to say is, I think we can safely rename that RGBColor interface to whatever we want, and continue using the name in the new API. Any objections? (Plus, this might give us the impetus needed to officially retire DOM Level 2 Style.) ~TJ
Received on Tuesday, 15 July 2014 21:38:12 UTC