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