850952 - Rootmost SVG element uses "wrong" viewport to resolve percentages

Status: VERIFIED INVALID

(Core :: SVG, defect)

Description

[Alan Oursland]

Attachment: relative_units_bug.html

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.160 Safari/537.22

Steps to reproduce:

Create a DIV with an absolute width and height.
Create an SVG inside the DIV with width and height of 100%
Create a RECT inside the SVG that has percentage positions.


Actual results:

The size of the RECT is based on the size body or the browsers window or something. The rectangle is drawn outside of the bounds of the DIV.



Expected results:

I expect the RECT to be drawn as a percentage of the DIV.

The SVG spec is not clear on the desired behavior (thus the quotes around "correct" in the title. Webkit uses the size of the DIV. Firefox and Opera use the size of some element above the DIV (although Webkit has a bug when zooming the attached repro). I'm trying to get all of the browsers to have the same behavior.

I think using the size of the DIV to resolve the percentages makes the most sense.

Comment 1

[Robert Longson [:longsonr]]

Your rootmost SVG doesn't actually have a width and height of 100% of it's container. It's actually 300 x 150 since you've not supplied any width/height.

Comment 2

[Alan Oursland]

The w3 spec at http://www.w3.org/TR/SVG/struct.html#SVGElementWidthAttribute says that unspecified values for width and height on SVG elements are 100%.

"If the attribute is not specified, the effect is as if a value of '100%' were specified."

Comment 3

[Robert Longson [:longsonr]]

While true, it's not actually relevant to this issue.

Per http://www.w3.org/TR/2011/PR-SVG11-20110609/coords.html#ViewportSpace

======
The ‘width’ attribute on the outermost svg element establishes the viewport's width, unless the following conditions are met:

    the SVG content is a separately stored resource that is embedded by reference (such as the ‘object’ element in XHTML [XHTML]), or the SVG content is embedded inline within a containing document;
    and the referencing element or containing document is styled using CSS [CSS2] or XSL [XSL];
    and there are CSS-compatible positioning properties ([CSS2], section 9.3) specified on the referencing element (e.g., the ‘object’ element) or on the containing document's outermost svg element that are sufficient to establish the width of the viewport.

Under these conditions, the positioning properties establish the viewport's width.
======

Comment 4

[Alan Oursland]

I'm pretty sure that part of the spec says that CSS style width takes precedence over the attribute width. The repro does not specify CSS width on the top most SVG element so it should default to "100%".

The SVG content is inline so it matches the first clause.
And the containing document is styled using CSS
But the referencing element (the rootmost SVG element) does not have any positioning styles applied so it should default to 100%.

I tested the repro with height and width attributes set to "100%" on the rootmost svg element. It does work as expected with the values specified so it seems that this is an issue with default values.

I verified that version 8.01 on Windows 8 works as expected. When I updated from 8.01 to 12.0 it was broken. This looks like a regression.

Comment 5

[Robert Longson [:longsonr]]

Nearly, but not quite, the CSS style width is actually auto because it's not explicitly set.

It's not a regression if we didn't use to follow the relevant specifications and now we do though is it? 

If you want to read the whole story it's in bug 668163 which as you have discovered was a Firefox 12 fix.

Comment 6

[Alan Oursland]

From my perspective, the W3 specs are written in gloriously ambiguous natural language and interpreting them requires a combination of looking at author intent, web developer usefulness and browsers ecosystem behavior.  I think it is a desirable goal to have all major browser implementations converge on a common interpretation of a common spec.

I read through the comments on 668163. I'd like to summarize my understanding of the issue both for posterity and to make sure we are talking about the same issue. Please correct me if I am interpreting this incorrectly.

According to "http://www.w3.org/TR/2011/PR-SVG11-20110609/coords.html#ViewportSpace", specified CSS width takes precedence over the topmost SVGSVGElement width. However, since default CSS has "width:auto" the SVGSVGElement width is never used. The solution was to set style width when the attribute width is specified.

I do not think the intent of SVG11 7.2 is to make CSS values always take precedence over the attribute values. To me, it sounds like only specified values should take precedence over the attribute values. A default value of 'auto' in CSS should not take precedence over a specified value of "width='50px'". Bug 668163 got around that by setting the width style when the width attribute is set, but that seems to be a very complex interpretation of the spec. It seems to me that the spec actually intends for a specified attribute value to take precedence over a default CSS value.

However, it leaves open the question of a default CSS value versus a default attribute value. I argue that it is consistent with the spec for a default attribute value of 100% to take precedence over a default CSS value of 'auto'.

I think Firefox are following an incorrect interpretation of the spec in this case.

I tried out the following modifications to the attached repro:
1. <svg width="100%" height="100%">          // SVG size is based on enclosing DIV
2. <svg style="width:100%; height:100%;">   // SVG size is based on enclosing DIV
3. <svg style="width:auto;height:auto;">        // SVG size is same as with nothing specified

Webkit doesn't seem to respect the specified 'auto' behavior correctly. I don't understand how 'auto' is resolved, but once I do I'll file a bug against Chrome and Safari for that behavior (as well as IE if it is also broken when I test it).

Comment 7

[Robert Longson [:longsonr]]

Attachment: reporters testcase fixed to be valid

Comment 8

[Robert Longson [:longsonr]]

Sorry about comment 7. I attached it to the wrong bug.