[css-transform] the used value for border-box

[CJKu]

The css-transforms spec[1] said:

For SVG elements without an associated CSS layout box, the used value for border-box is view-box

Compare to clip-path geometry box[2], the used value for border-box is fill-box. Is there any special reason that we want them fallback to different value?

[1] transform box
https://drafts.csswg.org/css-transforms/#transform-box

For SVG elements without an associated CSS layout box, the used value for border-box is view-box.
For elements with an associated CSS layout box, the used value for fill-box and view-box is border-box.

[2] clip-path geometry box
https://drafts.fxtf.org/css-masking-1/#the-clip-path

For SVG elements without associated CSS layout box, the used value for content-box, padding-box, border-box and margin-box is fill-box.
For elements with associated CSS layout box, the used value for fill-box, stroke-box and view-box is border-box.

[AmeliaBR]

I've been frustrated with these mis-matches myself, but after looking at it thoroughly myself, I ended up agreeing with the approach: in both cases, it works out as "if the specified value doesn't apply to the element, use the default behavior", where CSS and SVG rendering modes have different defaults.

Trying to logically match CSS boxes to SVG boxes is always going to cause problems, because they just don't match up. And also, not all boxes are available in each property.

[dbaron]

This should maybe be a duplicate of #857.

[fantasai]

Series of resolutions from Tokyo F2F:

• border-box is treated as stroke-box in SVG
• padding-box and content-box are treated as fill-box in SVG
• fill-box and stroke-box are treated as defined in fill-stroke module in CSS
• view-box is treated as border-box in CSS
• initial value is view-box

[AmeliaBR]

view-box is treated as border-box in CSS

Well that's one way around the problem of different defaults for transform-box, although it closes off the potential to allow transforms relative to the containing box in CSS. (But we have the extended motion/offset-path options for that.)

So will all boxes now be valid? The current spec only allows border-, fill- and view-box.

[fantasai]

I think we're staying with the set that's in the spec. :) The correspondances are as above.

[smfr]

Not sure if I should say that border-box maps to "stroke-box" for SVG elements, since we don't want to introduce a new value with that name in this spec and fill-and-stroke is still a draft. Should transforms-1 say that it border-box behaves like https://www.w3.org/TR/SVG2/coords.html#TermStrokeBoundingBox for SVG elements?

[smfr]

https://lists.w3.org/Archives/Public/www-style/2017May/0053.html

[dirkschulze]

CSS Masking 1 has the same definition as SVG2 in case CSS Masking develops faster: https://drafts.fxtf.org/css-masking-1/#compute-stroke-bounding-box

[dirkschulze]

@fantasai The definition for stroke-box and fill-box in CSS Fill and Stroke is incomplete in the sense it needs to be used in CSS Transforms. It only defines the boxes for SVG shapes and text in the SVG namespace but misses the other elements. That is why filter effects and masking use

For SVG elements without an associated CSS layout box

(An SVG element with an associated layout box is an element.)

Are those mappings supposed to be universal? CSS Masking uses different mappings dependent on the property. I need to check if those mappings defined in #999 (comment) would cause compatibility issues with existing content.