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] Make grayscale() work without parameters #1
0 means no change. Thus seems unintuitive. I would expect grayscale()
For what it's worth, this seems to be how -webkit-filter is implemented.
For implementers of the standard property, neither Edge nor Firefox
@AmeliaBR Firefox does not support
@dirkschulze If there's a good reason that default parameters for functions are not supported, then all the text about "lacuna values" should just be removed, as it's confusing.
Plus, as @tabatkins pointed out on the mailing list, lacuna value is an undefined term from old SVG specs.
Since the phrase used by the spec is "lacuna value for interpolation", perhaps the main intent is to define the no-op version of each function in order to insert into a filter list. Which makes perfect sense, and should be defined. But it is not at all clear from the language used.
I think a no-parameter version makes sense for
None of the others make sense without a parameter. It would be confusing if these three were given maximum-effect parameter-less versions but the others were given no-op parameter-less versions.
The no-op versions for interpolation still need to be defined, but I recommend avoiding the term "lacuna value". CSS Transforms uses the phrase "identity transform function", since these are functions that compute to the identity matrix; I'm not sure whether talking about an "identity filter function" helps anything.
FTR, Blink has a use counter for the "no arguments" case:
Blink currently implements the "default value" for
Lacuna values are used when interpolating per https://www.w3.org/TR/filter-effects/#interpolation-of-filters. Changing the lacuna value would change how interpolation works in some cases. Firefox implements that specification text and uses lacuna values at that point. The default values are not superfluous even though in markup they are required.
According to the Blink use counter quite a lot of ppl use "no argument" functions. As @longsonr mentions, the default values were introduced for interpolation.
Now I see the following problem:
Yes? That's completely fine. The "no-op" version of a function and the "default arguments" version of a function have no intrinsic connection to each other, and will naturally be different in cases where there is a "maximum" version of the effect. (The "max" is probably what you want to default to when no arguments are specified.)
Yes, the default parameter should be completely different from the "value that is equivalent to
The no-effect values for each filter are only there for interpolation to
@AmeliaBR The spec does say initial value for interpolation.
I did. run some testing in Safari and Chrome. Both support value-less filter functions for all functions but
Firefox follows the spec still.
IMO most values do make sense. I don't think that
The Working Group just discussed
The full IRC log of that discussion<dael> Topic: [filter-effects] Make grayscale() work without parameters
<dael> github: https://github.com/w3c/fxtf-drafts/issues/1
<dael> AmeliaBR: The shorthand functions as currently defined all have required parameters. For the one prompting this, though it applies to a few, to get a grayscale filter you have to say 100%, That wasn't how it worked in webkit prefixed and when I checked it last June even without hte prefix safari & chrome support a number of functions without param
<dael> AmeliaBR: Confusing part is the way the functions are defined in some there is an obvious do this all the way, like gray scale 100% is all the way gray scale. Other functions have two possible directions. You can make something lighter or darker. For those 100% is no effect.
<dael> AmeliaBR: That's the baseline and you need more or less than 100%.
<Chris> Agree with AmeliaBR grayscale() equivalent to grayscale(100%) and same for sepia and invert
<dael> AmeliaBR: I think that's why this spec was defined as it was. For the effects like grayscale where there is a clear apply this completely it's a nice author convenience to not have the 100% on greyscale. We also have existing differences in impl.
<dael> krit: I'd like to add webkit and blink do support none arguments for everything except drop shadow. It's convenient to have no argument for some fucntions. The toher kinds of functions if you don't specify it's no effect. If there's no value for opacity you don't get opacity
<dael> krit: Do we agree sepia, grayscale and intvert don't need a scale and would result in complete change. And if yes do we want the others to not require a param is that no effect?
<dael> Chris: It seems obvious that if there's no param it does the obvious thing. Only down side is the knock on items for interpolation. It's not clear that's been sorted, but if we can do that yes.
<dael> AmeliaBR: I've never tested safari and chrome for transitions. I'm assuming they treat greyscale no param as 100%. There would be text about serialization.
<dael> leaverou: I would agree to sensible defaults. I seem to recall being confused on grayscale no param, but I jsut tried it on chrome so perhaps it's been fixed.
<astearns> ack Chris
<dael> krit: Also possible to keep as is on L1 and think about good options for L2.
<dael> krit: To chris we think about different initial for normal and interpolation so differing between two initial values is fine.
<dael> smfr: I'd prefer we spec L1 in terms of what browsers impl. So I'm fine having no arguments in L1. I don't htink animations would be a problem, so I don't see anything tricky there.
<fantasai> +1 to smfr
<dael> krit: Only webkit and blink support without arguments with the exception of drop shadow.
<dael> smfr: But if spec requires arguments there's compat issues. It seems harmless to allow no arguments then require and later on allow optional.
<dael> fantasai: I would agree we should allow no argument where there is an obvious default. I'm less convinced for all the others.
<dael> AmeliaBR: I think it would be best ot resolve soon b/c we do have browser issues. If the end is allow some and not others I'd like to see impl match asap.
<dael> AmeliaBR: Otherwise...right now the other ones are no effect independantly but if they're in a filter list, like a transition, there's a question as to if that's a valid parsing sequence. You could suddenly break a site so we want to resolve asap.
<dael> krit: And it's a Q if safari webkit and blink are willing to change if we change requirements.
<dael> smfr: I think that's too much of a compat risk.
<dael> krit: In this cas eit makes sense to make arguments optional and we need to decide what happens for those that it's no obvious. Most are no effect. Brightness it will use 0 and I'm not sure that's preferred and if content relies on that.
<dael> krit: smfr would you be willing the change brightness to no effect if ther'es no argument.
<dael> smfr: I don't know. I'm not sure if brightness [missed]
<dael> AmeliaBR: Logically brightness should behave like contrast or saturate because you can increase and decrease. Brightness 100% is no effect. I'm not sure why no param as 0 was impl.
<dael> smfr: I don't feel too strongly. But brightness without arguments doesn't seem common.
<dael> krit: Would you change brightness w/o arguements to no effect?
<dael> smfr: I think so.
<dael> krit: Drop shadow asside we agree we'd have arguments on filter functions be option. specia graysale and invert it would be the opposite and for the others no effect.
<dael> smfr: sgtm
<dael> astearns: Obj?
<AmeliaBR> s/the opposite/the complete effect/
<dael> RESOLVED: Allow filter functions to work without params. Drop shadow aside arguments on filter functions be optional. sepia graysale and invert it would be the opposite and for the others no effect.
<dael> astearns: Chris added a needs test case.
<dael> krit: Agree