W3C home > Mailing lists > Public > www-svg@w3.org > July 2008

Re: Applying SVG properties to non-SVG content

From: Bert Bos <bert@w3.org>
Date: Fri, 11 Jul 2008 20:58:20 +0200
To: "www-style@w3.org" <www-style@w3.org>
Cc: www-svg <www-svg@w3.org>
Message-Id: <200807112058.21351.bert@w3.org>

On Wednesday 09 July 2008 01:00, Robert O'Callahan wrote:
> I've implemented some experimental features for applying SVG effects
> to HTML. In particular, SVG 'filter', 'clip-path', and 'mask'
> properties are made applicable to non-SVG content and SVG paint
> servers can be used as CSS backgrounds. These are described with
> examples in my blog:
> http://weblogs.mozillazine.org/roc/archives/2008/06/applying_svg_ef.h
>tml
> http://weblogs.mozillazine.org/roc/archives/2008/07/svg_paint_serve.h
>tml There are also links to experimental Firefox builds supporting
> these features.
>
> I've written up a draft specification for these features:
> http://people.mozilla.com/~roc/SVG-CSS-Effects-Draft.html

At first sight, it looks sound, in the sense that it fits the 
architecture of SVG and CSS and it can be specified without 
contradictions.

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).

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.

> I'd greatly appreciate any comments. One thing I'm not sure about is
> where this specification should live. Obviously it's right in between
> two working groups :-).

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.

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...

> Another thing I'm interested in resolving is 
> how we should expose these in Gecko releases; using a vendor prefix
> would be more annoying than usual because I've created no new
> properties here (in fact, no new syntax at all).

I see the problem...

Maybe the problem isn't too big, though. There probably aren't many 
style sheets that are applied to HTML and contain SVG properties. And 
among those that do, there are probably not many where the SVG 
properties are applied to HTML elements.



Bert
-- 
  Bert Bos                                ( W 3 C ) http://www.w3.org/
  http://www.w3.org/people/bos                               W3C/ERCIM
  bert@w3.org                             2004 Rt des Lucioles / BP 93
  +33 (0)4 92 38 76 92            06902 Sophia Antipolis Cedex, France
Received on Friday, 11 July 2008 18:59:00 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:39 GMT