Re: [fxtf-drafts] [filter-effects] Why can't opacity() filter function ever increase opacity?

The Working Group just discussed `Why can't opacity() filter function ever increase opacity?`.

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: Why can't opacity() filter function ever increase opacity?<br>
&lt;krit> https://github.com/w3c/fxtf-drafts/issues/178<br>
&lt;dael> github: https://github.com/w3c/fxtf-drafts/issues/178<br>
&lt;dael> AmeliaBR: We have an opacity shorthald filter function. It takes any int >0 but any >1 is clamped to 1. So opacity filter reduces but cannot increase opacity. So a number of features like taking a blur or drop shadow and inclreasing opacity of blurred areas is not possible.<br>
&lt;dael> AmeliaBR: We're getting late int he process for major changes. All engines currently impl as spec. Problem is because the way it's spec it won't be easy to add this in later. If it was currently written that >1 is invalid we could add it later without worrying about breaking.<br>
&lt;dael> AmeliaBR: As far as an author prespective I found this to be an arbitrary restriction so I wanted to change, but I recognize it's late in the game.<br>
&lt;dael> krit: 2 comments. Spec was following impl already, that was already impl. Point 2 that I think TabAtkins mentioned if you have some areas with a 0 they will not get opaque again. THere might be issues there. Also some browsers might have optimizations.<br>
&lt;dael> krit: Biggest issue is there might be content already that can increase >1 and this code will result in 2 differnt results.<br>
&lt;dael> TabAtkins: I take back my objection. AmeliaBR pointed out that's exactly what you do want.<br>
&lt;dael> AmeliaBR: It's consistant with behavior of other shorthands like brightness.<br>
&lt;dael> smfr: There are other issues. 1 is that some browsers may rely on platform graphics libraries that expect 0-1 value. Second is with premultiplied alpha. Many engines will store in that and you have very small rgb units and when you multiply that you get this grey. I think that'll happen with >1 opacity.<br>
&lt;dael> krit: For some effects we require to go back to unmodified, yes. Depending on how impl is done you get very different results.<br>
&lt;dael> smfr: You've got data laoss with premultiplied alpha<br>
&lt;dael> smfr: I also don't like because it gives us different behavior in opacity. If we want this we should think about a different filter.<br>
&lt;dael> AmeliaBR: Yes, that one lets you modify each channel.<br>
&lt;dael> Chris: Agree. Exposing that is the best way forward.<br>
&lt;dael> AmeliaBR: That is something that could be added in the future without web compat. Add a separate function in the future.<br>
&lt;dael> smfr: That would be fine.<br>
&lt;dael> TabAtkins: sgtm<br>
&lt;dael> AmeliaBR: Sounds like a reasonable way forward. hoping to get filters stable so I'll aceept<br>
&lt;dael> astearns: So we'll close this issue no change and put fe component transfer as future work.<br>
&lt;dael> AmeliaBR: I'll open an issue on filters 2.<br>
</details>


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

Received on Wednesday, 21 February 2018 17:54:02 UTC