Re: [fxtf-drafts] [filter-effects] Make grayscale() work without parameters

The Working Group just discussed `[filter-effects] Make grayscale() work without parameters`, and agreed to the following resolutions:

* `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.`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: [filter-effects] Make grayscale() work without parameters<br>
&lt;dael> github:<br>
&lt;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 &amp; chrome support a number of functions without param<br>
&lt;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.<br>
&lt;dael> AmeliaBR: That's the baseline and you need more or less than 100%.<br>
&lt;Chris> Agree with AmeliaBR grayscale() equivalent to grayscale(100%) and same for sepia and invert<br>
&lt;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.<br>
&lt;Chris> q+<br>
&lt;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<br>
&lt;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?<br>
&lt;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.<br>
&lt;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.<br>
&lt;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.<br>
&lt;astearns> ack Chris<br>
&lt;dael> krit: Also possible to keep as is on L1 and think about good options for L2.<br>
&lt;dael> krit: To chris we think about different initial for normal and interpolation so differing between two initial values is fine.<br>
&lt;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.<br>
&lt;fantasai> +1 to smfr<br>
&lt;dael> krit: Only webkit and blink support without arguments with the exception of drop shadow.<br>
&lt;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.<br>
&lt;dael> fantasai: I would agree we should allow no argument where there is an obvious default. I'm less convinced for all the others.<br>
&lt;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.<br>
&lt;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.<br>
&lt;dael> krit: And it's a Q if safari webkit and blink are willing to change if we change requirements.<br>
&lt;dael> smfr: I think that's too much of a compat risk.<br>
&lt;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.<br>
&lt;dael> krit: smfr would you be willing the change brightness to no effect if ther'es no argument.<br>
&lt;dael> smfr: I don't know. I'm not sure if brightness [missed]<br>
&lt;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.<br>
&lt;fantasai> +1<br>
&lt;dael> smfr: I don't feel too strongly. But brightness without arguments doesn't seem common.<br>
&lt;dael> krit: Would you change brightness w/o arguements to no effect?<br>
&lt;dael> smfr: I think so.<br>
&lt;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.<br>
&lt;dael> smfr: sgtm<br>
&lt;dael> astearns: Obj?<br>
&lt;AmeliaBR> s/the opposite/the complete effect/<br>
&lt;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.<br>
&lt;dael> astearns: Chris added a needs test case.<br>
&lt;dael> krit: Agree<br>

GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at using your GitHub account

Received on Wednesday, 24 January 2018 17:44:00 UTC