Bug 293616

Summary: The width and height properties via CSSOM on existing svg elements show differing behavior with setting numbers across WebKit/Chromium and Firefox
Product: WebKit Reporter: noreply
Component: CSSAssignee: Nobody <webkit-unassigned>
Status: NEW    
Severity: Normal CC: karlcow, koivisto, sabouhallawa, sam, simon.fraser, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: Other   
Hardware: PC   
OS: Windows 11   
See Also: https://bugs.webkit.org/show_bug.cgi?id=265420
Attachments:
Description Flags
A small reproduction for the case.
none
rendering in safari, firefox, chrome
none
testcase quirks mode
none
testcase in standard mode none

noreply
Reported 2025-05-27 08:22:34 PDT
Created attachment 475383 [details] A small reproduction for the case. When setting the width and height properties of an existing SVG element via CSSOM using a number, WebKit and Chromium convert this number to a pixel value for both properties. This pixel conversion is not consistently observed across different scenarios or browsers. Within WebKit and Chromium themselves, the conversion does not occur when setting width or height for newly created SVG elements via DOM APIs, nor for HTML elements where numbers for such properties are typically handled differently. However, Firefox does not exhibit this pixel conversion. This behavior can be reproduced using the attached HTML file. Reproduced on WebKit 18.4 (playwright build v2158) on Windows 11 (23H2).
Attachments
A small reproduction for the case. (791 bytes, text/html)
2025-05-27 08:22 PDT, noreply 		no flags
Details
rendering in safari, firefox, chrome (118.13 KB, image/png)
2025-12-01 23:10 PST, Karl Dubost 		no flags
Details
testcase quirks mode (511 bytes, text/html)
2025-12-01 23:11 PST, Karl Dubost 		no flags
Details
testcase in standard mode (485 bytes, text/html)
2025-12-01 23:11 PST, Karl Dubost 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1 2025-05-27 19:03:50 PDT
Thank you for the report! Could you please clarify why you are saying that this is a bug and WebKit and in Blink, not in Gecko? To be clear, I do not have any insight into this personally, just making sure that all relevant information is collected.
Karl Dubost
Comment 2 2025-05-28 21:41:12 PDT
So looking at the spec. https://drafts.csswg.org/css-values-4/#length-value length-value for width and height can only be a value with a unit except for 0. Making the test a bit more complete: <svg style="width:50px;background-color:green"></svg> <svg style="width:50;background-color:red"></svg> <svg style="background-color:gold"></svg> <svg id="cssom" style="background-color:blue"></svg> <svg id="cssom2" style="width:0px;background-color:pink"></svg> <script> document.querySelector("#cssom").style.width="50"; document.querySelector("#cssom2").style.width="50"; </script> * red box in Firefox is 350x150, it didn't grok the unit-less width. * pink box in Firefox is not visible (default size is 0px) the unit-less doesn't override it. see https://codepen.io/webcompat/pen/dPoogQQ I wonder if it's because the code conflates the SVG width attribute with the CSS width in the style attribute?
Karl Dubost
Comment 3 2025-05-28 21:44:07 PDT
Sam has very recently touched the code for SVGLengthValue in SVGRenderStyle. https://github.com/WebKit/WebKit/pull/45999/files
Radar WebKit Bug Importer
Comment 4 2025-06-03 08:28:40 PDT
<rdar://problem/152502387>
Antti Koivisto
Comment 5 2025-06-25 05:35:04 PDT
Simple reduction <!DOCTYPE html> <style> .case { background: red; height: 64px; width: 0px; } </style> <body> <svg class="case" id="svg"></svg> </body> <script> svg.style.width = 64; </script>
Antti Koivisto
Comment 6 2025-06-25 05:45:32 PDT
We always parse the inline style for SVG elements in quirks mode. if (!inlineStyle) { Ref mutableProperties = MutableStyleProperties::create(strictToCSSParserMode(isHTMLElement() && !document().inQuirksMode())); .... This is a long-standing behavior that matches Chrome. Firefox respects the no-quirks mode of the document. I don't couldn't find anything definite in the specs to say if this is wrong or not though Firefox behavior makes more logical sense. Maybe it would be a safe change.
Karl Dubost
Comment 7 2025-12-01 23:10:28 PST
Created attachment 477580 [details] rendering in safari, firefox, chrome The Quirks Mode spec refers to CSS https://quirks.spec.whatwg.org/#the-unitless-length-quirk > A <quirky-length> is syntactically identical to a <number-token>, and is interpreted as a px length with the same value. > > (In other words, Quirks Mode allows all px lengths in the affected properties to be written without a unit, similar to unitless zero lengths.) — https://drafts.csswg.org/css-values-4/#deprecated-quirky-length I created two tests, one in Quirks Mode (document.compatMode -> BackCompat), and one in standard mode (document.compatMode -> CSS1Compat) Only Firefox has a different behavior for QuirksMode.
Karl Dubost
Comment 8 2025-12-01 23:11:21 PST
Created attachment 477581 [details] testcase quirks mode
Karl Dubost
Comment 9 2025-12-01 23:11:58 PST
Created attachment 477582 [details] testcase in standard mode
Karl Dubost
Comment 10 2025-12-01 23:50:22 PST
So the part of SVG spec for CSS Styling is https://svgwg.org/svg2-draft/styling.html#StylingUsingCSS The specific part about the style element is defined in https://svgwg.org/svg2-draft/styling.html#ElementSpecificStyling * the style element in https://svgwg.org/svg2-draft/styling.html#StyleElement > The ‘style’ element allows style sheets to be embedded directly within SVG content. SVG's ‘style’ element has the same attributes as the corresponding element in HTML. > > The semantics and processing of a ‘style’ and its attributes must be the same as is defined for the HTML ‘style’ element. * the style attribute in https://svgwg.org/svg2-draft/styling.html#StyleAttribute > The ‘style’ attribute is used to supply a CSS declaration of an element. The attribute is parsed as a declaration-list. > > Aside from the way that the ‘class’ attribute is reflected in the SVG DOM (in the className IDL attribute on SVGElement), the semantics and behavior of the ‘class’ and ‘style’ attributes must be the same as that for the corresponding attributes in HTML. The style attribute is defined in HTML https://html.spec.whatwg.org/multipage/dom.html#attr-style > All HTML elements may have the style content attribute set. This is a style attribute as defined by CSS Style Attributes. [CSSATTR] > > In user agents that support CSS, the attribute's value must be parsed when the attribute is added or has its value changed, according to the rules given for style attributes. [CSSATTR] Which links to the CSS spec about style attribute https://drafts.csswg.org/css-style-attr/#style-attribute > Some document formats have a style attribute to permit the author to directly apply style information to specific elements in documents. If a document format defines a style attribute (whether named ‘style’ or something else) and the attribute accepts CSS as its value, then this specification defines that style attribute’s syntax and interpretation. and > The interpreter must parse the style attribute's value using the same forward-compatible parsing rules that apply to parsing declaration block contents in a normal CSS style sheet (see chapter 4 of the CSS2.1 specification [CSS21]), with the following addition: when the UA expects the start of a declaration or at-rule (i.e., an IDENT token or an ATKEYWORD token) but finds an unexpected token instead, that token is considered to be the first token of a malformed declaration. I.e., the rule for malformed declarations, rather than malformed statements, is used to determine which tokens to ignore in that case. So I don't think there is an ambiguity for parsing. The issue is more That both Chrome and Safari do not respect the parsing rules for standard mode. The attribute should be ignored. FIREFOX CSS1Compat svgelt.width.baseVal SVGLength { unitType: 2, value: 9.999999682655225e-21, valueInSpecifiedUnits: 100, valueAsString: "100%" } svgelt.style.width "" FIREFOX BackCompat svgelt.width.baseVal SVGLength { unitType: 2, value: 64, valueInSpecifiedUnits: 100, valueAsString: "100%" } svgelt.style.width "64px" SAFARI CSS1Compat / CHROME CSS1Compat svgelt.width.baseVal SVGLength { unitType: 2, value: 64, valueInSpecifiedUnits: 100, valueAsString: "100%" } svgelt.style.width "64px" SAFARI BackCompat / CHROME BackCompat svgelt.width.baseVal SVGLength { unitType: 2, value: 64, valueInSpecifiedUnits: 100, valueAsString: "100%" } svgelt.style.width "64px" Basically Safari and Chrome should ignore the style attribute set with a unitless value.
Karl Dubost
Comment 11 2025-12-01 23:57:06 PST
There is a missing WPT test in https://wpt.fyi/results/svg/styling to illustrate this case.
Karl Dubost
Comment 12 2025-12-01 23:59:31 PST
The code from Sam is coming from https://searchfox.org/wubkat/rev/6230eecf3f6be5d63f1e9265d72f9c7570659613/Source/WebCore/dom/StyledElement.cpp#87-100 ```cpp Ref<MutableStyleProperties> StyledElement::ensureMutableInlineStyle() { RefPtr<StyleProperties>& inlineStyle = ensureUniqueElementData().m_inlineStyle; if (!inlineStyle) { Ref mutableProperties = MutableStyleProperties::create(strictToCSSParserMode(isHTMLElement() && !document().inQuirksMode())); inlineStyle = mutableProperties.copyRef(); return mutableProperties; } if (RefPtr mutableProperties = dynamicDowncast<MutableStyleProperties>(*inlineStyle)) return *mutableProperties; Ref mutableProperties = inlineStyle->mutableCopy(); inlineStyle = mutableProperties.copyRef(); return mutableProperties; } ```
Note You need to log in before you can comment on or make changes to this bug.