You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, only Blink supports the ability to transform some SVG geometric properties in CSS with unitless values.
While a pixel unit is implied under the hood from my understanding (as a pixel in the non-scaled SVG canvas), it means that using a unitless value in HTML or assigning one in JavaScript cannot be also be supplied as-is to a stylesheet, and needs to be converted into a pixel value (either in script or via calc() in CSS).
The unitless case (left) only correctly reacts to hover in Blink. The top/pink dot moves to the X origin due to the custom property being rejected and defaulting to 0, and the bottom/cyan dot doesn't move at all due to the unitless value being ignored, so it reverts to the cx attribute in the markup.
The pixel unit case (right) works across all browsers, as expected.
It would be great to have consistency across all engines so that the native behaviour of SVG, accepting unitless values, extends to CSS, allowing to use the same value across markup, styles, and scripts.
Additionally, if the SVG is scaled to something other than 100%, in this example, changing the cx to 75px is counter-intuitive as it doesn't perform a 25px move (from the original 50). So if your SVG has a viewBox of 0 0 100 100, but the CSS specifies width: 20px; height: 20px;, moving an element to 75px would intuitively go out of the viewBox, but doesn't. While the behaviour with the px unit is correct, I believe allowing authors to provide a unitless value makes more sense and is more in-line with the authoring experience with SVG.
I reported this as a bug for Firefox but it as rejected due to the CSS spec not allowing unitless lengths besides 0. Given this is an SVG property, it doesn't seem outlandish to me to conform to SVG's handling of these values instead of enforcing CSS's handling.
Description
Currently, only Blink supports the ability to transform some SVG geometric properties in CSS with unitless values.
While a pixel unit is implied under the hood from my understanding (as a pixel in the non-scaled SVG canvas), it means that using a unitless value in HTML or assigning one in JavaScript cannot be also be supplied as-is to a stylesheet, and needs to be converted into a pixel value (either in script or via
calc()
in CSS).A demo of the behaviour is visible here: https://codepen.io/chriskirknielsen/pen/rNdgJOB
0
, and the bottom/cyan dot doesn't move at all due to the unitless value being ignored, so it reverts to thecx
attribute in the markup.It would be great to have consistency across all engines so that the native behaviour of SVG, accepting unitless values, extends to CSS, allowing to use the same value across markup, styles, and scripts.
Additionally, if the SVG is scaled to something other than 100%, in this example, changing the
cx
to75px
is counter-intuitive as it doesn't perform a 25px move (from the original50
). So if your SVG has aviewBox
of0 0 100 100
, but the CSS specifieswidth: 20px; height: 20px;
, moving an element to75px
would intuitively go out of the viewBox, but doesn't. While the behaviour with thepx
unit is correct, I believe allowing authors to provide a unitless value makes more sense and is more in-line with the authoring experience with SVG.I reported this as a bug for Firefox but it as rejected due to the CSS spec not allowing unitless lengths besides
0
. Given this is an SVG property, it doesn't seem outlandish to me to conform to SVG's handling of these values instead of enforcing CSS's handling.Specification
W3C
Open Issues
No response
Tests
No response
Current Implementations
Standards Positions
No response
Browser bug reports
https://bugzilla.mozilla.org/show_bug.cgi?id=1787374
Developer discussions
No response
Polls & Surveys
No response
Existing Usage
No response
Workarounds
No response
Accessibility Impact
No response
Privacy Impact
No response
Other
No response
The text was updated successfully, but these errors were encountered: