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

[css-ui] Unprefix 'appearance' and/or make the spec web-compatible #3024

Open
zcorpan opened this Issue Aug 17, 2018 · 36 comments

Comments

Projects
None yet
@zcorpan
Member

zcorpan commented Aug 17, 2018

In whatwg/html#3912 there is a proposal to specify two new values of the 'appearance' for the fieldset and legend elements.

I note that none of WebKit, Chromium, Gecko or Edge support 'appearance' unprefixed, but they do support 'webkit-appearance'.

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/6114

Would it be reasonable to unprefix it?

cc @mstensho @MatsPalmgren @dholbert @emilio @thejohnjansen @smfr

@zcorpan

This comment has been minimized.

Show comment
Hide comment
@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk
Member

annevk commented Aug 17, 2018

@emilio

This comment has been minimized.

Show comment
Hide comment
@emilio

emilio Aug 17, 2018

Collaborator

The current spec (https://drafts.csswg.org/css-ui/#propdef-appearance) is not web-compatible at all. I'd be against unprefixing it without a proper spec for the property.

cc @FremyCompany too

Collaborator

emilio commented Aug 17, 2018

The current spec (https://drafts.csswg.org/css-ui/#propdef-appearance) is not web-compatible at all. I'd be against unprefixing it without a proper spec for the property.

cc @FremyCompany too

@jwatt

This comment has been minimized.

Show comment
Hide comment
@jwatt

jwatt Aug 17, 2018

Will all browsers going to support the -webkit prefixed variant, and a lot of content using that, I'm not sure there's a ton of value in unprefixing. It would certainly be great to get a spec written for this though as emilio says. I have some notes that I'm going to try and get tidied up in the near future.

jwatt commented Aug 17, 2018

Will all browsers going to support the -webkit prefixed variant, and a lot of content using that, I'm not sure there's a ton of value in unprefixing. It would certainly be great to get a spec written for this though as emilio says. I have some notes that I'm going to try and get tidied up in the near future.

@zcorpan

This comment has been minimized.

Show comment
Hide comment
@zcorpan

zcorpan Aug 22, 2018

Member

I think it would be good to have a spec that is closer to what browsers are willing to implement. I may be able to work on that in the near term.

Member

zcorpan commented Aug 22, 2018

I think it would be good to have a spec that is closer to what browsers are willing to implement. I may be able to work on that in the near term.

@zcorpan zcorpan changed the title from [css-ui] Unprefix 'appearance' to [css-ui] Unprefix 'appearance' and/or make the spec web-compatible Aug 23, 2018

@zcorpan

This comment has been minimized.

Show comment
Hide comment
@zcorpan
Member

zcorpan commented Aug 24, 2018

@zcorpan

This comment has been minimized.

Show comment
Hide comment
@zcorpan
Member

zcorpan commented Aug 27, 2018

@frivoal

This comment has been minimized.

Show comment
Hide comment
@frivoal

frivoal Aug 29, 2018

Contributor

The version specified in css-ui-4 isn't meant to be exactly identical to the prefixed version, as the prefixed version is sort of insane. The biggest problem with the prefixed version is that there's not value that lets native form control just do their normal thing. You need a gigantic list of values, some of which are meant to apply to non-standard pseudo elements that represent parts of form controls.

As far as I know, no browser is planning on harmonizing the full list of pseudos+values.

The proposed "standard" version has an "auto" value to cope with that problem, so you don't need the full laundry list of values (and associated pseudos) for it to work at all. auto does nothing on divs, and does the right thin on the right type of control.

That said, we could add a few select values that people do want to opt into, either because they're genuinely useful, or for compat reasons. Browser representatives in the css wg have so far objected to doing that, but there's nothing in the design of the property that prevents us from adding more than just auto and none.

If we do add more, there are two ways to go about it. appearance: foo (with foo being something else than auto and none, such as buttton, or fieldset…) could mean either:

  • just turn anything into a foo, so you can turn regular divs into foos, you can turn bars into foos, etc.
  • do the same as auto

The second one is much more limited, but also much easier to implement. The reason it might be useful despite the limitation is that very often, people use that value to negate an earlier appearance: none and turn back the control into what it was supposed to be in the first place. Had they had an auto value, they'd have used that, but they don't so they're being specific. Since browser have so far said that they're not terribly interested in letting people turn buttons into fieldsets, or select menus into legends, maybe that's an easier path. Last time we talked about it, it looked like this might be enough to make the "standard" appearance web compatible, but this was not an in depth investigation. We should do one.

The other thing that needs to be investigated in depth is exactly what appearance: none does, and how much of the form controls' parts it turns off. In the prefixed version, this is a relatively straightforward question, and the complexity is in how many non-standards pseudos you need to apply it to if you want to make various bits go away. But since the standard version is trying to do without pseudos, we need a detailed answer to that question.

The high level principle is that since this is an appearance property, not a behavior property, it should leave everything that is necessary to be able to operate the control and for which a functional equivalent cannot be otherwise recreated in pure CSS, within the limits allowed by web compat. However, going through all the form controls and figuring out exactly what that means for each of them hasn't been done.

Contributor

frivoal commented Aug 29, 2018

The version specified in css-ui-4 isn't meant to be exactly identical to the prefixed version, as the prefixed version is sort of insane. The biggest problem with the prefixed version is that there's not value that lets native form control just do their normal thing. You need a gigantic list of values, some of which are meant to apply to non-standard pseudo elements that represent parts of form controls.

As far as I know, no browser is planning on harmonizing the full list of pseudos+values.

The proposed "standard" version has an "auto" value to cope with that problem, so you don't need the full laundry list of values (and associated pseudos) for it to work at all. auto does nothing on divs, and does the right thin on the right type of control.

That said, we could add a few select values that people do want to opt into, either because they're genuinely useful, or for compat reasons. Browser representatives in the css wg have so far objected to doing that, but there's nothing in the design of the property that prevents us from adding more than just auto and none.

If we do add more, there are two ways to go about it. appearance: foo (with foo being something else than auto and none, such as buttton, or fieldset…) could mean either:

  • just turn anything into a foo, so you can turn regular divs into foos, you can turn bars into foos, etc.
  • do the same as auto

The second one is much more limited, but also much easier to implement. The reason it might be useful despite the limitation is that very often, people use that value to negate an earlier appearance: none and turn back the control into what it was supposed to be in the first place. Had they had an auto value, they'd have used that, but they don't so they're being specific. Since browser have so far said that they're not terribly interested in letting people turn buttons into fieldsets, or select menus into legends, maybe that's an easier path. Last time we talked about it, it looked like this might be enough to make the "standard" appearance web compatible, but this was not an in depth investigation. We should do one.

The other thing that needs to be investigated in depth is exactly what appearance: none does, and how much of the form controls' parts it turns off. In the prefixed version, this is a relatively straightforward question, and the complexity is in how many non-standards pseudos you need to apply it to if you want to make various bits go away. But since the standard version is trying to do without pseudos, we need a detailed answer to that question.

The high level principle is that since this is an appearance property, not a behavior property, it should leave everything that is necessary to be able to operate the control and for which a functional equivalent cannot be otherwise recreated in pure CSS, within the limits allowed by web compat. However, going through all the form controls and figuring out exactly what that means for each of them hasn't been done.

@frivoal

This comment has been minimized.

Show comment
Hide comment
@frivoal

frivoal Aug 29, 2018

Contributor

Anway, I think that there isn't anything specific we can do in this issue, and what we need to do is to close the related #1250, my preference being to do it by picking option 7 in comment #1250 (comment).

Are y'all OK with closing this as a duplicate, and resuming the discussion there?

Contributor

frivoal commented Aug 29, 2018

Anway, I think that there isn't anything specific we can do in this issue, and what we need to do is to close the related #1250, my preference being to do it by picking option 7 in comment #1250 (comment).

Are y'all OK with closing this as a duplicate, and resuming the discussion there?

@annevk

This comment has been minimized.

Show comment
Hide comment
@annevk

annevk Aug 30, 2018

Member

I don't know, I'm much more favorable (and I think I can safely say that this goes for Mozilla as a whole) to a plan for standardizing -webkit-appearance as a start (since we all have to implement it, yay web), than adding a bunch of new functionality in a similarly named property with vastly different semantics.

Member

annevk commented Aug 30, 2018

I don't know, I'm much more favorable (and I think I can safely say that this goes for Mozilla as a whole) to a plan for standardizing -webkit-appearance as a start (since we all have to implement it, yay web), than adding a bunch of new functionality in a similarly named property with vastly different semantics.

@frivoal

This comment has been minimized.

Show comment
Hide comment
@frivoal

frivoal Aug 30, 2018

Contributor

Starndardizing -webkit-appearance means explaining form controls with it in the UA stylesheet, and having the full list of values and pseudo elements to go along, since that's how it works in Blink/Webkit. The feedback I've heard in the csswg from all browsers so far was that people were not willing to do that, because it is a very leaky abstraction: the list was gigantic (and includes pseudos elements) to cover every imaginable form control and sub-component of form control, but also it needs to evolve each time we come up with a new form control, and isn't even necessarily the same on different platforms.

Maybe that has changed, but then we need to realize that this cannot be limited to just specifying and/or unprefix webkit-appearance with the none value and a handful of other values. If we actually want to do the same thing, we'll need to go through a giant list of things that include stuff like searchfield-cancel-button or sliderthumb-horizontal, and also implement all the pseudo elements to go with it. If we don't do that, the property doesn't work standalone.

As far as I understand, web compat efforts around -webkit-appearance so far have not been that, and instead rely on the existence of some other unspecified mechanism (-moz-appearance) to explain the rest of the form control's appearance, that -webkit-appearance overrides (in an undefined way) when it has a specified value.

A normal css property needs to have a computed value on all elements, and the few values that have been found needed for web compat are insufficient to cover all elements. We could specify that -webkit-appearance is not a regular property, but actually some kind of shorthand to a non specified property, and in that way, limit the values we support in -webkit-appearance to those needed by cross-browser web compat.

I don't object to doing that, but specifying the shorthand without the longhand feels a little weird. That said, we could prioritize that, since it is needed for compat, and worry about that rest later.

I suspect that for "the rest", there's only two alternatives though:

  • one that uses auto (in addition to the few values needed for compat) to explain form control behavior in general
  • one that has the full laundry list of everything imaginable, and comes with a bunch of pseudos elements.

and I think I can safely say that this goes for Mozilla as a whole

I don't know. In previous CSS meeting representatives from Mozilla have specifically pushed back to having any other value than none and auto.

Contributor

frivoal commented Aug 30, 2018

Starndardizing -webkit-appearance means explaining form controls with it in the UA stylesheet, and having the full list of values and pseudo elements to go along, since that's how it works in Blink/Webkit. The feedback I've heard in the csswg from all browsers so far was that people were not willing to do that, because it is a very leaky abstraction: the list was gigantic (and includes pseudos elements) to cover every imaginable form control and sub-component of form control, but also it needs to evolve each time we come up with a new form control, and isn't even necessarily the same on different platforms.

Maybe that has changed, but then we need to realize that this cannot be limited to just specifying and/or unprefix webkit-appearance with the none value and a handful of other values. If we actually want to do the same thing, we'll need to go through a giant list of things that include stuff like searchfield-cancel-button or sliderthumb-horizontal, and also implement all the pseudo elements to go with it. If we don't do that, the property doesn't work standalone.

As far as I understand, web compat efforts around -webkit-appearance so far have not been that, and instead rely on the existence of some other unspecified mechanism (-moz-appearance) to explain the rest of the form control's appearance, that -webkit-appearance overrides (in an undefined way) when it has a specified value.

A normal css property needs to have a computed value on all elements, and the few values that have been found needed for web compat are insufficient to cover all elements. We could specify that -webkit-appearance is not a regular property, but actually some kind of shorthand to a non specified property, and in that way, limit the values we support in -webkit-appearance to those needed by cross-browser web compat.

I don't object to doing that, but specifying the shorthand without the longhand feels a little weird. That said, we could prioritize that, since it is needed for compat, and worry about that rest later.

I suspect that for "the rest", there's only two alternatives though:

  • one that uses auto (in addition to the few values needed for compat) to explain form control behavior in general
  • one that has the full laundry list of everything imaginable, and comes with a bunch of pseudos elements.

and I think I can safely say that this goes for Mozilla as a whole

I don't know. In previous CSS meeting representatives from Mozilla have specifically pushed back to having any other value than none and auto.

@zcorpan

This comment has been minimized.

Show comment
Hide comment
@zcorpan

zcorpan Aug 30, 2018

Member

We don't necessarily need to match webkit/chromium exactly. We can specify the intersection of what browsers do, and look at httparchive to find out what is neccessary for web compat.

Member

zcorpan commented Aug 30, 2018

We don't necessarily need to match webkit/chromium exactly. We can specify the intersection of what browsers do, and look at httparchive to find out what is neccessary for web compat.

@frivoal

This comment has been minimized.

Show comment
Hide comment
@frivoal

frivoal Aug 30, 2018

Contributor

I'm not sure I understand what you propose doing. As far as I understand, both Webkit/chromium and gecko fully describe the look of all form controls using the appearance property on elements and their pseudos, using the UA stylesheet. Either we've got the full set, and we can use the property that way, or we don't we need to explain form controls differently.

An appearance property that only has a subset of the value wouldn't work the same way as the webkit (or moz) prefixed one. Not just in the sense that it lacks values, but the way it works in general would have to be different.

For instance, let's say we have an appearance property that only none, button, checkbox, and fieldset. What's the computed value on <input type=search>?

  • If it's something like auto, we're back the the spec's proposal. Which I think is a reasonable approach, but it not what browsers are currently doing.
  • If it's a value specific to the element (searchfield?), then we need the full list that describes every form control, and for every single one of them agree if it is fully described by a single value on the element, or if you also need pseudo elements to described subcomponents. Like the little "x" that chrome gives you to clear the content of a <input type=search> using ::-webkit-search-cancel-button { -webkit-appearance: searchfield-cancel-button; }: do you have to have that pseudo and that value, or can/must it be implied by appearance: searchfield?
  • If there's no computed value, then the property is something like a shorthand, but a shorthand to what?

I think we can get away with specifying the webkit prefixed one as a shorthand to something, and leave the something to later.

But we'll eventually need to come back to what that is, and I suspect a property with an auto value is a much more standardizable answer than a giant list that needs to cover for every variation of every form control on every platform.

Contributor

frivoal commented Aug 30, 2018

I'm not sure I understand what you propose doing. As far as I understand, both Webkit/chromium and gecko fully describe the look of all form controls using the appearance property on elements and their pseudos, using the UA stylesheet. Either we've got the full set, and we can use the property that way, or we don't we need to explain form controls differently.

An appearance property that only has a subset of the value wouldn't work the same way as the webkit (or moz) prefixed one. Not just in the sense that it lacks values, but the way it works in general would have to be different.

For instance, let's say we have an appearance property that only none, button, checkbox, and fieldset. What's the computed value on <input type=search>?

  • If it's something like auto, we're back the the spec's proposal. Which I think is a reasonable approach, but it not what browsers are currently doing.
  • If it's a value specific to the element (searchfield?), then we need the full list that describes every form control, and for every single one of them agree if it is fully described by a single value on the element, or if you also need pseudo elements to described subcomponents. Like the little "x" that chrome gives you to clear the content of a <input type=search> using ::-webkit-search-cancel-button { -webkit-appearance: searchfield-cancel-button; }: do you have to have that pseudo and that value, or can/must it be implied by appearance: searchfield?
  • If there's no computed value, then the property is something like a shorthand, but a shorthand to what?

I think we can get away with specifying the webkit prefixed one as a shorthand to something, and leave the something to later.

But we'll eventually need to come back to what that is, and I suspect a property with an auto value is a much more standardizable answer than a giant list that needs to cover for every variation of every form control on every platform.

@zcorpan

This comment has been minimized.

Show comment
Hide comment
@zcorpan

zcorpan Aug 30, 2018

Member

We can specify the intersection of what browsers do,

This would be https://compat.spec.whatwg.org/#css-non-aliased - we can use that as a starting point, and define what those values mean.

and look at httparchive to find out what is neccessary for web compat.

https://gist.github.com/zcorpan/191f7d0183b7b41c8d44fc6fe12ac0d7

We can decide based on this data that we don't need to support the button-arrow-down value (supported by Firefox), since only 1 page uses it.

We might also decide to add "normal" as a keyword (instead of "auto"?), or take a closer look at those pages to see what they expect.

etc.

Member

zcorpan commented Aug 30, 2018

We can specify the intersection of what browsers do,

This would be https://compat.spec.whatwg.org/#css-non-aliased - we can use that as a starting point, and define what those values mean.

and look at httparchive to find out what is neccessary for web compat.

https://gist.github.com/zcorpan/191f7d0183b7b41c8d44fc6fe12ac0d7

We can decide based on this data that we don't need to support the button-arrow-down value (supported by Firefox), since only 1 page uses it.

We might also decide to add "normal" as a keyword (instead of "auto"?), or take a closer look at those pages to see what they expect.

etc.

@frivoal

This comment has been minimized.

Show comment
Hide comment
@frivoal

frivoal Aug 31, 2018

Contributor

It seems to me that we're talking past each other.

Specifying the intersection of values that all browsers support (or possibly the subset that are actually used in web pages), as well as the values that only chrome supports but that are needed for web compat. This is not hard.

However, this does not answer the question of how the property works as a whole, and we need to answer that question if we're supposed to standardize it.

  1. Do we expect each browser to support the specified handful of values plus a gazillion proprietary values and corresponding pseudo-elements to describe the rest of form controls?
  2. Do we expect the rest of form controls to be handled by a single magic value that means "do the right thing", called auto or normal?
  3. Do we expect the rest of form controls to be handled by a separate mechanism, that is only overridden when the -webkit-appearance property is set (implying that -webkit-appearance isn't a regular property, but something like a shorthand, since it would otherwise have to have an effect on all elements, which brings us back to option 1 or 2)?

We might also decide to add normal as a keyword (instead of auto?)

This is the approach I am pushing for, so I'm happy to go with it, but I don't see how the name of that keyword makes any difference. I'm happy to take normal over auto if that makes something easier, or even if that's a mere preference.

Contributor

frivoal commented Aug 31, 2018

It seems to me that we're talking past each other.

Specifying the intersection of values that all browsers support (or possibly the subset that are actually used in web pages), as well as the values that only chrome supports but that are needed for web compat. This is not hard.

However, this does not answer the question of how the property works as a whole, and we need to answer that question if we're supposed to standardize it.

  1. Do we expect each browser to support the specified handful of values plus a gazillion proprietary values and corresponding pseudo-elements to describe the rest of form controls?
  2. Do we expect the rest of form controls to be handled by a single magic value that means "do the right thing", called auto or normal?
  3. Do we expect the rest of form controls to be handled by a separate mechanism, that is only overridden when the -webkit-appearance property is set (implying that -webkit-appearance isn't a regular property, but something like a shorthand, since it would otherwise have to have an effect on all elements, which brings us back to option 1 or 2)?

We might also decide to add normal as a keyword (instead of auto?)

This is the approach I am pushing for, so I'm happy to go with it, but I don't see how the name of that keyword makes any difference. I'm happy to take normal over auto if that makes something easier, or even if that's a mere preference.

@frivoal

This comment has been minimized.

Show comment
Hide comment
@frivoal

frivoal Aug 31, 2018

Contributor

Following up from the points I make above, I think the -webkit-appearance as described in https://compat.spec.whatwg.org/#css-non-aliased is problematic, as it's trying to take an easier path that doesn't really exist, and leads to contradictions.

The initial value must be none

Therefore, it has an initial value. Therefore it has a value on all elements, and isn't something like a shorthand. In the absence of author styles, the value is either none, or what the UA stylesheet specifies for each form control.

Since none is expected to suppress the native look and feel of every form control, form controls that do have a native look and feel must be set to some value other than none. Let's see what that value can be.

These values must be supported: […]

The UA stylesheet can use these, and the corresponding form controls will have their native look. So far so good.

(note that it is neither a giant list, nor includes auto)

More values may be supported, but [...]

Ok, let's see what the restrictions are.

The appearance property must not be supported, since it is not web-compatible as currently defined

I believe this argues against having an auto value, since that is the main difference. So there cannot be a neutral/magic/normal/auto value, that just let form controls look like their normal selves without specifying what that self is.

Implementers are encouraged to only support values that are necessary for web compatibility

As a mechanical consequence of the previous points, implementers either have to ignore that recommendation and do the full giant list anyway, or add auto (but there's a must against it), or decide that they will not have a native appearance any other form control than those listed in the short list of required values (plus the few more values that should be added to that list for web compat).


I don't believe that the intention of this piece of text was to make a recommendation that is impossible to follow, nor that it intended to limit the list of form controls available on the web to just 13+ε types.

This means that that definition is broken.


Here's what I suggest we do:

  1. Spec both -webkit-appearance and appearance
  2. Limit the values of -webkit-appearance to none and the values needed for web compat, using those listed in https://compat.spec.whatwg.org/#css-non-aliased as a starting point
  3. Do not define that -webkit-appearance has an initial value. Instead, define it as a shorthand of appearance. This means appearance may have values that cannot be expressed in -webkit-appearance (as needed for the UA stylesheet), and -webkit-appearance can be limited to the values that are required for web compat.
  4. Define the values of appearance to be, none, auto, plus all the values that -webkit-appearance has.
  5. Make auto the initial value of appearance

Optional steps:

  1. If we only care about the web compat values for the sake of undoing an earlier none, and not for the sake of turning any arbitrary element (including form controls) into any other arbitrary form control, we can define that the effect of the compat values is the same as auto.
  2. If we need it for compat reasons on the OM, we could make auto compute to none on non form controls.
  3. If we need it for compat reasons on the OM, we could make auto compute to the appropriate web compat value on the appropriate form controls.
Contributor

frivoal commented Aug 31, 2018

Following up from the points I make above, I think the -webkit-appearance as described in https://compat.spec.whatwg.org/#css-non-aliased is problematic, as it's trying to take an easier path that doesn't really exist, and leads to contradictions.

The initial value must be none

Therefore, it has an initial value. Therefore it has a value on all elements, and isn't something like a shorthand. In the absence of author styles, the value is either none, or what the UA stylesheet specifies for each form control.

Since none is expected to suppress the native look and feel of every form control, form controls that do have a native look and feel must be set to some value other than none. Let's see what that value can be.

These values must be supported: […]

The UA stylesheet can use these, and the corresponding form controls will have their native look. So far so good.

(note that it is neither a giant list, nor includes auto)

More values may be supported, but [...]

Ok, let's see what the restrictions are.

The appearance property must not be supported, since it is not web-compatible as currently defined

I believe this argues against having an auto value, since that is the main difference. So there cannot be a neutral/magic/normal/auto value, that just let form controls look like their normal selves without specifying what that self is.

Implementers are encouraged to only support values that are necessary for web compatibility

As a mechanical consequence of the previous points, implementers either have to ignore that recommendation and do the full giant list anyway, or add auto (but there's a must against it), or decide that they will not have a native appearance any other form control than those listed in the short list of required values (plus the few more values that should be added to that list for web compat).


I don't believe that the intention of this piece of text was to make a recommendation that is impossible to follow, nor that it intended to limit the list of form controls available on the web to just 13+ε types.

This means that that definition is broken.


Here's what I suggest we do:

  1. Spec both -webkit-appearance and appearance
  2. Limit the values of -webkit-appearance to none and the values needed for web compat, using those listed in https://compat.spec.whatwg.org/#css-non-aliased as a starting point
  3. Do not define that -webkit-appearance has an initial value. Instead, define it as a shorthand of appearance. This means appearance may have values that cannot be expressed in -webkit-appearance (as needed for the UA stylesheet), and -webkit-appearance can be limited to the values that are required for web compat.
  4. Define the values of appearance to be, none, auto, plus all the values that -webkit-appearance has.
  5. Make auto the initial value of appearance

Optional steps:

  1. If we only care about the web compat values for the sake of undoing an earlier none, and not for the sake of turning any arbitrary element (including form controls) into any other arbitrary form control, we can define that the effect of the compat values is the same as auto.
  2. If we need it for compat reasons on the OM, we could make auto compute to none on non form controls.
  3. If we need it for compat reasons on the OM, we could make auto compute to the appropriate web compat value on the appropriate form controls.
@MatsPalmgren

This comment has been minimized.

Show comment
Hide comment
@MatsPalmgren

MatsPalmgren Aug 31, 2018

If you suggest that appearance should be available in author sheets, then it seems likely to me that some authors will start using the "internal" appearance values and then we'd have an even bigger mess to sort out eventually...

Fwiw, Gecko can make individual property values available in the UA-sheet only. For example -moz-menulist-button, which we set in the UA-sheet on the <select> disclosure button, is an invalid value in an author sheet and simply doesn't parse there. I think this is the mechanism we'll use to deprecate -webkit-appearance values that we need internally but aren't needed for web-compat.

Would it be possible for other UAs to parse a different set of values for UA/author sheets?

MatsPalmgren commented Aug 31, 2018

If you suggest that appearance should be available in author sheets, then it seems likely to me that some authors will start using the "internal" appearance values and then we'd have an even bigger mess to sort out eventually...

Fwiw, Gecko can make individual property values available in the UA-sheet only. For example -moz-menulist-button, which we set in the UA-sheet on the <select> disclosure button, is an invalid value in an author sheet and simply doesn't parse there. I think this is the mechanism we'll use to deprecate -webkit-appearance values that we need internally but aren't needed for web-compat.

Would it be possible for other UAs to parse a different set of values for UA/author sheets?

@AmeliaBR

This comment has been minimized.

Show comment
Hide comment
@AmeliaBR

AmeliaBR Aug 31, 2018

As an author, I have to say that Florian's argument makes the most sense, even if it means that -webkit-appearance will allow different values than appearance (which all eventually map to auto).

The values that are most useful for authors are none and "actually, I changed my mind, do whatever you'd normally do for this element" (aka auto or normal).

Being able to say that an arbitrary element should be styled like, e.g., a native checkbox or drop-down list, would only be useful if you could also check and uncheck that checkbox, or expand and collapse that list. But as far as I can tell, there are no properties or attributes that allow you to do that. So if you use a specific -webkit-appearance value on a <div>, you only get a random smattering of the native styles, not a complete recreation of the native widget.

If there are specific appearance values that browsers want to make available for styling any arbitrary element, then those should be added. But if a specific value only makes sense on a specific element or pseudo-element, then I don't understand what the web-compat risk is in mapping that value to auto in the unprefixed property.

AmeliaBR commented Aug 31, 2018

As an author, I have to say that Florian's argument makes the most sense, even if it means that -webkit-appearance will allow different values than appearance (which all eventually map to auto).

The values that are most useful for authors are none and "actually, I changed my mind, do whatever you'd normally do for this element" (aka auto or normal).

Being able to say that an arbitrary element should be styled like, e.g., a native checkbox or drop-down list, would only be useful if you could also check and uncheck that checkbox, or expand and collapse that list. But as far as I can tell, there are no properties or attributes that allow you to do that. So if you use a specific -webkit-appearance value on a <div>, you only get a random smattering of the native styles, not a complete recreation of the native widget.

If there are specific appearance values that browsers want to make available for styling any arbitrary element, then those should be added. But if a specific value only makes sense on a specific element or pseudo-element, then I don't understand what the web-compat risk is in mapping that value to auto in the unprefixed property.

@MatsPalmgren

This comment has been minimized.

Show comment
Hide comment
@MatsPalmgren

MatsPalmgren Aug 31, 2018

Isn't the "do whatever you'd normally do for this element" use case already solved by revert?

MatsPalmgren commented Aug 31, 2018

Isn't the "do whatever you'd normally do for this element" use case already solved by revert?

@zcorpan

This comment has been minimized.

Show comment
Hide comment
@zcorpan

zcorpan Sep 1, 2018

Member

https://www.chromestatus.com/metrics/feature/popularity has use counters for different values (search for "CSSValueAppearance"). I don't know yet how to interpret these; it seems CSSValueAppearanceButton is much higher than CSSValueAppearanceButtonForButton.

Also see https://bugs.chromium.org/p/chromium/issues/detail?id=767757

cc @tkent-google

Member

zcorpan commented Sep 1, 2018

https://www.chromestatus.com/metrics/feature/popularity has use counters for different values (search for "CSSValueAppearance"). I don't know yet how to interpret these; it seems CSSValueAppearanceButton is much higher than CSSValueAppearanceButtonForButton.

Also see https://bugs.chromium.org/p/chromium/issues/detail?id=767757

cc @tkent-google

@patrickdark

This comment has been minimized.

Show comment
Hide comment
@patrickdark

patrickdark Sep 1, 2018

Contributor

@zcorpan I'd guess that the appearance property is being used to style links (i.e., a elements) as buttons because of the spec's prohibition on button element links (i.e., both <a href=""><button/></a> and <button><a href=""/></button> are disallowed).

Contributor

patrickdark commented Sep 1, 2018

@zcorpan I'd guess that the appearance property is being used to style links (i.e., a elements) as buttons because of the spec's prohibition on button element links (i.e., both <a href=""><button/></a> and <button><a href=""/></button> are disallowed).

@zcorpan

This comment has been minimized.

Show comment
Hide comment
@zcorpan

zcorpan Sep 1, 2018

Member

But CSSValueAppearanceButtonForAnchor doesn't add up to the general counter.

Member

zcorpan commented Sep 1, 2018

But CSSValueAppearanceButtonForAnchor doesn't add up to the general counter.

@patrickdark

This comment has been minimized.

Show comment
Hide comment
@patrickdark

patrickdark Sep 1, 2018

Contributor

@zcorpan That's a good point.

Sites could be doing what Facebook is doing though: <div role="button">…<a href=""/>…</div>. It's not clear to me if that's covered under the CSSValueAppearanceForOtherButtons metric. (As far as I can tell, Facebook is only using -moz-appearance: none, not -*-appearance: button, and I'm not sure as to what that's being applied to.)

Contributor

patrickdark commented Sep 1, 2018

@zcorpan That's a good point.

Sites could be doing what Facebook is doing though: <div role="button">…<a href=""/>…</div>. It's not clear to me if that's covered under the CSSValueAppearanceForOtherButtons metric. (As far as I can tell, Facebook is only using -moz-appearance: none, not -*-appearance: button, and I'm not sure as to what that's being applied to.)

@tkent-google

This comment has been minimized.

Show comment
Hide comment
@tkent-google

tkent-google Sep 3, 2018

CSSValueAppearanceButton (currently 37.22%) is counted if -webkit-appearance:button appears in loaded CSS style sheets, regardless of effectiveness of the property.

CSSValueAppearanceButtonRendered (1.21%) is a subset of CSSValueAppearanceButton and counted if an element with -webkit-appearance:button is rendered.

  • CSSValueAppearanceButtonForButton (0.92%) is a subset of CSSValueAppearanceButtonRendered, and counted if <button> with -webkit-appearance:button is rendered.
  • CSSValueAppearanceButtonForOtherrButtons (0.28%) is a subset of CSSValueAppearanceButtonRendered, and counted if <input type=button/reset/submit> with -webkit-appearance:button is rendered.
  • CSSValueAppearanceButtonForAnchors (0.01%) is a subset of CSSValueAppearanceButtonRendered, and counted if <a href=...> with -webkit-appearance:button is rendered.

The data means that <button>, <input> buttons, and <a href=...> cover almost all of -webkit-appearance:button usage (0.92% + 0.28% + 0.01% = 1.21%), and removing <a href=...> support from -webkit-appearance:button will break 0.01% of page views.

tkent-google commented Sep 3, 2018

CSSValueAppearanceButton (currently 37.22%) is counted if -webkit-appearance:button appears in loaded CSS style sheets, regardless of effectiveness of the property.

CSSValueAppearanceButtonRendered (1.21%) is a subset of CSSValueAppearanceButton and counted if an element with -webkit-appearance:button is rendered.

  • CSSValueAppearanceButtonForButton (0.92%) is a subset of CSSValueAppearanceButtonRendered, and counted if <button> with -webkit-appearance:button is rendered.
  • CSSValueAppearanceButtonForOtherrButtons (0.28%) is a subset of CSSValueAppearanceButtonRendered, and counted if <input type=button/reset/submit> with -webkit-appearance:button is rendered.
  • CSSValueAppearanceButtonForAnchors (0.01%) is a subset of CSSValueAppearanceButtonRendered, and counted if <a href=...> with -webkit-appearance:button is rendered.

The data means that <button>, <input> buttons, and <a href=...> cover almost all of -webkit-appearance:button usage (0.92% + 0.28% + 0.01% = 1.21%), and removing <a href=...> support from -webkit-appearance:button will break 0.01% of page views.

@zcorpan

This comment has been minimized.

Show comment
Hide comment
@zcorpan

zcorpan Sep 5, 2018

Member

That 0.01% is 102 pages in HTTP Archive.

#standardSQL
SELECT
  Alexa_rank AS rank,
  url
FROM
  `httparchive.pages.2018_08_15_desktop`
JOIN
  `httparchive.urls.20170315`
ON
  NET.REG_DOMAIN(url) = Alexa_domain
WHERE
  JSON_EXTRACT(payload, '$._blinkFeatureFirstUsed.Features.CSSValueAppearanceButtonForAnchor') IS NOT NULL
ORDER BY
  rank

->
https://gist.github.com/zcorpan/60ab11129a70755bf2ec6a9cf8cf3c4d

Member

zcorpan commented Sep 5, 2018

That 0.01% is 102 pages in HTTP Archive.

#standardSQL
SELECT
  Alexa_rank AS rank,
  url
FROM
  `httparchive.pages.2018_08_15_desktop`
JOIN
  `httparchive.urls.20170315`
ON
  NET.REG_DOMAIN(url) = Alexa_domain
WHERE
  JSON_EXTRACT(payload, '$._blinkFeatureFirstUsed.Features.CSSValueAppearanceButtonForAnchor') IS NOT NULL
ORDER BY
  rank

->
https://gist.github.com/zcorpan/60ab11129a70755bf2ec6a9cf8cf3c4d

@zcorpan

This comment has been minimized.

Show comment
Hide comment
@zcorpan

zcorpan Sep 5, 2018

Member

I have updated https://developer.mozilla.org/en-US/docs/Web/CSS/appearance so that it has complete (I believe) information for Firefox, Chrome, Safari, and Edge.

I created the following spreadsheet to flesh out a proposal that covers enough for web compat, but also restricts what the values can apply to.

https://docs.google.com/spreadsheets/d/1YdMpU172CP60QUoomzK2iJpZw7kHQi9X2PjPUoNu20s/edit?usp=sharing

Member

zcorpan commented Sep 5, 2018

I have updated https://developer.mozilla.org/en-US/docs/Web/CSS/appearance so that it has complete (I believe) information for Firefox, Chrome, Safari, and Edge.

I created the following spreadsheet to flesh out a proposal that covers enough for web compat, but also restricts what the values can apply to.

https://docs.google.com/spreadsheets/d/1YdMpU172CP60QUoomzK2iJpZw7kHQi9X2PjPUoNu20s/edit?usp=sharing

@zcorpan

This comment has been minimized.

Show comment
Hide comment
@zcorpan

zcorpan Sep 12, 2018

Member

Here's what I suggest we do:

  1. Spec both -webkit-appearance and appearance
  2. Limit the values of -webkit-appearance to none and the values needed for web compat, using those listed in https://compat.spec.whatwg.org/#css-non-aliased as a starting point
  3. Do not define that -webkit-appearance has an initial value. Instead, define it as a shorthand of appearance. This means appearance may have values that cannot be expressed in -webkit-appearance (as needed for the UA stylesheet), and -webkit-appearance can be limited to the values that are required for web compat.
  4. Define the values of appearance to be, none, auto, plus all the values that -webkit-appearance has.
  5. Make auto the initial value of appearance

Optional steps:

  1. If we only care about the web compat values for the sake of undoing an earlier none, and not for the sake of turning any arbitrary element (including form controls) into any other arbitrary form control, we can define that the effect of the compat values is the same as auto.
  2. If we need it for compat reasons on the OM, we could make auto compute to none on non form controls.
  3. If we need it for compat reasons on the OM, we could make auto compute to the appropriate web compat value on the appropriate form controls.

This seems unnecessarily complicated to me. It seems simpler to support the values necessary for web compat, and have -webkit-appearance be a simple alias, and I think that also matches web developers' expectations better (if -webkit-prefixed stuff is an indication).

Do you have implementer buy-in for what you suggest?

Member

zcorpan commented Sep 12, 2018

Here's what I suggest we do:

  1. Spec both -webkit-appearance and appearance
  2. Limit the values of -webkit-appearance to none and the values needed for web compat, using those listed in https://compat.spec.whatwg.org/#css-non-aliased as a starting point
  3. Do not define that -webkit-appearance has an initial value. Instead, define it as a shorthand of appearance. This means appearance may have values that cannot be expressed in -webkit-appearance (as needed for the UA stylesheet), and -webkit-appearance can be limited to the values that are required for web compat.
  4. Define the values of appearance to be, none, auto, plus all the values that -webkit-appearance has.
  5. Make auto the initial value of appearance

Optional steps:

  1. If we only care about the web compat values for the sake of undoing an earlier none, and not for the sake of turning any arbitrary element (including form controls) into any other arbitrary form control, we can define that the effect of the compat values is the same as auto.
  2. If we need it for compat reasons on the OM, we could make auto compute to none on non form controls.
  3. If we need it for compat reasons on the OM, we could make auto compute to the appropriate web compat value on the appropriate form controls.

This seems unnecessarily complicated to me. It seems simpler to support the values necessary for web compat, and have -webkit-appearance be a simple alias, and I think that also matches web developers' expectations better (if -webkit-prefixed stuff is an indication).

Do you have implementer buy-in for what you suggest?

@frivoal

This comment has been minimized.

Show comment
Hide comment
@frivoal

frivoal Sep 13, 2018

Contributor

Do you have implementer buy-in for what you suggest?

My understanding of the position of Microsoft (cc @FremyCompany), at least some at Mozilla (@dbaron @tantek), at least some at Google (@tabatkins), and of the CSS-WG at large every time we discussed this, is that there's fairly strong agreement that we should have appearance with only auto none, with auto as the initial value (and no particular need for anything else in the UA stylesheet), plus a small set of additional values limited to those needed for for compat reasons, with a preference if compat allows for defining the other values to do the same as auto, so that they work for reverting a none, but not for turning arbitrary things into arbitrary other things. And I believe that everybody agrees that what is required for back compat is required, so we'll have to spec -webkit-appearance as well. We have not discussed whether the auto value needed to be excluded from the webkit prefixed version. I made the proposal above as a solution to combine -webkit-appearance with the set of values (and only these) defined by the compat spec with appearance as defined above. If there is no need for excluding the auto value from the prefixed version, we can simply alias the two. But the whole CSS-WG does have fairly strong agreement that we don't want to have a enormous list of values to cover all form controls in the UA stylesheet, and that the only way we've found to do that without resorting to undefined behavior is to have an auto value.

It seems simpler to support the values necessary for web compat, and have -webkit-appearance be a simple alias

As a simple alias to what? I am not sure what you're proposing.

  1. Alias -webkit-apperance to appearance, and both have an auto value, which is the initial value?

    That's totally fine, as discussed above. But I don't think this is what you're proposing. More than happy to be mistaken.

  2. Alias to an appearance property that takes the same limited set of keywords needed for web compat and only these?

    That's not possible, as you cannot express the UA stylesheet using only the values listed as necessary for webcompat.

  3. Alias to an unspecified appearance or -other-vendor-appearance property that takes the same limited set of keywords needed for web compat plus whatever each vendor wants to have to express the UA stylesheet?

    If both properties don't actually have the same set of keywords, they're cannot really be strict aliases. But one could be a shorthand for the other or something like that. However aliasingshorthanding to an undefined thing feels really weird, as then you're not really defining how things work. And if you're going to aliasshorthand to a property with a different set of values so that you can express the UA stylesheet, why not do what I said above, which is aliasingshorthanding to a defined thing, and use auto rather than a giant list of values? At least that way, Chrome could also implement the auto value, and try to remove all other values not needed for web compat, and we'd have a chance of converging on a finite set of values.

  4. Alias to an unspecified -other-vendor-appearance property, and both properties that takes the same limited set of keywords needed for web compat plus whatever they need to express the UA stylesheet?

    The still leaves the basic mechanism undefined, which not only feels weird, but also means that over time, we will get continuing pressure to align closer and closer with the market-share dominant player. This means that we're buying time, but in the long run, it isn't terribly different from the next one:

  5. Forget about only supporting only the -webkit-appearance values needed for web compat, and just wholesale copy every value of the original -webkit-appearance, so that we can write the UA stylesheet with that?

    Which -webkit-appearance? Blink and Webkit support different values. But even if we'd pick one (Blink, presumably), we still have problems:

    1. The list is huge, and standardizing all that is going to be very painful
    2. Many values in that list are meant to be used in the UA stylesheet by being applied to proprietary pseudo-elements. Are we going to standardize those as well? We'd have to, otherwise many values are useless, and many form controls cannot be given their look and feel.
    3. Form controls look different on different browsers or on different platforms, and have different sub-components/proprietary pseudos. That is best left to the discretion of each vendor. And it evolves. So a fixed list is not desirable. And an everchanging list is not fun to try to standardize or to converge on.
Contributor

frivoal commented Sep 13, 2018

Do you have implementer buy-in for what you suggest?

My understanding of the position of Microsoft (cc @FremyCompany), at least some at Mozilla (@dbaron @tantek), at least some at Google (@tabatkins), and of the CSS-WG at large every time we discussed this, is that there's fairly strong agreement that we should have appearance with only auto none, with auto as the initial value (and no particular need for anything else in the UA stylesheet), plus a small set of additional values limited to those needed for for compat reasons, with a preference if compat allows for defining the other values to do the same as auto, so that they work for reverting a none, but not for turning arbitrary things into arbitrary other things. And I believe that everybody agrees that what is required for back compat is required, so we'll have to spec -webkit-appearance as well. We have not discussed whether the auto value needed to be excluded from the webkit prefixed version. I made the proposal above as a solution to combine -webkit-appearance with the set of values (and only these) defined by the compat spec with appearance as defined above. If there is no need for excluding the auto value from the prefixed version, we can simply alias the two. But the whole CSS-WG does have fairly strong agreement that we don't want to have a enormous list of values to cover all form controls in the UA stylesheet, and that the only way we've found to do that without resorting to undefined behavior is to have an auto value.

It seems simpler to support the values necessary for web compat, and have -webkit-appearance be a simple alias

As a simple alias to what? I am not sure what you're proposing.

  1. Alias -webkit-apperance to appearance, and both have an auto value, which is the initial value?

    That's totally fine, as discussed above. But I don't think this is what you're proposing. More than happy to be mistaken.

  2. Alias to an appearance property that takes the same limited set of keywords needed for web compat and only these?

    That's not possible, as you cannot express the UA stylesheet using only the values listed as necessary for webcompat.

  3. Alias to an unspecified appearance or -other-vendor-appearance property that takes the same limited set of keywords needed for web compat plus whatever each vendor wants to have to express the UA stylesheet?

    If both properties don't actually have the same set of keywords, they're cannot really be strict aliases. But one could be a shorthand for the other or something like that. However aliasingshorthanding to an undefined thing feels really weird, as then you're not really defining how things work. And if you're going to aliasshorthand to a property with a different set of values so that you can express the UA stylesheet, why not do what I said above, which is aliasingshorthanding to a defined thing, and use auto rather than a giant list of values? At least that way, Chrome could also implement the auto value, and try to remove all other values not needed for web compat, and we'd have a chance of converging on a finite set of values.

  4. Alias to an unspecified -other-vendor-appearance property, and both properties that takes the same limited set of keywords needed for web compat plus whatever they need to express the UA stylesheet?

    The still leaves the basic mechanism undefined, which not only feels weird, but also means that over time, we will get continuing pressure to align closer and closer with the market-share dominant player. This means that we're buying time, but in the long run, it isn't terribly different from the next one:

  5. Forget about only supporting only the -webkit-appearance values needed for web compat, and just wholesale copy every value of the original -webkit-appearance, so that we can write the UA stylesheet with that?

    Which -webkit-appearance? Blink and Webkit support different values. But even if we'd pick one (Blink, presumably), we still have problems:

    1. The list is huge, and standardizing all that is going to be very painful
    2. Many values in that list are meant to be used in the UA stylesheet by being applied to proprietary pseudo-elements. Are we going to standardize those as well? We'd have to, otherwise many values are useless, and many form controls cannot be given their look and feel.
    3. Form controls look different on different browsers or on different platforms, and have different sub-components/proprietary pseudos. That is best left to the discretion of each vendor. And it evolves. So a fixed list is not desirable. And an everchanging list is not fun to try to standardize or to converge on.
@zcorpan

This comment has been minimized.

Show comment
Hide comment
@zcorpan

zcorpan Sep 13, 2018

Member

I suggest doing (2), but allowing internal values that are only supported in the UA style sheet, not in author style sheets, to make up for default styling as necessary (including internal pseudo elements etc).

Possibly adding the auto keyword, if you can convince @MatsPalmgren.

Member

zcorpan commented Sep 13, 2018

I suggest doing (2), but allowing internal values that are only supported in the UA style sheet, not in author style sheets, to make up for default styling as necessary (including internal pseudo elements etc).

Possibly adding the auto keyword, if you can convince @MatsPalmgren.

@dbaron

This comment has been minimized.

Show comment
Hide comment
@dbaron

dbaron Sep 13, 2018

Member

My understanding of the position of Microsoft (cc @FremyCompany), at least some at Mozilla (@dbaron @tantek), at least some at Google (@tabatkins),

BTW, I don't think I hold that position, although that doesn't mean I hold the opposite position either. But I'd tend to defer to Mats and others who have dug into the issues further.

Member

dbaron commented Sep 13, 2018

My understanding of the position of Microsoft (cc @FremyCompany), at least some at Mozilla (@dbaron @tantek), at least some at Google (@tabatkins),

BTW, I don't think I hold that position, although that doesn't mean I hold the opposite position either. But I'd tend to defer to Mats and others who have dug into the issues further.

@MatsPalmgren

This comment has been minimized.

Show comment
Hide comment
@MatsPalmgren

MatsPalmgren Sep 13, 2018

@frivoal

That's not possible, as you cannot express the UA stylesheet using only the values listed as necessary for webcompat.

You're making a false assumption. Gecko is already doing exactly that. FYI, it's fairly easy to implement in the CSS parser actually, we basically do:

if ("currently parsing an UA sheet")
  parse_full_set_of_values();
else
  parse_web_exposed_set_of_values();

FYI, this is the mechanism we'll use to prune our implementation of -webkit-appearance to the minimal set needed for web-compat, while still retaining some values for internal use.

MatsPalmgren commented Sep 13, 2018

@frivoal

That's not possible, as you cannot express the UA stylesheet using only the values listed as necessary for webcompat.

You're making a false assumption. Gecko is already doing exactly that. FYI, it's fairly easy to implement in the CSS parser actually, we basically do:

if ("currently parsing an UA sheet")
  parse_full_set_of_values();
else
  parse_web_exposed_set_of_values();

FYI, this is the mechanism we'll use to prune our implementation of -webkit-appearance to the minimal set needed for web-compat, while still retaining some values for internal use.

@MatsPalmgren

This comment has been minimized.

Show comment
Hide comment
@MatsPalmgren

MatsPalmgren Sep 13, 2018

Unfortunately, there exist a lot of web pages that set -webkit-appearance without setting the unprefixed property. For that reason, I firmly believe that we're stuck with supporting -webkit-appearance for all eternity. So I don't see much value in adding an unprefixed version if the goal of removing the prefixed property is unachievable. I'd prefer to just standardize -webkit-appearance and prune its set of values to the minimal set needed for web-compat.

And if we introduce appearance, then I think it must be a simple alias (meaning they would accept the exact same set of values). I simply do not believe that appearance:none|auto is web-compatible. The only way to convince me otherwise would be if WebKit/Blink successfully shipped that. Then I'm sure we'll follow their lead.

MatsPalmgren commented Sep 13, 2018

Unfortunately, there exist a lot of web pages that set -webkit-appearance without setting the unprefixed property. For that reason, I firmly believe that we're stuck with supporting -webkit-appearance for all eternity. So I don't see much value in adding an unprefixed version if the goal of removing the prefixed property is unachievable. I'd prefer to just standardize -webkit-appearance and prune its set of values to the minimal set needed for web-compat.

And if we introduce appearance, then I think it must be a simple alias (meaning they would accept the exact same set of values). I simply do not believe that appearance:none|auto is web-compatible. The only way to convince me otherwise would be if WebKit/Blink successfully shipped that. Then I'm sure we'll follow their lead.

@FremyCompany

This comment has been minimized.

Show comment
Hide comment
@FremyCompany

FremyCompany Sep 13, 2018

Contributor

My understanding of the position of Microsoft (cc @FremyCompany), at least some at Mozilla (@dbaron @tantek), at least some at Google (@tabatkins),

BTW, I don't think I hold that position, although that doesn't mean I hold the opposite position either. But I'd tend to defer to Mats and others who have dug into the issues further.

Same here. My position is that the appearance property should only have two meaningful values, but I don't think that means two values only, that would not be web-compatible. I think you should be able to say appearance: clippy-trombone and this should work and behave as appearance: auto ;-)

I would prefer appearance and -webkit-appearance to be aliases if possible. If webcompat requires supporting some UA-stylesheet values that are not auto for a couple of elements, I wouldn't mind that.

Contributor

FremyCompany commented Sep 13, 2018

My understanding of the position of Microsoft (cc @FremyCompany), at least some at Mozilla (@dbaron @tantek), at least some at Google (@tabatkins),

BTW, I don't think I hold that position, although that doesn't mean I hold the opposite position either. But I'd tend to defer to Mats and others who have dug into the issues further.

Same here. My position is that the appearance property should only have two meaningful values, but I don't think that means two values only, that would not be web-compatible. I think you should be able to say appearance: clippy-trombone and this should work and behave as appearance: auto ;-)

I would prefer appearance and -webkit-appearance to be aliases if possible. If webcompat requires supporting some UA-stylesheet values that are not auto for a couple of elements, I wouldn't mind that.

@FremyCompany

This comment has been minimized.

Show comment
Hide comment
@FremyCompany

FremyCompany Sep 13, 2018

Contributor

Fwiw the only reason I would argue to add appearance is that it is bad for developer ergonomics that appearance: none (which is useful addition to the platform) has to be prefixed; eventually features should be unprefixed if possible to make developers' work easier.

Contributor

FremyCompany commented Sep 13, 2018

Fwiw the only reason I would argue to add appearance is that it is bad for developer ergonomics that appearance: none (which is useful addition to the platform) has to be prefixed; eventually features should be unprefixed if possible to make developers' work easier.

@AmeliaBR

This comment has been minimized.

Show comment
Hide comment
@AmeliaBR

AmeliaBR Sep 14, 2018

Fwiw the only reason I would argue to add appearance is that it is bad for developer ergonomics that appearance: none (which is useful addition to the platform) has to be prefixed; eventually features should be unprefixed if possible to make developers' work easier.

Strong agreement here. I really don't want to get in the habit of telling people "oh, just use the webkit version, no unprefixed property is required". If there is agreement that this property has value to the web platform, that it is something whose use shouldn't be discouraged, that support is about more than just legacy compat, then it should have a prefix-free name.

Also, there are still many developers who are confused / surprised to discover that -webkit- properties work at all outside WebKit/Blink browsers.

AmeliaBR commented Sep 14, 2018

Fwiw the only reason I would argue to add appearance is that it is bad for developer ergonomics that appearance: none (which is useful addition to the platform) has to be prefixed; eventually features should be unprefixed if possible to make developers' work easier.

Strong agreement here. I really don't want to get in the habit of telling people "oh, just use the webkit version, no unprefixed property is required". If there is agreement that this property has value to the web platform, that it is something whose use shouldn't be discouraged, that support is about more than just legacy compat, then it should have a prefix-free name.

Also, there are still many developers who are confused / surprised to discover that -webkit- properties work at all outside WebKit/Blink browsers.

@frivoal

This comment has been minimized.

Show comment
Hide comment
@frivoal

frivoal Sep 14, 2018

Contributor

I suggest doing (2), but allowing internal values that are only supported in the UA style sheet, not in author style sheets, to make up for default styling as necessary (including internal pseudo elements etc).

Possibly adding the auto keyword, if you can convince @MatsPalmgren.

Ok, now I see how you plan to resolve what I otherwise though was a contradiction. (I'll note that this is not mentioned in the compat spec). This has not yet been brought up in discussions in the CSSWG, so I don't know how other people feel about that.

As far as I know, this notion of different abilities in the UA stylesheet and author stylesheets would be a new things as far as standards are concerned.

Although I am a little skeptical, I'm open to exploring the idea, as that does indeed seem to be a solution that could work, but If we're talking not only about introducing/standardizing a new property, but also of a new mechanism in the cascade, I'd like us to be very careful and deliberate about that.

For instance, what do you get out of the OM (the old style one or the typed OM) if the property has one of these values that the authors can't set? Presumably you still get that value in string or object representation, but what happens if you try to assign it back? In the string based om, presumably the same kind of failure as with any parse error, but in the Typed OM we've bypassed the parser, so do you get an exception? Probably, but which? TypeError or something more specialized? Do we break something by making it impossible to re-set the property the the value it currently has? Can you use revert to go back to the a value that you could not manually set? Presumably yes, but as the revert value is not widely implemented, how are authors supposed to cancel a none if revert isn't there? Is the richer set of values available in user style sheets (presumably not)? Is there any weird interaction with custom properties? Is there any weird interaction with animations or transitions? …

And maybe most importantly, does that concept have other uses than this (-webkit-)appearance property? And in what way does this solve the problem better than the much more conventional auto approach?

Contributor

frivoal commented Sep 14, 2018

I suggest doing (2), but allowing internal values that are only supported in the UA style sheet, not in author style sheets, to make up for default styling as necessary (including internal pseudo elements etc).

Possibly adding the auto keyword, if you can convince @MatsPalmgren.

Ok, now I see how you plan to resolve what I otherwise though was a contradiction. (I'll note that this is not mentioned in the compat spec). This has not yet been brought up in discussions in the CSSWG, so I don't know how other people feel about that.

As far as I know, this notion of different abilities in the UA stylesheet and author stylesheets would be a new things as far as standards are concerned.

Although I am a little skeptical, I'm open to exploring the idea, as that does indeed seem to be a solution that could work, but If we're talking not only about introducing/standardizing a new property, but also of a new mechanism in the cascade, I'd like us to be very careful and deliberate about that.

For instance, what do you get out of the OM (the old style one or the typed OM) if the property has one of these values that the authors can't set? Presumably you still get that value in string or object representation, but what happens if you try to assign it back? In the string based om, presumably the same kind of failure as with any parse error, but in the Typed OM we've bypassed the parser, so do you get an exception? Probably, but which? TypeError or something more specialized? Do we break something by making it impossible to re-set the property the the value it currently has? Can you use revert to go back to the a value that you could not manually set? Presumably yes, but as the revert value is not widely implemented, how are authors supposed to cancel a none if revert isn't there? Is the richer set of values available in user style sheets (presumably not)? Is there any weird interaction with custom properties? Is there any weird interaction with animations or transitions? …

And maybe most importantly, does that concept have other uses than this (-webkit-)appearance property? And in what way does this solve the problem better than the much more conventional auto approach?

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