- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 13 Jun 2018 16:46:38 +0000
- To: public-fxtf-archive@w3.org
The Working Group just discussed `Effect of filter on document element`, and agreed to the following: * `RESOLVED: if there is an explicit author-specified background, that layer that has gotten propagated on top of the canvas, filter does effect that` <details><summary>The full IRC log of that discussion</summary> <Rossen_> topic: Effect of filter on document element<br> <Rossen_> github: https://github.com/w3c/fxtf-drafts/issues/282<br> <tantek> regrets+<br> <melanierichards> ???: question is whether this effects the root background color, by which I mean HTML body element. The way the spec currently stands it's possible to create unreadable text [paraphrased]. Wonder if it's possible to allow the canvas's background color to be effected by filter()<br> <fantasai> s/???/smfr<br> <melanierichards> smfr: summarized in issue, but what happens if you apply filter() to html element?<br> <melanierichards> smfr: informal poll on twitter, authors didn't expect currently defined behavior, expecting inverted background<br> <smfr> https://twitter.com/LeaVerou/status/1001859421469855744<br> <melanierichards> florian: not sure about how the question was phrased, didn't seem to be clearly about the html element and various interactions<br> <leaverou> (poll phrasing was exactly the same as smfr's<br> <melanierichards> Rossen: one of the points being made is, when you do apply a filter that happens to apply to the default canvas background color, this is something that we have not specified. we are keeping this UA dependent. we might want to have the window or the canvas of the UA itself to be not necessarily want particular color. we may have special filters applied to it. In the more recent version of Windows, that's one of the defining principles. I'm not<br> <melanierichards> particularly excited in losing this ability in saying no, the background color would have to be a specced color, black or white<br> <florian> the poll phrasing asked if people expected the invert filter "to make the default white background black" it did not ask if people expected that it would "make the default transparent background that is over a while background black"<br> <melanierichards> smfr: I don't think this is saying that. In webkit we have the ability to make the canvas transparent and have other things shine through. you would be apply to transparent pixels and the filter would be applied in the correct way. if there was a color, the filter would apply to that color<br> <melanierichards> Chris: what if the filters make the pixels transparent?<br> <melanierichards> Chris: I think we shouldn't allow a webview to become transparent<br> <melanierichards> [general consensus]<br> <melanierichards> smfr: when you're rendering with a filter, you essentially take a snapshot of the page, render the filter, and apply the snapshot.<br> <melanierichards> Florian: it seems simpler to say that the filter on the background effects the background color of the HTML element, and not the background behind it, which is white<br> <chris> no, background on html is black (and background on root is transparent) see https://drafts.csswg.org/css-color/#sample<br> <melanierichards> Florian: from the twitter poll it seems to be referring to the white background behind transparent background<br> <melanierichards> AmeliaBR: part of the problem is authors don't have a detailed understanding of how the background layers work in the spec<br> <melanierichards> smfr: they don't understand the root behind html, those sort of details<br> <chris> s/smfr/chrisl<br> <melanierichards> florian: most people don't understand those, but can still ask the question: what do you expect? instead of suggesting an answer<br> <chrisl> needs a couple of good examples in the spec, and a diagram showing root, html, and body layers<br> <melanierichards> AmeliaBR: regardless of exact poll details, I think we can accept this is a confusing topic and needs to be clearly defined and explained. There are a couple layers of it. By the fact that it hasn't come up, if you apply filter to html that would apply to a background image on the element, is everyone in agreement with that?<br> <melanierichards> [general consent] So long as there's another color behind that<br> <melanierichards> AmeliaBR: we have the canvas default color, behind that we have the background image or color set on the root element, or set on the body and propagated up to the root. the question is what if that layer has not been set and it defaults to transparent<br> <melanierichards> smfr: what you proposed is actually a behavior change in Chrome and FF<br> <melanierichards> AmeliaBR: that is a change but I think we agree it's logical. next question: if there is no root bg on the element, then we still have the default canvas background, which is a separate layer. Used as separate in blend modes, where blend modes never affect that default canvas layer. I'm ok with saying that that default canvas layer is independent from filters, but need to communicate clearly to authors<br> <melanierichards> AmeliaBR: if we let that never be effected by filters, we need to deal with if the filter makes that ??? layer partially transparent<br> <melanierichards> ???: 3 layers: root background, canvas layer, root element which may be different?<br> <melanierichards> AmeliaBR: the root element never has a background of its own, it's always propagated to the canvas<br> <astearns> s/???/chrishtr<br> <melanierichards> chrishtr: I think we can always have two layers<br> <melanierichards> Rossen: what we are getting at, if we have this model of 2 bg colors on the canvas, one which is modifiable by whatever comes from the root, and one which is not which is the very bottom background layer, UA defined, but it's blendable with whatever's on top of it. the only way this could work is if the intermediate one is transparent. If body or html propagates to transparent, transparent is transparent. so you see whatever is on the bottom layer<br> <melanierichards> (the UA background canvas color)<br> <melanierichards> Rossen: we have one bottom layer which is non reachable by any CSS constructs, regardless of whether or not we are propagating. we have the intermediate layer that allows you to blend what you need to blend; author defined background color propagates to here. is this the model we're trying to get to?<br> <melanierichards> smfr: propagated color not necessarily opaque, rgba<br> <melanierichards> Rossen: but still not effecting the bottom layer. don't want to punch a hole through webview by specifying transparent root bg color<br> <melanierichards> Florian: if the filter is applied to the transparent canvas, we would still see the white background behind it, right?<br> <melanierichards> Rossen: if we need to have an initial color on say html that gets propagated to background root element, that is different from transparent, we can discuss this<br> <melanierichards> Florian: would be ok with default being white<br> <florian> +1 to AmeliaBR<br> <melanierichards> AmeliaBR: in spec we could have a warning that if you apply filter to the html element, then also need an opaque background for it to work correctly<br> <melanierichards> AmeliaBR: think it can be handled with note to authors to apply background color to root element<br> <melanierichards> smfr: what about applying filter to root elements for accessibility reasons? (UA etc) might be different from the author of the page<br> <melanierichards> smfr: we have some interest in this from dark themes on Mac<br> <melanierichards> fantasai: could set white as default in that case, and user would've had to set root bg color explicitly to transparent<br> <melanierichards> Bo Campbell: would like to look into this a little more from accessibility, can you help me understand that use case better?<br> <melanierichards> smfr: someone with accessibility issues might want to avoid bright colors and apply a saturation filter to all the web pages they look at. or they want to turn down brightness (don't want to see stark white background)<br> <melanierichards> Florian: in the UA style sheet, they could set it to white, and only if author set to transparent would it break<br> <florian> s/in the UA style sheet, they could/in the user style sheet, they could/<br> <melanierichards> smfr: an option to allow filters to apply to default page bg would be to propagate the color from the bottom UA-controlled layer to the intermediate layer<br> <melanierichards> Rossen: the blending layer!<br> <melanierichards> chrishtr: smfr's proposal seems reasonable<br> <melanierichards> AmeliaBR: that proposal to always make the root background opaque, messes with how blend modes currently work<br> <melanierichards> smfr: will have to think carefully about blend modes w/ new conceptual model<br> <melanierichards> Rossen: proposal is an intermediate layer where background from UA-controlled layer is propagated by default. All of the bg color propagation from HTML also propagates up to that intermediary layer. can we try to adopt that model and resolve? otherwise take back to GH<br> <melanierichards> Rossen: objections to adopting this model?<br> <AmeliaBR> s/messes/may mess/<br> <melanierichards> Florian: whether it gets the UA layer background color or not, I think that's what we have to think about more<br> <melanierichards> AmeliaBR: quick test, looks like blend modes never effect the canvas layer even if explicitly set on root element. Still need careful consideration<br> <melanierichards> Florian: open question is whether or not we propagate from the background layer or not<br> <melanierichards> AmeliaBR: if there is an explicit author-specified background, that layer that has gotten propagated on top of the canvas, filter does effect that. need a resolution on that<br> <melanierichards> Rossen: objections to resolution in Amelia's comments?<br> <melanierichards> RESOLVED: if there is an explicit author-specified background, that layer that has gotten propagated on top of the canvas, filter does effect that<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-397007286 using your GitHub account
Received on Wednesday, 13 June 2018 16:46:42 UTC