filter should be defined to establish a containing block for fixed and absolutely positioned elements

[dbaron]

As resolved in http://www.w3.org/2015/02/10-fx-minutes.html#action02 and mentioned in the introduction to the spec, 'filter' not 'none' should create a containing block for absolutely and fixed positioned elements.

(Per https://lists.w3.org/Archives/Public/public-fx/2015OctDec/0035.html I think we should explicitly state that it also applies to absolutely positioned elements, and not just assume the reader can infer that absolute implies fixed as well, since nothing says that.)

[dholbert]

CC @erikdahlstrom @dirkschulze can we get this addressed?

[chrishtr]

I'm concerned that this will make it impossible to apply a filter (e.g., for accessibility to change the color) to an entire webpage without messing up fixed-position elements. This is because there is no HTML
element exposed to the developer which is the containing block for fixed-position elements.

[mstange]

That is true and a bit unfortunate.

In browsers that support backdrop-filter, you can put a fixed element on top of everything (with pointer-events: none) and apply the filter you want as that element's backdrop filter. But that's more a workaround than a true solution.

A better solution would be the ability to set the filter directly on the containing block for fixe-position elements. I don't know how you would expose that.

[richschwer]

I may have misunderstood your comment, but, aria-hidden only hides the container and its descendants from an AT (screen reader/screen magnifier, etc.) and it does not impact the visibility of the element or its descendants.
 
Rich Schwerdtfeger
 
 
----- Original message -----From: chrishtr [email protected]: w3c/fxtf-drafts [email protected]:Subject: Re: [w3c/fxtf-drafts] filter should be defined to establish a containing block for fixed and absolutely positioned elements (#11)Date: Wed, Nov 2, 2016 1:04 PM 
I'm concerned that this will make it impossible to apply a filter (e.g., for accessibility to change the color) to an entire webpage without messing up fixed-position elements. This is because there is no HTMLelement exposed to the developer which is the containing block for fixed-position elements.
—You are receiving this because you are subscribed to this thread.Reply to this email directly, view it on GitHub, or mute the thread.

 

[chrishtr]

My comment was not about aria. It was about losing the ability to provide a color or other filter extension
for web pages, without causing the page to display fixed-position elements incorrectly.

[mstange]

The only other idea I have for addressing that case is: We could make filter on the root element special, similar to what we do for overflow and background, and make it always propagate up to the containing block for position:fixed elements.

[bzbarsky]

@dirkschulze @erikdahlstrom any chance of this spec getting updated per the resolution mentioned above?

[chrishtr]

If there is consensus, I'd like to try to make this change in Chrome.

[bzbarsky]

Note that Firefox has been shipping this behavior for a while now, as I understand, since that was what the working group resolved...

[css-meeting-bot]

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

The full IRC log of that discussion

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

[mstange]

@dbaron, can you clarify the resolution? If you set a blur filter on the root element, should fixpos elements be blurred?

[mstange]

Also, when I have an SVG filter applied to the root element which draws a green square at 100,100 using <feFlood flood-color="lime" x="100" y="100" width="100" height="100"/>, should scrolling move the square? (The solution I proposed in #11 (comment) would not move the square.)

If the root element has a transparent background, should a filter on the root element apply to the default background color? (The default background color usually gets rendered behind the root stacking context; for example, mix-blend-mode blending does not blend with the default background color.)

[chrishtr]

It's also not so clear to me what "root element" means. Is that the <html> element?

[dholbert]

For an HTML document, yes -- but the behavior that Markus suggested (that we'd be mimicking here for filters) also involves the <body> element and the viewport. Here's the spec text for the behaviors that Markus was referencing for overflow and background, with more concrete definitions/explanations:
https://www.w3.org/TR/css-overflow-3/#overflow-propagation
https://www.w3.org/TR/css-backgrounds-3/#body-background

[EDIT: Sorry, I initially thought you were asking RE Markus's earlier suggestion about background/overflow, but now I see the autocollapsed CSSWG discussion, which seems to land on something more restrictive than Markus's suggestion.]

[upsuper]

I think the resolution was that, when a filter is applied to body (or the documentElement? This is one place which confused me in the meeting), the filter is instead applied to the viewport (so that fixed-pos elements would continue being fixed-pos rather than becoming absolutely-pos).

[dbaron]

I think the idea is that a filter on the root element (and maybe also the body) would:

• not change any containing blocks
• set the filter on the canvas rather than the root element's box (or body's box, if applied to body as well)

This would apply that position: fixed elements would be filtered by a filter on the root, but they'd also still be fixed rather than behaving like absolute as other position: fixed elements with an ancestor with filter would.

It's probably worth checking with some others with the discussion that they agree that was the intent.

[dbaron]

And I think it wouldn't filter the default background color, since if the document is transparent, then that default background color lives behind the document. But I'm not sure that concept is specified clearly.

[mstange]

I see, so the filter should be applied to the canvas, not to the viewport. Applying it on the canvas means that:

1. Scrolling the document will scroll the filter. This only makes a difference for filters that have position-dependent rendering, like <feFlood flood-color="lime" x="100" y="100" width="100" height="100"/>.
2. The scrollbars for the root scroll frame are not filtered. They exist outside the filter.
3. The root scroll frame's "scrollport clip" (i.e. the viewport minus scrollbars) applies to the filtered results, not to the contents of the filter.

I'm happy with this proposal. @chrishtr, what do you think?

[chrishtr]

That is fine with me too. Sorry for the delay.

[dirkschulze]

@mstange @dbaron @chrishtr @dholbert @bzbarsky To summarize: The CSS WG resolution stands: filters should establish containing blocks for abspos and fixpos with the exception of the root element (outermost root element in SVG terms).

The viewport is defined as a region and is no content itself nor does it describe a surface. The canvas is a (theoretically) infinite (unbound) drawing surface. We never filter regions but filters or filtered content might get clipped to regions. So I am not sure if the specification actually needs to differ between the filtered "canvas" or filtered "viewport".
In fact, I am not sure if we even need to reference the term "canvas". IMO all that is needed is the exception for: "The outermost document root element in the current document context."

• I am not sure if HTML/CSS has a term for "root" element that applies to SVG as well.
• document context is meant for embedded documents with <foreignObject>, <object>/<embed>, <frame> where the document root element is "within" those elements.

I welcome better prose proposal. :)

[chrishtr]

crbug.com/795549 tracks making this change in Chromium.

[vmpstr]

Just as clarification, our interpretation of the latest draft (including #263 ) is the following:

• Non-none filter value establishes a containing block for elements.
• The exception to this is the document element. In other words if the document element is filtered, the filter is applied after scroll and clip but before viewport scrollbars. This logic applies to all frames, including iframes.

This means that:

1. body is not treated any differently from any other non-document-element element.*
2. fixed position children of filtered document element do not scroll (ie, the same behavior as if the document element was not filtered).

* - @chrishtr and I discussed this and we believe that this is good behavior, which avoids a quirk in which document element "steals" body's filter.

[mstange]

That sounds correct to me, yes.

[dirkschulze]

@chrishtr Could you clarify?

This logic applies to all frames, including iframes.

It sounded like in your description, scrollbars should still get filtered for iframes, just not for the actual window scrollbars. Did I misunderstand this aspect?

[chrishtr]

It sounded like in your description, scrollbars should still get filtered for iframes, just not for the actual window scrollbars. Did I misunderstand this aspect?

I think it need not. If a filter is specified on the root element of an iframe (e.g. on its element) then we can skip filtering its scrollbars. I think this is consistent with the proposed algorithm I mentioned
earlier. Is there a problem I'm not seeing?

Also, making iframes consistent with main frames is good for platform consistency.

[css-meeting-bot]

The Working Group just discussed filter should be defined to establish a containing block for fixed and absolutely positioned elements.

The full IRC log of that discussion

<dael> Topic: filter should be defined to establish a containing block for fixed and absolutely positioned elements
<dael> github: https://github.com//issues/11#issuecomment-360240933
<dael> astearns: We discussed once before
<NegativeInfinity> yes but no mic working
<dael> astearns: Looks like krit and chris have been discussing. Are either on?
<NegativeInfinity> irc only
<dael> chris: I did discuss but not prepared to present
<dael> astearns: krit said he didn't have an opinion either
<dael> chris: It was Chris Harleson (sp?) contributing.
<dael> TabAtkins: I'll get him on the call next week.

[astearns]

@christr @dirkschulze Did the discussion on issue #282 last week cover this? #282 (comment)

Or do we still need to go over the PR for this issue?

[chrishtr]

We still need to go over this issue. It's different than the other one.

[css-meeting-bot]

The Working Group just discussed Containing block of filter, plus effect when applied to the root element.

The full IRC log of that discussion

<dael> Topic: Containing block of filter, plus effect when applied to the root element
<dael> github: https://github.com//issues/11#issuecomment-360240933
<dael> chrish: I believe we skipped this last week because dbaron wasn't there. Is that correct?
<dael> astearns: It was because you weren't. If we have you and krit we can discuss
<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
<dael> chrishtr: Example is applying an a11y filter on entire webpage and you don't want that to break fixedpos, just be more readable.
<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.
<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.
<dael> chrishtr: Any feedback on this?
<dael> smfr: Sounds fine. I thinkt hat means the filte ron the root prop to the canvas
<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
<dael> bradk: Don't quite understand the scrollbar comment.
<dael> chrishtr: Only root scrollbars of the frame. Scrollbars of root frame would never be able to eb filtered
<dael> bradk: Why is that bad compared to other scrollbars?
<dael> bradk: Would ti be good if I'm reversing screen?
<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.
<dael> rbyers: No strong feeling, but seems odd.
<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
<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?
<dael> chrishtr: Unless it's on the root of the page. Proposal is in addition w apply filter after scrolla nd clip
<dael> Rossen_: Initial containing block in this case?
<dael> chrishtr: I don't think it's changed.
<astearns> PR under discussion: https://github.com//pull/263/files
<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.
<dael> chrishtr: I dont think this changes containing blocks, just order in which things apply.
<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.
<dael> smfr: I don't think that's true
<dael> smfr: It's only if filter is on the root
<dael> fantasai: Yeah.
<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
<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
<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.
<dael> chrishtr: WG already resolved ot make filter a containing block except for on root.
<dael> krit: And it's in the spec.
<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
<dael> fantasai: Does clipping clip abspos element whose ancestor is a container?
<dael> chrishtr: Follows containing block chair. ANd that's the problem. That's what leads to these obnoxious cases
<Rossen_> s/post and you have opacity it would trap/pos and opacity for example is a containing block but not for fixed/
<TabAtkins> <relpos><clip><abspos/></clip></relpos>
<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?
<Rossen_> s/blocka nd/block and/
<dael> chrishtr: Then clip:rect will clip. Or clip path
<dael> fantasai: But if I say overflow:hidden no clip?
<dael> chrishtr: Correct.
<dael> fantasai: Seems weird.
<dael> chrishtr: Containing blocka nd overflow clip and scroll are weird and unfortunate.
<dael> smfr: That's a fundimental design mistake with CSS
<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
<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.
<dael> chrishtr: yep
<dael> fantasai: Random set of properties that effect look of something in a subtle way, but these ones effect layout.
<dael> chrishtr: Yep. consiquence that they apply to whole subtree but containng block is defined elsewhere
<dael> smfr: How does this work with opacity?
<dael> chrishtr: It doesn't effect px so it can be special cased.
<dael> fantasai: Why can't filter applyt containing block chain and not subtree? Wouldn't that solve it?
<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.
<dael> chrishtr: THe WG resolved the thing o nthe containing block. Best not to re-litegate.
<dael> Rossen_: We resolve and revisit. So that we resolved doesn't mean we can't rediscuss.
<dael> chrishtr: Okay
<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
<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.
<dael> chrishtr: If you want filter to apply to fixedpos descendents you need to define how that works.
<dael> fantasai: And in a large part of cases without fixed pos it'll be strange and unexpected.
<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.
<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
<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.
<dael> fantasai: That is what I'd expect
<dael> TabAtkins: It's impossible to do in a reasonable way
<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.
<fantasai> s/per/perf/
<dael> smfr: It's important to try and define filter for the way you want [missed]
<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.
<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.
<dael> fantasai: As an author that's what I would expect
<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.
<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.
<dael> chrishtr: I won't be there, but I'm okay with others talking at F2F
<dael> smfr: I won't be there
<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.
<dael> smfr: Sounds like [missed] not clarification
<fantasai> s/[missed]/like a complexification of the current rules/
<fantasai> s/clarification/simplification/
<dael> krit: Impl mostly do what spec says. It would be interweved on the page, not composited.
<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.
<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
<dael> chrishtr: Okay
<dael> astearns: Thanks for taking us through this chrishtr. We'll come back to this.

[astearns]

@chrishtr to save some time, could you add a comment here summarizing what you want the working group to resolve on?

[atanassov]

The issue is not ready for CSSWG discussion since we're waiting for use cases (as discussed on last call, see minutes above).

[chrishtr]

I'm going to close this issue in favor of #282. Going to post a complete proposed solution to all issues on that issue.

[Lonniebiz]

The spec need to make exception for filters that have nothing to do with size or positioning (color-based filters for example).

If I want to grayscale the entire page, why should that have any effect on absolute/fixed positioned descendants?

Take a look at this example:
https://stackoverflow.com/questions/62717289/

There, I'm trying to grayscale an entire webpage that contains a fixed positioned element. As soon as I apply the filter, it breaks the positioning (no longer allowing me to fix that element to the "Dead Center" of the page).

Shouldn't the type of filter be taking into consideration instead just assuming that all filters must sabotage fixed/absolute positioning? If a particular filter has nothing to do with size/positioning, then no descendants should be encapsulated with container-elements.

I'm very disappointed that the spec doesn't provide any granularity: all filters corrupt fix/absolute descendants, while that behavior should only be reserved for those certain filter-types that really can't work without that treatment.

A filter that only effects color, shouldn't bother descendant's position in any way!

[chrishtr]

The spec says that a filter on the HTML element does not break fixed position elements. In particular:

A value other than none for the filter property results in the creation of a containing block for absolute and fixed positioned descendants unless the element it applies to is a document root element in the current browsing context.

This behavior is implemented in at least Chromium and works correctly on this page (just tried it). This exception for the root element was made for the use case you described about fixed-position elements.

[Lonniebiz]

@chrishtr Those containing blocks do indeed break fixed/absolute positioned descendants and the root element exception that's working in Chromium, and not in Firefox, is not enough in my opinion.

On filters that modify color, and have no aspiration of modifying size or position, the containing blocks should not be created even if the target element is NOT root. I've submitted a separate issue here. The spec should impose the granularity of making the containing blocks conditional based on the type(s) of filters being applied and not just the non-granular all filters approach. Color related filters like grayscale and invert should not invoke the creation of containing blocks (even when applied to non-root elements).

For example, body { filter: grayscale(100%); }, should not cause the creation of containing blocks, even though the filter is being placed on body instead of :root. This should be the case on any element. #402

[chrishtr]

@chrishtr Those containing blocks do indeed break fixed/absolute positioned descendants and the root element exception that's working in Chromium, and not in Firefox, is not enough in my opinion.

The situation with Firefox (and Webkit most likely) it is just a browser bug that should be fixed.

On filters that modify color, and have no aspiration of modifying size or position, the containing blocks should not be created even if the target element is NOT root. I've submitted a separate issue here. The spec should impose the granularity of making the containing blocks conditional based on the type(s) of filters being applied and not just the non-granular all filters approach. Color related filters like grayscale and invert should not invoke the creation of containing blocks (even when applied to non-root elements).

It's not just size and position. Even filters that don't affect such things would have ill-defined behavior for non-contained elements, and make it significantly more difficult to implement hardware-accelerated rendering paths.

[emilio]

We should update the spec to reflect #11 (comment) I suspect. Blink and WebKit do filter the whole viewport.

[chrishtr]

@emilio: Do you mean the comment about the containing block thing not apply to the root element?

[emilio]

The only reference to this special case I see in the spec is:

A value other than none for the filter property results in the creation of a containing block for absolute and fixed positioned descendants unless the element it applies to is a document root element in the current browsing context. The list of functions are applied in the order provided.

Which is not quite only what's going on. The actual behavior is a lot more subtle, as you need to also "lift" the filters from the root element box to the viewport (minus scrollbars), so that they apply to fixed pos elements, etc.

[chrishtr]

Which is not quite only what's going on. The actual behavior is a lot more subtle, as you need to also "lift" the filters from the root element box to the viewport (minus scrollbars), so that they apply to fixed pos elements, etc.

Oh, that part. I did add that to the compositing spec in this PR.