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: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Mon, 25 Mar 2019 20:27:59 +0000
To: public-fxtf-archive@w3.org
Message-ID: <issue_comment.created-476364115-1553545678-sysbot+gh@w3.org>
The SVG Working Group just discussed `[css-masking-1] stroke-bounding-box and non-scaling-stroke`, and agreed to the following:

* `RESOLVED: Desire to use the same heuristic as CSS masking, but modify it to make it apply equally to all shapes, and modify it to incorporate non-scaling stroke. Revisit this once we have specific text`

<details><summary>The full IRC log of that discussion</summary>
&lt;myles> Topic: [css-masking-1] stroke-bounding-box and non-scaling-stroke<br>
&lt;myles> GitHub: https://github.com/w3c/fxtf-drafts/issues/279<br>
&lt;myles> krit: We have the stroke bounding box and for various limitations in implementations and difficulties in rendering, masking is having some heuristics for the bounding box. These heuristics don't say anything about the non scaling stroke property. In some cases it makes it smaller, and in some bigger.<br>
&lt;myles> krit: So what happens? Does it affect the bounding box?<br>
&lt;myles> chris: It should take it into account. CSS masking allows SVG to override it, so this affects CSS. There's a question about dashing - it takes dashing into account, then the stroke bounding box will change depending on dashing, and the bounding box can change on every iteration from, so it should take all the largest possible stroke that could be painted, and it may not be the tightest box<br>
&lt;myles> krit: WebKit does use tight stroke bounding box at the moment.<br>
&lt;myles> chris: It does the tight boudning box including the dashing?<br>
&lt;myles> krit: yes<br>
&lt;myles> chris: That's correct. It's probably easier for implementors too<br>
&lt;myles> krit: It's expensive to compute.<br>
&lt;myles> krit: However, the difficulty is the differences between the implementations depending on how they compute it.<br>
&lt;myles> krit: That's why we need heuristics in the first place.<br>
&lt;myles> chris: Is that about miter limits?<br>
&lt;myles> krit: yes, mostly.<br>
&lt;myles> krit: I did a patch for WebKit to include it. It is possible to compute it correctly and include it into the heuristic. It can be done. I can put it in the spec.<br>
&lt;myles> chris: I don't think it affects very much. You work out what the width really is, and then proceed.<br>
&lt;myles> AmeliaBR: It becomes an issue if you have weird transforms. In the coordinate system for the shape, your stroke that is an even width line on the screen, it isn't even in the unevenly scaled coordinate system.<br>
&lt;myles> myles: You would implement it by computing it and passing it through a transform.<br>
&lt;myles> AmeliaBR: Yes. Figure out what the shape should be in the screen coordinate system, and stroke it there. But bbox needs to be in local coordinate system. So it needs to round-trip<br>
&lt;myles> krit: AmeliaBR, myles, should we integrate it?<br>
&lt;myles> AmeliaBR: Either make it really simple or really accurate. I don't like CSS masking because it's in-between. It has weird extra heuristics that complicate things that gives you weird results that aren't what you want. Let's keep it really simple that are the fill bounding box padded by half the stroke width, or let's be accurate.<br>
&lt;myles> krit: What about miter?<br>
&lt;myles> AmeliaBR: In CSS masking, you get a different stroke bounding box for a rectangle and for a polygon with the same corners as the rectange. That's unfortunate.<br>
&lt;myles> krit: We can make it consistent ... &lt;missed><br>
&lt;myles> AmeliaBR: The heuristic assumes there might be a sharp corner, but there might not be. They're rough approximations.<br>
&lt;myles> krit: I uploaded an image that the heuristic can be wrong, depending on the miter limit.<br>
&lt;myles> myles: what do authors want?<br>
&lt;myles> krit: Heuristics are for giving the same experience in every browser.<br>
&lt;myles> chris: The other thing is that the bbox should include all the stroke. If it includes more, that's probably okay<br>
&lt;myles> chris: but if it includes less, then that's worse.<br>
&lt;myles> chris: you typically want to apply a filter to that region or use that region for pointer events. If you missing some, that's visually intrusive.<br>
&lt;myles> myles: given we're already passing these paths through transforms, we should probably just do the right thing<br>
&lt;myles> krit: What is the "correct thing"? The tight stroke box without dashing?<br>
&lt;myles> myles: no opinion<br>
&lt;myles> myles: (about dashing)<br>
&lt;myles> krit: You want it to entirely contain, but in some examples, the heuristic can do bad things<br>
&lt;myles> AmeliaBR: My main concern is that you can end up changing the bounding box by changing a shape to a path. If we can address that, so we leave room for those miter corners even on a circle that never has miter corners, that would address the issue. I don't like the idea of convering a shape to a path and the bbox changes and now your effects are no longer aligned.<br>
&lt;myles> krit: So, you would rather prefer to have the red box than the correct one for non-rects and symbols?<br>
&lt;myles> AmeliaBR: yes<br>
&lt;myles> AmeliaBR: It's better to be overly generous. The main reason in the first place is authoring complaints that the default bounding box doesn't include the stroke (it's too small)<br>
&lt;myles> krit: Do people agree?<br>
&lt;myles> krit: chris?<br>
&lt;myles> chris: I'm fine with that.<br>
&lt;myles> krit: proposed resolution: Don't include non-scaling stroke in the bounding box<br>
&lt;myles> krit: proposed resolution: use the same heuristic regardless of what shape it is<br>
&lt;myles> krit: Let's start with the second one. Then we can do the first one and see if we can work out how to do it<br>
&lt;myles> AmeliaBR: Try to see if we can come up with a reasonable heuristic for incorporating non-scaling stroke<br>
&lt;myles> AmeliaBR: Proposed resolution: Use the same heuristic as CSS masking, but modify it to make it apply equally to all shapes, and modify it to incorporate non-scaling stroke<br>
&lt;myles> chris: and if we can't?<br>
&lt;myles> AmeliaBR: If we can't do anything useful, do nothing<br>
&lt;myles> chris: If we can't, we can err on the side of exactness<br>
&lt;myles> krit: I'll make a proposal.<br>
&lt;myles> AmeliaBR: "Use the same heuristic as CSS masking, but modify it to make it apply equally to all shapes, and modify it to incorporate non-scaling stroke" but make it clear we will revisit when we have proposed text<br>
&lt;myles> RESOLVED: Desire to use the same heuristic as CSS masking, but modify it to make it apply equally to all shapes, and modify it to incorporate non-scaling stroke. Revisit this once we have specific text<br>

GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/279#issuecomment-476364115 using your GitHub account
Received on Monday, 25 March 2019 20:28:01 UTC

This archive was generated by hypermail 2.3.1 : Monday, 25 March 2019 20:28:02 UTC