- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 08 Nov 2017 01:13:10 +0000
- To: public-fxtf-archive@w3.org
The Working Group just discussed `Filter effects - filters should establish containing blocks for abspos and fixpos`, and agreed to the following resolutions: * `RESOLVED: follow the existing resolution, add a quirk for filters on the root element to not trap fixpos` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: Filter effects - filters should establish containing blocks for abspos and fixpos<br> <TabAtkins> TabAtkins: Filters are morally equivalent to opacity (or vice versa) and opacity establishes a cb, so what's wrong?<br> <TabAtkins> ericwilligers: People were using extensions to apply a filter ot the whole page, and they didn't want things to rearrange<br> <TabAtkins> TabAtkins: Ah, it would break fixpos in that case.<br> <smfr> TabAtkins: opacity creates stacking context, not contaiing block<br> <TabAtkins> ahhhh<br> <TabAtkins> TabAtkins: Right, I was thinking of stacking context; i don't have a strong opinion on cb<br> <TabAtkins> TabAtkins: So my position is just: opacity is a filter, we need a very good reason to make filter and opacity work differently in any regard<br> <dbaron> github: https://github.com/w3c/fxtf-drafts/issues/11<br> <dbaron> Perhaps it's worth reading the background in https://www.w3.org/2015/02/10-fx-minutes.html#item02 on the previous time this was resolved?<br> <fantasai> TabAtkins: In the linked details, roc gives an explanation for why opacity is different. It commutes with the clipping operation, whatever that means<br> <fantasai> TabAtkins: That doesn't apply to other filters<br> <fantasai> TabAtkins: tha'ts a reason for opacity to work different from other filters<br> <fantasai> TabAtkins: that is a reason for filters to make a containing block 'cuz awkward wherenot for opacity<br> <fantasai> TabAtkins: can special case root element to have filters apply to canvas<br> <fantasai> TabAtkins: since that's the compat issue<br> <fantasai> TabAtkins: and maybe also body<br> <myles> We are worried about web compat<br> <fantasai> TabAtkins: root has filter, fixedpos, and filters keep cb, then fixedpos is not fixedpos, it's abspos<br> <dbaron> blur then clip is different from clip then blur<br> <fantasai> TabAtkins: Filters create a containing block for fixedpos<br> <fantasai> TabAtkins: turn them into abspos<br> <fantasai> TabAtkins: opacity doesn't have this problem much, so doesn't need to do this<br> <Rossen> +1 to myles<br> <fantasai> TabAtkins: Are you worried aobu tmore than just filter on body?<br> <fantasai> myles: yes<br> <fantasai> TabAtkins: You get weird results, as dbaron points out<br> <fantasai> TabAtkins: Blur followed by clip is very different than clip then blur<br> <fantasai> TabAtkins: fixedpos figuring out what that menas is weird<br> <fantasai> TabAtkins: what do you do now?<br> <fantasai> myles: I don't know<br> <smfr> we’re kinda broken<br> <smfr> :)<br> <dbaron> I think Gecko has been shipping this for a while<br> <smfr> not sure if bugs or fundamental problems with implememtation<br> <fantasai> Rossen: fixe,d everyone expects to behave a certain way<br> <fantasai> Rossen: If you have a filte on a nelement you expet an effect<br> <fantasai> Rossen: want to trap abspos things so they filter applies to them as well<br> <dbaron> we did get a small number of bug reports when we shipped it, I think<br> <fantasai> Rossen: but for fixed, not so much<br> <dbaron> although at least some of them were due to bugs in what we initially shipped<br> <fantasai> TabAtkins: Shoudl fixedpos be blurred or not blurred?<br> <fantasai> Rossen: Should not be<br> <fantasai> TabAtkins: OK, that's an entirely diferent solution<br> <fantasai> tienr-ren: Does that mean fixedpos escapes stacking context?<br> <fantasai> ... including Opacity and CSS Mask stackign context?<br> <fantasai> ... Does it still follow z-index stacking order?<br> <fantasai> Rossen: Of course<br> <fantasai> TabAtkins: We already have these same cases addressed<br> <fantasai> TabAtkins: So we should change everything in lockstep<br> <TabAtkins> fantasai: The reason we did this for transforms is we need to find the staticpos<br> <TabAtkins> fantasai: But for filters, nothing's moving...<br> <TabAtkins> TabAtkins: Sure can - displacement filter<br> <TabAtkins> fantasai: You can have a fixpos in a scroll container, it escapes the container unless there's special trapping behavior there. Why would filters be different from that?<br> <fantasai> TabAtkins: but then can't apply the filter<br> <fantasai> fantasai: That seems reasonable<br> <fantasai> TabAtkins: But it's different from other things<br> <fantasai> fantasai: I'm not really convinced that any of these should trap fixedpos...<br> <fantasai> TabAtkins: yeah but that's what ppl implemented so now we're stuck with it<br> <fantasai> Rossen: So proposed resolution is apply both containing block for and abspos on filters as well as stacking context<br> <TabAtkins> Rossen: Now that we've caught up, the proposed resolution is to make filters apply a cb to abspos and fixpos<br> <TabAtkins> Rossen: Second is potentially add a quirk for the root containing block to not trap fixpos<br> <fantasai> Rossen: and other is add a quirk for root containing block, where fixed positioes remain fixed rather than turning into abspos<br> <fantasai> Rossen: can take in order or together<br> <fantasai> TabAtkins: Think we need to take them together<br> <fantasai> Rossen: So Filters establish stacking context as well as containing block for any positioned descendants except when they are apply to the root element, in which case they affect everthing<br> <dbaron> fwiw, the group already resolved to do this, it just never got edited into the spec...<br> <fantasai> Tien-Ren: Do we have to do this on body or just root?<br> <fantasai> fantasai: Please not on body, it's so terrible<br> <fantasai> TabAtkins: Depends on web-compat<br> <fantasai> Tien-Ren: describes some horrible thing that happens with style-stealing from body<br> <fantasai> TabAtkins: Yes, I would prefer root only if possible<br> <fantasai> Rossen: dbaron kindly reminds us that we resolved on all of this and we just need to edit<br> <TabAtkins> proposed: follow the existing resolution, add a quirk for filters on the root element to not trap fixpos<br> <TabAtkins> RESOLVED: follow the existing resolution, add a quirk for filters on the root element to not trap fixpos<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/11#issuecomment-342677391 using your GitHub account
Received on Wednesday, 8 November 2017 01:13:15 UTC