- From: Pierre-Luc Auclair <p.lucauclair@heliosmulti.com>
- Date: Wed, 10 Jan 2007 12:37:02 -0500
- To: www-style@w3.org, www-svg@w3.org
> Another one?
>
> Hasn't the conclusion, whenever someone has brought up the subject of
> macros of this type, been that it would break backwards compatability
> and can be solved server side / in a preprocessor / with editor macros
> / with find/replace?
Yes, yet another one. I think if people request one no-end, W3C-CSS should
eventually adopt something of the kind.
It would break backwards compatibility -- idea of which I'm not a huge
proponent. Personally as long as the content is carried, it's good enough
backwards compatibility.
And whatever hack you use to emulate this kind of thing, it's still a hack,
and you can't standardize it across application easily (if you have many
implementation) IMO.
> according the CSS specification, when you write yellow.color {}, it
> select the <yellow> element which have the css class "color".
>
> So you can't use this syntax to create a color definition.
Indeed, that's an error from my part. Should either be color.yellow or
color#yellow {} depending how you see it.
> See <http://www.w3.org/TR/SVGMobile12/painting.html#SolidColorElement>.
I'm aware of the SolidColor element. It's just not powerful enough for
applications other than screen display. It's also not accessible from XHTML.
What I'm trying to bring here is something that's compatible between both
formats.
Of course I'm not pretending like it will be implemented at all, I'm just
trying to bring dicsussion on the topic again. We really need such color
information.
Pierre-Luc
Received on Wednesday, 10 January 2007 17:37:11 UTC