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

[zcorpan]

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]

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 whatwg/compat#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 #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]

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

[ExE-Boss]

Also, have we decided whether we want to keep auto as essentially an alias for revert?

I’m asking because revert isn’t very supported yet.

[zcorpan]

Yes, auto should be supported. It's easier for authors to use just auto and none and not have to remember other values, and we don't need to introduce new keywords for new form controls/widgets. It's not technically an alias for revert, though.

I’m asking because revert isn’t very supported yet.

auto isn't supported at all yet.

[tkent-google]

I added more counters to Google Chrome, and here is the current summary:

Summary:

• button can not be an alias of auto at this moment.
• We can restrict button to <button>, <input type=button/reset/submit>, and <a>.
• If textfield is not an alias of auto, menulist-button and searchfield-cancel-button should not be too.
• We can restrict textfield to text-field-like <input> including type=search.
• We can not restrict menulist-button and searchfield-cancel-button to specific elements. We don't have data.
• sliderthumb-vertical and slider-vertical can't be aliases of auto, and we should make a conclusion of Rendering <input type=range> vertically whatwg/html#4177.
• Other keywords can be aliases of auto.

Data:

(Following counter values are page view ratio in which an element with the keyword is painted. 'for others' means the keyword is applied to elements which doesn't have the keyword in UA stylesheet.)

A) Usage is not low.
button for input[type=button/reset/submit]: 0.34% https://www.chromestatus.com/metrics/feature/timeline/popularity/1472
Input buttons have -webkit-appearance:push-button by default.

B) Usage is low. Changing their behavior would have some risks. However probably it's doable.
button for anchors: 0.013%
https://www.chromestatus.com/metrics/feature/timeline/popularity/1470
menulist-button for others: 0.016%
https://www.chromestatus.com/metrics/feature/timeline/popularity/2583
searchfield-cancel-button for others: 0.017% https://www.chromestatus.com/metrics/feature/timeline/popularity/2579
textfield for input[type=search]: 0.015%
https://www.chromestatus.com/metrics/feature/timeline/popularity/1474

C) Usage is very low. However they are necessary for vertical input[type=range] in WebKit and Blink. See whatwg/html#4177
sliderthumb-vertical for input[type=range]: 0.001%
https://www.chromestatus.com/metrics/feature/timeline/popularity/2574
slider-vertical for input[type=range]: 0.0009%
https://www.chromestatus.com/metrics/feature/timeline/popularity/2570

D) Usage is very low.
button for others (exclude anchors and input[type=button/reset/submit]): 0.005%
https://www.chromestatus.com/metrics/feature/timeline/popularity/2775
checkbox for others: 0.0015%
https://www.chromestatus.com/metrics/feature/timeline/popularity/2560
inner-spin-button for others: 0.000003%
https://www.chromestatus.com/metrics/feature/timeline/popularity/2564
menulist for others: 0.0024%
https://www.chromestatus.com/metrics/feature/timeline/popularity/2566
progress-bar for others: 0.00004%
https://www.chromestatus.com/metrics/feature/timeline/popularity/2817
push-button for others: 0.0003%
https://www.chromestatus.com/metrics/feature/timeline/popularity/2585
radio for others: 0.0002%
https://www.chromestatus.com/metrics/feature/timeline/popularity/2562
search-field for others: 0.0008%
https://www.chromestatus.com/metrics/feature/timeline/popularity/2577
slider-horizontal for others: 0.000006%
https://www.chromestatus.com/metrics/feature/timeline/popularity/2569
sliderthumb-horizontal for others: 0.000001%
https://www.chromestatus.com/metrics/feature/timeline/popularity/2573
sliderthumb-vertical for others: 0.000002%
https://www.chromestatus.com/metrics/feature/timeline/popularity/2575
slider-vertical for others: 0.0006%
https://www.chromestatus.com/metrics/feature/timeline/popularity/2571
square-button for others: 0.0012%
https://www.chromestatus.com/metrics/feature/timeline/popularity/2587
textarea for others: 0.0023%
https://www.chromestatus.com/metrics/feature/timeline/popularity/2581
textfield for others: 0.0008%
https://www.chromestatus.com/metrics/feature/timeline/popularity/2822

[zcorpan]

Thank you, @tkent-google !

If textfield is not an alias of auto, menulist-button and searchfield-cancel-button should not be too.

We can not restrict menulist-button and searchfield-cancel-button to specific elements. We don't have data.

For textfield being special on <input type=search>, I had identified web content that use this in my previous analysis of httparchive. (comment above)

For menulist-button, I have tried today to find examples in httparchive where this value is used on elements that are not select, and I couldn't find any. (I found various selectors targeting other elements, but upon closer inspection, either there was no such element, or -webkit-appearance was overridden by a different style rule, or some other.)

How do we find out where this is needed? Can we try making it an alias to auto and see if we get any bug reports, knowing that usage is low and having tried to find things that would break has so far yielded nothing?

searchfield-cancel-button is used on a pseudo-element in the UA stylesheet. I've seen examples on the web that set -webkit-appearance to this value on that pseudo-element, but not on other things. I will take another look for cases where it's used on something else.

[zcorpan]

OK I have now looked for searchfield-cancel-button. HTTP Archive has ~4.9m pages.

506 pages have -webkit-appearance: searchfield-cancel-button.

Of these, 505 use a selector with ::-webkit-search-cancel-button (the pseudo-element where this value is set in the UA stylesheet in chromium and webkit). (I don't know why they include this at all. Maybe to override other CSS that sets appearance to none?)

The last 1 was

page	match
http://www.playmemoriesonline.com/	}\n\ninput::-webkit-clear-button {\n -webkit-appearance: searchfield-cancel-button

...which seems to be a misspelling of "webkit-search-cancel-button"

So this value does not need to apply to anything apart from the pseudo-element. Furthermore, since ::-webkit-search-cancel-button is not a standardized pseudo-element, it seems weird to standardize a value for 'appearance' for this pseudo-element. I suggest we keep this value out of the spec, for now.

[zcorpan]

We can restrict button to <button>, <input type=button/reset/submit>, and <a>.

What about button on drop-down <select>? This has come up previously

button on select
39,select.class123-select{-webkit-appearance:button}

[zcorpan]

I wrote:

How do we find out where this is needed? Can we try making it an alias to auto and see if we get any bug reports, knowing that usage is low and having tried to find things that would break has so far yielded nothing?

I almost forgot about this: #3574

In particular, it has an effect (different from auto) on drop-down <select>. But I'm not aware of the value being needed on other elements.

[tkent-google]

I thought we could drop support of category B for simplicity. However textfield for input[type=search] is a reasonable usecase, and dropping "button for anchors" won't have much benefit if we need to support button for input[type=button/reset/submit].

}\n\ninput::-webkit-clear-button {\n -webkit-appearance: searchfield-cancel-button

Oh, I found "searchfield-cancel-button for others" unexpectedly contained ::-webkit-clear-button usage. ::-webkit-clear-button is similar to ::-webkit-search-cancel-button, but it's for input[type=date/datetime-local/month/time/week], and it has "-webkit-appearance: searchfield-cancel-button" in UA stylesheet. I'll correct the counter, and I hope we can restrict searchfield-cancel-button to these pseudo elements.

I have no idea of usecases of "menulist-button for others".

Probably Chrome's action items would be:

• Correct the counter for "searchfield-cancel-button for others"
• Deprecate and remove arbitrary element support of category D and menulist-button

[zcorpan]

Based on the information above, these are the edits I suggest for the spec:

• menulist-button being different from auto: PR [css-ui] appearance: menulist-button is different from auto #3574
• restrict button to <button>, <input type=button/reset/submit>, <a>, and drop-down <select>: PR [css-ui] Restrict appearance: button more #3966
• add inline spec issue about sliderthumb-vertical and slider-vertical, and point to Rendering <input type=range> vertically whatwg/html#4177 : PR [css-ui] Add an issue about slider-vertical & sliderthumb-vertical #3967
• add a section on recommendation for internal parts of form controls: PR [css-ui] Disallow internal pseudo-elements and 'appearance' values #3968 [ edit: new issue [cssom] Should getComputedStyle() support non-standard pseudo-elements? #3980 ]
  • don't expose such pseudo-elements (e.g. ::-webkit-search-cancel-button) to author CSS
  • don't allow getting computed style for such pseudo-elements with getComputedStyle()
  • don't expose support for 'appearance' keywords (e.g. searchfield-cancel-button) specific to such pseudo-elements to author CSS
  • if some of these do ought to be exposed to authors, all related parts need to be standardized, not just the 'appearance' keywords
• Require vendor-specific values to use the auto keyword (simpler alternative to address the same issue as the previous bullet point)

[jugglinmike]

CSS Cascading and Inheritance defines the term "legacy name alias" as follows:

When the old property’s syntax is identical to or a subset of the value space of the new property’s syntax, the two names are aliased with an operation on par with case-mapping: at parse time, the old property is converted into the new property. This conversion also applies in the CSSOM, both for string arguments and property accessors: requests for the old property name transparently transfer to the new property name instead.

I can't tell if -webkit-appearance qualifies in our latest design. I suspect that it does, so I've submitted some tests to the web-platform-tests project, but it would be helpful if anyone following along could verify this. @frivoal called out the novelty of this solution. Does that warrant a modification to the definition of "legacy name alias"?

[zcorpan]

The novelty discussed in that comment is about supporting some keywords in the UA stylesheet but not in author stylesheets. I think that's orthogonal to aliasing. "Legacy name alias" as defined should be OK I think.

[frivoal]

@zcorpan I think this issue has served its purpose, and can now be closed. There are/will be more issues about appearance to deal with, but as a high level one, this one seems done. OK?

[frivoal]

Actually, we have a resolution to close, in #3024 (comment). Closing accordingly. Please reopen new, more specific issues, if anything is left to do that isn't covered in other open issues.

[zcorpan]

Sounds good. Thank you @frivoal