New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
dbaron opened this Issue Jun 27, 2016 · 47 comments

Comments

@dbaron
Member

dbaron commented Jun 27, 2016

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

This comment has been minimized.

Show comment
Hide comment
@dholbert

dholbert Oct 18, 2016

CC @erikdahlstrom @dirkschulze can we get this addressed?

dholbert commented Oct 18, 2016

CC @erikdahlstrom @dirkschulze can we get this addressed?

@chrishtr

This comment has been minimized.

Show comment
Hide comment
@chrishtr

chrishtr Nov 2, 2016

Contributor

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.

Contributor

chrishtr commented Nov 2, 2016

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

This comment has been minimized.

Show comment
Hide comment
@mstange

mstange Nov 2, 2016

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.

mstange commented Nov 2, 2016

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

This comment has been minimized.

Show comment
Hide comment
@richschwer

richschwer Nov 2, 2016

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 notifications@github.comTo: w3c/fxtf-drafts fxtf-drafts@noreply.github.comCc: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.

 

richschwer commented Nov 2, 2016

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 notifications@github.comTo: w3c/fxtf-drafts fxtf-drafts@noreply.github.comCc: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

This comment has been minimized.

Show comment
Hide comment
@chrishtr

chrishtr Nov 14, 2016

Contributor

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.

Contributor

chrishtr commented Nov 14, 2016

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

This comment has been minimized.

Show comment
Hide comment
@mstange

mstange Nov 14, 2016

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.

mstange commented Nov 14, 2016

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

This comment has been minimized.

Show comment
Hide comment
@bzbarsky

bzbarsky Apr 3, 2017

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

bzbarsky commented Apr 3, 2017

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

@chrishtr

This comment has been minimized.

Show comment
Hide comment
@chrishtr

chrishtr Apr 4, 2017

Contributor

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

Contributor

chrishtr commented Apr 4, 2017

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

@bzbarsky

This comment has been minimized.

Show comment
Hide comment
@bzbarsky

bzbarsky Apr 5, 2017

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

bzbarsky commented Apr 5, 2017

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

MXEBot pushed a commit to mirror/chromium that referenced this issue Apr 16, 2017

chrishtr Commit bot
Add a use-counter for viewport-fixed position:fixed under a filter
This will inform whether we can make the change suggested in
w3c/fxtf-drafts#11

BUG=711736
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2

Review-Url: https://codereview.chromium.org/2817583006
Cr-Commit-Position: refs/heads/master@{#464853}

GnorTech pushed a commit to nwjs/chromium.src that referenced this issue Apr 26, 2017

Chris Harrelson
Add a use-counter for viewport-fixed position:fixed under a filter
This will inform whether we can make the change suggested in
w3c/fxtf-drafts#11

BUG=711736
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2

Review-Url: https://codereview.chromium.org/2817583006
Cr-Commit-Position: refs/heads/master@{#464853}
(cherry picked from commit e208bf0)

Review-Url: https://codereview.chromium.org/2821943002 .
Cr-Commit-Position: refs/branch-heads/3071@{#14}
Cr-Branched-From: a106f0a-refs/heads/master@{#464641}
@css-meeting-bot

This comment has been minimized.

Show comment
Hide comment
@css-meeting-bot

css-meeting-bot Nov 8, 2017

Member

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/w3c/fxtf-drafts/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
Member

css-meeting-bot commented Nov 8, 2017

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/w3c/fxtf-drafts/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

This comment has been minimized.

Show comment
Hide comment
@mstange

mstange Nov 8, 2017

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

mstange commented Nov 8, 2017

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

@mstange

This comment has been minimized.

Show comment
Hide comment
@mstange

mstange Nov 8, 2017

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.)

mstange commented Nov 8, 2017

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

This comment has been minimized.

Show comment
Hide comment
@chrishtr

chrishtr Nov 8, 2017

Contributor

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

Contributor

chrishtr commented Nov 8, 2017

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

@dholbert

This comment has been minimized.

Show comment
Hide comment
@dholbert

dholbert Nov 8, 2017

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.]

dholbert commented Nov 8, 2017

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

This comment has been minimized.

Show comment
Hide comment
@upsuper

upsuper Nov 11, 2017

Member

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).

Member

upsuper commented Nov 11, 2017

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

This comment has been minimized.

Show comment
Hide comment
@dbaron

dbaron Nov 30, 2017

Member

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.

Member

dbaron commented Nov 30, 2017

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

This comment has been minimized.

Show comment
Hide comment
@dbaron

dbaron Nov 30, 2017

Member

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.

Member

dbaron commented Nov 30, 2017

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

This comment has been minimized.

Show comment
Hide comment
@mstange

mstange Dec 6, 2017

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?

mstange commented Dec 6, 2017

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

This comment has been minimized.

Show comment
Hide comment
@chrishtr

chrishtr Dec 14, 2017

Contributor

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

Contributor

chrishtr commented Dec 14, 2017

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

@dirkschulze

This comment has been minimized.

Show comment
Hide comment
@dirkschulze

dirkschulze Dec 15, 2017

Contributor

@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. :)

Contributor

dirkschulze commented Dec 15, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@chrishtr

chrishtr Dec 16, 2017

Contributor

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

Contributor

chrishtr commented Dec 16, 2017

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

ardalanamini pushed a commit to siliconjs/chromium that referenced this issue Dec 21, 2017

Chris Harrelson Commit Bot
Revert obsolete use counter.
It's obsolete because the CSSWG resolved to fix ths issue by special-casing
the root element. See w3c/fxtf-drafts#11

TBR=trchen

Bug: 711736
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: Ie17644b5d8d2fd8f34e97ee0803b26854ef0150d
Reviewed-on: https://chromium-review.googlesource.com/831399
Commit-Queue: Chris Harrelson <chrishtr@chromium.org>
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#525581}

dirkschulze added a commit that referenced this issue Dec 28, 2017

@dirkschulze

This comment has been minimized.

Show comment
Hide comment
@dirkschulze

dirkschulze Dec 28, 2017

Contributor

I added the requested change right below the filter property definition: https://drafts.fxtf.org/filter-effects-1/#FilterProperty

Please review the change and re-open this issue if it is not satisfying.

Contributor

dirkschulze commented Dec 28, 2017

I added the requested change right below the filter property definition: https://drafts.fxtf.org/filter-effects-1/#FilterProperty

Please review the change and re-open this issue if it is not satisfying.

@isiahmeadows

This comment has been minimized.

Show comment
Hide comment
@isiahmeadows

isiahmeadows Jan 6, 2018

@dirkschulze So what does that make of this Mozilla bug (that I filed thinking it was a program bug)? (Note: I'm more of a general web developer than a spec implementor.)

isiahmeadows commented Jan 6, 2018

@dirkschulze So what does that make of this Mozilla bug (that I filed thinking it was a program bug)? (Note: I'm more of a general web developer than a spec implementor.)

@dirkschulze

This comment has been minimized.

Show comment
Hide comment
@dirkschulze

dirkschulze Jan 6, 2018

Contributor

@isiahmeadows Filters create a containing block for descendants now. This means, the behavior of Firefox is following the spec with the edits from 4081eda . The filter behaves like transform now.

I should probably modify this sentence as clarification:

Any value other than none for the filter property causes the element to become a containing block, and the object acts as a containing block for fixed positioned descendants.

Just for completeness: filter also create a stacking context. The spec states that a couple paragraphs later.

Contributor

dirkschulze commented Jan 6, 2018

@isiahmeadows Filters create a containing block for descendants now. This means, the behavior of Firefox is following the spec with the edits from 4081eda . The filter behaves like transform now.

I should probably modify this sentence as clarification:

Any value other than none for the filter property causes the element to become a containing block, and the object acts as a containing block for fixed positioned descendants.

Just for completeness: filter also create a stacking context. The spec states that a couple paragraphs later.

@isiahmeadows

This comment has been minimized.

Show comment
Hide comment
@isiahmeadows

isiahmeadows Jan 6, 2018

@dirkschulze So, is there a way to access an element that's the global stacking context root? (As in, is :root it, or is it something else?)

isiahmeadows commented Jan 6, 2018

@dirkschulze So, is there a way to access an element that's the global stacking context root? (As in, is :root it, or is it something else?)

@isiahmeadows

This comment has been minimized.

Show comment
Hide comment
@isiahmeadows

isiahmeadows Jan 6, 2018

Note: this is relevant for any "night mode" extension writers, who generally work by applying a filter to the page.

isiahmeadows commented Jan 6, 2018

Note: this is relevant for any "night mode" extension writers, who generally work by applying a filter to the page.

@dirkschulze

This comment has been minimized.

Show comment
Hide comment
@dirkschulze

dirkschulze Jan 6, 2018

Contributor

@isiahmeadows As I understood the resolution (and it was changed in the spec to) it would be :root.

Contributor

dirkschulze commented Jan 6, 2018

@isiahmeadows As I understood the resolution (and it was changed in the spec to) it would be :root.

@chrishtr

This comment has been minimized.

Show comment
Hide comment
@chrishtr

chrishtr Jan 24, 2018

Contributor

@dbaron @mstange @dirkschulze
Update: Blink is now implementing the change.

Unfortunately I don't think the resolution described in comments on Nov 29 and Dec 6 (and reflected in the draft spec) are what is desired. I didn't read it carefully enough at the time, sorry about that. :(

From that resolution, one would conclude that root element that is filtered is not a containing block for any fixed-position elements. This is at odds with what I see as the core intent of the whole change, which
is to not have any element ever have a containing block chain which skips an ancestor filter.

Instead, the filter should apply to the viewport (in Blink/WebKit-speak, the LayoutView). Thus:

  1. The filter does not scroll with the content
  2. It is a containing block for every descendant, including fixed-position elements
  3. It applies to the clipped contents of the viewport
  4. It filters the root background color (perhaps this is optional though, if there are use-cases where it is really not desired)
  5. It does not apply to scrollbars (same as previous resolution)

In terms of order of conceptual operations for drawing the content to the screen, it would be:

a. Draw content under root scroll
b. Scroll (a)
c. Draw fixed-position content (not technically accurate here because of z-index, but anyway..)
d. Clip to viewport
e. Apply filter
f. Draw scrollbars

This new resolution also makes the root scroller behave the same as any other element with overflow:scroll, which is good for sanity of the platform.

Contributor

chrishtr commented Jan 24, 2018

@dbaron @mstange @dirkschulze
Update: Blink is now implementing the change.

Unfortunately I don't think the resolution described in comments on Nov 29 and Dec 6 (and reflected in the draft spec) are what is desired. I didn't read it carefully enough at the time, sorry about that. :(

From that resolution, one would conclude that root element that is filtered is not a containing block for any fixed-position elements. This is at odds with what I see as the core intent of the whole change, which
is to not have any element ever have a containing block chain which skips an ancestor filter.

Instead, the filter should apply to the viewport (in Blink/WebKit-speak, the LayoutView). Thus:

  1. The filter does not scroll with the content
  2. It is a containing block for every descendant, including fixed-position elements
  3. It applies to the clipped contents of the viewport
  4. It filters the root background color (perhaps this is optional though, if there are use-cases where it is really not desired)
  5. It does not apply to scrollbars (same as previous resolution)

In terms of order of conceptual operations for drawing the content to the screen, it would be:

a. Draw content under root scroll
b. Scroll (a)
c. Draw fixed-position content (not technically accurate here because of z-index, but anyway..)
d. Clip to viewport
e. Apply filter
f. Draw scrollbars

This new resolution also makes the root scroller behave the same as any other element with overflow:scroll, which is good for sanity of the platform.

@chrishtr

This comment has been minimized.

Show comment
Hide comment
@chrishtr

chrishtr Jan 24, 2018

Contributor

Note: for overflow:scroll elements, currently (f) is before (e) in at least Blink and Gecko, so scrollbars are actually filtered. Example:

data:text/html,<div style='width: 100px; height:100px; overflow:scroll; filter: blur(5px); background: lightgray'>
<div style='width: 50px; height:4000px; background: lightblue'>TEXT</div>
</div>
Contributor

chrishtr commented Jan 24, 2018

Note: for overflow:scroll elements, currently (f) is before (e) in at least Blink and Gecko, so scrollbars are actually filtered. Example:

data:text/html,<div style='width: 100px; height:100px; overflow:scroll; filter: blur(5px); background: lightgray'>
<div style='width: 50px; height:4000px; background: lightblue'>TEXT</div>
</div>
@chrishtr

This comment has been minimized.

Show comment
Hide comment
@chrishtr

chrishtr Jan 24, 2018

Contributor

Also, the current level 1 filter spec says that scrollbars of overflow-scroll elements should be filtered:

"Conceptually, any parts of the drawing are effected by filter operations. This includes any content, background, borders, text decoration, outline and visible scrolling mechanism of the element to which the filter is applied"

https://www.w3.org/TR/filter-effects-1/#FilterProperty

I can see how this is desirable, since developers may want to gray out a scroller when it is inactive
in the current view.

However, the root scrollbar of the webpage is special and should I think be considered something
under the control of the user agent, for accessibility reasons.

Contributor

chrishtr commented Jan 24, 2018

Also, the current level 1 filter spec says that scrollbars of overflow-scroll elements should be filtered:

"Conceptually, any parts of the drawing are effected by filter operations. This includes any content, background, borders, text decoration, outline and visible scrolling mechanism of the element to which the filter is applied"

https://www.w3.org/TR/filter-effects-1/#FilterProperty

I can see how this is desirable, since developers may want to gray out a scroller when it is inactive
in the current view.

However, the root scrollbar of the webpage is special and should I think be considered something
under the control of the user agent, for accessibility reasons.

@mstange

This comment has been minimized.

Show comment
Hide comment
@mstange

mstange Jan 24, 2018

I prefer your new proposal over what we decided on previously.

mstange commented Jan 24, 2018

I prefer your new proposal over what we decided on previously.

@dirkschulze

This comment has been minimized.

Show comment
Hide comment
@dirkschulze

dirkschulze Jan 25, 2018

Contributor

@chrishtr We are still talking about a filter applied to the root element and not to arbitrary elements? Asking specifically because of your "Clip to viewport" rule.

Contributor

dirkschulze commented Jan 25, 2018

@chrishtr We are still talking about a filter applied to the root element and not to arbitrary elements? Asking specifically because of your "Clip to viewport" rule.

@dirkschulze dirkschulze reopened this Jan 25, 2018

@chrishtr

This comment has been minimized.

Show comment
Hide comment
@chrishtr

chrishtr Jan 25, 2018

Contributor

Yes, just adjustment for root element.

Contributor

chrishtr commented Jan 25, 2018

Yes, just adjustment for root element.

@chrishtr

This comment has been minimized.

Show comment
Hide comment
@chrishtr

chrishtr Mar 8, 2018

Contributor

PR for this change:

#263

Contributor

chrishtr commented Mar 8, 2018

PR for this change:

#263

@chrishtr

This comment has been minimized.

Show comment
Hide comment
@chrishtr

chrishtr Apr 11, 2018

Contributor

Ping on this. Does the PR look ok? it's a one-sentence edit.

Contributor

chrishtr commented Apr 11, 2018

Ping on this. Does the PR look ok? it's a one-sentence edit.

@dirkschulze

This comment has been minimized.

Show comment
Hide comment
@dirkschulze

dirkschulze Apr 11, 2018

Contributor

@chrishtr Thanks for the PR. I'll put this on the agenda of the CSS WG.

Contributor

dirkschulze commented Apr 11, 2018

@chrishtr Thanks for the PR. I'll put this on the agenda of the CSS WG.

@vmpstr

This comment has been minimized.

Show comment
Hide comment
@vmpstr

vmpstr Apr 26, 2018

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.

vmpstr commented Apr 26, 2018

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

This comment has been minimized.

Show comment
Hide comment
@mstange

mstange Apr 26, 2018

That sounds correct to me, yes.

mstange commented Apr 26, 2018

That sounds correct to me, yes.

@dirkschulze

This comment has been minimized.

Show comment
Hide comment
@dirkschulze

dirkschulze Apr 27, 2018

Contributor

@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?

Contributor

dirkschulze commented Apr 27, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@chrishtr

chrishtr Apr 27, 2018

Contributor

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.

Contributor

chrishtr commented Apr 27, 2018

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

This comment has been minimized.

Show comment
Hide comment
@css-meeting-bot

css-meeting-bot Jun 6, 2018

Member

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/w3c/fxtf-drafts/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.
Member

css-meeting-bot commented Jun 6, 2018

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/w3c/fxtf-drafts/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

This comment has been minimized.

Show comment
Hide comment
@astearns

astearns Jun 18, 2018

Member

@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?

Member

astearns commented Jun 18, 2018

@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

This comment has been minimized.

Show comment
Hide comment
@chrishtr

chrishtr Jun 19, 2018

Contributor

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

Contributor

chrishtr commented Jun 19, 2018

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

@css-meeting-bot

This comment has been minimized.

Show comment
Hide comment
@css-meeting-bot

css-meeting-bot Jun 20, 2018

Member

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/w3c/fxtf-drafts/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/w3c/fxtf-drafts/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.
Member

css-meeting-bot commented Jun 20, 2018

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/w3c/fxtf-drafts/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/w3c/fxtf-drafts/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 astearns removed the Agenda+ label Jul 2, 2018

@chrishtr chrishtr added this to Backlog in High-priority issues via automation Jul 25, 2018

@chrishtr chrishtr moved this from Backlog to In progress in High-priority issues Jul 25, 2018

@chrishtr chrishtr added the Agenda+ label Jul 27, 2018

@astearns

This comment has been minimized.

Show comment
Hide comment
@astearns

astearns Aug 14, 2018

Member

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

Member

astearns commented Aug 14, 2018

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

@atanassov atanassov removed the Agenda+ label Aug 20, 2018

@atanassov

This comment has been minimized.

Show comment
Hide comment
@atanassov

atanassov Aug 20, 2018

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

atanassov commented Aug 20, 2018

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

@chrishtr

This comment has been minimized.

Show comment
Hide comment
@chrishtr

chrishtr Sep 6, 2018

Contributor

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

Contributor

chrishtr commented Sep 6, 2018

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

@chrishtr chrishtr closed this Sep 6, 2018

High-priority issues automation moved this from In progress to Done Sep 6, 2018

robin-raymond pushed a commit to webrtc-uwp/chromium-tools that referenced this issue Sep 20, 2018

Chris Harrelson Commit Bot
Revert obsolete use counter.
It's obsolete because the CSSWG resolved to fix ths issue by special-casing
the root element. See w3c/fxtf-drafts#11

TBR=trchen

Bug: 711736
Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: Ie17644b5d8d2fd8f34e97ee0803b26854ef0150d
Reviewed-on: https://chromium-review.googlesource.com/831399
Commit-Queue: Chris Harrelson <chrishtr@chromium.org>
Reviewed-by: Chris Harrelson <chrishtr@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#525581}
Cr-Mirrored-From: https://chromium.googlesource.com/chromium/src
Cr-Mirrored-Commit: d35b3dbaf9b11af8fe30ae37098b5381635b8d37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment