Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[filter-effects] Why can't opacity() filter function ever increase opacity? #178
The description of the shorthand
Was there a practical reason why the function cannot be used to increase opacity? Have browsers implemented the clamping of the input parameter? Or do they only clamp the final value? (Sorry, don't have time to test right now...)
I think it removes much of the usefulness of the function that it can't be used to increase opacity of semi-transparent regions (e.g., of blurred edges created by
I think it's kinda weird to do it multiplicatively; in particular, it means that something which is currently 0% opacity can't ever become visible, but something that's 1% can be (with an opacity of 10000%, for example). But opacity() can't do additive modification.
Or, from another direction: all the filters can be conceptually thought of as just rendering the subject to a bitmap and then fiddling with the pixels. To have >100% opacity work, you'd need to allow the alpha channel of the pixels to be an unbounded value, which is very inconsistent with current models of pixel color.
That's exactly the functionality I want!
And as far as weirdness goes, I'd say it's even less intuitive for
I'm not saying that the end result should be something greater than 100% opacity. The output of the filter operator would be clipped to the allowable range, just like it is for every other operator.
It would be nice to also have an additive option for both
PS. This is used in the nice SVG version of the so-called "gooey" filter effect. In contrast, the current all-shorthand version that is popular requires adding a solid background and using
Inputs and outputs would be clamped. The multiplicative factor would not be clamped. So
The equivalent long-hand definition would be:
<filter id="opacity"> <feComponentTransfer> <feFuncA type="linear" slope="[amount]"/> </feComponentTransfer> </filter>
A test of how browsers currently handle opacity filter values greater than 1 / 100%:
Sadly for me, they all seem to match the spec. Parameters are clamped to 1, so that opacity of a partially-transparent element can never be increased with the shorthand filters.
That seems to imply that we should continue to require clamping, but then later have an explicit no-clamping opt-in.
Technically, what I'm asking for would still be a multiplicative alpha effect. Just allowing multiplication with values greater than 1.
I agree that adding any other behavior (e.g., additive offsets) would be something to defer to another level of the spec.
The problem with defering
(Maybe it's already a compat risk, I don't know. People could be doing weird things with
Adding this functionality in the future would require adding a separate function (
The Working Group just discussed
The full IRC log of that discussion<dael> Topic: Why can't opacity() filter function ever increase opacity?
<dael> github: https://github.com//issues/178
<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.
<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.
<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.
<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.
<dael> krit: Biggest issue is there might be content already that can increase >1 and this code will result in 2 differnt results.
<dael> TabAtkins: I take back my objection. AmeliaBR pointed out that's exactly what you do want.
<dael> AmeliaBR: It's consistant with behavior of other shorthands like brightness.
<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.
<dael> krit: For some effects we require to go back to unmodified, yes. Depending on how impl is done you get very different results.
<dael> smfr: You've got data laoss with premultiplied alpha
<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.
<dael> AmeliaBR: Yes, that one lets you modify each channel.
<dael> Chris: Agree. Exposing that is the best way forward.
<dael> AmeliaBR: That is something that could be added in the future without web compat. Add a separate function in the future.
<dael> smfr: That would be fine.
<dael> TabAtkins: sgtm
<dael> AmeliaBR: Sounds like a reasonable way forward. hoping to get filters stable so I'll aceept
<dael> astearns: So we'll close this issue no change and put fe component transfer as future work.
<dael> AmeliaBR: I'll open an issue on filters 2.