Re: [fxtf-drafts] [filter-effects-1] What is the visual effect of filter() on the document element?

The CSS Working Group just discussed `Next on graphics issues`, and agreed to the following:

* `RESOLVED: In mix-blend-mode, the default background color is also painted within the page group`
* `RESOLVED:  the filter applies to the result of the page group on top of the root background color`
* `RESOLVED: clip path, opacity, mask will be applied to the output of the page group on top of the root group`

<details><summary>The full IRC log of that discussion</summary>
&lt;gregwhitworth> Topic: Next on graphics issues<br>
&lt;gregwhitworth> Rossen: this is about success on filters elements on the root element<br>
&lt;Rossen> github: https://github.com/w3c/fxtf-drafts/issues/282<br>
&lt;gregwhitworth> chrishtr: I brought this a few months ago - there were a few pieces of feedback<br>
&lt;gregwhitworth> chrishtr: how do you treat the root element, in particalur frames that are transparent - similiar to iframes<br>
&lt;gregwhitworth> chrishtr: it's in a webview in side of an app for example<br>
&lt;gregwhitworth> chrishtr: some other device that wants transparency<br>
&lt;gregwhitworth> chrishtr: I did some more testcases<br>
&lt;gregwhitworth> chrishtr: and have a proposed solution<br>
&lt;gregwhitworth> chrishtr: the new proposal is that - there are two conceptual layers you draw into, the frame root background layer<br>
&lt;gregwhitworth> chrishtr: the root element layer<br>
&lt;gregwhitworth> chrishtr: the background is always opaque white<br>
&lt;gregwhitworth> chrishtr: so there is white and then the root element<br>
&lt;gregwhitworth> chrishtr: you draw the stacking context of the root element into that layer except the background is extended into the infinite canvas<br>
&lt;gregwhitworth> chrishtr: everything would apply as is<br>
&lt;gregwhitworth> chrishtr: clipping and filter and blend-mode and backdrop-filter are done in the same order as before<br>
&lt;gregwhitworth> chrishtr: so I went throught he examples that simone fraser came out as he expected<br>
&lt;gregwhitworth> mstange: I don't think that is true<br>
&lt;gregwhitworth> mstange: in your root element layer there is no white background<br>
&lt;gregwhitworth> mstange: if you don't have a background element on html then you can apply and filter and it will break<br>
&lt;gregwhitworth> mstange: if you have the background there then we will get what Simon expects<br>
&lt;gregwhitworth> mstange: we need to update background-blend mode or we cannot invert<br>
&lt;gregwhitworth> krit: blend mode currently defines white to be the pages backdrop<br>
&lt;gregwhitworth> mstange: yes it does, but only the result of the blending is composited on top of it - it doesn't participate<br>
&lt;gregwhitworth> chrishtr: is the contention - if you make it part of it then it fixes the invert, but if you don't then it breaks it<br>
&lt;gregwhitworth> mstange: if you make the white part - part of the page group you fix invert but change how mix-blend-mode is defined<br>
&lt;gregwhitworth> mstange: this part isn't implemented by Chrome<br>
&lt;gregwhitworth> mstange: correct?<br>
&lt;gregwhitworth> chrishtr: I think Chrome is probably incorrect<br>
&lt;gregwhitworth> mstange: but if we change it, Chrome doesn't need to change<br>
&lt;gregwhitworth> chrishtr: true<br>
&lt;gregwhitworth> krit: I want to change web pages that will always have the white backdrop<br>
&lt;gregwhitworth> krit: it is there for sites that didn't provide a background, is it providing the background for websites<br>
&lt;gregwhitworth> mstange: we still allow people to change the default color to the background<br>
&lt;gregwhitworth> mstange: there may be a11y issues here<br>
&lt;gregwhitworth> chrishtr: let's save that for a different issue<br>
&lt;gregwhitworth> mstange: sure<br>
&lt;gregwhitworth> chrishtr: do we want to consider white as part of the root<br>
&lt;gregwhitworth> chrishtr: then the root is not different than any other stacking context<br>
&lt;gregwhitworth> mstange: the filter may be opacity: 0 - you'll need some type of result<br>
&lt;gregwhitworth> mstange: I support painting the background twice, once inside and outside of the page group<br>
&lt;gregwhitworth> mstange: and defining the remaining issues<br>
&lt;gregwhitworth> chrishtr: why twice<br>
&lt;gregwhitworth> chrishtr: why isn't it ok to composite the filter to white?<br>
&lt;gregwhitworth> mstange: that could work<br>
&lt;gregwhitworth> chrishtr: you should just expect it to be composited to white<br>
&lt;gregwhitworth> mstange: if we say it's white for now<br>
&lt;gregwhitworth> mstange: if you want invert to be inverted<br>
&lt;gregwhitworth> mstange: it needs to be painted in the page group<br>
&lt;gregwhitworth> mstange: if you want a merge to apply to the default background color<br>
&lt;gregwhitworth> mstange: the white needs to be present to the input of the filter, now you have a result so you composite that to something, what is under the result<br>
&lt;gregwhitworth> chrishtr: it is white<br>
&lt;gregwhitworth> mstange: that's why it needs to be twice<br>
&lt;gregwhitworth> chrishtr: in the scenario where there is no background defined<br>
&lt;gregwhitworth> Sim: you propogate the color to the root element layer, and then do the composition<br>
&lt;gregwhitworth> chrishtr: yes<br>
&lt;gregwhitworth> chrishtr: I think it's equivolent<br>
&lt;gregwhitworth> simon: if the root is white with alpha<br>
&lt;gregwhitworth> chrishtr: I think the math comes out the same<br>
&lt;gregwhitworth> krit: depens on the transform and color<br>
&lt;gregwhitworth> krit: let's say you can set the color in the page group, what would happen? Would backdrop not get inverted?<br>
&lt;gregwhitworth> mstange: FF settings don't allow alpha, the result would be opaque and that would be composted onto white, always gives you the same result<br>
&lt;gregwhitworth> krit: my only concern - do we always have a solid color<br>
&lt;gregwhitworth> mstange: as written, it would allow support for any background color including no background color besides what is defined on the root background color<br>
&lt;gregwhitworth> chrishtr: whatever the screen happened to have on it would be composited<br>
&lt;mstange> proposed resolution: In mix-blend-mode, reword the paragraphs "The page group is an isolated group. The page group is composited with a backdrop color of white with 100% opacity." to mention that the default background color is also painted within the page group, i.e. that blending happens with the default background color.<br>
&lt;gregwhitworth> Rossen: Any objections?<br>
&lt;gregwhitworth> Resolved ^<br>
&lt;gregwhitworth> Proposed Resolution: the filter applies to the result of the page group on top of the root background color<br>
&lt;gregwhitworth> Rossen: objections?<br>
&lt;gregwhitworth> Resolved ^<br>
&lt;gregwhitworth> mstange: your document also changes opacity, mix blend modes and filter?<br>
&lt;gregwhitworth> chrishtr: you mean it also changes opacity?<br>
&lt;Rossen> RESOLVED: In mix-blend-mode, the default background color is also painted within the page group<br>
&lt;gregwhitworth> mstange: if you have a background red on root and opacity: 0<br>
&lt;Rossen> RESOLVED:  the filter applies to the result of the page group on top of the root background color<br>
&lt;gregwhitworth> mstange: if I have background red on the root element, does this go inside the page group and root group?<br>
&lt;gregwhitworth> chrishtr: no<br>
&lt;gregwhitworth> mstange: that changes what occurs - this does not change the root element<br>
&lt;gregwhitworth> chrishtr: this would change<br>
&lt;gregwhitworth> mstange: opacity is a type of filter<br>
&lt;gregwhitworth> mstange: clip-path and mask would change as well<br>
&lt;gregwhitworth> mstange: if you have clip-path on the root element, the clip would effect the background of red<br>
&lt;gregwhitworth> chrishtr: I think that's good<br>
&lt;gregwhitworth> mstange: I agree<br>
&lt;gregwhitworth> Proposed Resolution: opacity, clip-path, mast and clip path will be applied to output of the page group on top of the root group<br>
&lt;gregwhitworth> mstange: I don't agree with clip-path<br>
&lt;gregwhitworth> chrishtr: it's always a stacking context<br>
&lt;mstange> s/clip-path/clip<br>
&lt;gregwhitworth> mstange: should we just not mention clip<br>
&lt;gregwhitworth> chrishtr: sounds fine<br>
&lt;smfr> s/mast/mask/<br>
&lt;gregwhitworth> Proposed resolution: clip path, opacity, mask will be applied to the output of the page group on top of the root group<br>
&lt;gregwhitworth> Rossen: objections<br>
&lt;gregwhitworth> Resolved ^<br>
&lt;Rossen> RESOLVED: clip path, opacity, mask will be applied to the output of the page group on top of the root group<br>
&lt;gregwhitworth> chrishtr: the reason I think we should use white as the background is to provide consistency to authors<br>
&lt;gregwhitworth> chrishtr: this is inconsistent with the need for a dark mode<br>
&lt;gregwhitworth> krit: why not just keep a weight<br>
&lt;gregwhitworth> Simon: Why not have white be the default and allow UAs to adjust it<br>
&lt;gregwhitworth> chrishtr: I'm fine with that<br>
&lt;gregwhitworth> chrishtr: should we ok with defining opaque<br>
&lt;gregwhitworth> krit: we should define the UA may define the background color and default is white<br>
&lt;gregwhitworth> Simon: and it doesn't need to be opaque<br>
&lt;gregwhitworth> Proposed Resolution: The background color is UA defined with default being white<br>
&lt;gregwhitworth> Resolved: The background color is UA defined with default being white<br>
</details>


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

Received on Tuesday, 23 October 2018 14:12:52 UTC