Re: [css3] support for filters

On 1/11/11 6:54 AM, Alan Gresley wrote:
> On 11/01/2011 5:25 PM, Boris Zbarsky wrote:
>> Or in HTML in any browser with an HTML5 parser, right?
>
> I currently use FF 3.6.13 which I believe has a HTML5 parser.

It doesn't.  You need a beta of Firefox 4 (or a current dev build of 
Chrome, iirc, or a Webkit nightly).  Whatever stage Chrome 9 is in might 
work too.

> But nothing is appearing in FF. Safari and Opera shows the text flowing
> around the border of the floated <svg> element but no SVG (just the text
> node 'svg'). FF is worst since it shows bazaar rendering. The FF web
> developers toolbar reports that the <p> is the child of <stop>. The tree
> shows html > body > svg > g > lineargradient #gradient > stop > p.

Right, because when parsed with the old tagsoup parser the stop element 
is never closed.  The HTML5 parser special-cases the "/>" thing for SVG.

> I did a quick search and found this
> <http://www.tutorialspoint.com/html5/html5_svg.htm>. It mentions Firefox
> 3.7 and about enabling HTML5 via about:config.

Right.  It defaults to on in Firefox 4 betas; the preference has no 
effect in 3.6.13.

> So what appears between <style> and </style> that can be a SVG filter
> but is part of the CSS?

No.  What appears between <style> and </style> can include a "filter: 
url(something)" declaration pointing to some filter, either in the same 
document or a different document.

> but all the examples return a 404. The link below to "a small demo" also
> return a 404.
>
> http://people.mozilla.org/~bzbarsky/svg-external-resource/example.html

Someone in their infinite wisdom took down the whole people.mozilla.org 
webserver without telling anyone....

> http://css-class.com/test/svg/example2.svg
>
> I can view it in FF 3.6.13 and other browsers. When offline though,
> unlike the other browsers, FF pops up a window asking me what I would
> like to do with the file.

I have no idea what you're seeing there.

> What is a same-origin restrictions?

This was documented in the link in my previous e-mail.  Gecko currently 
enforces that an SVG resource document is same-origin with the thing 
that linked to it.

> All in all, I not saying that the above non support or behavior is
> wrong. I am just seeking a method of testing with SVG filters to see how
> it is best to incorporate it into CSS as CSS syntax. Using some MS
> propriety filter is not a way to demonstrate an affect.

I have no idea what's MS proprietary here.  The SVG spec says that the 
computed value of the "filter" property for an SVG element is a url that 
points to an SVG filter to use for that element.  All Gecko has done is 
drop the "for an SVG element" part of that and make the behavior work 
for all elements.

-Boris

Received on Tuesday, 11 January 2011 14:31:56 UTC