1270210 - Some <svg> elements with clip attribute aren't rendered

Status: RESOLVED INVALID

(Core :: SVG, defect)

Description

[Adam Roach [:abr]]

Attachment: testcase 1

When viewed in Firefox 46.0 on OS X, the attached diagram is missing several elements (the icons representing documents). They are rendered correctly under OS X quickview, in Chrome, and in Safari, and are at least partially rendered by several SVG rasterizers.

Comment 1

[Daniel Holbert [:dholbert]]

The problem is with the "clip" property (as a mapped SVG attribute), on the inner <svg> elements.

If I override that by adding this CSS to the page...
   svg { clip: initial !important;}
...then our rendering changes to match Chrome.

Comment 2

[Daniel Holbert [:dholbert]]

And looking more closely, those clip attributes are all set to the following 
  clip="rect(7.61327 7.61332 7.61327 7.61332)

It looks to me like that creates an empty clipping region -- so rendering nothing in these <svg> elements seems to be correct...  

This syntax is defined here: https://drafts.csswg.org/css2/visufx.html#propdef-clip "rect(<top>, <right>, <bottom>, <left>) where <top> and <bottom> specify offsets from the top border edge of the box, and <right>, and <left> specify offsets from the left border edge of the box."

Comment 3

[Daniel Holbert [:dholbert]]

It's not as simple as comment 2, though, because:
 (1) If I change clip="..." to style="clip:..." the issue goes away (no clipping happens)
 (2) Any value of the clip attribute (even "0 0 100 100") seems to disable rendering.

Comment 4

[Daniel Holbert [:dholbert]]

er, I meant "rect(0 0 100 100)"

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: testcase 2: nested <svg clip="rect(7 7 7 7)">

Comment 6

[Daniel Holbert [:dholbert]]

Attachment: testcase 3: nested <svg clip="rect(0 0 100 100)">

Comment 7

[Daniel Holbert [:dholbert]]

Robert, do you know what's going on here?

Comment 8

[Daniel Holbert [:dholbert]]

[Side note: this isn't a regression (or not a recent one, at least) -- a Nightly build from 3 years ago (2013-05-04, version 23.0a1) renders all testcases here exactly the same as current Nightly.]

Comment 9

[Cameron McCormack (:heycam)]

The difference between the clip="" presentation attribute and the style="clip: ..." is that the latter requires the px units on the four offsets.  I'm not sure about the actual rendering.

Comment 10

[Daniel Holbert [:dholbert]]

Thanks - that clears up mystery #1 from comment 3.

This bug *does* reproduce in a testcase like one of the attached files, with the "clip" attribute replaced with CSS & "px" units, like so:
   <svg style="clip: rect(0px, 0px, 100px, 100px);">

Comment 11

[Robert Longson [:longsonr]]

We implement CSS 2.1 clipping. This is not what SVG 1.1 specificies as it links to CSS 2.0 which assigns a different meaning to the clip attributes. For CSS 2.1 the attributes are

rect(top, right, bottom, left)

they are a distance in from the edge of the shape.

CSS 2.0 has these in a different order. Commas **are** required. Which I assume is the reason for the failures around comment 5 to comment 7.

Comment 12

[Daniel Holbert [:dholbert]]

(In reply to Robert Longson from comment #11)
> We implement CSS 2.1 clipping [...]
> rect(top, right, bottom, left)
> 
> they are a distance in from the edge of the shape.

OK -- but then, I'd expect "testcase 2" to render with 7px shaved off on all the edges. And I'd expect a variant with "rect(0px, 0px, 0px, 0px)" to render with no clipping at all. But both of those actually end up rendering as blank (i.e. everything clipped).

> CSS 2.0 has these in a different order. Commas **are** required. Which I
> assume is the reason for the failures around comment 5 to comment 7.

The absence/presence of commas don't seem to impact our rendering here, based on my testing.

Comment 13

[Daniel Holbert [:dholbert]]

(Note also that my link in comment 2 (with "css2" in the URL) is actually the Editors Draft of CSS 2.2 -- it's not CSS 2.0.)

Comment 14

[Robert Longson [:longsonr]]

https://www.w3.org/TR/CSS21/visufx.html#clipping

In CSS 2.1, the only valid <shape> value is: rect(<top>, <right>, <bottom>, <left>) where <top> and <bottom> specify offsets from the top border edge of the box, and <right>, and <left> specify offsets from the left border edge of the box. Authors should separate offset values with commas. User agents must support separation with commas, but may also support separation without commas (but not a combination), because a previous revision of this specification was ambiguous in this respect. 

non-commas is a may and I guess we support that option. I was mistaken about which edges we go in from, 0 0 0 0 should result in nothing visible as the right/bottom values go from the left/top of the box and we get a 0 size rect.

Comment 15

[Daniel Holbert [:dholbert]]

(In reply to Robert Longson from comment #14)
> I was mistaken about
> which edges we go in from, 0 0 0 0 should result in nothing visible as the
> right/bottom values go from the left/top of the box and we get a 0 size rect.

That matches my understanding (and would mean we're correct in rendering nothing for the original testcase here).  I'm still confused about why we render nothing for testcase 3, though, with 0 0 100 100.

Comment 16

[Robert Longson [:longsonr]]

I think you meant to write rect(0, 100, 100, 0) right is the second argument but it's measured from the left. So if the second argument is 0 then the right edge of the clip is on the left edge of the rect so you see nothing.