- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 30 Apr 2020 23:34:12 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `background-filter`, and agreed to the following: * `RESOLVED: Close #4736 and #4715 as no-change; filter() is what's intended to solve these cases.` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: background-filter<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/4706<br> <TabAtkins> AmeliaBR: This issue, and the next about background-opacity, are basically the same issue<br> <TabAtkins> AmeliaBR: When you have layered backgrounds, sometimes you want to modify those backgrounds, or see one thru the other<br> <TabAtkins> AmeliaBR: Like have a dark overlay over a texture image<br> <TabAtkins> AmeliaBR: Or you want a slightly blurred image so it's not as distracting from the text over top<br> <TabAtkins> AmeliaBR: Right now no way to do that<br> <TabAtkins> AmeliaBR: Some things you can do with blend modes, but not a lot<br> <smfr> q+<br> <TabAtkins> AmeliaBR: So today people have to instead put the bg on a pseudo-element and abspos it behind the element's content, and then use 'filter' on it<br> <TabAtkins> AmeliaBR: Suggestion is to add more properties that describe filter-effects, or perhaps just a simple opacity.<br> <TabAtkins> AmeliaBR: One thing that immediately is brought up is that we have a spec for this fucntionality - in filter effects, there's a filter() function that should take an image, apply filters to it<br> <TabAtkins> AmeliaBR: So could say "background-image: filter(url(...) blur(...));"<br> <TabAtkins> AmeliaBR: But no impl of that<br> <faceless2_> We implemented t yesterday!<br> <TabAtkins> AmeliaBR: Don't know the reasons for that, if therea re technical issues or just priority<br> <fantasai> There's also https://drafts.fxtf.org/filter-effects-2/ which has no FPWD or anything<br> <TabAtkins> AmeliaBR: Other side, about separating to properties, that might be nicer from an authoring perspective to just reuse the existing bg model, rather than trying to squish everyting into a proeprty<br> <TabAtkins> AmeliaBR: But need to talk about whether people will implement if specced in a different way<br> <astearns> ack smfr<br> <TabAtkins> smfr: We do have stable impl of filter() in webkit<br> <TabAtkins> smfr: I like it because authors are used to filter property, this is a simple way to apply that in a diff context<br> <TabAtkins> smfr: And lets you do the classic thing of shipping one set of images and changing them on the fly with filters to do what you want<br> <TabAtkins> smfr: Plus you can animate the filters<br> <faceless2_> q+<br> <TabAtkins> smfr: So I like filter(), wold like to hear form othe rimplementors<br> <TabAtkins> smfr: There's also a proposal to support the asme filters for canvas<br> <TabAtkins> smfr: So if they don't have it already, will need it soon anyway<br> <TabAtkins> smfr: Also, filter() can be used anywhere, like border-image. If doing a background-* property, can't apply it to othe rimage props<br> <astearns> ack faceless2_<br> <TabAtkins> faceless2_: One difference between background-filter and filter(), background-filter aplies to all layers after merging, filter() is per-layer<br> <TabAtkins> faceless2_: Also when trying to blur image, filter doesn't apply beyond the bounds of the image<br> <TabAtkins> faceless2_: Not a problem if you have a single image covering the hwole bg<br> <TabAtkins> faceless2_: But if you're tiling the image, you won't get th edesired effect<br> <astearns> ack fantasai<br> <TabAtkins> fantasai: So i think there's still a usecase for a whole-layer filter<br> <TabAtkins> s/fantasai/faceless2_/<br> <TabAtkins> fantasai: Good point<br> <TabAtkins> fantasai: Another proposal for backdrop-filter property; it does something else entirely.<br> <smfr> q+<br> <TabAtkins> It's not the backgrounhd at all, actually<br> <TabAtkins> smfr: backdrop-filter is different<br> <TabAtkins> smfr: It renders what's behind the element, then filter it. *Then* the element itself, including its background, is composited atop it.<br> <TabAtkins> fantasai: So there's still another case for compositing the bg layers together before filtering<br> <AmeliaBR> q+<br> <TabAtkins> smfr: Yeah, definitely a difference there. Use-cases for both<br> <TabAtkins> smfr: For backgrounds, if you're using colors you can use alpha.<br> <TabAtkins> smfr: Would be curious to see use-cases for bg-filter that wants the whole bg at once<br> <faceless2_> q+<br> <TabAtkins> smfr: And if doing it for bg, why not for border? So you can blur your borders? Feature-creep potential.<br> <heycam> q+<br> <TabAtkins> fantasai: I think there are cases of peopl eusing bg to make a stretchtable scene in several layers, and there you'd want to composite them together berfore applying opacity<br> <TabAtkins> astearns: Any response to simon's question about other impls of the filter() fucntion?<br> <fantasai> i/astearns/smfr: that's a good use case/<br> <TabAtkins> iank_: Have to check wit the pain team<br> <astearns> q?<br> <TabAtkins> emilio: Seems like putting it in the image is the more flexible thing to do<br> <tantek> s/fucntion/function<br> <faceless2_> q+<br> <astearns> ack smfr<br> <astearns> ack dbaron<br> <Zakim> dbaron, you wanted to mention controls for treatment of edges<br> <TabAtkins> dbaron: Someone mentioned tiled bg images, and diff between blurring each tile vs the whole set<br> <TabAtkins> dbaron: One control that's common here is what's off the edge<br> <TabAtkins> dbaron: One option is the edge is transparent black, vs closest pixel, vs pretend you tiled<br> <TabAtkins> dbaron: So with that control you could get the effect you wanted<br> <astearns> ack AmeliaBR<br> <TabAtkins> dbaron: Filter controls like that are generally applicable, worth considering<br> <astearns> zakim, close queue<br> <Zakim> ok, astearns, the speaker queue is closed<br> <TabAtkins> AmeliaBR: That's call edgemode attribute on feGaussianBlur<br> <TabAtkins> AmeliaBR: filter() is, as defined in spec, should magically choose edgemode based on tiling or not<br> <smfr> “For the <blur()> function the edgeMode attribute on the feGaussianBlur element is set to duplicate. This produces more pleasant results on the edges of the filtered input image.”<br> <TabAtkins> AmeliaBR: If bg image is tiled, is does blurring smoothly.<br> <TabAtkins> AmeliaBR: So for what is getting filtered, I think that's worth talking about, but if there's a concern, there are ways to address that concern.<br> <TabAtkins> I can dust off the @filter rule proposal, dino expressed interest in it again a while back...<br> <TabAtkins> AmeliaBR: Maybe there are use-cases for both "filter each layer" vs "filter layers together"<br> <TabAtkins> AmeliaBR: But filter() function is def treating each image before tiling/compositing.<br> <TabAtkins> AmeliaBR: Other question is why only bg?<br> <TabAtkins> AmeliaBR: I brought this up as well. If we did it as a spearate property, all the other similar groups would want a matching prop, so could add a bunch of properties.<br> <TabAtkins> AmeliaBR: fill-image-filter, border-image-filter, et<br> <astearns> ack faceless2_<br> <TabAtkins> faceless2_: Re: compositing borders together, table borders would make me cry...<br> <TabAtkins> faceless2_: And table bgs are stacked up as well, phew<br> <astearns> ack heycam<br> <TabAtkins> heycam: I think it's not just an issue with tiling; agree we need something to fix that.<br> <TabAtkins> heycam: Also stretching - before or after filter() could affect things.<br> <TabAtkins> Yeah, blur() would act differently if applied before or after stretching.<br> <TabAtkins> AmeliaBR: So, we have filter() in the spec. There are clear use-cases.<br> <TabAtkins> AmeliaBR: Do we feel that, from an authoring or impl standpoint, filter() isn't good enough and we need to look at new options? Or is it good enough, we close this no-change, and continue working on filter()<br> <TabAtkins> fantasai: I think this addresses a number of the cases.<br> <TabAtkins> fantasai: But think it doesn't address "i want opacity on entire bg at once, but not on the text", which is a common use<br> <fantasai> TabAtkins: One of the things suggested there was a ::background pseudo<br> <fantasai> TabAtkins: if you could put filter on that, could achieve that case at least syntactically it's easy<br> <fantasai> astearns: Would end up with a lot of pseudos for each thing you might want to filter...<br> <TabAtkins> astearns: Then you run into "well if you do it for bgs, why not borders, etc"<br> <fantasai> TabAtkins: Well, so far it seems that filter per layer shouldn't be handled by separate properties<br> <fantasai> TabAtkins: Pursue filter() function as preferred method for that<br> <fantasai> astearns: Do we leave background-filter issue open to deal with the background-all-at-once case?<br> <fantasai> AmeliaBR: I think we should see more use of filter() before we say that use case isn't addressed<br> <TabAtkins> AmeliaBR: Think we need wider us eof the filter() before we can conclude we need to address more use-cases<br> <TabAtkins> astearns: So we can do that - close these as no-change and use filter() function<br> <TabAtkins> astearns: Objections?<br> <TabAtkins> RESOLVED: Close #4736 and #4715 as no-change; filter() is what's intended to solve these cases.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4706#issuecomment-622174548 using your GitHub account
Received on Thursday, 30 April 2020 23:34:18 UTC