- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 20 Jun 2018 16:47:25 +0000
- To: public-fxtf-archive@w3.org
The Working Group just discussed `Containing block of filter, plus effect when applied to the root element`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: Containing block of filter, plus effect when applied to the root element<br> <dael> github: https://github.com/w3c/fxtf-drafts/issues/11#issuecomment-360240933<br> <dael> chrish: I believe we skipped this last week because dbaron wasn't there. Is that correct?<br> <dael> astearns: It was because you weren't. If we have you and krit we can discuss<br> <dael> chrishtr: We resolved in same issue to make filter containing block for all elements except when filter is on root. Reason for carve out is to avoid breaking fixed pos elemetns<br> <dael> chrishtr: Example is applying an a11y filter on entire webpage and you don't want that to break fixedpos, just be more readable.<br> <dael> chrishtr: as currently stands root element is nto the containing block for fixed pos elements. Means scroll of the fixed position element escapes the filter. Problem because in general it doesn't really make sense to have clips and scrolls escape filters because they can move pixels and it becomes strange or impossible to impl.<br> <dael> chrishtr: I proposed that filter on the root gets applied after scroll and clip but before scrollbars. Can still aplly filter to the whole page, but it will apply clip and scroll correctly and scrollbar is on top.<br> <dael> chrishtr: Any feedback on this?<br> <dael> smfr: Sounds fine. I thinkt hat means the filte ron the root prop to the canvas<br> <dael> chrishtr: Right, last week it was details of how it applies to the canvas and this is making sure it pushes up to canvas and not apply before scroll and clip<br> <dael> bradk: Don't quite understand the scrollbar comment.<br> <dael> chrishtr: Only root scrollbars of the frame. Scrollbars of root frame would never be able to eb filtered<br> <dael> bradk: Why is that bad compared to other scrollbars?<br> <dael> bradk: Would ti be good if I'm reversing screen?<br> <dael> chrishtr: In some use cases I don't think it is. Root of a UA thing the web page should effect. Scrollbars in page are an effect of the page. It's a gray area but makes sense to carve out.<br> <dael> rbyers: No strong feeling, but seems odd.<br> <dael> chrishtr: Applies to iframes as well. If you had it on the root of the iframe it wouldn't be filtered. I don't feel super strongly but it seems good to not let content mess up the root scrollbar of the page<br> <dael> Rossen_: I want to make sure I get proposal. currently filters will establish a stacking context as well as containing blocka nd being containing block for fixed pos?<br> <dael> chrishtr: Unless it's on the root of the page. Proposal is in addition w apply filter after scrolla nd clip<br> <dael> Rossen_: Initial containing block in this case?<br> <dael> chrishtr: I don't think it's changed.<br> <astearns> PR under discussion: https://github.com/w3c/fxtf-drafts/pull/263/files<br> <dael> Rossen_: Way we defined so far is this is the root containing block which in your description...that's what confuses me...currently if nothing becomes a containing block the initial one will be the containing block. IT's defined as it being the root cotnaining block. You're trying to reverse that which means to me something above containing block or I'm missing something.<br> <dael> chrishtr: I dont think this changes containing blocks, just order in which things apply.<br> <dael> fantasai: I'm trying to understand what we're doing. Seems changes are very aggressive and I don't understand why it's a good thing. THere's several things...first, we're making anything with a filter be acontaining block for abspos and fixedpos elements. And the filter is fixed for viewport in the same way as a background is fixed.<br> <dael> smfr: I don't think that's true<br> <dael> smfr: It's only if filter is on the root<br> <dael> fantasai: Yeah.<br> <dael> fantasai: So if I want a filter for the entire page and not this weird layered thing I can't do that. But that seems what I'd want most of the time. THe filter being a fixed thing that doesn't move it re-filters every time I scroll and the page could shimmer as I scroll. Seems weird<br> <dael> fantasai: Also don't understand why making it fixed pos containing block. I think we did that for transforms because figuring out static pos is confusing, but I don't know why doing that for filters<br> <dael> Rossen_: And more confusing because if you have filters become containing block for fixed post and you have opacity it would trap. This whole thing is kind of messy.<br> <dael> chrishtr: WG already resolved ot make filter a containing block except for on root.<br> <dael> krit: And it's in the spec.<br> <dael> chrishtr: This is an adjustment. 2nd, why should it be a containing block: Because otherwise the drawing algo to the screen is ill defined. Filter can move pixel and so can't commute with a clip. There's also a perf reason with compositing and GPU accl. THat's one of the main reasons transform is containing block<br> <dael> fantasai: Does clipping clip abspos element whose ancestor is a container?<br> <dael> chrishtr: Follows containing block chair. ANd that's the problem. That's what leads to these obnoxious cases<br> <Rossen_> s/post and you have opacity it would trap/pos and opacity for example is a containing block but not for fixed/<br> <TabAtkins> <relpos><clip><abspos/></clip></relpos><br> <dael> fantasai: I Have an element with clip applied. Inside element there is a child that's abspos and the containing block is an ancestor of the element with clip. If I use overflow then the abspos is not clipped. But if I use clip what happens?<br> <Rossen_> s/blocka nd/block and/<br> <dael> chrishtr: Then clip:rect will clip. Or clip path<br> <dael> fantasai: But if I say overflow:hidden no clip?<br> <dael> chrishtr: Correct.<br> <dael> fantasai: Seems weird.<br> <dael> chrishtr: Containing blocka nd overflow clip and scroll are weird and unfortunate.<br> <dael> smfr: That's a fundimental design mistake with CSS<br> <dael> chrishtr: And this discussion is a result of that. Making filter containing block is one of a series of changes we need to make it make sense<br> <dael> fantasai: My view is when I'm applying a graphical effect to an element I expect it to be everything in the element. Seems odd at a higher level. Fixed pos being effected seems odd to me. Seems weird that I want to apply a filter would change layout.<br> <dael> chrishtr: yep<br> <dael> fantasai: Random set of properties that effect look of something in a subtle way, but these ones effect layout.<br> <dael> chrishtr: Yep. consiquence that they apply to whole subtree but containng block is defined elsewhere<br> <dael> smfr: How does this work with opacity?<br> <dael> chrishtr: It doesn't effect px so it can be special cased.<br> <dael> fantasai: Why can't filter applyt containing block chain and not subtree? Wouldn't that solve it?<br> <dael> chrishtr: Leads to other problems. I wrote a bunch of design docs on ideas like that and it's just really difficult to resolve these issues. The contaning block thing is different then subtree for stacking context.<br> <dael> chrishtr: THe WG resolved the thing o nthe containing block. Best not to re-litegate.<br> <dael> Rossen_: We resolve and revisit. So that we resolved doesn't mean we can't rediscuss.<br> <dael> chrishtr: Okay<br> <dael> astearns: On the other hand since the thing under discussion depends on that resolutiona nd is required for that previous resolution we could resolve on this because it makes current spec consistent and then revisit containing block bit<br> <dael> krit: Even then there's do we want entire page with filter o jsut what's on the viewport. Has impact on things like blur.<br> <dael> chrishtr: If you want filter to apply to fixedpos descendents you need to define how that works.<br> <dael> fantasai: And in a large part of cases without fixed pos it'll be strange and unexpected.<br> <dael> fantasai: What kind of filters do people use? A whole bunch. Do you expect recalc as yous scroll? Page will shift as you scroll. WHen I look at a page and it's a thing I expect it to be a static thing that shifts under viewport. With a filter it doesn't do that.<br> <dael> chrishtr: An invert filter. You won't be able to tell. Only a blur where you can see. Blur is the problematic and is illdeefined otherwise<br> <dael> TabAtkins: For blur to do what you want fantasai you have to render the entire page to a texture and then clip what's in your viewport. THat's untennitable.<br> <dael> fantasai: That is what I'd expect<br> <dael> TabAtkins: It's impossible to do in a reasonable way<br> <dael> fantasai: If you define root to not do that then authors who don't want shimmer as you scroll they'll apply to the descendant of the root and you're in the same place for per.<br> <fantasai> s/per/perf/<br> <dael> smfr: It's important to try and define filter for the way you want [missed]<br> <dael> chrishtr: Suppose you apply scroll after blur, what does that mean? A filter is applied atomically to a texture. Then you have two textures, one for fixed and one for not. For me it's not perf, it also leads to simpler compositing algo.<br> <dael> fantasai: If I had fixed pos elements on my page and I decided to blur the entire page I would expect that the entire page, everything under fixed pos, would be blurred all at once. If you imaging viewport as a cutour in a cardboard and the paper is under as you movet he cardboard it's all blurred. And the fixed position things on the cardboard I would have applied the blur. If there was a red boarder at the top of the footer it would bleed over the page.<br> <dael> fantasai: As an author that's what I would expect<br> <dael> chrishtr: The problem is fixed pos content isn't fully separated because containing block and stacking context aren't related. z index and interwave with rest of page.<br> <dael> krit: I'm not sure we're getting to a conclusion. Should we discuss at Sydney F2F? I dont' be there but maybe all parties discussing.<br> <dael> chrishtr: I won't be there, but I'm okay with others talking at F2F<br> <dael> smfr: I won't be there<br> <dael> fantasai: I'd rather get common cases to work and if necessary change how we do stacking rather then do something that's not what people expect to preserve current rules of stacking context.<br> <dael> smfr: Sounds like [missed] not clarification<br> <fantasai> s/[missed]/like a complexification of the current rules/<br> <fantasai> s/clarification/simplification/<br> <dael> krit: Impl mostly do what spec says. It would be interweved on the page, not composited.<br> <dael> fantasai: I haven't looked at stacking context rules in details. Yes they're interweved, but how many pages do that? not meany. You can say if there's a filter on the root we don't interweave anymore. Most pages won't see that but then you can have the filters applied in the way authors would expect.<br> <dael> astearns: I suggest we take discussion back to github and bring up use cases. We've talked generally about kinds of pages authors would want, but concrete examples would be helpful. Of fixed pos and interweaving. Have thos in mind as we come to discuss again<br> <dael> chrishtr: Okay<br> <dael> astearns: Thanks for taking us through this chrishtr. We'll come back to this.<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-398819083 using your GitHub account
Received on Wednesday, 20 June 2018 16:47:28 UTC