W3C home > Mailing lists > Public > www-style@w3.org > July 2014

[css-color] Naming the color classes

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Tue, 15 Jul 2014 14:29:50 -0700
Message-ID: <CAAWBYDDWc=r--a=qVD56bkHxLvQMh=Lxwf=-hGCRr6qgBZUQhw@mail.gmail.com>
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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:23 UTC