[css-ui] 'auto' as the initial value for the 'appearance' property isn't web-compatible

[MatsPalmgren]

https://drafts.csswg.org/css-ui-4/#appearance-switching

Value: auto | none

For this testcase, the output in the Console in Chrome, Safari and Edge is:

div: none
select with -webkit-appearance:inherit: none
button: button
button w. -webkit-appearance:initial: none

I think that makes it clear that the initial value for -webkit-appearance is none in those UAs. I believe the initial value for appearance must be the same.

After implementing appearance according to spec in Gecko (with auto as the initial value and -webkit-appearance as an alias) we found that this isn't web-compatible.

We will now try with none as the initial value instead, and override that with appearance:auto in the UA sheet for elements that have a native theme in Gecko, <button> <select> etc.

[frivoal]

Sorry for the slow follow up.

The spec is not expected to be web compatible if used under the webkit prefix.

The different prefixed version by different browsers are different from eachother, as they have a separate value for lots and lots of replaced element / form control / parts of form controls, and they all have a different non standard set of these. It's not just the values of -foo-appearance that are non standards, but the actual things they represent.

Based on this, when drafting the spec for appearance, I concluded (and as far as meetings show, the CSSWG agreed) that what was currently implemented by browsers was not possible to standardize, and that we should try to build a saner thing that actually could be, so that in the long run it would take over. The result is replacing the long list of weird values with a single 'auto' value, and 'none'. Since that's not how the prefixed versions work, I am not surprised that implementing that and aliasing it to -webkit-appearance would be web incompatible.

However, would it still be web incompatible if you did not alias the two?

As far as I can tell, "something sane for all UAs and all platforms" and "something compatible with -webkit-appearance" are mutually exclusive goals.

We could make the change you suggest ('none' as the initial value instead, and override that with 'appearance:auto' in the UA sheet for elements that have a native look), but:

1. I suspect this would not be enough to make the appearance web compatible if aliased with the '-webkit-appearance'
2. It's a a kudge.

If 1. isn't actually true, and that's enough to make it possible to alias appearance and -webkit-appearance and have that be web compatible, maybe it's worth the ugliness.

However, I suspect that it will not and that you (unfortunately) will need to implement a both sane version of appearance, which is something like what's in the spec with more details filled in, and separately implement a -webkit-appearance that you'll be tweaking for years to come as you find more odd sites depending on yet another misunderstood aspect of it.

We should totally also specify that variant, since web compat requires it, but I hope we can also provide a clean and sane path forward to authors.

[frivoal]

ping @MatsPalmgren Any opinion on the above?

[MatsPalmgren]

FYI, we intend to implement -webkit-appearance with support for all values that Chrome supports. Sadly, that seems to be what is required to be web-compatible. I don't think we're particularly interested in implementing an unprefixed appearance property at this point. It would bring zero benefits with a lot web-compat risk. (If Chrome implements and ships that first, then we can reconsider.) As for standardization, I think it would probably be more useful to add -webkit-appearance to the compat spec.

However, would it still be web incompatible if you did not alias the two?

Right, we didn't try that. Assuming you cascade it separately and that appearance: none trumps the prefixed property(ies), then you get problems like:

input {
  -webkit-appearance: none;
  -moz-appearance: none;
  appearance: none;
}
input[type="checkbox"] {
  -webkit-appearance: checkbox;
  /* oops forgot to add the other properties here */
}

where the used value will be none. I'm also worried about about stray appearance: none that web developers added at some point and then forgot about. etc. Personally, I doubt an unprefixed appearance can be web-compatible in any form. (Sorry, I don't mean to discourage you.)

Anyway, auto must of course be the default for appearance if it's a separate property that trumps the other ones, so I withdraw my original request.

[frivoal]

Browser vendor representatives in the CSSWG, including mozilla, were very much not interested in a version of appearance with all the legacy values, and even a limited set got push back (button, textfield).

I think we need to revisit this discussion, taking into account compat data.

• Do we want/need the simpler/cleaner model focused on none and auto, possibly extensible to a few extra values, but explicitly not meant to have the full legacy list
• Do we want/need the full legacy list for company reasons?
• Do want/need both?

[frivoal]

I think it'd be good to talk about this at the upcoming paris F2F. To help, can we have:

• Info from Mozilla (ping @MatsPalmgren @dbaron) about what you are running into that makes you need more than auto and none
• usage data from Blink and Webkit (ping @tabatkins @RByers @grorg @smfr) on your prefixed variant
• usage data (and possible remaining problems) from Microsoft since for -webkit-appearance is supported in IE/Edge

[dbaron]

From Mats's link in #1250 (comment) at least one of the issues we were hitting was https://webcompat.com/issues/5910 . But probably the bigger one was https://bugzilla.mozilla.org/show_bug.cgi?id=1365614 .

[karlcow]

putting the dates here. So I can give all the webcompat cases to @MatsPalmgren and @dbaron prior to the meeting.

https://wiki.csswg.org/planning/paris-2017
Dates: Wednesday-Friday, August 2-4, 2017

[SebastianZ]

But probably the bigger one was https://bugzilla.mozilla.org/show_bug.cgi?id=1365614 .

Regarding this issue, the question is whether appearance values others than none and auto are already used in the wild.

The given example it obviously wrong, as it uses appearance: checkbox. If it looked like this, everything would be fine:

input {
  -webkit-appearance: none;
  -moz-appearance: none;
  appearance: none;
}
input[type="checkbox"] {
  -webkit-appearance: checkbox;
  -moz-appearance: checkbox;
  appearance: auto;
}

Sebastian

[frivoal]

@karlcow CSS F2F in Paris starts tomorrow. If you haven't had the chance yet to give webcompat cases to @MatsPalmgren and @dbaron, now would be a good time.

[karlcow]

@frivoal
Most of the case I met for webcompat are documented in
https://bugzilla.mozilla.org/show_bug.cgi?id=1368555#c4 and subsequent comments.

[dbaron]

@karlcow I think that's not the list that we needed -- we need the list of compat problems that caused @MatsPalmgren's patch to be backed out.

[dbaron]

(And I'd also note that I'm skeptical of things being classified as a "compat problem" if they're reported by the developer of the site rather than a user of it.)

[css-meeting-bot]

The CSS Working Group just discussed CSS UI 4 and appearance, and agreed to the following resolutions:

• RESOLVED: Put a note into "appearance" saying it's not ready to implement, list the possible solutions discussed here, ask impls which they want to do.

The full IRC log of that discussion

<fantasai> Topic: CSS UI 4 and appearance
<TabAtkins> ScribeNick: TabAtkins
<astearns> github: https://github.com//issues/1250
<TabAtkins> Florian: There's an appearance proeprty. We started standardizing it, because a lot of people use "none" on form controls to make them styleable in CSS.
<TabAtkins> Florian: This previous existed as a prefixed form in most browsers.
<TabAtkins> Florian: Before stadndardization, the values other than none was a very long list of all the ways an element could look; this list was different across browsers.
<TabAtkins> Florian: We concluded this was impossible to standardize, in part because many apply to pseudo-elements that other browsers don't have, as they construct form elements differently.
<TabAtkins> Florian: Instead, we'd just have an "auto" value that makes form controls look like whatever they need, and a "none" value that suppresses it.
<TabAtkins> Florian: We could possibly exxtend this into a small list of special values, like "button" to make it look like a native button, but so far ahve resolved not to.
<TabAtkins> Florian: Now Moz said that they need to implement all of the -webkit-appearance values.
<TabAtkins> Florian: I'm a little suspicious.
<TabAtkins> dbaron: Not sure if that's accurate.
<TabAtkins> dbaron: I think it's, *when* we implemented both appearance and -webkit-appearance, sites broke.
<TabAtkins> Florian: They first said they aliased them to each other, and that broke stuff.
<TabAtkins> Florian: That's expected, they're very different.
<TabAtkins> Florian: They said "we need to ipmlement all the -webkit values anyway, so the simple one isn't useful to us"
<TabAtkins> dbaron: Not sure that's what we said/meant.
<TabAtkins> Florian: Then I'm confused and need to know what they mean.
<TabAtkins> Florian: "fwiw, we intend to support -webkit-appearance with all values that Chrome supports" ~ Mats Palmgren, June 7
<astearns> comment here: https://github.com//issues/1250#issuecomment-306788821
<TabAtkins> dbaron: There are sites that specifically set "input { appearance: none; } input[type=checkbox] { appearance: checkbox; }"
<TabAtkins> Florian: We did say that, if needed for webcompat, we could add a handful of required values.
<TabAtkins> Florian: This is very different from adding all 50+ webkit values.
<tantek> FYI: https://bugzilla.mozilla.org/show_bug.cgi?id=1368555
<TabAtkins> dbaron: If that's the case, then don't put 'appearance' in a spec ready for impl.
<TabAtkins> dbaron: Otherwise people try to implement it.
<fantasai> TabAtkins: Maybe have a scary notice saying this is problemantic
<fantasai> Florian: I had that note. WG asked me to remove it.
<tantek> see the webcompat.com URLs in the above bugzilla bug
<fantasai> TabAtkins: I'm fine with putting note back
<fantasai> TabAtkins: to say that we might need some values
<TabAtkins> Florian: Cool. But that's different from saying we need all the webkit values. Because then we need all the webkit pseudo-elements, and I'm not speccing that.
<TabAtkins> jet: Doesn't mean we might not need it.
<TabAtkins> Florian: Maybe, but it'll be a huge effort. Need good proof it's needed.
<fantasai> and Florian should be given a correspondingly significant budget for working on it :)
<TabAtkins> TabAtkins: So suggestion: add note saying don't implement this property yet; it needs some subset of the -webkit-appearance values; impls need to tell us which subset is necessary
<TabAtkins> Florian: Initial draft included the other values Edge supports for -webkit; presumably that's for compat reasons.
<TabAtkins> Florian: WG told me to remove it.
<TabAtkins> gregwhitworth: My recollection was a question whether it was even needed.
<TabAtkins> TabAtkins: David suggested we did - his example would break checkbox rendering.
<TabAtkins> dbaron: I don't know the exact details, there's so many bugs and compat stuff it'll take a while to untangle.
<TabAtkins> Florian: So two options: none | auto | <non-exhaustive-list> ; or none | <exhaustive-list>
<TabAtkins> fremy: Alternatiely: let it take any keyword, treat unknown ones as "auto".
<TabAtkins> Florian: That doesn't match today.
<TabAtkins> astearns: Why is "auto" only with non-exhaustive list?
<ericwilligers> +q
<TabAtkins> TabAtkins: We could put it with exhaustive, and we could omit it from the non-exhaustive list. Depends on details.
<tantek> q?
<astearns> ack ericwilligers
<TabAtkins> fremy: If you have "div { -webkit-appearance:button}", nothing happens. But "input { -webkit-appearance: none; }" does work; using "checkbox" will work on a checkbox input, but won't turn a text input into a checkbox.
<TabAtkins> ericwilligers: I heard dbaron say that if they ship appearance it'll break compat. Can we just change the name?
<fremy> TabAtkins, yes
<tantek> q+ to note or we go with original guidance to drop appearance from CSS UI, and let it get documented in https://compat.spec.whatwg.org/ instead (all prefix or not variants)
<TabAtkins> Florian: And then we can avoid saying "none", and use "normal" instead, which sounds better.
<tantek> per https://github.com//issues/1250#issuecomment-306788821
<TabAtkins> dino: Who implements unprefixed appearance?
<fremy> TabAtkins, input { -webkit-apperance:none} input[type=button] { -webkit-appearance: checkbox } renders as a button
<TabAtkins> Florian: Nobody that I know, but I last checked a while ago.
<TabAtkins> dbaron: We tried, but backed it out before it hit stable.
<TabAtkins> dbaron: It's not clear what portions of the problem were with "appearance" and which were with "-webkit-appearance".
<TabAtkins> dino: I was considering implementing unprefixed with just "none" and "auto".
<TabAtkins> ack tantek
<Zakim> tantek, you wanted to note or we go with original guidance to drop appearance from CSS UI, and let it get documented in https://compat.spec.whatwg.org/ instead (all prefix or not
<Zakim> ... variants)
<TabAtkins> tantek: One of the points Mats made is that this isn't a particularly useful feature for web authors.
<TabAtkins> tantek: So one proposal is just to drop it entirely.
<TabAtkins> fantasai: People use it a lot.
<TabAtkins> TabAtkins: I use "none" plenty to do styles on my buttons, etc.
<TabAtkins> dbaron: It's not cleaer to me which of these was the good reason to back the whole thing out.
<TabAtkins> dbaron: ONe of my guidelines is that if a user reports a bug, that's a compat problem; if the dev does, that's not a compat problem.
<TabAtkins> dbaron: And one of them was reported by a dev, because it comes with a jsfiddle.
<fantasai> s/not/not necessarily/
<fantasai> TabAtkins: That said, your example looks believable
<fantasai> TabAtkins: It would be fixed by fremy's proposal
<fantasai> astearns: would also be fixed by minting an entirely new property
<TabAtkins> astearns: So that seems like a cleaner solution.
<TabAtkins> TabAtkins: Possible conclusion, just leave this unresolved, but note the handful of possible solutions and ask impls to tell us which they want to do.
<TabAtkins> Florian: Seems better than trashing it.
<tantek> seems like a lot of work for very little benefit
<tantek> so I question why
<TabAtkins> RESOLVED: Put a note into "appearance" saying it's not ready to implement, list the possible solutions discussed here, ask impls which they want to do.
<fantasai> TabAtkins: Answer to tantek's question is that people use it for useful things today
<fantasai> TabAtkins: and there is no other solution for what they want today
<tantek> where is the documentation of the use-case in the spec? let's drop a URL here for the minutes

[FremyCompany]

In Edge we do not need a behavior more complex than if (appearance == none) { A() } else { B() } anywhere but this one exception:

• When -webkit-appearance is none, webkit based browsers do not show the action part nor does it consume space.
• When -webkit-appearance is not the default, webkit based browsers do not show the action part but it does consume space.

[karlcow]

@dbaron

(And I'd also note that I'm skeptical of things being classified as a "compat problem" if they're reported by the developer of the site rather than a user of it.)

If you are talking about codepen stuff, it's usually me trying to reduce real issues.

The backout was generated by a new issue we didn't have in webcompat (aka not reported by us). I guess we could not know about them without having the change made. When @MatsPalmgren released its build, I tested the previous issues and it was working.

Before the backout (aka before the new issue) I had mentioned that for GECKO

• -webkit-appearance: none should behave like it does on webkit
• appearance: none is used in code like an alias of -webkit-appearance
• -moz-appearance: none can not be removed.

[SebastianZ]

So it looks like the options are:

1. Keep appearance: none | auto; and accept that it breaks use cases like the one mentioned earlier.
2. Let unrecognized keywords map to auto.
3. Change the none keyword to something else.
4. Change the property name.
5. Change initial value to none and overwrite it in UA style sheet with auto.
6. Remove the property from the spec.

Do I miss other options?

Sebastian

[karlcow]

Paper trail https://log.csswg.org/irc.w3.org/css/2017-08-03/#e845293

[FremyCompany]

1. given firefox had to remove it from their browser, this is probably not acceptable
2. would work if webkit browsers agreed to fix the case mentioned in my comment above
3. would defeat the reason why we want this property in the first place.
4. would defeat the reason why we want this property in the first place.
5. doesn't solve the problem reported by Mozilla.
6. doesn't solve anything either because we would need to specify the webkit one then.

There is also option 7:

7. create a list of keywords that browsers should support for the property and mention they should all behave like "auto" but may have other effects in some cases (we will try to document such cases; the only one I am aware is the one mentioned above)

[frivoal]

I'd like to make progress on this. It seems to me that what @FremyCompany suggested in #1250 (comment) is a good way forward. We can do it "option 2" style, and accept any keyword for the auto behavior, or option 7 style, and white-list what we accept.

I think I lean towards white-listing the things that should behave as auto, so that if we ever decide we want to introduced some values with another behavior, we're not stuck, but this is merely a preference, and I'm happy to go with something else if there's implementer consensus.

[sabithpocker]

Tangent on system colors and appearance being both deprecated

I am quoting from an outdated document here (as it is the only place a reason is mentioned for the deprecation of System Colors)

The CSS2 System Color values have been deprecated in favor of the CSS3 UI 'appearance' property for specifying the complete look of user interface related elements.

It now appears that appearance won't be taking up this responsibility and this quoted line has been removed from the document. The reason why System Colors was deprecated and if appearance will provide an alternative remains vague as of now.

How do we proceed with scenarios where we have to style elements to look as native as possible?

I am not sure if this is the place to place this query in, please ignore this or direct me to a place where this issue can be raised. (Issue placed here)

[FremyCompany]

@sabithpocker Yes, it would be nice if you opened another issue (in this same repo) to discuss this.

[zcorpan]

Also see whatwg/compat#104

[zcorpan]

@FremyCompany

• When -webkit-appearance is none, webkit based browsers do not show the action part nor does it consume space.
• When -webkit-appearance is not the default, webkit based browsers do not show the action part but it does consume space.

Can you clarify what this refers to? Which element? What is the action part?

[FremyCompany]

@zcorpan I believe this was the <select> element

[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;.

That would probably solve many issues.

[zcorpan]

@FremyCompany OK. What you describe seems right for Edge/Chrome/Firefox on Windows, but not for Safari/Chrome/Firefox on macOS.

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

What should we require in the spec?

[FremyCompany]

@zcorpan What a mess. I'm not sure. the Windows behavior makes no sense, so I'd vouch for the MacOS behavior, but the reason why things converged to this state should probably be considered, and I don't have that background. Maybe someone from the Chrome team does.

[MatsPalmgren]

Fwiw, Firefox is consistent across platforms - it removes the space for the dropdown button when 'appearance' is not 'menulist'. I don't think it makes sense to reserve space for it but not render it.

[zcorpan]

The initial value is now 'none' and the specification supports a number of legacy keywords for web compat. Although the exact list of keywords is still being tweaked, I believe this issue is essentially fixed.

Can the warning in the spec be removed? If not (yet), what needs to happen first?

[jugglinmike]

@frivoal We'd like to request that browsers implement the unprefixed property, but the warning text may dissuade them. Are you comfortable with removing it?

[css-meeting-bot]

The CSS Working Group just discussed Remove warning about 'appearance', and agreed to the following:

• RESOLVED: Remove implementation warning and add a note about possible changes to list of values for webcompat. Wording at editors discretion

The full IRC log of that discussion

<dael> Topic: Remove warning about 'appearance'
<dael> github: https://github.com//issues/1250#issuecomment-492759907
<dael> florian: I can unless whomever added it wants it
<TabAtkins> I'll be in one sec... (Feel free to do the next issue first)
<dael> florian: Design of appearance property is proceeded by a warning that we don't know if it's webcompat. What's spec is a combo of none and auto and a few compat things. It seems that design works and people are trying to implement. I have been asked to remove it.
<dael> florian: I support removing the warning. If we agree I will remove the giant note that says this isn't good to impl
<dael> dbaron: Who has shipped support?
<dael> florian: I think Google is trying to ship support for this. I don't know the state
<dael> florian: I think Mozilla is also trying
<dael> tantek: Presumably someone is trying to ship or else it wouldn't be a compat problem
<dael> florian: It was a compat concern. The work zcorpan did showed it was likely to be web compat. We never know until everything is finished
<dael> tantek: Comment says it's for webcompat. THe legacy keywords are for web compat
<dael> florian: The spec is for web compat
<dael> tantek: Then that means someone must have impl it.
<dael> fantasai: Is zcorpan on?
<dael> florian: It was designed in order to handle web compat. zcorpan researched it and I believe he concluded it was. It has not shipped
<fantasai> +1
<dael> Rossen_: ANy reason not to remove the warning? Warning was pending someone attempting to impl. Seems there are attempts to impl and experiment. If that's the case let's remove warning
<dael> fremy: Makes sense. If there's a problem when people impl we can change the spec. NO reason to think there is so we can remove the note.
<dael> dbaron: I'd prefer to leave something but remove the warning it's not okay to ship. I think we should still have a warning saying we're not sure this is going to work.
<dael> Rossen_: Are we sure anything will work before we ship?
<dael> dbaron: I think we're particularly unsure
<dael> astearns: Could change to something that says set of values other than none needs to be evaluated. Need to figure out if this is the correct set
<dael> florian: Agree but we have spent time investigating. It won't be over until shipped, but it's not that it hasn't started
<dael> astearns: Something like as far as WG understands this is the set of non-none values, but more input is welcome
<dael> tantek: I think your first wording is right, but change to tense that we are evaluating and continuing to evaluate
<dael> astearns: zcorpan evaluated and we came to a comclusion
<dael> tantek: He says the list is being tweaked so I think that's not final
<dael> florian: He requested the removal
<fantasai> Replace curent wording with "ISSUE: We are evaluating Web-compat of this feature's list of values. Please send any relevant feedback to the CSSWG" ?
<dael> tantek: But I wouldn't dispute what he's saying
<fantasai> or maybe even s/ISSUE/NOTE/
<dael> astearns: Prop: We have a not suggesting people impl and try this out, but we are open to more input on what the necessary set of values are. Let the editors wordsmith that.
<dael> dbaron: sounds fine
<dael> s/not/note
<dael> astearns: fantasai suggests it's an issue not a note?
<dael> fantasai: No opinion, I just wanted to put wording
<dael> fantasai: Leaving to the editor and moving on is okay
<dael> tantek: b/c it's an open question still about normative text i think it deserves to be an issue. Note implies nothing normative will change
<dael> astearns: We often put notes in L3 drafts saying things might change in L4
<dael> astearns: Would you object to leaving as a note tantek ?
<dael> tantek: I can live. Just indicating preference
<dael> astearns: Proposal: Remove implementation warning and add a note about possible changes to list of values for webcompat. Wording at editors discretion
<dael> RESOLVED: Remove implementation warning and add a note about possible changes to list of values for webcompat. Wording at editors discretion

[zcorpan]

Thank you, @frivoal. The change LGTM.

Also apologies for being late to the telecon to miss the discussion!