Re: [fxtf-drafts] [filter-effects][css-masking][fill-stroke] clarify userSpaceOnUse / objectBoundingBox applied to non-SVG elements (#249)

The CSS Working Group just discussed `Clarify how userSpaceOnUse and objectBoundingBox apply to non-SVG elements`.

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> Topic: Clarify how userSpaceOnUse and objectBoundingBox apply to non-SVG elements<br>
&lt;astearns> github: https://github.com/w3c/fxtf-drafts/issues/249<br>
&lt;TabAtkins> AmeliaBR: Mega issue that affects everything in SVG graphical effects that we support applying to CSS boxes<br>
&lt;TabAtkins> AmeliaBR: svg effects (gradients, patterns, clips) have a switch for how they're scaled and positioned<br>
&lt;TabAtkins> AmeliaBR: So when you apply it to a rect, it can either be scaled to that rect, or to the svg as a whole so a gradient spreads smoothly across multiple rects, etc.<br>
&lt;TabAtkins> AmeliaBR: When we added the specs for applying masks/clip-paths/filters to CSS boxes, it was never defined how they map to CSS coordinate spaces<br>
&lt;TabAtkins> AmeliaBR: Actual impls are inconsistent<br>
&lt;TabAtkins> AmeliaBR: I periodically get bug reports about how this is supposed to work<br>
&lt;astearns> TabAtkins: roc had a proposal<br>
&lt;astearns> TabAtkins: both anchor position according to CSS coordinate space, (and some other stuff)<br>
&lt;astearns> TabAtkins: you at least get consistent sizing<br>
&lt;TabAtkins> AmeliaBR: Yes, that's tehe simplest approach that still has sensible results<br>
&lt;TabAtkins> AmeliaBR: So boxes are always the size of the css box<br>
&lt;dbaron> s/consistent sizing/consistent sizing, but don't have the ability to have multiple boxes with views into the same gradient/<br>
&lt;TabAtkins> AmeliaBR: And OBB, which assumes the effect is scaled 0->1 gets that, and USOU gets normal px measurements<br>
&lt;dbaron> (I think that's right?)<br>
&lt;dbaron> (Tab says it is)<br>
&lt;TabAtkins> AmeliaBR: Other possiblity is that you map USOU to the ICB (or nearest CB). Firefox does one of these, don't remember which CB.<br>
&lt;TabAtkins> AmeliaBR: This doesn't match roc's proposal.<br>
&lt;TabAtkins> AmeliaBR: So ncan we get more eyeballs on this? It prevents us from getting a reasonable spec on several of our fxtf specs.<br>
&lt;fantasai> ScribeNick: fantasai<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/249#issuecomment-499618850 using your GitHub account

Received on Thursday, 6 June 2019 18:44:50 UTC