W3C home > Mailing lists > Public > public-fxtf-archive@w3.org > March 2019

Re: [fxtf-drafts] [css-masking-1] stroke-bounding-box and non-scaling-stroke (#279)

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
Message-ID: <issue_comment.created-474078169-1552939290-sysbot+gh@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

This archive was generated by hypermail 2.3.1 : Monday, 18 March 2019 20:01:34 UTC