New issue

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

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

Already on GitHub? Sign in to your account

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

Open
MatsPalmgren opened this Issue Apr 19, 2017 · 22 comments

Comments

Projects
None yet
@MatsPalmgren

MatsPalmgren commented Apr 19, 2017

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.

@tabatkins tabatkins added the css-ui-3 label Apr 20, 2017

@frivoal frivoal added css-ui-4 and removed css-ui-3 labels May 12, 2017

@frivoal frivoal self-assigned this May 12, 2017

@frivoal

This comment has been minimized.

Show comment
Hide comment
@frivoal

frivoal May 12, 2017

Contributor

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.

Contributor

frivoal commented May 12, 2017

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

This comment has been minimized.

Show comment
Hide comment
@frivoal

frivoal Jun 6, 2017

Contributor

ping @MatsPalmgren Any opinion on the above?

Contributor

frivoal commented Jun 6, 2017

ping @MatsPalmgren Any opinion on the above?

@MatsPalmgren

This comment has been minimized.

Show comment
Hide comment
@MatsPalmgren

MatsPalmgren Jun 7, 2017

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.

MatsPalmgren commented Jun 7, 2017

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

This comment has been minimized.

Show comment
Hide comment
@frivoal

frivoal Jun 8, 2017

Contributor

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?
Contributor

frivoal commented Jun 8, 2017

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 frivoal reopened this Jun 8, 2017

@frivoal frivoal added the Agenda+ F2F label Jun 8, 2017

@frivoal

This comment has been minimized.

Show comment
Hide comment
@frivoal

frivoal Jun 8, 2017

Contributor

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

Contributor

frivoal commented Jun 8, 2017

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

@dbaron

This comment has been minimized.

Show comment
Hide comment
@dbaron

dbaron Jun 8, 2017

Member

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 .

Member

dbaron commented Jun 8, 2017

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

This comment has been minimized.

Show comment
Hide comment
@karlcow

karlcow Jun 8, 2017

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

karlcow commented Jun 8, 2017

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

This comment has been minimized.

Show comment
Hide comment
@SebastianZ

SebastianZ Jun 8, 2017

Contributor

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

Contributor

SebastianZ commented Jun 8, 2017

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

This comment has been minimized.

Show comment
Hide comment
@frivoal

frivoal Aug 1, 2017

Contributor

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

Contributor

frivoal commented Aug 1, 2017

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

@astearns astearns removed the Agenda+ F2F label Aug 1, 2017

@karlcow

This comment has been minimized.

Show comment
Hide comment
@karlcow

karlcow Aug 2, 2017

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

karlcow commented Aug 2, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@dbaron

dbaron Aug 3, 2017

Member

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

Member

dbaron commented Aug 3, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@dbaron

dbaron Aug 3, 2017

Member

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

Member

dbaron commented Aug 3, 2017

(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

This comment has been minimized.

Show comment
Hide comment
@css-meeting-bot

css-meeting-bot Aug 3, 2017

Member

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/w3c/csswg-drafts/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/w3c/csswg-drafts/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/w3c/csswg-drafts/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
Member

css-meeting-bot commented Aug 3, 2017

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/w3c/csswg-drafts/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/w3c/csswg-drafts/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/w3c/csswg-drafts/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

This comment has been minimized.

Show comment
Hide comment
@FremyCompany

FremyCompany Aug 3, 2017

Contributor

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

FremyCompany commented Aug 3, 2017

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

This comment has been minimized.

Show comment
Hide comment
@karlcow

karlcow Aug 3, 2017

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

karlcow commented Aug 3, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@SebastianZ

SebastianZ Aug 5, 2017

Contributor

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

Contributor

SebastianZ commented Aug 5, 2017

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

This comment has been minimized.

Show comment
Hide comment
@FremyCompany

This comment has been minimized.

Show comment
Hide comment
@FremyCompany

FremyCompany Aug 17, 2017

Contributor
  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:

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

FremyCompany commented Aug 17, 2017

  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:

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

This comment has been minimized.

Show comment
Hide comment
@frivoal

frivoal Nov 3, 2017

Contributor

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.

Contributor

frivoal commented Nov 3, 2017

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.

@astearns astearns removed the Agenda+ F2F label Nov 6, 2017

@sabithpocker

This comment has been minimized.

Show comment
Hide comment
@sabithpocker

sabithpocker Feb 5, 2018

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)

sabithpocker commented Feb 5, 2018

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

This comment has been minimized.

Show comment
Hide comment
@FremyCompany

FremyCompany Feb 5, 2018

Contributor

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

Contributor

FremyCompany commented Feb 5, 2018

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

@zcorpan

This comment has been minimized.

Show comment
Hide comment
@zcorpan
Member

zcorpan commented Aug 27, 2018

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