- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 18 Nov 2020 17:47:03 +0000
- To: public-css-archive@w3.org
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` <details><summary>The full IRC log of that discussion</summary> <dael> Topic: [css-ui] Change appearance: button to only apply to buttons<br> <dael> github: https://github.com/w3c/csswg-drafts/issues/5174<br> <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.<br> <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.<br> <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.<br> <dael> florian: Might not break the web, but if you look at github page the new issue button is a link not a button.<br> <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.<br> <dael> florian: Request is to extend that if you do it on a link element it causes it to look like a button<br> <emilio> q+<br> <jensimmons> q+<br> <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.<br> <astearns> ack emilio<br> <dael> florian: I don't have an issue, wanted thoughts.<br> <iank_> q+<br> <florian_irc> q+<br> <zcorpan_> q+<br> <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<br> <astearns> ack jensimmons<br> <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<br> <fantasai> jensimmons, see https://github.com/w3c/csswg-drafts/issues/5174#issuecomment-707015527<br> <astearns> ack iank_<br> <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<br> <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.<br> <plinss> q+<br> <astearns> ack florian_irc<br> <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<br> <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<br> <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.<br> <dael> emilio: I'm not sure that argument makes sense to me but I may be misreading<br> <dael> emilio: If you style a native button to look non-native, that you can do. not sure what capability we're lacking<br> <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<br> <astearns> ack zcorpan_<br> <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<br> <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.<br> <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.<br> <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<br> <dael> zcorpan_: Or allowing forms to submit to tel. not sure why that doesn't work<br> <bkardell_> q+<br> <astearns> ack fantasai<br> <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<br> <tantek> from my experience with web authors, this is not a use-case they want<br> <bkardell_> q-<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/5174#issuecomment-707015527<br> <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 ^<br> <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.<br> <emilio> q+<br> <jensimmons> q+<br> <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.<br> <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.<br> <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<br> <astearns> ack plinss<br> <fantasai> s/Button is the correct/appearance:button is the correct/<br> <astearns> ack emilio<br> <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<br> <bradk> How buttons and links work is not a CSS issue. How they look is.<br> <jensimmons> q-<br> <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<br> <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<br> <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<br> <tantek> the right approach is to work on making OpenUI work for this kind of use-case and related use-cases<br> <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.<br> <tantek> disagreed. the behavior of links and buttons is not "sorta close" at all, nor are their semantics.<br> <dael> astearns: At the end of queue, not hearing consensus<br> <bkardell_> tantek: I would like to hear the argument you're making there ^<br> <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.<br> <tantek> plinss's point is exactly why we abandoned the 'appearance' property approach<br> <dael> plinss: If all the behavior you want is a link, use a link.<br> <tantek> bkardell_: great, participate in OpenUI for those discussions<br> <dael> florian_irc: Links that behave like links should be links. Good to have it look like a button? People do it<br> <jensimmons> btw, I tweeted this question out: https://twitter.com/jensimmons/status/1329115564233662464<br> <tantek> to be blunt, this is the wrong call to solve this problem. this should get pushed to OpenUI<br> <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<br> <chrishtr> I agree about the OpenUI suggestion.<br> <chrishtr> s/about/with/<br> <tantek> and please stop trying to make appearance a thing (insert Mean Girls meme)<br> <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<br> <dael> zcorpan_: tantek suggested bring this to OpenUI group<br> <dael> astearns: I think that's fair<br> <dael> zcorpan_: And for HTML changes we should discuss with WHATWG<br> <dael> astearns: Right, if there are behaviors that should be shared can discuss there<br> <dael> astearns: Prop: Reclose with no additional change<br> <dael> astearns: Obj?<br> <tantek> +1 to close without change.<br> <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<br> <dael> astearns: I think it is a separate consideration that could have its own issue<br> <dael> florian_irc: Fair, narrower<br> <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<br> <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<br> <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<br> <dael> astearns: And if they do and find problems that's argument for changing spec<br> <dael> astearns: I'd like a narrower issue and to close the older one<br> <dael> astearns: Obj?<br> <dael> RESOLVED: Close this issue no change and open a more narrowly scoped issue<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5174#issuecomment-729846123 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 18 November 2020 17:47:05 UTC