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