SVG clip and viewBox transform, Chrome vs Firefox

VERIFIED INVALID

Status

()

Core
SVG
VERIFIED INVALID
3 years ago
3 years ago

People

(Reporter: dougfelt, Unassigned)

Tracking

36 Branch
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

797 bytes, image/svg+xml
Details
(Reporter)

Description

3 years ago
Created attachment 8570713 [details]
test.svg

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.111 Safari/537.36

Steps to reproduce:

See the attached file. The clip is in a different location w.r.t the image in Chrome and Firefox.

 on Ubuntu
    "version": "36.0",
    "appBuildID": "20150224134236",
    "platformVersion": "36.0",
    "platformBuildID": "20150224134236",
    "os": "Linux",
    "xpcomabi": "x86_64-gcc3",
    "updateChannel": "release"





Actual results:

SVG 1.1 in http://www.w3.org/TR/SVG/masking.html#AutoClipAtViewportNotViewBox says that in order to clip to the viewBox, one establishes a clip with the viewBox bounds.

Firefox appears to be following proposed 2.0 semantics (?) and using the coordinates in use at reference, which apparently (it is not clear to me from the draft) for an <svg> element is prior to the viewBox transform. This causes the clip to not align with the viewBox, unlike the described 1.1 behavior.

See http://www.w3.org/TR/2012/WD-css-masking-20121115/#ClipPathElement referenced from http://www.w3.org/TR/SVG2/struct.html#DefsElement



Expected results:

I expected Chrome behavior. In particular, since the svg is specified as version 1.1, I expected version 1.1 semantics.
Component: Untriaged → SVG
Product: Firefox → Core
viewBox transforms apply only to descendents per http://www.w3.org/TR/SVG/coords.html#ViewBoxAttribute
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INVALID
Status: RESOLVED → VERIFIED
(Reporter)

Comment 2

3 years ago
From http://www.w3.org/TR/SVG/coords.html#ViewBoxAttribute.  Note the last line.  clip-path is an attribute and is not listed in the list of those excluded.

Unlike the ‘transform’ attribute (see effect of the ‘transform’ on sibling attributes), the automatic transformation that is created due to a ‘viewBox’ does not affect the ‘x’, ‘y’, ‘width’ and ‘height’ attributes (or in the case of the ‘marker’ element, the ‘markerWidth’ and ‘markerHeight’ attributes) on the element with the ‘viewBox’ attribute. Thus, in the example above which shows an ‘svg’ element which has attributes ‘width’, ‘height’ and ‘viewBox’, the ‘width’ and ‘height’ attributes represent values in the coordinate system that exists before the ‘viewBox’ transformation is applied. On the other hand, like the ‘transform’ attribute, it does establish a new coordinate system for all other attributes and for descendant elements.
This is the key sentence though: If specified, an additional transformation is applied to all descendants of the given element to achieve the specified effect.

The viewBox transform does not apply to the clip-path as it is defined on the <svg> element itself (it would apply if you put the clip-path on all the <rect> elements).
(Reporter)

Comment 4

3 years ago
I just don't see how else you can read "like the ‘transform’ attribute, it does establish a new coordinate system for all other attributes". This seems like an explicit carve-out for attributes on the element itself, not just the descendants.  Why is this sentence there, if not to affirm this?
clip-path is not an attribute it is a CSS property. http://www.w3.org/TR/SVG/attindex.html vs http://www.w3.org/TR/SVG/propidx.html
(Reporter)

Comment 6

3 years ago
I wasn't aware of that distinction.

I note that here: https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute

clip-path is listed under the heading 'Presentation attributes'.  

It is also described as an attribute here: https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/clip-path

Can you direct me to a page that makes the distinction between the spec's treatment of 'attributes' versus 'properties'?
That documentation could stand to be improved in that regard. It doesn't distinguish attributes and CSS properties very well at all.
You need to log in before you can comment on or make changes to this bug.