[EMAIL PROTECTED] wrote:
> I wasn't sure whether to blog about this but I thought I might as well
> start a little conversation here first...
> 
> People are proposing all sorts of extensions to CSS for fancy
> presentational effects --- gradients, canvas backgrounds, masks, and
> so on. I think this is unwieldy and duplication of effort. Instead I'd
> just like the SVG CSS properties 'filter', 'mask', 'clip-path', and
> 'fill' to Just Work on non-SVG content --- making the full power of
> SVG paint servers and effects available to HTML content.

I don't know what "fill" would mean for a non-SVG element, but it sounds
like a pretty reasonable approach in general. You just have to define for
each property what exactly it means when applied to a CSS box.

 > And I'd like a way to specify any element as an 'image' source for CSS
 > 'background' > and other properties ... could be as simple as url(#element).
 >
> The biggest problem with this is making the necessary SVG fragments
> available in an HTML document. Using HTML5's proposed parsing
> extensions, or just XHTML, you could including the SVG fragments in
> the underlying document, but that's clumsy if you're using the same
> stylesheet in many documents.
>
> A better approach would be to give the stylesheet an accompanying .svg
> file and use external references to that SVG file. So foo.css would
> contain "filter:url(foo.svg#bar)". That would work pretty well if we
> can load the file once per base document and resolve all references to
> foo.svg to that same loaded document. Unfortunately the spec
> http://www.w3.org/TR/SVG/struct.html#URIReference doesn't say anything
> about this but perhaps that just means we can interpret it the way we
> want.

I think that makes a lot of sense, but you'd have to define what happens
if I reference e.g. an SVG <rect> element for my background-image. What
are the intrinsic dimensions here? What happens if I reference an SVG font
element? Or a <text> element? A gradient? A filter? Some of these make
sense and some of them don't. Whether they're defined to do something useful
or defined to be ignored, they all need to be defined explicitly one way
or another.

~fantasai
_______________________________________________
dev-tech-layout mailing list
dev-tech-layout@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-layout

Reply via email to