[csswg-drafts] [css-values-4] Define `width` and `height` CSS values for SVG Elements in mapping (#12376)

goldenboy777 has just created a new issue for https://github.com/w3c/csswg-drafts:

== [css-values-4] Define `width` and `height` CSS values for SVG Elements in mapping ==
As per the spec https://svgwg.org/svg2-draft/geometry.html#Sizing, width and height CSS properties are allowed on few SVG elements like 
`rect`,`svg`,`image` and `foreignObject` elements.
Chromium is building a [feature](https://chromestatus.com/feature/5178789386256384) that now allows width and height CSS properties to now be applied on nested `svg` elements. During the [discussion](https://github.com/WebKit/standards-positions/issues/509), it was bought to our attention that the specification lacks in clearly defining the mapping of these values with respect to SVG elements.
For example, a possible value of width CSS property is `min-content` (whose value is resolved based on the CSS box model specification) but SVG elements don't generate CSS boxes and hence the behaviour when `min-content` is applied to SVG elements is unknown.

I have divided the possible values of `width` and `height` in possible sections:

### Defined Behavior 

1) Absolute units:  
These include units like **px, pt, pc, cm, mm, in**. Absolute values are defined in the [specification](https://www.w3.org/TR/CSS2/visudet.html#propdef-width).
 
2) Relative units 
These include units like **em, rem, %, ex, ch, lh, rlh**. Relative values are defined in the specification (though only % is mentioned in the [specification](https://www.w3.org/TR/CSS2/visudet.html#propdef-width)).

3) Special keyword: 
These include keywords like **auto, initial, inherit, unset, revert, revert-layer**. Their behaviour is also defined in the SVG specification (though only auto and inherit is mentioned in the [specification](https://www.w3.org/TR/CSS2/visudet.html#propdef-width)). Other values like initial, revert, unset etc. are not mentioned but their behaviour seems to be consistent (in Chromium they are mapped to `100%` when used).

### Undefined Behaviour 

4) Viewport relative units: 
These include units like **vw, vh, vmin, vmax, svw, svh, lvw, lvh, dvw, dvh**.  These units/values depend on the viewport on where the element is defined. The specification does not explicitly mention what viewport with respect to which their values should be resolved.  

5) Intrinsic sizing keywords: 
These include keywords like **min-content, max-content, fit-content, stretch**. These units depend on CSS box model for their computation and hence their behavior is ambiguous for elements like `rect`, nested `svg` elements etc.  

6) Calculated values: 
These include functions like **calc(), min(), max(), clamp(), calc-size()**. Functions whose computation depends on absolute/relative units like calc(), min(),max(),clamp() their behaviour is consistent with their CSS counterparts like `div` element (in Chromium). However, functions like calc-size() that allow calculation on intrinsic units have the same ambiguous behaviour as units in (5).


One strategy we propose to handle the Undefined Behaviours:
**For Viewport units the viewport to be selected is the one made by SVG elements (as defined in specification https://svgwg.org/svg2-draft/coords.html#EstablishingANewSVGViewport).
For all other values (like min-content, stretch, calc-size()) where the resolution of values depends on CSS box model, we propose the value to be defaulted to 100% instead** in case of SVG elements.

We wanted expert's opinion on what should actually happen when undefined values of width and height CSS properties are applied on SVG elements. If possible, we also request a mapping of these values for the SVG elements to be updated in a specification so that other implementations could also follow the same behaviour.

Please give us your feedback on the above strategy that we are proposing.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12376 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 20 June 2025 14:11:29 UTC