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

Re: [fxtf-drafts] [filter-effects-2] Backdrop filters should not use BackgroundImage (#53)

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Thu, 06 Jun 2019 14:02:23 +0000
To: public-fxtf-archive@w3.org
Message-ID: <issue_comment.created-499506867-1559829741-sysbot+gh@w3.org>
The CSS Working Group just discussed `backdrop filter disagreement`.

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> Topic: backdrop filter disagreement<br>
&lt;TabAtkins> dbaron: My understanding is that there's disagreement between WK and Blink about how b-f should work<br>
&lt;TabAtkins> dbaron: previous state is that spec is kinda vague<br>
&lt;TabAtkins> dbaron: Current state is that blink engineers wrote a new spec that reflects their engine, and WK disagrees with this.<br>
&lt;TabAtkins> dbaron: a) if would be good to solve this to get with interop<br>
&lt;astearns> github: https://github.com/w3c/fxtf-drafts/issues/53<br>
&lt;TabAtkins> dbaron: b) we have a summer intern that should work on this<br>
&lt;TabAtkins> dbaron: If this is a viable project we need to tell this intern what to do<br>
&lt;TabAtkins> dbaron: I think part of teh problem is that we don't necessarily have the righ tpeople in the room<br>
&lt;fantasai> TabAtkins: Sounds like our objection is based on our technical architecture<br>
&lt;fantasai> TabAtkins: WebKit's is based on their technical architecture<br>
&lt;TabAtkins> mstange: I agree with Chrome's proposal entirely; there were some objections, they got addressed<br>
&lt;TabAtkins> mstange: Chrome's proposal is easier to implement and make smore sense to authors imo<br>
&lt;fantasai> TabAtkins^: y'all presumably also have a preference based on your technical architecture?<br>
&lt;TabAtkins> mstange: Other resolution from last time is that if Apple wants their impl in spec they have to write up how that works<br>
&lt;TabAtkins> hober: As far as I understand, Dino still has that action.<br>
&lt;fantasai> TabAtkins: Given questions we had on "how does it work" were "we're not sure"<br>
&lt;fantasai> TabAtkins: I can't in good conscience accept their proposal<br>
&lt;fantasai> TabAtkins: Right now we have a choice between "here's an explicit algorithm" and "we haven't described this yet"<br>
&lt;TabAtkins> dbaron: Having seen some of the discussion...<br>
&lt;TabAtkins> dbaron: I think WK was arguing their stuff is betteer fo rusers<br>
&lt;TabAtkins> dbaron: I think I'm sympathetic to that, looking at examples, but it does require details of how it acutally works<br>
&lt;TabAtkins> mstange: Stil important questions, like does it punch thru group opacity, etc<br>
&lt;TabAtkins> mstange: So in examples where you have opacity but not group opacity, those are simpler cases.<br>
&lt;Rossen_> q?<br>
&lt;TabAtkins> mstange: So putting in a special case into the spec that lets you punch thru opacity when it's not acting as group opacity, that's tricky. And letting it punch thru when it *is* group opacity, that's hard to predict.<br>
&lt;TabAtkins> AmeliaBR: So all we can resolve right now is that we need a clear description...?<br>
&lt;TabAtkins> Rossen_: That's where we left it last time.<br>
&lt;TabAtkins> dbaron: And Apple engineers should be aware that if they don't give details, we're probably defaulting to Chrome's implementation.<br>
&lt;TabAtkins> myles_: The technical burden of altering Core Animation to support Chirome's behavior is on the sam eorder of magnitude of altering CHrome's compositor to support our behavior.<br>
&lt;AmeliaBR> s/.../ of the disagreements between the implementations/<br>
&lt;TabAtkins> iank_: Par tof our reason for our architectur eis because we care about very low-end memory gpu classes<br>
&lt;TabAtkins> dbaron: So that's about it.<br>

GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/53#issuecomment-499506867 using your GitHub account
Received on Thursday, 6 June 2019 14:02:25 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:50:25 UTC