- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 17 Jan 2018 18:03:12 +0000
- To: public-fxtf-archive@w3.org
The Working Group just discussed `end`. <details><summary>The full IRC log of that discussion</summary> <dael> Topic: end<br> <dael> Rossen_: There's a number ofFXTF. I don't know who has time to review what. krit and AmeliaBR are on the phone, I believe. There's many issues, but if there's 1 or 2 on the top of the list I'd like to know which.<br> <krit> https://github.com/w3c/fxtf-drafts/issues/238<br> <Chris> github: https://github.com/w3c/fxtf-drafts/issues/238<br> <dael> github: https://github.com/w3c/fxtf-drafts/issues/238<br> <dael> krit: In certain cases it's possible to fix an object. When you look at the 2nd link in first comment there's an example. You can open in any browser except Safari. Element is fixed, has a filter applied. When you scroll down user expects top line is blurred as well. You can watch that in FF or Chrome to see difference.<br> <krit> https://jsfiddle.net/3bdv532b/<br> <dael> krit: On the top row there is always some white b/c something outside the box is taked for blur. User expects once you scroll you don't take white. Safari you can see that or there's an example ^<br> <dael> krit: If you try to get this link open in any browser you'll see the difference.<br> <dael> krit: If you open it you can scroll down a bit, elemebt is still fixed, top row doesn't have white. Scroll up and there's white. That's a very specific issue. User expects there's some indication on the fixed element.<br> <dael> Rossen_: fwiw I see Edge has same behavior. We have some issue with fixed background that I'm hoping we'll fix, but it seems we're handling the same...uh, sorry. We're same as Chrome and FF. This isn't what spec defines?<br> <dael> krit: It's what the spec defines. But the author expects what you see in safari.<br> <dael> krit: You can see that from the jsfiddle, it's an emulation of the correct behavior using JS.<br> <dael> krit: If you scroll down you don't see white on the top.<br> <dael> krit: I do think that behavior of Edge/Chrome/FF is as spec intended. but for users it's a better indication if the blue scrolled with doc as the background stays fixed.<br> <dael> krit: You could argue there's a JS work around. And 'd be in favor of staying with current.<br> <dael> Rossen_: So you propose no change?<br> <dael> krit: Right.<br> <Chris> No-one can hear me, but for me the fiddle is working very oddly in firefox<br> <dael> AmeliaBR: I haven't looked carefully, but if Safari is different it's prob how the handle edge mode of blurs. I'm pretty sure the other browsers aren't matching spec unless spec was changed. It's about avoiding edges of elements getting errorded when you blur the element and that's what wesee. WE're first clipping and then blur errodes.<br> <dael> krit: Spec states that what you draw on the screen gets filtered after. Therefore what you should see is what you get from FF. THere's nothing beyond doc top if you want to put it that way.<br> <AmeliaBR> Spec https://drafts.fxtf.org/filter-effects/#FilterCSSImageValue , blur() function is supposed to use edgeMode="duplicate", but last I checked Safari was the only one that does that.<br> <dael> smfr: I'm not sure spec says what happens outside doc bounds. For me safari makes more sense. OTher browsers are pullin in white from beyond doc bounds which doesn't seem right.<br> <dael> krit: Does background get clipped to viewport? If it's beyond you're probably right.<br> <dael> smfr: I don't think we ever spec that. Maybe filter should spec what happens when you can potentioally get pixels from outside the viewport.<br> <dael> Rossen_: Is this viewport or any scrollport?<br> <dael> smfr: Anywhere with clipping I guess.<br> <dael> Rossen_: From that PoV I wouldn't want special casing for viewport.<br> <dael> Rossen_: It's general for all scroll port.<br> <dael> smfr: If this was inside overflow hidden you'd expect pixel from the outside content maybe? So maybe experiment with blurred things inside and see what the pixel effects are. That's a more general.<br> <dael> smfr: THis specific problem is pretty irrelevent I haven't seen a page to do this, but It would be good to spec carefully.<br> <dael> krit: If an object is clipped with clip path it's clear, but here clipping is implicit by the browser itself.<br> <dael> smfr: You have to think about order. If there's clipping abd blurring We clip and then blur. If the ancestor clips and blur is descendant that's more similar.<br> <dael> Rossen_: Right.<br> <dael> smfr: I don't know if we have a good desc of the ordering these effects occur in. I don't think it's written you clip then filter.<br> <dbaron> I think there are some open github issues about specifying the ordering...<br> <dael> AmeliaBR: General is clip after filter. No body has written in any spec how that applies to something like background attachment, but generally clip after filter.<br> <dael> smfr: Not sure that's what we impl<br> <AmeliaBR> Correction to my previous post/link: No that's the spec for filter(<image>, blur()) function. Nevermind.<br> <dael> fantasai: Clip to a whole element, I think you filter to the whole element and then clip. Backgrounds are different, you draw it and then filter then clip it.<br> <dael> fantasai: Background is clipped to the boundries already because it's only drawn to the element bounderies. You draw background into the area and then we filter the whole thing that results.<br> <dael> AmeliaBR: Good point.<br> <dael> fantasai: WE need abackground filter property, but we don't have one.<br> <dael> AmeliaBR: That's different effects. What fantasai is saying is that the background is acting like a child to the element where it gets clipper earlier in the rendering. Overflow on the element is a clip after filter, but background attachment is at a different place.<br> <dael> Rossen_: WE're nearing the end of the call. WE have some fairly basic order of operations and based on this discussion we don't have a clear explination of what happens when in the combo of backgrounds, no backgrounds, clip, clip-path etc. I would be curious to see if we can agree on the order and from that we should be able to extrrapolate what this should do in terms of clip and blur<br> <dael> Rossen_: Would you be interested in putting that inside this issue krit ?<br> <dael> krit: Yes, I think we should.<br> <dael> Rossen_: We're at the end of the call. I don't think we can resolve. I suggest going back to the issue and continuing.<br> <dael> Rossen_: I also want to invite anyone in the CSSWG participating in FXTF to look at all the items in the agenda and participate before next week. We'll continue discussing open items as time permits.<br> <dael> Rossen_: Thanks for calling and we'll chat next week.<br> <Rossen_> trackbot, end meeting<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/fxtf-drafts/issues/238#issuecomment-358390179 using your GitHub account
Received on Wednesday, 17 January 2018 18:03:14 UTC