Re: [csswg-drafts] anything that creates a stacking context should sort in the positioned descendants z-ordering list

The Working Group just discussed `anything that creates a stacking context should sort in the positioned descendants z-ordering list`.

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: anything that creates a stacking context should sort in the positioned descendants z-ordering list<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/2717<br>
&lt;dael> dbaron: I think at this point it's calling attention to it rather then resolve<br>
&lt;dael> dbaron: Underlying issue is due to how we structured our specs we changed things relating to paining order and stacking context without patching this cnetral stuff.<br>
&lt;dael> dbaron: I proposed that everything that creates a stacking context paints where css 2.1 paints<br>
&lt;fantasai> dbaron++++++++<br>
&lt;dael> dbaron: I tried to create test cases. Lots of non-interop. Underlying principle seems entirely followed by chrome and webkit. Mostly followed by gecko. Edge might be futher, but might be due to bug. Cases where gecko didn't follow is when an impl literally followed spec and did nothing else and got different.<br>
&lt;dael> dbaron: Other thing worth discussing is if people agree anythign creates a stacking context should cause something painted as a descendant.<br>
&lt;fantasai> dbaron, makes sense to me<br>
&lt;dael> TabAtkins: I think Chris H. would be in favor of it. I'll ping him into the thread.<br>
&lt;dael> dbaron: Chrome follows the principle exactly I think<br>
&lt;dael> dbaron: I wrote a comment in the issue with the exceptions. chrome and webkit are eq.<br>
&lt;dael> dbaron: When you start looking at which properties are supposed to create stacking context there's lack of interop<br>
&lt;astearns> it's @chrishtr<br>
&lt;dael> florian: Suggestion is patch css 2 for more generic worded statement?<br>
&lt;dael> dbaron: Part of it is css 2 needs to introduce terms other specs can add. It says positioned element. We need a term...I thought it's in the issue...I didn't propose a name. But we need a term.<br>
&lt;dael> florian: Other terms?<br>
&lt;dael> dbaron: We need a second that's for elements that create a stacking context and become a containing block. Since that doesn't exist in L2 it could be introduced in an L3 spec<br>
&lt;dael> Rossen: I looked briefly a couple weeks ago. Thought at the time is...we have opacity which is a stacking context but not containing block. display:fixed which is stacking not containing. We have transforms that are stacking and containing blocks including fixed.<br>
&lt;dael> Rossen: Is that what you're proposing to add...alll of this?<br>
&lt;dbaron> https://dbaron.org/css/test/2018/stacking-context-z-order<br>
&lt;dael> dbaron: There's other pieces<br>
&lt;dael> dbaron: In the big test case ^ there's a lot of details<br>
&lt;gsnedders> dbaron: or in 2.2, surely?<br>
&lt;dael> dbaron: Things I think are supposed to...everything on the left except red background should create stacking. Things with green box I think also create containing block for fixed pos.<br>
&lt;dael> dbaron: Based on current spec and current resolutions that aren't yet edited in<br>
&lt;dael> Rossen: This is a really good summary of all the different combinations which I had not seen. Sorry. I want to go over this and make sure we can cross our t and dot our i.<br>
&lt;dael> dbaron: I think if anything I might want resolution on general principle we'd like to make them eq if we can get away with it, stacking context and position descendants layer. fixed pos is only somethings definitely.<br>
&lt;dael> dbaron: But totally fine taking time<br>
&lt;dael> dbaron: I tried to make a list of bugs at the bottom<br>
&lt;dael> Rossen: Other thing that I don't see in write up or matrix is there are...also the discussion about body and html in the root and filter on html or body would behave<br>
&lt;dael> dbaron: I think we had sep. resolution on that<br>
&lt;dael> Rossen: filter should effect scrolling for viewport or not for example?<br>
&lt;dael> dbaron: I rememebr we discussed that for filter or mask. I'd like to keep root stuff sep.<br>
&lt;dael> Rossen: That's fine. When it comes to, especially the fixed containing box drama would be great. And that's where all the root and body and filter drama comes into play<br>
&lt;dael> Rossen: Without considering the reverse style propagation it's hard.<br>
&lt;dbaron> we had some discussion about filter and body/root in https://github.com/w3c/fxtf-drafts/issues/11<br>
&lt;dael> dbaron: I'll link to another issue where we discussed that, I think<br>
&lt;dael> astearns: Sounds like we all need to look more and come back to see if we can resolve. It'd like to in part to get these tests into wpt<br>
&lt;dael> Rossen: Want to make sure we'll cast a wide net and put this to rest.<br>
&lt;dael> astearns: Right<br>
&lt;dael> astearns: Anything more to discuss this week?<br>
&lt;dael> dbaron: I'm fine with later.<br>
&lt;dael> astearns: Maybe a F2F<br>
&lt;dael> Rossen: One more to add, filter opacity vs. opacity does the right thing per spec.<br>
&lt;dael> dbaron: Yeah. I just picked a random filter for my test, but yes.<br>
&lt;dael> Rossen: Reason why is this on we've had confusion where people expect opacity and filter opacity behave the same and it doesn't for fixed pos.<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/2717#issuecomment-395249977 using your GitHub account

Received on Wednesday, 6 June 2018 23:57:16 UTC