Re: Color proposal

> 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:17 UTC