- From: Tantek Çelik <tantek@cs.stanford.edu>
- Date: Mon, 14 Apr 2003 15:52:56 -0700
- To: Christoph Päper <christoph@paeper.de>, <www-style@w3.org>
On 4/14/03 2:43 PM, "Christoph Päper" <christoph.paeper@tu-clausthal.de> wrote: > > Tantek Çelik: >> On 2/16/03 4:57 AM, "Christoph Päper" <christoph.paeper@tu-clausthal.de> >> >> <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 www-svg: http://lists.w3.org/Archives/Public/www-svg/ 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) http://www.w3.org/TR/SVG12/ 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 themselves). > 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 bugs). 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.). Tantek [1] http://people.opera.com/howcome/1999/foch.html [2] http://www.cwi.nl/~steven/css/hsl.html
Received on Monday, 14 April 2003 18:51:33 UTC