765141 - SVG basic 1.1 filter isn't being applied, and actually hides the element it's applied to

Status: RESOLVED INVALID

(Core :: SVG, defect)

Description

[blordstudio]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_7_4) AppleWebKit/536.11 (KHTML, like Gecko) Chrome/20.0.1132.27 Safari/536.11

Steps to reproduce:

watch this fiddle:

http://jsfiddle.net/uNdDn/


Actual results:

Neither of the two svg elements are displayed at all.

The first svg element has the filter applied as an attribute of the SVG element, in markup.

The second, nearly identical svg element has a different version of the same filter (though with a different ID number, for the sake of clear testing) applied through CSS.

Neither of these work. Even more troubling, they completely hide the element they're being applied to. This is particularly frustrating because FF proudly passes the javascript test for SVG filter support that Erik Dahlstrom recently wrote for Modernizr. How are developers supposed to test reliably for filter support?

Also, in principle, I would hope that if filter support fails, the browser would at least fall back to showing the SourceGraphic, the way Safari does. Showing nothing at all is really the worst from a developer's point of view.

If you go into firebug, you can see the svgs in the DOM. On the second element, try toggling the css filter off, to at least show the element (though without my filter effect applied).

(For general reference purposes, Chrome at least shows the first svg element with the filter applied, although with some wonky layout weirdness.)


Expected results:

Two identical simultaneous SMIL animations with the respective filters applied. One with the filter defined as an attribute of the first SVG viewport, and one with the SVG filter applied through CSS.

Comment 1

[Robert Longson [:longsonr]]

According to http://www.w3.org/TR/SVG/filters.html#feColorMatrixElement

the values attribute must be between 0 and 1. You have 3 which is invalid.

Comment 2

[Robert Longson [:longsonr]]

Opera displays the same as Firefox in this case.

Comment 3

[Robert Longson [:longsonr]]

As for error handling according to http://www.w3.org/TR/SVG/implnote.html#ErrorProcessing if there is an error you don't render the element that has an error.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Robert, are you willing to raise a WebKit bug on their mishandling of this testcase?

Comment 5

[Robert Longson [:longsonr]]

Sure, I can do that.

Comment 6

[Robert Longson [:longsonr]]

Raised https://bugs.webkit.org/show_bug.cgi?id=89222

Comment 7

[blordstudio]

The original spec was misformed on this point, because without the possibility of values over 1 there's no way to saturate the image. That's why the latest editor's draft of the spec:

http://dvcs.w3.org/hg/FXTF/raw-file/3f1fdd4a8004/filters/publish/Filters.html#feColorMatrixElement

states that:

"A value of 0 produces a fully desaturated (grayscale) filter result, while a value of 1 passes the filter input image through unchanged. Values outside the 0..1 range under- or oversaturates the filter input image respectively."

According to this thread on the topic:

http://lists.w3.org/Archives/Public/www-svg/2011Sep/0090.html

Erik D says that Opera *does* work with values over 1 in this case. I realize the draft isn't final, but that part doesn't seem likely to change, and it would really help make these features accessible to developers who aren't matrix mathematicians.

Comment 8

[blordstudio]

Thanks Robert. A word about error processing:

The spec says that "The document shall be rendered up to, but not including, the first element which has an error."

This part of the spec says nothing about filter errors specifically. In fact, I would argue that in a very general sort of way, the filter comes last, after the elements have been specified, even if the filter's application is declared earlier in the markup. It's really way more commonsensical to render at least something as a fallback. Where the letter of the law is unclear, its spirit should prevail, and the spirit is "show as much as you possibly can up to the point of the error." It doesn't break anything to do so. I'm all for the spec, but it really doesn't help developers when you read the spec in the way you're suggesting.

The spec also says:

"A highly perceivable indication of error shall occur. For visual rendering situations, an example of an indication of error would be to render a translucent colored pattern such as a checkerboard on top of the area where the SVG content is rendered."

FF doesn't do that. And that really  *would* help developers. Can we get that checkerboard? :)

The spec also says that:

"If the user agent has access to an error reporting capability such as status bar, it is recommended that the user agent provide whatever additional detail it can to enable the user or developer to quickly find the source of the error. For example, the user agent might provide an error message along with a line number and character number at which the error was encountered."

Firebug doesn't do that. Again, it would be a great help to developers.

Thanks for all your hard work to make these features accessible.

Comment 9

[Robert Longson [:longsonr]]

> 
> This part of the spec says nothing about filter errors specifically. In
> fact, I would argue that in a very general sort of way, the filter comes
> last, after the elements have been specified, even if the filter's
> application is declared earlier in the markup. It's really way more
> commonsensical to render at least something as a fallback. Where the letter
> of the law is unclear, its spirit should prevail, and the spirit is "show as
> much as you possibly can up to the point of the error." It doesn't break
> anything to do so. I'm all for the spec, but it really doesn't help
> developers when you read the spec in the way you're suggesting.

Here's the SVG testsuite test that we need to pass: http://www.w3.org/Graphics/SVG/Test/20110816/harness/htmlObjectApproved/filters-felem-01-b.html

> 
> FF doesn't do that. And that really  *would* help developers. Can we get
> that checkerboard? :)

Not without failing the testsuite test. You should take that up with w3c.

> 
> The spec also says that:
> 
> "If the user agent has access to an error reporting capability such as
> status bar, it is recommended that the user agent provide whatever
> additional detail it can to enable the user or developer to quickly find the
> source of the error. For example, the user agent might provide an error
> message along with a line number and character number at which the error was
> encountered."

We do report an error if it isn't a number but we only check for range on rendering. bug 702016 is for line numbers in error messages, bug 476538 would need to be fixed before we could report rendering errors otherwise we'd report an error on every paint.

Comment 10

[blordstudio]

> Here's the SVG testsuite test that we need to pass:
> http://www.w3.org/Graphics/SVG/Test/20110816/harness/htmlObjectApproved/
> filters-felem-01-b.html

I don't see anything in this test suite that contradicts the W3C "transparent checkerboard" suggestion. It says that:

"The top right subtest applies a filter to the red circle, but there is no corresponding filter element. Thus, a null filter is applied and the red circle is not shown, allowing the green circle to be seen."

So, in the case of a null filter, the browser running this test should show the green circle, per the test description, but also show a transparent checkerboard, per the spec. That would satisfy both sets of demands. The user sees a green circle, no red circle, and also a transparent checkerboard. I see no contradiction between hiding elements on filter syntax errors and showing transparent checkerboards on filter syntax errors. Am I missing something?

Also can you comment on the changes in the draft of the spec [Comment 8]? Should developers just be ignoring the editor's draft for now until it's official?

Comment 11

[Boris Zbarsky [:bzbarsky]]

> Am I missing something?

The general conformance criterion for the SVG test suite is that if your SVG doesn't look like the reference PNG you fail the test.  Do you see any checkerboarding in the reference PNG?

Comment 12

[blordstudio]

I don't see checkerboarding, of course. Boris, are you trying to be funny? The spec says that there should be "a highly perceivable indication of error". As you fully realize, there are multiple recommendations in the spec and test suites. Some are broad, and some are very specific. Sometimes they appear to contradict. This is one of those areas. Things get hashed out in forums and bug reports. I'm taking time to communicate with you guys about a small hurdle for developers. There's no need for condescension.

To return to the original topic, about values over 1, I would still genuinely like to hear a response to my question about the editor's draft in comment 7.

Comment 13

[Robert Longson [:longsonr]]

Webkit changed to make this invalid recently according to https://bugs.webkit.org/show_bug.cgi?id=89222

There are other tests for how invalid things display such as: http://www.w3.org/Graphics/SVG/Test/20110816/harness/htmlObjectApproved/styling-pres-01-t.html

There are, however no tests in the testsuite that display checkerboarding.

Thanks for taking the time to communicate with us, we do appreciate it.

I don't know when the existing contributors would start implementing editor's draft changes. We have some extensions to SVG 1.1 2nd edition such as filters, clipPaths and masking on html elements and SVG 1.2 tiny non-scaling-stroke. If you're really keen, submit a patch and see what happens.

Comment 14

[blordstudio]

Thanks. I realize the issues are very complex. I guess my point, for the record on this thread, is that as it stands, the implementation of feColorMatrixElement with type=saturate can only be used to desaturate an image. Anyone who want to saturate an image using this attribute will be out of luck, and that seems like a painful constraint given that the math (and revised spec) are already there.