[svgwg] Define width and height CSS values for SVG Elements in a mapping in SVG specification (#984)

goldenboy777 has just created a new issue for https://github.com/w3c/svgwg:

== Define width and height CSS values for SVG Elements in a mapping in SVG specification ==
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).


We propose the following strategy to address Undefined Behaviors:

**For viewport units, the viewport to be selected should be the one created by SVG elements, as outlined in the specification https://svgwg.org/svg2-draft/coords.html#EstablishingANewSVGViewport.
For other values (such as min-content, stretch, calc-size()) where the resolution depends on the CSS box model, we recommend defaulting the value to 100% in the 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 the SVG specification so that other implementations could also follow the same behaviour.

Since the discussion is about CSS properties, we have also opened a csswg-draft issue https://github.com/w3c/csswg-drafts/issues/12376 to get more opinions, and opened this issue as a meaning of tracking the final agreed upon behaviour in the SVG specification.

Please view or discuss this issue at https://github.com/w3c/svgwg/issues/984 using your GitHub account


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

Received on Tuesday, 24 June 2025 14:27:53 UTC