W3C home > Mailing lists > Public > public-fxtf-archive@w3.org > November 2017

Re: [fxtf-drafts] filter should be defined to establish a containing block for fixed and absolutely positioned elements

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
Message-ID: <issue_comment.created-342677391-1510103589-sysbot+gh@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>
&lt;TabAtkins> Topic: Filter effects - filters should establish containing blocks for abspos and fixpos<br>
&lt;TabAtkins> TabAtkins: Filters are morally equivalent to opacity (or vice versa) and opacity establishes a cb, so what's wrong?<br>
&lt;TabAtkins> ericwilligers: People were using extensions to apply a filter ot the whole page, and they didn't want things to rearrange<br>
&lt;TabAtkins> TabAtkins: Ah, it would break fixpos in that case.<br>
&lt;smfr> TabAtkins: opacity creates stacking context, not contaiing block<br>
&lt;TabAtkins> ahhhh<br>
&lt;TabAtkins> TabAtkins: Right, I was thinking of stacking context; i don't have a strong opinion on cb<br>
&lt;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>
&lt;dbaron> github: https://github.com/w3c/fxtf-drafts/issues/11<br>
&lt;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>
&lt;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>
&lt;fantasai> TabAtkins: That doesn't apply to other filters<br>
&lt;fantasai> TabAtkins: tha'ts a reason for opacity to work different from other filters<br>
&lt;fantasai> TabAtkins: that is a reason for filters to make a containing block 'cuz awkward wherenot for opacity<br>
&lt;fantasai> TabAtkins: can special case root element to have filters apply to canvas<br>
&lt;fantasai> TabAtkins: since that's the compat issue<br>
&lt;fantasai> TabAtkins: and maybe also body<br>
&lt;myles> We are worried about web compat<br>
&lt;fantasai> TabAtkins: root has filter, fixedpos, and filters keep cb, then fixedpos is not fixedpos, it's abspos<br>
&lt;dbaron> blur then clip is different from clip then blur<br>
&lt;fantasai> TabAtkins: Filters create a containing block for fixedpos<br>
&lt;fantasai> TabAtkins: turn them into abspos<br>
&lt;fantasai> TabAtkins: opacity doesn't have this problem much, so doesn't need to do this<br>
&lt;Rossen> +1 to myles<br>
&lt;fantasai> TabAtkins: Are you worried aobu tmore than just filter on body?<br>
&lt;fantasai> myles: yes<br>
&lt;fantasai> TabAtkins: You get weird results, as dbaron points out<br>
&lt;fantasai> TabAtkins: Blur followed by clip is very different than clip then blur<br>
&lt;fantasai> TabAtkins: fixedpos figuring out what that menas is weird<br>
&lt;fantasai> TabAtkins: what do you do now?<br>
&lt;fantasai> myles: I don't know<br>
&lt;smfr> we’re kinda broken<br>
&lt;smfr> :)<br>
&lt;dbaron> I think Gecko has been shipping this for a while<br>
&lt;smfr> not sure if bugs or fundamental problems with implememtation<br>
&lt;fantasai> Rossen: fixe,d everyone expects to behave a certain way<br>
&lt;fantasai> Rossen: If you have a filte on a nelement you expet an effect<br>
&lt;fantasai> Rossen: want to trap abspos things so they filter applies to them as well<br>
&lt;dbaron> we did get a small number of bug reports when we shipped it, I think<br>
&lt;fantasai> Rossen: but for fixed, not so much<br>
&lt;dbaron> although at least some of them were due to bugs in what we initially shipped<br>
&lt;fantasai> TabAtkins: Shoudl fixedpos be blurred or not blurred?<br>
&lt;fantasai> Rossen: Should not be<br>
&lt;fantasai> TabAtkins: OK, that's an entirely diferent solution<br>
&lt;fantasai> tienr-ren: Does that mean fixedpos escapes stacking context?<br>
&lt;fantasai> ... including Opacity and CSS Mask stackign context?<br>
&lt;fantasai> ... Does it still follow z-index stacking order?<br>
&lt;fantasai> Rossen: Of course<br>
&lt;fantasai> TabAtkins: We already have these same cases addressed<br>
&lt;fantasai> TabAtkins: So we should change everything in lockstep<br>
&lt;TabAtkins> fantasai: The reason we did this for transforms is we need to find the staticpos<br>
&lt;TabAtkins> fantasai: But for filters, nothing's moving...<br>
&lt;TabAtkins> TabAtkins: Sure can - displacement filter<br>
&lt;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>
&lt;fantasai> TabAtkins: but then can't apply the filter<br>
&lt;fantasai> fantasai: That seems reasonable<br>
&lt;fantasai> TabAtkins: But it's different from other things<br>
&lt;fantasai> fantasai: I'm not really convinced that any of these should trap fixedpos...<br>
&lt;fantasai> TabAtkins: yeah but that's what ppl implemented so now we're stuck with it<br>
&lt;fantasai> Rossen: So proposed resolution is apply both containing block for and abspos on filters as well as stacking context<br>
&lt;TabAtkins> Rossen: Now that we've caught up, the proposed resolution is to make filters apply a cb to abspos and fixpos<br>
&lt;TabAtkins> Rossen: Second is potentially add a quirk for the root containing block to not trap fixpos<br>
&lt;fantasai> Rossen: and other is add a quirk for root containing block, where fixed positioes remain fixed rather than turning into abspos<br>
&lt;fantasai> Rossen: can take in order or together<br>
&lt;fantasai> TabAtkins: Think we need to take them together<br>
&lt;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>
&lt;dbaron> fwiw, the group already resolved to do this, it just never got edited into the spec...<br>
&lt;fantasai> Tien-Ren: Do we have to do this on body or just root?<br>
&lt;fantasai> fantasai: Please not on body, it's so terrible<br>
&lt;fantasai> TabAtkins: Depends on web-compat<br>
&lt;fantasai> Tien-Ren: describes some horrible thing that happens with style-stealing from body<br>
&lt;fantasai> TabAtkins: Yes, I would prefer root only if possible<br>
&lt;fantasai> Rossen: dbaron kindly reminds us that we resolved on all of this and we just need to edit<br>
&lt;TabAtkins> proposed: follow the existing resolution, add a quirk for filters on the root element to not trap fixpos<br>
&lt;TabAtkins> RESOLVED: follow the existing resolution, add a quirk for filters on the root element to not trap fixpos<br>

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

This archive was generated by hypermail 2.3.1 : Tuesday, 20 November 2018 00:45:59 UTC