- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 12 Sep 2018 16:38:05 +0000
- To: public-fxtf-archive@w3.org
The CSS Working Group just discussed `What is the visual effect of filter() on the document element?`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: What is the visual effect of filter() on the document element?<br> <dael> github: https://github.com/w3c/fxtf-drafts/issues/282#issuecomment-418954332<br> <dael> chrishtr: In previous WG meeting we discussed a couple of issues. One was filter is a containing block for all elements unless filter is on root. Reason for that is that it's important for impl reason and rationality of platform for it to be CB. For root we want fixed to behave correct<br> <dael> chrishtr: Second issue from smfr is that it's unclear what happens when you put a filter and what happens to default white backdrop<br> <dael> chrishtr: Discussed and had somewhat resolution similar to my proposal, but needed use cases<br> <astearns> https://docs.google.com/document/d/1iN0LiaKPF3NZ2PCXD9gdWz1WmruhQIER8fJ_EYMm5YE/edit#<br> <dael> chrishtr: THere's 3 drawing layers for every doc. UA background layer, canvas layer, root element layer. Blended for final output<br> <dael> chrishtr: Want to make sure final is opaque. That's function of UA background<br> <dael> Rossen_: Always meaning per discression of UA right?<br> <dael> chrishtr: yes but don't think it's good idea<br> <dael> Rossen_: If a UA wants blending enabled for, say, webview with different composition other then opaque they should be allowed. Saying background is always opaque is too strong<br> <dael> chrishtr: Would you agree it's important for dev not to be able to cause blending there?<br> <dael> Rossen_: Agree. Trying to distinguish that UA layer is controlled by UA only. Opque or not is per discretion of UA. Rest is correct<br> <dael> chrishtr: Canvas layer is second. Purpose is a blending backdrop for root element. Root element never has a background, lawyas stolen by canvas layer. THat's as is. Other cases in HTML where body gets its background sotlen, but that's not valid here<br> <dael> chrishtr: I want mixed blend mode and filter to apply to canvas layer as it mixed blend and filter of root element and canvas. Default color of canvas is white. If you don't spec a color on html element canvas will be white<br> <dael> Rossen_: Purpose of root element layer?<br> <dael> chrishtr: Content that's not the background but drawn into stacking context. If you have a non-stacking div that's filtered in<br> <dael> Rossen_: Makes sense<br> <dbaron> http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cstyle%3E%0Abody%20%7B%20background%3A%20aqua%20%7D%0A%3C%2Fstyle%3E%0A%3Ciframe%20srcdoc%3D%22%3Cdiv%20style%3Dbackground%3Ablue%3Bheight%3A30px%3E%3C%2Fdiv%3E%22%3E<br> <dael> smfr: There was a step to prop. the UA background layer color to the canvas. If you make canvas whit eyou prevent UA from transparency.<br> <dael> chrishtr: Default color of the canvas is white. Step 1 in the algo is paint white into UA. step 2 is put background of root into canvas and if no background put white. Guar. of opaque comes from UA layer, not canvas. UA layer forces the opaque, not canvas.<br> <dael> dbaron: Question on assumption. I put a test case in^<br> <dael> dbaron: Only tested FF, but iframe is transparent. Canvas does not always have white background<br> <dael> chrishtr: I think the demo is in case of iframe...yeah...white background is root frame but not sub frames. Right. And iframes can be transparent. Right.<br> <dael> astearns: Should that be added to algo?<br> <dael> chrishtr: Yeah. White color is specific to root document. For subframes it's transparent<br> <dael> chrishtr: Tranparent iframe is legitimate<br> <dael> Rossen_: There is no ua background layer in this case<br> <dael> chrishtr: THere is eventually if you go up stacking<br> <dael> Rossen_: Yes, for the frame itself<br> <dael> chrishtr: Right. And as dbaron said it doesn't draw white by default. There is no infinite canvas for an iframe. That needs to be thought through<br> <dael> chrishtr: Another comment on github from earlier today that asked about clipping and masking order relative to filter and blend. Compositing says filter first and then...there's an order<br> <chris> yes, filter should be applied first.<br> <chris> so there are two separate clip stages?<br> <dael> chrishtr: Clipping is clip-path. I think it's important to be after scrolling and overflow clip. Not masking or clip-path. Not sure you can mask or clip-path root. Does anyone know?<br> <dael> chrishtr: It would apply to iframes but not root document<br> <dael> Rossen_: QUestion was?<br> <dael> chrishtr: Masking for css clip to the root<br> <dael> chrishtr: Any way to cause clip on root element<br> <dael> chrishtr: Not sure it makes any sense for root of webpage or if UA impl. Makes sense for an iframe<br> <dael> Rossen_: NOt sure<br> <dael> Rossen_: Assume the use case for iframe I would question why that use case doesn't apply to top level root<br> <dael> chrishtr: Reason wuld be iframes are in a larger drawing serface.<br> <dael> Rossen_: Yes, unless root is inside an iframe. If use case applies to doc in iframe, why when it's not.<br> <dael> fremy: Also if you're drawing on a glass screen I can imagine websites wanting to be transparent and only white background when they want it. I don't think there's a reason to think iframe use case doesn't apply on root<br> <dael> chrishtr: Okay. I see.<br> <dael> Rossen_: Where do we go? Your summary in the explainer is decent. What's next?<br> <dael> chrishtr: Need to go into more detail about iframes and clipping/masking. Then I think it'll be ready to come back<br> <dael> Rossen_: This is great chrishtr . Thank you for putting this together.<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-420715623 using your GitHub account
Received on Wednesday, 12 September 2018 16:38:07 UTC