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

[zcorpan]

In https://github.com/whatwg/html/issues/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]

annevk pointed me to https://groups.google.com/forum/#!msg/mozilla.dev.platform/Fq6OH5SWeRo/lxHDXFnwCQAJ

[annevk]

@jwatt

[emilio]

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]

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]

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]

cc @frivoal

[zcorpan]

Also see https://github.com/whatwg/compat/pull/104

[frivoal]

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]

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 https://github.com/w3c/csswg-drafts/issues/1250, my preference being to do it by picking option 7 in comment https://github.com/w3c/csswg-drafts/issues/1250#issuecomment-322933332.

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

[annevk]

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]

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]

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]

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]

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]

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]

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:

6. 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.
7. If we need it for compat reasons on the OM, we could make auto compute to none on non form controls.
8. 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]

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]

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]

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

[zcorpan]

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]

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

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

[patrickdark]

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

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]

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]

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]

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]

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]

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]

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]

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

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]

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]

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]

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]

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?

[zcorpan]

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.

FYI, I've now started working on this for Mozilla. Here's a spreadsheet I use to track this work:

https://docs.google.com/spreadsheets/d/1-EGzSxgFrGihArz0ZuZiZ2krrN_KhUYrSzdOhQi-zrI/edit?usp=sharing

[zcorpan]

Draft spec for rendering form controls and 'appearance' at

https://docs.google.com/document/d/1FE5YIoirPKxYbbnMd8kS6w39M8bzLTl5tf4wwOxR1wc/edit?usp=sharing

Feedback welcome :)

[ExE-Boss]

I think appearance: auto; should behave as appearance: revert;, possibly skipping the user cascade level and going straight to the UA cascade.

And appearance: initial; should behave as appearance: none;.

[fantasai]

@zcorpan Can you post that somewhere that is both a) public and b) archived ? I can't comment on a spec I can't see.

[ExE-Boss]

@fantasai

@zcorpan Can you post that somewhere that is both a) public and b) archived ? I can't comment on a spec I can't see.

It was still public just yesterday.

[tabatkins]

On Tue, Oct 16, 2018 at 11:55 PM ExE Boss notifications@github.com wrote:

@fantasai https://github.com/fantasai

@zcorpan https://github.com/zcorpan Can you post that somewhere that is both a) public and b) archived ? I can't comment on a spec I can't see.

It was still public just yesterday.

Well, it's not now.

[annevk]

I can access both fine, logged in and logged out. And the documents also claim they're "Public on the web".

[zcorpan]

Apologies, I accidentally changed the sharing settings yesterday. Anyone should be able to view and comment again now.

As for (b), I expect to move to GitHub PRs when it is a bit more stable, but I could also do something to archive the working doc outside google docs. Any suggestions?

[fantasai]

@zcorpan Export to plaintext/HTML/PDF and send a copy to www-archive@w3.org? It's what I usually do when I just need something archived...

[zcorpan]

https://lists.w3.org/Archives/Public/www-archive/2018Oct/0001.html

[zcorpan]

Here are some of my web compatibility findings.

Most common values

• most common -webkit-appearance values in httparchive
• most common -moz-appearance values in httparchive
• most common -webkit-appearance values in Chrome and Edge per MS's data
• most common -moz-appearance values in Firefox per MS's data

Analysis of -moz-appearance and -webkit-appearance values

• most common combinations of non-equal -moz-appearance and -webkit-appearance values in httparchive
  • This can help inform the web compat impact of unshipping certain values from gecko.
• most common style rules (including selector) containing -webkit-appearance or -moz-appearance (excluding 'none') in httparchive
  • menulist-button on select (switches to an alternative gray theme in safari/chrome on macOS)
  • 6216,.wsite-com-checkout-section .wsite-form-field select{-webkit-appearance:menulist-button;border:1px solid #ccc}
  • push-button on buttons (should give themed appearance like it does by default):
  • 5202,".plugin-search_tags .search-tags-submit-button { -webkit-appearance: push-button; padding: 2px 4px; }"
  • textfield on input type=search (they are 'searchfield' by default):
  • 3041,input[type=search]{-webkit-appearance:textfield;box-sizing:content-box}
  • textfield on input type=number (hides the step buttons in Firefox)
  • 1083,"input[type=""number""]{-moz-appearance:textfield}"
  • caret on input, textarea, select (suppresses painting of borders in safari/chrome)
  • 405,"ul.token-input-list li input { border: 0; width: 350px; padding: 3px 8px; background-color: white; -webkit-appearance: caret; }"
  • 26,"/* 6.1 buttons */a.button, a.comment-reply-link, #commentform #submit, .submit, input[type=submit], input.button, button.button, #wrapper .woo-sc-button { [...] -webkit-appearance: caret; /* remove input shadowing on ios */ -moz-appearance: caret; /* mobile firefox too! */ }"
  • 5,.m-mobile textarea{font-size:16px !important;-webkit-appearance:caret;-moz-appearance:caret;appearance:caret}
  • 4,".page-ios .block-form select,.page-ios .block-form textarea,.page-ios .block-form input{-webkit-appearance:caret;-moz-appearance:caret}"
  • button on select
  • 39,select.class123-select{-webkit-appearance:button}
  • checkbox on input type=radio
  • 18,input[type=radio].radio-checkbox{-webkit-appearance:checkbox;-moz-appearance:checkbox;-ms-appearance:checkbox;-o-appearance:checkbox}
  • radio on input type=checkbox
  • 8,"input[type=""radio""],input[type=""checkbox""]{-webkit-appearance:radio!important;apperenace:radio!important}"
  • menulist-text on select (like caret afaict)
  • 8,"select{ -webkit-appearance: menulist-text; }"
  • -apple-pay-button (only supported by safari)
  • 157,.nt3_cl{-webkit-appearance:-apple-pay-button;display:inline-block;width:100%;min-width:180px;height:40px;border:1px solid #000;background-repeat:no-repeat;background-color:#fff;background-position:50% 50%;border-radius:5px;cursor:pointer}
  • Browser-specific hacks
  • 1,"}@media print{@supports (-moz-appearance:meterbar) and (background-blend-mode:difference,normal){html,body{margin:30px 0 !important;}"

[zcorpan]

@frivoal asked at tpac what the computed style should be for an element that has a non-author-exposed value in the UA style sheet.

I think we should not end up in such a situation. All values on elements in the UA style sheets should be supported.

Chromium and Gecko support more values than it uses in the UA stylesheet, that they don't need to support for web compat but may need to support internally. For example, Gecko has some values for XUL. They have now unshipped these values.

Some browsers also have pseudo-elements on form controls. I think we should either standardize such pseudo-elements, or make them also not author-exposed. In any case, per CSSOM you can't ask for computed style on pseudo-elements other than ::before and ::after.

[zcorpan]

Do people have an opinion about where the spec for 'appearance' should be? css-ui, whatwg/compat, somewhere else?

[ExE-Boss]

Probably CSS User Interface or possibly a new CSS Appearance Module (css‑appearance), as whatwg/compat contains prefixed and legacy features, so if anything, whatwg/compat would contain the ‑webkit‑appearance to appearance mapping.