Re: Applying SVG properties to non-SVG content

On Jul 11, 2008, at 22:41 , Robert O'Callahan wrote:
> On Sat, Jul 12, 2008 at 6:58 AM, Bert Bos <bert@w3.org> wrote:
> The paint server idea probably needs some work. What is the MIME  
> type of
> an SVG paint server? It seems to require some special-casing of SVG:  
> if
> the URL refers to an image/svg+xml file and the URL has a fragment ID,
> then it's not the whole SVG file that is drawn, but only the element
> with that ID (assuming it is a valid paint server according to the SVG
> spec).
>
> I'm not sure why the mime-type matters, but I see your point that  
> one might expect url() with a fragment identifier to behave just as  
> if there was no fragment identifier.

The media type matters because interpreting an URI fragment depends on  
the media type.

The media type of an SVG paint server, or of any other resource, is  
image/svg+xml. The registration is clear that it needn't be valid  
according to a schema (though in most cases it might be anyway) and  
therefore the document needn't begin with an svg element.

I'm not sure about which interpretation might lead one to expect a  
url() with a fragment to be interpreted as if it weren't there,  
especially for the properties we're talking about (for background I  
could see that bug creeping in because most image types don't have  
meaningful fragments).

> Would it be better to introduce a new CSS value, say "element()",  
> instead?

If its only value would be to be able to address an element by its ID  
inside an XML or HTML document it doesn't really seem useful as  
url(#foo) has been working for a while now and is nicely orthogonal.

> I'm happy to be the editor. If no great controversy arises (and so  
> far, so good) it shouldn't be much work. I've been working on it  
> because I think it is rather important and also urgent. These  
> effects are aready available in platforms that compete with the  
> standards-based Web.

+1

> There's also a strategic issue within the standards community. It  
> seems the "path of least resistance" to adding a single feature to a  
> standard like CSS (or SVG) is to just go ahead and extend CSS (or  
> SVG) with a new spec for that feature, rather than creating a  
> dependence on another standard that has that feature. It's often  
> more convenient for authors, it's often more convenient for  
> implementors, and it's often more convenient for those doing the  
> spec work, Unfortunately, in the long term, repeated iterations of  
> that approach will lead us to a lot of code, spec and authoring know- 
> how duplication. Instead I'd like to have standards integration in  
> place so that these features are *possible*, and then explore how we  
> can make things better, for example by adjusting standards for  
> smoother integration (e.g., dropping the requirement for an <svg>  
> container around SVG subtrees) or providing convenience syntax that  
> can hide the integration boundaries.

+1

-- 
Robin Berjon - http://berjon.com/

Received on Saturday, 12 July 2008 21:59:57 UTC