Re: [css3-colors] Comments on Last Call

On 4/14/03 2:43 PM, "Christoph Pšper" <>

> Tantek «elik:
>> On 2/16/03 4:57 AM, "Christoph Pšper" <>
>> <alpha> values were introduced as values between 0 and 1 in the SVG 1.0
>> specification.  CSS3 Color continues with that convention.
> I've never cared that much about SVG (neither Macromedia Flash),

But Christoph, surely you wouldn't deny that the web community as a whole
cares very much about vector graphics, if the adoption of Macromedia Flash
is any indication.

If you care about CSS, you care about presentation, and thus you _should_
care about SVG.

Nowhere does it say that only the CSS Working Group may introduce formatting
related properties.  Although there is at least a tacit agreement to
communicate among the primary groups that create formatting
properties/values (CSS, SVG, XSL), and those groups have spent considerable
hours in cross-group discussions.  The results haven't been perfect, but
neither have they been disastrous.

What would certainly help is for more folks like yourself who are in general
interested in the "style and presentation space" to at least monitor

A little cross-pollination would certainly be helpful in the realm of style.

> and have
> never read the spec myself, but it seems to me, that at least the CSS part
> of it was done without the amount of care (and/or public feedback) that is
> put into the real CSS.

I think if you have concerns about SVG, you really ought to review the
latest spec (SVG 1.2)

and provide feedback.  It's only a working draft, so now is the time to
provide input.

> I assume it was mainly done by graphic artists, who
> are used to certain things (X11, 0..1 alpha value), which are dumb or
> unlogic for historical reasons, and thus didn't even think of changing that.

That's a little unfair I think - it would be like claiming CSS was done by
typographers who are used to certain things (leading, point units) for
historical reasons and didn't even think of changing them.

> IMVHO this has some negative impact on CSS, which obviously tries to
> acommodate as many exisiting specs as possible. They're listed in "Status of
> this document".

CSS3 Color is perhaps unique in this way (but hopefully not for long) in
that it is the first CSS3 module to define a property and a value-type, that
is about (in weeks to a month?) to go CR, that is written in such a way that
other specifications, both CSS, and non-CSS, can refer to it normatively to
include color related features (rather than having to define them

> I've similar feelings about XSL.

Since we're talking about styling, I presume you are referring XSL-FO.
I'd prefer that we don't start that rant-fest again, I think it has been
well covered in the archives and particular web pages[1].

>>> 3.4. The 'rendering-intent' property
>>> Hm, all the other baby-blue tables have more details than just the
>>> property name.
>> Perhaps a problem with the W3C
>> working draft style sheet and your browser?
> Seems so, although I don't see the reason for it, it displays okay in Opera
> 7.

Perhaps the problem has been fixed since then.

>>> would prefer to see the algorithms expressed in English, although
>>> ABC is somehow close to that.
>> Since it sounds like ABC is acceptable to you,
> To me and implementors perhaps. I just wanted to remark that some,
> especially novices, might be offended when confronted with an unknown
> programming language in a specification. CSS3: List for example relies much
> on algorithms and requires them to be in English. Just noticed that you're
> an editor of that one, too.

True, but certainly CSS3 Color was written before CSS3 Lists was.  And, the
original algorithms for HSL->RGB were written in ABC by Steven Pemberton[2];
I didn't want to attempt to rewrite them (a process that usually introduces

Ian Hickson has done _a_lot_ of work to write up the English algorithm
descriptions in CSS3 Lists.  For most of them, he had nothing to start with,
so using English was as easy as using anything else, and seemed to make the
most sense.

>>> Nothing against it, but camelCase isn't something CSS used to use, is it?
>>> System colors use it, but with the starting letter being capital =>
>>> 'CurrentColor'.
>> Values in CSS are case-insensitive,
> Sure.
>> The particular capitalization 'currentColor' is used in the spec simply
>> because that is the same capitalization that is used for that value in the
>> SVG specifications.
> IMHO a specification should be consistent with itself in the first place,
> rather than something it refers to. It's of course a very minor issue.

Yes that is true, however it is also important to not change things slightly
for no functional reason.

If SVG had not introduced 'currentColor', then perhaps we could have
introduced 'current-color' instead.  At this point, it is not worth making
it different.  Indeed, even before SVG, CSS2 introduced named system colors
which were all camel-cased as well (or at least, unhyphenated), thus if
anything, SVG was only being consistent with the keyword value naming scheme
from CSS2 (nevermind the XML/DOM concerns etc.).




Received on Monday, 14 April 2003 18:51:33 UTC