- From: Amelia Bellamy-Royds via GitHub <sysbot+gh@w3.org>
- Date: Mon, 18 Mar 2019 20:01:32 +0000
- To: public-fxtf-archive@w3.org
> I would actually argue that the bounding box should be calculated assuming a non-dashing stroke. And that's currently specified in both algorithms for calculating it: [in CSS masking](https://drafts.fxtf.org/css-masking-1/#compute-stroke-bounding-box), and [in SVG 2](https://svgwg.org/svg2-draft/coords.html#BoundingBoxes). Where the two algorithms differ is in how they handle mitered corners and line caps. The SVG 2 algorithm uses the actual stroke shape for painting (assuming no dashing), while the CSS Masking algorithm (which explicitly warns that it may be overridden by SVG 2) uses a set of heuristics that add on a little bit extra to the stroke bounding box for `path`, `polygon` and `polyline` based on the value of the line join/cap properties, without actually checking for whether those properties cause the stroke to extend outside the box by (object bounding box + 1/2 stroke width padding). If we're using the actual stroke shape, then maybe it makes sense to use the shape as painted, with vector effects included. (But that still creates complications of translating that shape back into the current coordinate system.) If we're using the heuristics, then definitely keep it simple. Has anyone actually implemented any of these algorithms for properties that use a `stroke-box` value? -- GitHub Notification of comment by AmeliaBR Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/279#issuecomment-474078169 using your GitHub account
Received on Monday, 18 March 2019 20:01:34 UTC