New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[filter-effects] Make grayscale() work without parameters #1

Closed
AmeliaBR opened this Issue Mar 14, 2016 · 15 comments

Comments

Projects
None yet
10 participants
@AmeliaBR

AmeliaBR commented Mar 14, 2016

As brought up by @svgeesus on the mailing list:

The ED of filters says that the lacuna value for the grayscale filter is zero.

However:

  • the syntax does not seem to allow the argument to be omitted so how
    can the lacuna value be used
  • if it did, then 0 is an odd value

0 means no change. Thus seems unintuitive. I would expect grayscale()
to be equivalent to grayscale(100%) which is likely what authors would
expect and would be convenient for the most common use case "make this
grayscale".

Suggested fix:

  • change the grayscale filter syntax to make the argument optional
  • change the lacuna value to 1

For what it's worth, this seems to be how -webkit-filter is implemented.
In other words, -webkit-filter: grayscale() applies 100% grayscale filter
(in Chrome anyway, haven't tested Safari).

For implementers of the standard property, neither Edge nor Firefox
currently support the function without a parameter, so changing the lacuna
value would not break anything that isn't already broken.

@dirkschulze

This comment has been minimized.

Show comment
Hide comment
@dirkschulze

dirkschulze Apr 26, 2016

Contributor

@AmeliaBR Firefox does not support grayscale() and other filter functions without values. This probably should be brought up to the CSS WG but IIRC it was decided not to allow functions without values even though -webkit-filter does allow this. But I am not entirely sure. Maybe worth confirming.

Contributor

dirkschulze commented Apr 26, 2016

@AmeliaBR Firefox does not support grayscale() and other filter functions without values. This probably should be brought up to the CSS WG but IIRC it was decided not to allow functions without values even though -webkit-filter does allow this. But I am not entirely sure. Maybe worth confirming.

@AmeliaBR

This comment has been minimized.

Show comment
Hide comment
@AmeliaBR

AmeliaBR Apr 26, 2016

@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.

AmeliaBR commented Apr 26, 2016

@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.

@dirkschulze

This comment has been minimized.

Show comment
Hide comment
@dirkschulze

dirkschulze Apr 26, 2016

Contributor

@AmeliaBR If we require input values the default values are indeed superfluous. I am currently going through the minutes to get confirmation for a resolution on this topic.

Contributor

dirkschulze commented Apr 26, 2016

@AmeliaBR If we require input values the default values are indeed superfluous. I am currently going through the minutes to get confirmation for a resolution on this topic.

@dirkschulze

This comment has been minimized.

Show comment
Hide comment
@dirkschulze

dirkschulze Apr 26, 2016

Contributor

@dbaron @jwatt I am still looking through the minutes. Would Firefox be willing to support filter functions without function values? Note: This does not just affect grayscale() but all filter functions.

Contributor

dirkschulze commented Apr 26, 2016

@dbaron @jwatt I am still looking through the minutes. Would Firefox be willing to support filter functions without function values? Note: This does not just affect grayscale() but all filter functions.

@mstange

This comment has been minimized.

Show comment
Hide comment
@mstange

mstange Sep 29, 2016

I don't see why not. Especially grayscale() makes a lot of intuitive sense without arguments.

mstange commented Sep 29, 2016

I don't see why not. Especially grayscale() makes a lot of intuitive sense without arguments.

@AmeliaBR

This comment has been minimized.

Show comment
Hide comment
@AmeliaBR

AmeliaBR Sep 29, 2016

I think a no-parameter version makes sense for

  • grayscale() equivalent to grayscale(100%)
  • sepia() equivalent to sepia(100%)
  • invert() equivalent to invert(100%)

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.

AmeliaBR commented Sep 29, 2016

I think a no-parameter version makes sense for

  • grayscale() equivalent to grayscale(100%)
  • sepia() equivalent to sepia(100%)
  • invert() equivalent to invert(100%)

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.

@fsoder

This comment has been minimized.

Show comment
Hide comment
@fsoder

fsoder Dec 6, 2016

Collaborator

FTR, Blink has a use counter for the "no arguments" case:
https://www.chromestatus.com/metrics/feature/timeline/popularity/1403

Blink currently implements the "default value" for grayscale(), sepia() and invert() per @AmeliaBR's suggestion above, so there should be a decent chance for compat there. We could consider adding a counter for the other functions to see if that's a combination that authors use.

Collaborator

fsoder commented Dec 6, 2016

FTR, Blink has a use counter for the "no arguments" case:
https://www.chromestatus.com/metrics/feature/timeline/popularity/1403

Blink currently implements the "default value" for grayscale(), sepia() and invert() per @AmeliaBR's suggestion above, so there should be a decent chance for compat there. We could consider adding a counter for the other functions to see if that's a combination that authors use.

@longsonr

This comment has been minimized.

Show comment
Hide comment
@longsonr

longsonr Mar 1, 2017

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.

longsonr commented Mar 1, 2017

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.

@dirkschulze

This comment has been minimized.

Show comment
Hide comment
@dirkschulze

dirkschulze Jun 8, 2017

Contributor

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:
grayscale() means grayscale(1) in WebKit/Blink
The lacuna value/initial value/default value (will open a different issue for the term) currently is 0 in the spec. For interpolation that makes a lot of sense and I'd be surprised if WebKit would not use 0 in this case CC @grorg @smfr . So we might end up defining a used value for interpolation and a different used value if no value was specified by the user.

Contributor

dirkschulze commented Jun 8, 2017

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:
grayscale() means grayscale(1) in WebKit/Blink
The lacuna value/initial value/default value (will open a different issue for the term) currently is 0 in the spec. For interpolation that makes a lot of sense and I'd be surprised if WebKit would not use 0 in this case CC @grorg @smfr . So we might end up defining a used value for interpolation and a different used value if no value was specified by the user.

@tabatkins

This comment has been minimized.

Show comment
Hide comment
@tabatkins

tabatkins Jun 8, 2017

Member

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.)

Member

tabatkins commented Jun 8, 2017

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.)

@AmeliaBR

This comment has been minimized.

Show comment
Hide comment
@AmeliaBR

AmeliaBR Jun 9, 2017

Yes, the default parameter should be completely different from the "value that is equivalent to none". Otherwise, there's not much point in having a default parameter.

The no-effect values for each filter are only there for interpolation to none, and that needs to be clear. The "lacuna value" term was confusing, since elsewhere that term was used for default values. (Also, it's just a confusing, arbitrary jargon term in the first place.)

AmeliaBR commented Jun 9, 2017

Yes, the default parameter should be completely different from the "value that is equivalent to none". Otherwise, there's not much point in having a default parameter.

The no-effect values for each filter are only there for interpolation to none, and that needs to be clear. The "lacuna value" term was confusing, since elsewhere that term was used for default values. (Also, it's just a confusing, arbitrary jargon term in the first place.)

@dirkschulze

This comment has been minimized.

Show comment
Hide comment
@dirkschulze

dirkschulze Jun 11, 2017

Contributor

@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 drop-shadow():

  • blur(): blur(0) no effect
  • brightness(): brightness(0)
  • contrast(): contrast(1) no effect
  • drop-shadow(): not supported
  • grayscale(): grayscale(1)
  • hue-rotate(): hue-rotate(0) no effect
  • invert(): invert(1)
  • opacity(): opacity(1) no effect
  • sepia(): sepia(1)
  • saturate(): saturate(1) no effect

Firefox follows the spec still.

saturate(), contrast don't seem to follow the general default values but IMO make sense. There is no clear "opposite".

IMO most values do make sense. I don't think that brightness(0) as default is useful since it simply turns elements to black. I rather would align them with saturate(), contrast.

@grorg @smfr Do you remember the thoughts that went into the default behavior?

Contributor

dirkschulze commented Jun 11, 2017

@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 drop-shadow():

  • blur(): blur(0) no effect
  • brightness(): brightness(0)
  • contrast(): contrast(1) no effect
  • drop-shadow(): not supported
  • grayscale(): grayscale(1)
  • hue-rotate(): hue-rotate(0) no effect
  • invert(): invert(1)
  • opacity(): opacity(1) no effect
  • sepia(): sepia(1)
  • saturate(): saturate(1) no effect

Firefox follows the spec still.

saturate(), contrast don't seem to follow the general default values but IMO make sense. There is no clear "opposite".

IMO most values do make sense. I don't think that brightness(0) as default is useful since it simply turns elements to black. I rather would align them with saturate(), contrast.

@grorg @smfr Do you remember the thoughts that went into the default behavior?

@dirkschulze dirkschulze added the Agenda+ label Jan 2, 2018

@smfr

This comment has been minimized.

Show comment
Hide comment
@smfr

smfr Jan 24, 2018

I don't.

smfr commented Jan 24, 2018

I don't.

@css-meeting-bot

This comment has been minimized.

Show comment
Hide comment
@css-meeting-bot

css-meeting-bot Jan 24, 2018

Member

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.
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.
<Chris> q+
<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.
<fantasai> +1
<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
Member

css-meeting-bot commented Jan 24, 2018

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.
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.
<Chris> q+
<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.
<fantasai> +1
<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
@dirkschulze

This comment has been minimized.

Show comment
Hide comment
@dirkschulze

dirkschulze May 31, 2018

Contributor

Keeping "Needs WPT test" but close the issue.

Contributor

dirkschulze commented May 31, 2018

Keeping "Needs WPT test" but close the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment