Csswg-drafts: [css-ui] Change appearance: button to only apply to buttons

[zcorpan]

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

See https://github.com/whatwg/html/pull/4857

Change button to not be applicable to non-buttons
intent to ship

I didn't see a spec issue about this, so filing this.

I think the change to css-ui to match is to move button to the list of <compat-auto> non-terminal value type.

cc @tkent-google @emilio @smfr @frivoal

[zcorpan]

cc @heycam

[heycam]

For what it's worth, telemetry that I added to Firefox to check for -moz-appearance value usage showed that 0.051% of pages loads used -moz-appearance: button on some non-widget element, and 0.016% of page loads used -moz-appearance: button on a widget whose default appearance is not button.

[frivoal]

I believe we have a much older resolution saying that the WG didn't want any value other than none or auto, except for compat reasons. By that logic, if button on arbitrary elements isn't needed for compat, we ought to be retiring it, and making it part of <compat-auto> seems like the right way to do that.

@heycam Is 0.051% an acceptably low threshold for Mozilla for this particular change?

[heycam]

To me it feels a little high. That's one in every 2,000 pages.

[zcorpan]

There was more detailed analysis behind Chromium's decision to change this, see https://groups.google.com/a/chromium.org/forum/m/#!msg/blink-dev/QFXFzfQtlKk/YPOZLSoXCwAJ

This shipped in chromium 80. @tkent-google have there been any bug reports from this change?

[tkent-google]

This shipped in chromium 80. @tkent-google have there been any bug reports from this change?

AFAIk, there are only two bug reports.
https://bugs.chromium.org/p/chromium/issues/detail?id=1038687
https://bugs.chromium.org/p/chromium/issues/detail?id=1094709

We have no plan to revert the current behavior.

[css-meeting-bot]

The CSS Working Group just discussed Change appearance: button to apply only to buttons, and agreed to the following:

• RESOLVED: Limit 'appearance: button' to buttons once we figure out what buttons are

The full IRC log of that discussion

<fantasai> Topic: Change appearance: button to apply only to buttons

<Rossen_> github: https://github.com/w3c/csswg-drafts/issues/5174

<fantasai> florian: General principle that 'auto' does magic by tag, and 'none' turns of magic

<fantasai> florian: But we have some legacy stuff

<fantasai> florian: As specified, appearance: button makes things look like buttons

<fantasai> florian: even when not actually buttons

<fantasai> florian: We could reduce magic of button by only applying 'appearance: button' to buttons

<fantasai> florian: Mozilla was a bit skeptical

<tantek> q-

<emilio> scribenick: emiliop

<emilio> scribenick: emilio

<emilio> fantasai: I think this is one of the things that may be useful to do on things that are not buttons

<emilio> ... for visual reasons it may be useful. In a lot of cases they style it so that they look like their buttons, but if they weren't it would be useful

<iank_> q+

<emilio> ... I don't see a huge benefit from restricting this if we need to make it work for everything else so I'd lean towards not doing that

<fantasai> florian: Current definition allows to turn link into button ...

<emilio> florian: the current definition would allow you to turn stuff into buttons, but also weird cases where they should not

<emilio> q+

<tantek> not sure about the compat details, however I'm in favor of less magic here

<emilio> ack fantasai

<fantasai> florian: but do we reduce this to only compat necessity or do we let people make things into buttons when possible?

<Rossen_> ack iank_

<fantasai> iank_: I think part of the work with the simplifying making appearance sane was to limit the magic in scope

<fantasai> iank_: It seems like a bit of a reversal if we say, actually, we do want these to apply to everything

<fantasai> iank_: so prefer to restrict this down as much as possible

<Rossen_> ack emilio

<fantasai> emilio: If compat allows it, prefer to put less magic here

<fantasai> emilio: We have prefixed appearance, and hacky internal property to support 'appearance: button'

<emilio> s/prefixed/unprefixed, heycam|away implemented it

<fantasai> fantasai: wanted clarification...

<Rossen_> fantasai: are links explicitly called out? can they be used as btn?

<fantasai> florian: Current spec allows any element to look like a button

<fantasai> florian: Chrome says not many people use it, not even on links

<emilio> q+

<Rossen_> ack emilio

<fantasai> emilio: To be clear, magic of 'appearance: button' applies to everything except ? and ?

<emilio> input, textarea and non-listbox selects

<fantasai> iank_: I believe we've already shipped this in 80 which is quite a few releases ago

<fantasai> florian: by this you mean the simplification you proposed?

<fantasai> Rossen_: That means you're not breaking anyone who depends on this?

<fantasai> iank_: Got a few minor reports

<fantasai> iank_: no large-scale breakage

<fantasai> Rossen_: Based on data, we can live with scoping 'appearance: button' to buttons only, is this something we can resolve on?

<fantasai> Rossen_: Proposed resolution is scope 'appearance: button' to buttons only

<fantasai> Rossen_: Hearing no objections. Call it resolved. If there's issue wrt links, I'm sure we can re-oepn

<fantasai> smfr: Are we saying that 'appearance: button' only applies to the BUTTON element?

<fantasai> hober: <input type=button> ?

<fantasai> smfr: file input button?

<fantasai> florian: I guess it's BUTTON and <INPUT type=button>

<tantek> and reset

<fantasai> smfr: <input type=submit> ?

<fantasai> florian: Chrome folks can you clarify?

<tantek> Blink folks, what was implemented? <button> <input type=button|submit|reset>?

<fantasai> RESOLVED: Limit 'appearance: button' to buttons once we figure out what buttons are

[atanassov]

As a follow up on the previous discussion, we should define what _buttons_ refer to.

[frivoal]

The conclusion reached during the meeting is a little bit flawed, as we used imprecise language and confused ourselves.

RESOLVED: Limit 'appearance: button' to buttons once we figure out what buttons are

As a follow up on the previous discussion, we should define what buttons refer to

We don't actually need to define what buttons are, because the way we achieve "Limit 'appearance: button' to buttons" is by making button part of the <compat-auto> non-terminal value type. This means the button keyword will behave identically to the auto, this lets widgets get their native appearance, and leaves other things alone. The result is that things that aren't supposed to be buttons can no longer forcibly be made into buttons, but we don't need to specify which is which, as determining what is the correct native appearance of various widgets is the responsibility of the host language (HTML), not of the css spec.

Based on that, the resolution is actually enough to make the edit to the spec, and does not need further research to determine what buttons are.

[zcorpan]

Thanks @frivoal!

Tests updated in https://github.com/web-platform-tests/wpt/pull/25428

[zcorpan]

For the question "what is a button?", that is up to the host language per https://drafts.csswg.org/css-ui/#native-appearance

For HTML, per https://github.com/whatwg/html/pull/4857 these can end up with the "button" "kind of widget":

• button
• input with type Button, Submit, Reset, or Color

[MatsPalmgren]

Hmm, is this really web-compatible? I thought we all agreed that appearance:button on a HTML <select> should suppress the drop-down button. That's what Firefox and Safari still do and it's a fairly common use case on the web last I checked. I'm pretty sure Chrome used to have that behavior too because the reason we (Gecko) implemented it was that we were getting bug reports about broken web sites which expected that behavior because of Chrome.

[zcorpan]

@MatsPalmgren it has been shipping in Chromium since M80 (reached stable in February). See the intent to ship thread for number of page views impacted.

From the minutes above:

<fantasai> Rossen_: That means you're not breaking anyone who depends on this?
<fantasai> iank_: Got a few minor reports
<fantasai> iank_: no large-scale breakage

[zb3]

Do you really need to make it impossible to make links look like buttons without having to write custom button styles from scratch? Maybe I'm missing something, but what's the other way to make a button have an "Open in new tab" entry in it's context menu?

[frivoal]

Without taking a personal opinion on the matter, yes, this is what the change means: links aren't buttons, and the ability to make them look like buttons was an unintended accident of how things were implemented, and as we're cleaning up the way things work, it was judged acceptable to remove that ability, given that data seems to show that very few web pages actually used it.

There was some skepticism during the call where we took that resolution (notably expressed by @fantasai), but this wasn't strong enough to stop the proposal.

If you think this is a mistake, it would be good to either provide some evidence that the breakage of existing sites is going to be more common / severe than anticipated, or some explanation of why this ability is desirable (what are you trying to achieve + why is that a good thing + why can't you do it some other way). The more strongly you can make this argument, the better the chances.

[zb3]

You don't have to look far to find the use case, because even on this page, we have the New Issue link, which does look like a button, yet with all the benefits of it being a link, like copying the url or opening it in the new tab. a {appearance: button} is not used in this case (so it didn't count and wasn't affected), but this is only because its styles were implemented from scratch. In the end, this is what I did as well, I just made another class to make button links look like buttons without relying on a {appearance: button} so now I don't have to think about that.

I think my argument here is just that a {appearance: button} makes this scenario easier to implement, but in no way decides whether implementing this scenario is possible. My original use case was for generating a document with the ability to copy the link to tweak some of its parameters, but I don't think that's what I'd argue about.

[Marat-Tanalin]

So we are now still forced to use an empty form:

<form action="/example/">
    <button type="submit">Link button</button>
</form>

just to create a link that looks like a native button. With no ability to open it in a new tab/window, see the target URL in advance or copy the URL, and with a need to work around the Chromium and WebKit bugs that cause adding a question mark even though the query string is empty.

That’s amazing, CSSWG.

[Marat-Tanalin]

@frivoal

data seems to show that very few web pages actually used it.

Because people were waiting when the feature gets finally standardized? Instead of collecting stats regarding the appearance property, it would probably be more reasonable and useful to collect stats of:

• styling links to mimic buttons (GitHub is an example);
• using an empty form for that purpose (the _only_ way to make a link look like a _true_ native button, not just _similarly_).

[frivoal]

The past few comments (since https://github.com/w3c/csswg-drafts/issues/5174#issuecomment-704329991) seem to justify reopening this issue to me.

Summary: people want to do appearance: button on links, but per the latest spec this is not possible, appearance: button will only work on things that the markup language considers buttons, and links isn't one of those.

[zcorpan]

Maybe HTML could provide a way to create formless buttons that act more like links? And browsers could support submitting forms into a new tab through the context menu (without any spec changes).

I would be OK with allowing appearance: button on links, though.

[jensimmons]

I asked about this on Twitter: https://twitter.com/jensimmons/status/1329115564233662464

[css-meeting-bot]

The CSS Working Group just discussed [css-ui] Change appearance: button to only apply to buttons, and agreed to the following:

• RESOLVED: Close this issue no change and open a more narrowly scoped issue

The full IRC log of that discussion

<dael> Topic: [css-ui] Change appearance: button to only apply to buttons

<dael> github: https://github.com/w3c/csswg-drafts/issues/5174

<dael> florian: Background- general story is pre-standard version of appearance had a whole bunch of values which caused appearance to change. Button made things into buttons. Standard version attempts to only have none and auto. Auto lets form control be what they should be and none makes them HTML elements.

<dael> florian: Button is necesary for compat. Compat study done in Blink is if it behaves like auto and lets things that are buttons be like buttons that's enough. Button syntax exists, same as auto.

<dael> florian: Doesn't break thte web, but it break what people want. People don't want arbitrary things look like buttons, but they want links to look like buttons.

<dael> florian: Might not break the web, but if you look at github page the new issue button is a link not a button.

<dael> florian: This didn't always show up on web compat study they're styled buttons. Since the stylistic abilities on native controls are limited it doesn't always show as applying appearance button.

<dael> florian: Request is to extend that if you do it on a link element it causes it to look like a button

<emilio> q+

<jensimmons> q+

<dael> florian: We noted it during discussion on closing it might be wanted but we did it anyway. As soon as we resolved people said they did want it.

<astearns> ack emilio

<dael> florian: I don't have an issue, wanted thoughts.

<iank_> q+

<florian_irc> q+

<zcorpan_> q+

<dael> emilio: I sympathize with the use case. But if people are doing it it would have come up in the analysis we did. People have been able to do this for a long time and they haven't. Why should we re-introduce on basis that it might be nice sometimes

<astearns> ack jensimmons

<dael> jensimmons: Trying to think about this from author PoV. One of the struggles for people teaching best practices very often there are engineers who confuse a link and a button. Use links when should be buttons and the other way. They do a link b/c want styling and then have JS. I don't know if having demand for this is a good signal. might be demand from people that need to udnerstand better

<fantasai> jensimmons, see https://github.com/w3c/csswg-drafts/issues/5174#issuecomment-707015527

<astearns> ack iank_

<dael> jensimmons: Not sure of that either. There's a struggle among teachers to teach the right way to do things. I don't have a clear sense of the answer. But demand is not always a good thing

<dael> iank_: I think, one things from me, and this might be a not yet signal...a lot fo what we see is people styling own buttons because native aren't stylable enough. Might be more comfortable with this question after we make native form controls more stylable.

<plinss> q+

<astearns> ack florian_irc

<dael> iank_: Other interesting point is extending buttons to do more link-like things. I'm not saying no but maybe not yet until we understand more

<dael> florian_irc: To jensimmons I agree with overall problem. not sure which way it goes. There are places where you want behavior of a link that's what you want. You just wnat it to look like a button and bad to use HTML element to do that. Is that stronger or reverse, I'm not sure

<dael> florian_irc: As to not show in telemetry I think it may have been there but not break web. Could also be there less b/c not able to style native buttons. If they could style they may want to use it more and use it on links. It right now makes it look like non-native button as buttons and links are native and you don't want that.

<dael> emilio: I'm not sure that argument makes sense to me but I may be misreading

<dael> emilio: If you style a native button to look non-native, that you can do. not sure what capability we're lacking

<dael> florian_irc: Claim is that you can do and people do it. And that's why you're not finding it. But where you want to not change them away from buttons and want to keep button buttons and link buttons on a consistent style you need ability to do button style on link

<astearns> ack zcorpan_

<dael> emilio: Butotn resets a bunch of styles as well, like text-transform. Also a different layout box. Appearance: button is a paint-time hack. I don't feel like argument is super strong. I can see it

<dael> zcorpan_: First on the principle level feels a bit dirty to allow button on links. Buttons are buttons and links are links. That's the principled stand. There are practicle concerns. Some are in the thread and can be resolved by changing HTML. When it's open in a new tab, not all browsers can do that for submitting forms.

<dael> zcorpan_: Other was a bug where if you submit a form without any fields it still adds a ? to the URL which is shouldn't.

<dael> zcorpan_: Also, I know tel:links only works as links. Can't submit a form to a tel URL and have it open the phone app on your device yet people want that call us button to look like a button but their only choice is to use a link. Could be a use case

<dael> zcorpan_: Or allowing forms to submit to tel. not sure why that doesn't work

<bkardell_> q+

<astearns> ack fantasai

<dael> fantasai: Forms to submit to tel makes no sense. You guys are trying to justify the difference between button and link are because the style. That's rediculous. The idea is you pick your markup based on what it si and behavior it should have and then you style to what it should look like. They are link and behave like links. Only reason it has anything to do with button is want it to look like a button

<tantek> from my experience with web authors, this is not a use-case they want

<bkardell_> q-

<fantasai> https://github.com/w3c/csswg-drafts/issues/5174#issuecomment-707015527

<dael> fantasai: Trying to argue to make button act like link we should add an appearance to make it look like a button. Specific comment and use case in the issue ^

<dael> fantasai: Even on this page you have a new issue with all the button style and link properties. Github uses custom styles. This is what people want to do.

<emilio> q+

<jensimmons> q+

<dael> fantasai: Makes a lot of sense to handle at CSS layer. Button is correct tool. Should allow as it is in the past. It's not complicated to impl, we know how to apply button style to a box.

<tantek> as the person that came up with appearance for this exact use-case, I'm saying this is not a path worth going down.

<dael> fantasai: I think it makes sense. Maybe tehre's good tweaks to HTML but if they want to have something look like a button they shouldn't have to use the button element

<astearns> ack plinss

<fantasai> s/Button is the correct/appearance:button is the correct/

<astearns> ack emilio

<dael> plinss: I want to counter that. When building a web app the best practice is to have app state in the URL. Buttons to drive things. You often do want buttons that act like links. Most web component libs have href on the buttons. There's an argument to give button all the capbilities of a link

<bradk> How buttons and links work is not a CSS issue. How they look is.

<jensimmons> q-

<tantek> we already agreed to stop trying to make appearance more incrementally useful. I'm a bit surprised this is being re-opened without new information. one random github comment is not new information

<dael> emilio: I was going to say fantasai argument is the opposite of what we've been doing with appearance for the last couple years. We reduced number of values and restricted to apply to specific elements to avoid people doing this stuff. I don't see why we should change direction again. Appearance has been a mess

<dael> florian_irc: I can see inbetween. In previous appearance you could make a select drop down look like radio. You had values for all pseudo elements that are components. Turning button in drop down to look like scroll bar. Made no sense. Good to get rid of

<tantek> the right approach is to work on making OpenUI work for this kind of use-case and related use-cases

<dael> florian_irc: Buttons are an arbitrary container. Turning stuff into buttons isn't crazy. Ask is limited. It's not asking for a div. Link and button behavior is close. In this limited case it's not that hard.

<tantek> disagreed. the behavior of links and buttons is not "sorta close" at all, nor are their semantics.

<dael> astearns: At the end of queue, not hearing consensus

<bkardell_> tantek: I would like to hear the argument you're making there ^

<dael> plinss: One more point I forgot. Gneerally with custom elements buttons have beahvior, not jsut apeparance. Unless we give behavior the style won't give you everything.

<tantek> plinss's point is exactly why we abandoned the 'appearance' property approach

<dael> plinss: If all the behavior you want is a link, use a link.

<tantek> bkardell_: great, participate in OpenUI for those discussions

<dael> florian_irc: Links that behave like links should be links. Good to have it look like a button? People do it

<jensimmons> btw, I tweeted this question out: https://twitter.com/jensimmons/status/1329115564233662464

<tantek> to be blunt, this is the wrong call to solve this problem. this should get pushed to OpenUI

<dael> plinss: But you have visual effects and everything on your button and you won't get that on a link. You don't get the grid placement, etc. Easier to have a button that acts like a link

<chrishtr> I agree about the OpenUI suggestion.

<chrishtr> s/about/with/

<tantek> and please stop trying to make appearance a thing (insert Mean Girls meme)

<dael> astearns: I suggest that we close the issue without adding the suggestion of making links look like buttons. If people want ot make further arguments they can raise a separate issue

<dael> zcorpan_: tantek suggested bring this to OpenUI group

<dael> astearns: I think that's fair

<dael> zcorpan_: And for HTML changes we should discuss with WHATWG

<dael> astearns: Right, if there are behaviors that should be shared can discuss there

<dael> astearns: Prop: Reclose with no additional change

<dael> astearns: Obj?

<tantek> +1 to close without change.

<dael> florian_irc: I do kind of buy into fantasai argument. I'm not in a rush to go that way but a bit uneasy about closing w/o consensus

<dael> astearns: I think it is a separate consideration that could have its own issue

<dael> florian_irc: Fair, narrower

<gregwhitworth> zcorpan_: I would expect the potential HTML changes and "need" for appearance changes to fall out of Open UI discussion. As plinss noted, if buttons commonly are trying to use things on links and it's a common paradigm then this should be documented there and propagate to HTML

<dael> astearns: I'd like a new narrowly defined issue and maybe refer back to it. Let's not re-raise it unless you think there's a possibility of concensus

<dael> florian_irc: It's a bit tricky since pre-standard did allow. In terms of behavior browsers can do its. Spec as is would ask to remove

<dael> astearns: And if they do and find problems that's argument for changing spec

<dael> astearns: I'd like a narrower issue and to close the older one

<dael> astearns: Obj?

<dael> RESOLVED: Close this issue no change and open a more narrowly scoped issue

[Marat-Tanalin]

People will then just be forced to use empty forms to make “links” that can’t be opened in a new tab/window, and with no ability to see their URLs in advance. Such button is technically a button, but in fact is a link. Making a link button is technically possible, the resulting links are just not as usable as true links. Is that good?

Fwiw, the russian version of my blog post about making a link look like a native button, has about 60-70 visits daily and is consistently the most popular page of my site for years.

<tantek> I'm a bit surprised this is being re-opened without new information. one random github comment is not new information

There were _two_ comments actually. And mine was probably not about new information, but at least about that a wrong type of stats (using the appearance property itself for making a link look like a button) was used for making the whole decision. As I said, it would probably be more reasonable and useful to make the decision based on stats of:

• styling links to mimic buttons (GitHub is an example);
• using an empty form for that purpose (the _only_ way to make a link look like a _true_ native button, not just _similarly_).

That stats would be not about _how_ the goal is achieved (good developers tend to avoid using nonstandard features), but about _what_ people want to achieve. And I’m not sure collecting stats of cases of styling links to mimic buttons would be easy/possible in an automated way.

astearns: I'd like a narrower issue and to close the older one

Does such a new narrower issue already exist?

P.S. The IRC log is confusing and hard to read. Why is it <dael> florian: and not <florian>? It’s also unclear who each of the conversation participants is except for ones I personally historically know (while other readers might not) like bkardell_, fantasai, florian, tantek, zcorpan_. Some accompanying legend would be helpful for each of such IRC logs.

[astearns]

@Marat-Tanalin the log has <dael> at the beginning of most of the lines because she was minuting. It’s a fair point that the IRC nicks we use in the minutes don’t always match GitHub user names, both of which can be difficult to match to actual names. Perhaps I should start a wiki page with a table of who’s who (which may also help onboarding new members).

The narrower issue does not exist yet - I was asking to have a new one raised. This issue is about limiting the button value to actual buttons (mainly for compat reasons). I think allowing the button value on links is sufficiently different to merit a new start in the discussion.

[frivoal]

Does such a new narrower issue already exist?

Not yet, but it should be created.

The IRC log is confusing and hard to read. Why is it <dael> florian: and not <florian>?

Dael is the person who was taking minutes.

It’s also unclear who each of the conversation participants is except for ones I personally historically know (while other readers might not) like bkardell_, fantasai, florian, tantek, zcorpan_. Some accompanying legend would be helpful for each of such IRC logs.

The logs included here in github is a direct, unedited copy from the IRC session. A cleaned up version of the log, with irc nicks expanded to full names, gets posted to the www-style mailing list once there's been time for cleaning it up. The one that covers this particular issue is: https://lists.w3.org/Archives/Public/www-style/2020Nov/0015.html