Re: Applying SVG properties to non-SVG content

On Jul 11, 2008, at 20:58 , Bert Bos 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).

This is not a special casing but is part of the normal SVG processing  
model. References to filters, masks, paint servers, etc. are expected  
to be made to other files and do not expect them to be rendered.

> Opera currently seems to ignore the fragment ID and just draw the  
> whole
> SVG file. The MIME type definition for image/svg+xml doesn't seem to
> say anything about fragment IDs.

Opera uses them for backgrounds, which is a different case that  
involves SVG Views which I'm not sure Opera implements.

Processing of fragments (especially the parts IMHO of most relevance  
to Robert's spec) can be found by plodding around starting from  
FuncXMLRI: http://www.w3.org/TR/SVGMobile12/ 
types.html#DataTypeFuncXMLRI.

> Specifications that involve two or more working groups (other than  
> just
> to review each other's work) are indeed always a bit problematic. But
> as Robin already said, there is nothing that prohibits them. It is  
> just
> a question of organization. Depending on the nature of the work, it
> could be handled by joint meetings, by a task force, by people who
> attend both groups, or, if the project is simple enough, by letting  
> one
> group do the writing and the other the reviews.

Isn't this the part where you're supposed to twist Robert's arm until  
he agrees to edit the spec so that it doesn't have to deprioritise  
other things? :)

> A different problem is how to set the priorities. Compared to all the
> other work being done in SVG and CSS, how high a priority is this and
> how many resources are available for it? Should it be done in the next
> two years (at the cost of what other work?), can it wait a year or  
> two,
> should it not be done anytime soon, or not be done at all...

This seems to be an area of active progress and interest from  
implementers, maybe it's worth prioritising?

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

Received on Saturday, 12 July 2008 21:40:06 UTC