[css-sizing-3][css-values-4] Define width and height CSS values for SVG Elements in a mapping #12376
Description
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 that now allows width and height CSS properties to now be applied on nested svg elements. During the discussion, it was brought 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
-
Absolute units:
These include units like px, pt, pc, cm, mm, in. Absolute values are defined in the specification. -
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). -
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). Other values like initial, revert, unset etc. are not mentioned but their behaviour seems to be consistent (in Chromium they are mapped to100%when used).
Undefined Behaviour
-
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 clearly specify the viewport relative to which the values should be resolved. -
Intrinsic sizing keywords:
These include keywords like min-content, max-content, fit-content. These units depend on CSS box model for their computation and hence their behavior is ambiguous for elements likerect, nestedsvgelements etc. -
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 likedivelement (in Chromium). However, functions like calc-size() that allow calculation on intrinsic units have the same ambiguous behaviour as units in (5).
Proposal For Undefined Behaviour
Viewport-units like vh, vw etc should be resolved against the Initial Containing Block (ICB) if available, otherwise they should be resolved against the browser viewport.
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 auto in the case of SVG elements.
We want opinion on the above proposal. If possible, we also request a mapping of all possible values of width and height CSS properties for the SVG elements to be updated in a specification so that other implementations could also follow the same behaviour.