- From: Amelia Bellamy-Royds via GitHub <sysbot+gh@w3.org>
- Date: Thu, 20 Apr 2017 03:37:08 +0000
- To: public-css-archive@w3.org
To clarify "the current border-box/view-box dual behavior" mean that SVG and CSS layout boxes have different elements? I see on #895 there is a resolution against entrenching the Blink/WebKit "dual behavior" of a different sort, where % values use a different reference box than length values. For SVG versus CSS, I don't see a reason for `auto` the better way to address the issue is via user-agent styles, as discussed in #928. I can't imagine an author intentionally setting the same transformation on both SVG and CSS layout elements, and yet want different reference boxes for each. ________________ As for generally creating a mapping for CSS layout boxes to fallback to SVG layout boxes, and vice versa, I'm fine with that so long as it is consistent across all properties. To make that work for many properties either means expanding the number of allowed values so that the reference box equivalents exist, or defining a separate set of property-specific fallbacks. And for interest, my preferred equivalents are as follows: - view-box : positioning containment box (whatever would be used for % in width & height) - decorated-box : margin-box - stroke-box : border-box - fill-box : content-box That leaves `padding-box` without a match. I'd say it should also fallback to `fill-box` (but `fill-box` would fall back to `content-box`). For reference: [Definitions of the SVG boxes are here](https://www.w3.org/TR/SVG2/coords.html#BoundingBoxes). PS, This discussion should probably be in a separate issue. Not sure if one already exists, or if it needs to be created. -- GitHub Notification of comment by AmeliaBR Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/857#issuecomment-295567272 using your GitHub account
Received on Thursday, 20 April 2017 03:37:14 UTC