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 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.

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).

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). 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 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.