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

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

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Thu, 06 Jun 2019 18:44:48 +0000
To: public-fxtf-archive@w3.org
Message-ID: <issue_comment.created-499618850-1559846687-sysbot+gh@w3.org>
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

This archive was generated by hypermail 2.3.1 : Thursday, 6 June 2019 18:44:50 UTC