W3C home > Mailing lists > Public > www-style@w3.org > October 2005

Re: several messages

From: Boris Zbarsky <bzbarsky@mit.edu>
Date: Thu, 20 Oct 2005 00:46:33 -0500
Message-ID: <43572F39.1060506@mit.edu>
To: Robin Berjon <robin.berjon@expway.fr>
CC: www-style@w3.org

Robin Berjon wrote:
> I was talking about the issue of other W3C specifications not 
> being allowed to add CSS properties without changing the media type of 
> CSS style sheets.

Ah.  Yeah, that was not at all clear.

> My heartfelt compassion... Assuming that we would follow the CSS WG's 
> notion of what can be put in a text/css resource so that the SVG or CDF 
> WG would come up with a new media type (say application/cdf-css), how 
> would you see that being implemented? Given an XHTML document with 
> inlined SVG, if a property is defined on an XHTML element through a 
> linked in text/css resource, would it be allowed to cascade into the 
> SVG?

As long as the computed values come from the same set, I don't see why not (and 
at the moment, I believe they do).  If the computed values don't mean the same 
thing, then it's harder, of course.  Not sure then.  ;)

> Would it be easy/pleasant to branch the parser?

In Gecko's case, not so bad at all, actually.  We already do just that to deal 
with SVG presentational attributes -- we have to parse them in a special 
SVG-only mode.  So as a result, attr="value" and |selector { attr: value; }| 
behave differently in SVG documents in Gecko, but that was the best we could do 
under current conditions.  If there were a distinct MIME type for "CSS to be 
parsed by SVG rules", we could just set the parser mode based on the MIME type 
of the stylesheet involved (or the content-style-type for inline style) and get 
consistent behavior, at least.

> Are there benefits that you see to compensate the cost of introducing one (or more, if 
> other WGs imitate the CSS WG's approach) more media type?

Well, an immediate benefit to SVG authors using Gecko would be consistency in 
the treatment of CSS and presentational attributes, as outlined above...

Note that I'm not saying the separate MIME type solution is great, and I wish 
there were a better solution at this juncture, but given existing contradictions 
in specified behavior, I don't really see any good solutions.  Do you?  No 
matter what's done, some set of people will be unhappy; the question is how to 
minimize that set.  I won't pretend to know the answer to this; I haven't really 
looked into it.

Going forward, as an implementor, I would of course prefer it if working groups 
actually worked together to get stuff like this resolved before we end up in a 
situation like this.  That's clearly preferable to a proliferation of MIME types 
all over.

Received on Thursday, 20 October 2005 05:46:52 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:27:21 UTC