The Button Cheat Sheet(buttoncheatsheet.com)
buttoncheatsheet.com
The Button Cheat Sheet
https://www.buttoncheatsheet.com/
69 comments
> Am I the only one who thinks CSS + JS on top of HTML broke the conceptual model beyond hope?
no. developers everywhere (but nowhere near "all developers") are forgetting the fundamental advantages of hypertext and are often commanding high salaries despite their staggering ignorance about how to build user interfaces.
we should be trending toward mostly perfect UI paradigms in certain use cases, yet every few months, for no reason at all, user interface designers make huge changes and wreck everything. only rarely do user interfaces get better with such changes.
where is the UI which made large, sensible changes early in its life, favoring smaller and smaller changes as the perfect interface for a particular set of data and actions makes itself obvious? I can't remember the last time I saw one. some games, probably.
I maintain that games probably produce the most usable UIs today, in many ways. they are usually very well thought out, each page usually has a single purpose, and each screen provides all information needed to make a decision or change on a single page, whenever possible. and game UIs are FAST.
I'd love to see a motivated game designer have a go at Service Now or any other contemporary enterprise software, really.
it's very much like web designers are learning less as the study of electronic user interfaces matures. if you judge this by web or mobile user interfaces, you have likely lost all hope that a single semi-sensible design will ever emerge.
designers are very good at making things look good, don't misinterpret me. usability does not seem to be getting better, though.
I welcome counter-examples.
no. developers everywhere (but nowhere near "all developers") are forgetting the fundamental advantages of hypertext and are often commanding high salaries despite their staggering ignorance about how to build user interfaces.
we should be trending toward mostly perfect UI paradigms in certain use cases, yet every few months, for no reason at all, user interface designers make huge changes and wreck everything. only rarely do user interfaces get better with such changes.
where is the UI which made large, sensible changes early in its life, favoring smaller and smaller changes as the perfect interface for a particular set of data and actions makes itself obvious? I can't remember the last time I saw one. some games, probably.
I maintain that games probably produce the most usable UIs today, in many ways. they are usually very well thought out, each page usually has a single purpose, and each screen provides all information needed to make a decision or change on a single page, whenever possible. and game UIs are FAST.
I'd love to see a motivated game designer have a go at Service Now or any other contemporary enterprise software, really.
it's very much like web designers are learning less as the study of electronic user interfaces matures. if you judge this by web or mobile user interfaces, you have likely lost all hope that a single semi-sensible design will ever emerge.
designers are very good at making things look good, don't misinterpret me. usability does not seem to be getting better, though.
I welcome counter-examples.
am learning UI design at the moment would be curious to hear recs on what you think I should be learning to not make bad UIs
virtually every piece of enterprise software is an absolute mess.
it is often the columns of a database row exposed as html with a tiny bit of client-side validation in JavaScript.
a good UI has pages, panels, windows --whatever-- which have a single purpose and show only what is necessary for a user to do the thing that page/panel/whatever is meant for. show everything that is needed, and nothing more.
it's a very high bar to reach, and very difficult to get right. just avoid making awful mistakes and you'll do fine, I'm sure.
it is often the columns of a database row exposed as html with a tiny bit of client-side validation in JavaScript.
a good UI has pages, panels, windows --whatever-- which have a single purpose and show only what is necessary for a user to do the thing that page/panel/whatever is meant for. show everything that is needed, and nothing more.
it's a very high bar to reach, and very difficult to get right. just avoid making awful mistakes and you'll do fine, I'm sure.
I’m making a website right now that only uses HTML, no CSS/styles and no JavaScript and it is a breath of fresh air :)
The only problem with this is that, for historical reasons (and lack of caring?), the default stylesheets for unstyled HTML in the leading browsers are terrible. Best to apply a simple classless style sheet once then forget about it.
There's not that much that is objectively bad about the default styles. About the only thing that I can really put my finger on is equal top/bottom margins on headings. Possibly default line height, too. I wonder if one of the browsers will (or already has?) ever change that.
You can fake things in most UI systems, nothing new here.
Well, that's true, but HTML wasn't invented to create general UIs in the first place, so it's even worse.
I don't think that's really true; in the original WWW proposal[1], Tim Berners-Lee specifically talks about using the web to build applications and he considered hypermedia applications to be only a matter of time and resources (about which he was correct).
[1]: https://www.w3.org/History/1989/proposal.html
[1]: https://www.w3.org/History/1989/proposal.html
> Tim Berners-Lee specifically talks about using the web to build applications
And those applicatons are, and I quote:
=== start quote ===
Specific Applications
The following are three examples of specific places in which the proposed system would be immediately useful. There are many others.
Development Project Documentation.
The Remote procedure Call project has a skeleton description using Enquire. Although limited, it is very useful for recording who did what, where they are, what documents exist, etc. Also, one can keep track of users, and can easily append any extra little bits of information which come to hand and have nowhere else to be put. Cross-links to other projects, and to databases which contain information on people and documents would be very useful, and save duplication of information.
Document retrieval.
The CERNDOC system provides the mechanics of storing and printing documents. A linked system would allow one to browse through concepts, documents, systems and authors, also allowing references between documents to be stored. (Once a document had been found, the existing machinery could be invoked to print it or display it).
The "Personal Skills Inventory".
Personal skills and experience are just the sort of thing which need hypertext flexibility. People can be linked to projects they have worked on, which in turn can be linked to particular machines, programming languages, etc.
=== end quote ===
The web, even in Tim Berners-Lee's vision, is strictly about documents.
In comparison, by 1989 France's Minitel had over three million installed terminals with over 6000 different services [1]. Many of them (mail-order, games, ticket purchases etc.) cannot be expressed in a document-centric system. But even then (and I'm pretty sure Tim-Berners Lee had been aware of Minitel), the web was presented as a system for viewing and sharing documents, and the job of applications was left to applications.
[1] https://en.wikipedia.org/wiki/Minitel
And those applicatons are, and I quote:
=== start quote ===
Specific Applications
The following are three examples of specific places in which the proposed system would be immediately useful. There are many others.
Development Project Documentation.
The Remote procedure Call project has a skeleton description using Enquire. Although limited, it is very useful for recording who did what, where they are, what documents exist, etc. Also, one can keep track of users, and can easily append any extra little bits of information which come to hand and have nowhere else to be put. Cross-links to other projects, and to databases which contain information on people and documents would be very useful, and save duplication of information.
Document retrieval.
The CERNDOC system provides the mechanics of storing and printing documents. A linked system would allow one to browse through concepts, documents, systems and authors, also allowing references between documents to be stored. (Once a document had been found, the existing machinery could be invoked to print it or display it).
The "Personal Skills Inventory".
Personal skills and experience are just the sort of thing which need hypertext flexibility. People can be linked to projects they have worked on, which in turn can be linked to particular machines, programming languages, etc.
=== end quote ===
The web, even in Tim Berners-Lee's vision, is strictly about documents.
In comparison, by 1989 France's Minitel had over three million installed terminals with over 6000 different services [1]. Many of them (mail-order, games, ticket purchases etc.) cannot be expressed in a document-centric system. But even then (and I'm pretty sure Tim-Berners Lee had been aware of Minitel), the web was presented as a system for viewing and sharing documents, and the job of applications was left to applications.
[1] https://en.wikipedia.org/wiki/Minitel
It depends on your level of reductionism; if you believe in Unix-style "everything is a file" then "everything is a document, including the applications that edit other documents" isn't a massive conceptual leap.
Time Berners-Lee:
literally describes web applications as handling documents and only documents. Bases HTML on SGML, which is literally a language to describe documents, and only documents. Calls the system, a ypertext system. Lists exclusively text systems as systems one might connect to.
In the conclusion writes (emphasis mine): "We should work toward a universal linked information system, in which generality and portability are more important than fancy graphics techniques and complex extra facilities. The aim would be to allow a place to be found for any information or reference which one felt was important, and a way of finding it afterwards."
HN in 2021:
no-no-no, that's reductionism, what he really meant was full-featured applications, it's not "a massive conceptual leap"
====
Edit.
Time Berners-Lee in an interview [1]:
"It was designed in order to make it possible to get at documentation and in order to be able to get people — students working with me, contributing to the project, for example — to be able to come in and link in their ideas, so that we wouldn’t lose it all if we didn’t debrief them before they left. Really, it was designed to be a collaborative workspace for people to design on a system together. "
[1] https://achievement.org/achiever/sir-timothy-berners-lee/#in...
literally describes web applications as handling documents and only documents. Bases HTML on SGML, which is literally a language to describe documents, and only documents. Calls the system, a ypertext system. Lists exclusively text systems as systems one might connect to.
In the conclusion writes (emphasis mine): "We should work toward a universal linked information system, in which generality and portability are more important than fancy graphics techniques and complex extra facilities. The aim would be to allow a place to be found for any information or reference which one felt was important, and a way of finding it afterwards."
HN in 2021:
no-no-no, that's reductionism, what he really meant was full-featured applications, it's not "a massive conceptual leap"
====
Edit.
Time Berners-Lee in an interview [1]:
"It was designed in order to make it possible to get at documentation and in order to be able to get people — students working with me, contributing to the project, for example — to be able to come in and link in their ideas, so that we wouldn’t lose it all if we didn’t debrief them before they left. Really, it was designed to be a collaborative workspace for people to design on a system together. "
[1] https://achievement.org/achiever/sir-timothy-berners-lee/#in...
Here:
> would be immediately useful. There are many others.
Aren't we at the "many others" point of Sir Tim's theory?
You're using his three specific examples as if he was talking about the limit of the thing. I think he was talking about the start of something big.
> would be immediately useful. There are many others.
Aren't we at the "many others" point of Sir Tim's theory?
You're using his three specific examples as if he was talking about the limit of the thing. I think he was talking about the start of something big.
You sound like a stereotypical school teacher discussing literature. "What did the author mean, when he wrote the doo was red? Let's look at the evidence: https://news.ycombinator.com/item?id=27282030 Ah, yes, definitely fully-featured applications"
Let’s be real though, semantic html5 mostly describes an article on a blog site than a robust web application.
Paragraph tags are first class versus a Modal in HTML.
Paragraph tags are first class versus a Modal in HTML.
This is just playing a game with semantics; the form, canvas, dialog, and keygen elements are also first class. Nobody is saying that the web isn't primarily documents.
HTML was about markup so that styling could be left to the user-agent. So, adding CSS and JS breaks that model. It's the web we've got now.
I wonder how much "HTML non-compliance" is lack of education and how much dark patterns. Remember the time clean URLs were a thing? Don't tell me Facebook engineers haven't heard about it.
https://m.facebook.com/events/2805322196445083/?event_time_i...
Like seriously. It's almost like someone learned HTML/HTTP best practices, then did the exact opposite.
https://m.facebook.com/events/2805322196445083/?event_time_i...
Like seriously. It's almost like someone learned HTML/HTTP best practices, then did the exact opposite.
Somewhat off topic: I thought perhaps you meant cool URIs but it turns out that's a different term.
Cool URIs are about permanence. Reworking your internal file-structure should not break existing URIs. [0]
Clean URLs are about avoiding leaking implementation details into the URL, e.g. .php, and also avoiding excessive use of query strings. [1]
[0] https://www.w3.org/Provider/Style/URI
[1] https://en.wikipedia.org/wiki/Clean_URL#Structure
Cool URIs are about permanence. Reworking your internal file-structure should not break existing URIs. [0]
Clean URLs are about avoiding leaking implementation details into the URL, e.g. .php, and also avoiding excessive use of query strings. [1]
[0] https://www.w3.org/Provider/Style/URI
[1] https://en.wikipedia.org/wiki/Clean_URL#Structure
There are the bullets, and the gun.
Make up your own mind where you point it when it is loaded.
If you choose your own foot, that is your choice!
Make up your own mind where you point it when it is loaded.
If you choose your own foot, that is your choice!
For html buttons and other newer input elements specifically the css styling is really hard to get consistent/looking/working across devices and browsers or just flat out doesn't work.
Maybe developers should lean into just leaving the native styles, but it can look bad and present its own problems in tightly styled mobile sites or apps.
I might propose a better solution is expanding accessibly, aria, etc so we can make modern sites & elements more accessible.
The concept of what a website is has changed a LOT.
I don't think we can (and personally don't want to) stop the train towards expanding custom elements, components, intense dom stuff.
So instead we should prioritize making it more accessible.
Maybe developers should lean into just leaving the native styles, but it can look bad and present its own problems in tightly styled mobile sites or apps.
I might propose a better solution is expanding accessibly, aria, etc so we can make modern sites & elements more accessible.
The concept of what a website is has changed a LOT.
I don't think we can (and personally don't want to) stop the train towards expanding custom elements, components, intense dom stuff.
So instead we should prioritize making it more accessible.
It broke the conceptual model for programming, but allowed the web to take off in a way that it wouldn't have otherwise. We're dealing with the legacy of that decision. As someone who doesn't have to work on browser rendering engines, but did get into web development because of the super low barrier to entry in the 90s, I think it was the right call!
I've heard this rule of thumb:
If it is supposed to be a meaningful link - be it internal or external - use a direct anchor element with an href. Styling it however you like shouldn't hurt.
Otherwise, for any other interactions use a <button> element
If it is supposed to be a meaningful link - be it internal or external - use a direct anchor element with an href. Styling it however you like shouldn't hurt.
Otherwise, for any other interactions use a <button> element
Me too! And I been following this for as long as I remember. iirc, Digital A11Y too recommends that.
What about <embed src="button.swf">? Should I use that?
Try
<applet code="button.class" height="60" width="240">
<param name="button" value="Yea or nay?">
<b>Sorry, you need Java to press this button.</b>
</applet>
Mine had the lake applet. It was gorgeous.
> Shows wrong cursor on hover
This seems a bit unfair to single out given that they gave equal styles to all the buttons. Why didn't they include `cursor: default` so they all look exactly the same but function slightly differently?
This seems a bit unfair to single out given that they gave equal styles to all the buttons. Why didn't they include `cursor: default` so they all look exactly the same but function slightly differently?
They don't apply any cursor styles to any of these 'buttons', as far as I can see. Their stylesheet (https://www.buttoncheatsheet.com/assets/style.css) only has one instance of "cursor", which is unrelated.
Kinda funny to me we need a website to explain you should use <button> for a button
My rule of thumb has always been a button does something, a link takes you somewhere.
To me, a good website should be usable without any added style or scripting. CSS should make it look good, but you should be using the markup to make is usable and roughly laid out how you want, at least with a sensible default.
Do you have an example of such a website? I'm genuinely curious if such a thing exists. I've been doing some CSS+HTML tutorials lately, and the ones I've been reading, I don't see how you would without style attributes in all of your tags, which is essentially just using CSS.
This very site is usable for reading and writing without CSS or JavaScript. Oddly, you can vote without JavaScript but not without CSS (buttons aren't visible in layout), which could easily be corrected.
Its appearance doesn't change as much as it might because it uses nested tables for layout (a Nineties-era practice) and deprecated properties like bgcolor but even without those choices it could still be usable.
Its appearance doesn't change as much as it might because it uses nested tables for layout (a Nineties-era practice) and deprecated properties like bgcolor but even without those choices it could still be usable.
'Early' websites [0] were very linear, text-heavy affairs. They still had images, of course, just a pretty basic 'full width, top to bottom' layout. Authors quickly realised you could abuse tables for layout, but rudimentary alternatives used frames. They just relied on default styles. Next time you're working on a site, just drop the stylesheet. That. That's what sites looked like.
[0] I'm talking mid-late nineties here. I don't know, off the top of my head, what level of CSS support or style-in-html support there was, I'm just talking about very hazy memories of what they looked like.
[0] I'm talking mid-late nineties here. I don't know, off the top of my head, what level of CSS support or style-in-html support there was, I'm just talking about very hazy memories of what they looked like.
My personal website, which is admittedly quite simple, is (IMHO) totally readable and usable without CSS enabled.
As I was building it, I'd constantly check it with CSS off in order to make sure it had a reasonable flow for folks using screen readers.
www.ft.io if you're interested.
As I was building it, I'd constantly check it with CSS off in order to make sure it had a reasonable flow for folks using screen readers.
www.ft.io if you're interested.
Have any examples? Just using tables to lay stuff out?
No, definitely not. Tables are for data, not for laying stuff out.
For a fun surprise, view the HTML source of this page!
HTML embedded into email templates often uses tables for layout.
If you get a commercial email and the content has graphic borders around the content, check the source and you'll probably see a table. Also emails with text content in columns.
If you get a commercial email and the content has graphic borders around the content, check the source and you'll probably see a table. Also emails with text content in columns.
Not included is this unbelievable button from an example in TikTok’s web api:
https://developers.tiktok.com/doc/login-kit-web
I wonder if that's because the TikTok crapfest shouldn't even be a button, it should be a link.
Yes, I'll start to work on linkcheatsheet.com soon. :)
Whats missing is which ones work without JavaScript. And accessibility characteristics.
yeah, "A focusable div with a button role" should be pretty accessible compared to a div with onclick event and neither of those things, for example.
It is not sufficiently accessible because it still won't activate on Space Bar or Enter/Return keydown events. "Accessible" does not only mean "screen reader users can use it."
my point is that it's better then a div without those attributes.
Switching markup completely is a larger effort than adding tabindex and role and the latter still provides a benefit.
Switching markup completely is a larger effort than adding tabindex and role and the latter still provides a benefit.
True, only <button> (if type is not "button") and <input type="button"> function within a <form> context as a button.
<input type="image"> does as well.
without javascript the only meaningful thing that can be done in HTML are to navigate to a new document with HTTP GET (A[href=]) or submit data via HTTP POST or similar verbs ((BUTTON, INPUT[TYPE=BUTTON]. INPUT[TYPE=IMAGE]) where the url is in the FORM tag or the form* attributes. This is because without javascript there are no persistent stores on the client side and you have to interact with HTTP to create a stateful application.
Honestly, most people do not care whether you're doing client side or server side. Regular people don't even notice a difference.
I'd say whether a button does something without JavaScript is a separate topic.
The page repeatedly mentions accessibility characteristics, it just doesn't call them all out as such.
> Not keyboard focusable
> Correct button role
> correct key events by default
> No accessible name
"Shows wrong cursor on hover" is arguably also about an accessibility characteristic.
The page repeatedly mentions accessibility characteristics, it just doesn't call them all out as such.
> Not keyboard focusable
> Correct button role
> correct key events by default
> No accessible name
"Shows wrong cursor on hover" is arguably also about an accessibility characteristic.
One type of button is missing from the list. Input with type="image" and src="img.gif"
It's a button with all the properties of an image. Haven't used it in many years but it's still around.
It's a button with all the properties of an image. Haven't used it in many years but it's still around.
Interesting site, I'm not a big fan of emoji/slang/playful tone which makes me feel like I'm being taken for an idiot but that's my own problem
Thanks for making this and illustrating all the cases and variations of a problem, consider making a whole site about these accessibility problems
Thanks for making this and illustrating all the cases and variations of a problem, consider making a whole site about these accessibility problems
My rule is "anchor tag for everything unless it's a form submission", in which case, button.
Even better: "anchor tag for everything that takes a user to a url, button for everything else" (forms and other action/event initiators).
I don't think this rule. Anchor tags should be used to go somewhere. Buttons should be used to do something. There are cases where these overlap (am I popping up a settings menu (doing something) or navigating to the settings (going somewhere)) but in many cases it is distinct.
Furthermore anchors have awesome features such as being able to copy the destination or open the link in a new tab. If the target isn't actually a real location using anchors can be confusing.
Furthermore anchors have awesome features such as being able to copy the destination or open the link in a new tab. If the target isn't actually a real location using anchors can be confusing.
Weird-- The first <button> example shown does not show the right cursor when hovering for me.
The normal arrow (not the hand) is supposed to be the correct cursor for buttons, but many people change it to the hand because they think it indicates interactivity.
However, the div button is still wrong because it shows the text selection cursor in the button.
However, the div button is still wrong because it shows the text selection cursor in the button.
Check out https://knopf.dev for a fantastic CSS button library.
In any sufficiently complex UI, you really do end up needing a wide variety of button treatments, depending on the context, hierarchy, etc
In any sufficiently complex UI, you really do end up needing a wide variety of button treatments, depending on the context, hierarchy, etc
It seems odd there is no mention of labels. I am never sure about how accessible they are or if they can stand in for their target.
[deleted]
The fact you can make any element look and behave the almost the same way – ignoring compatibility and usability issues – is a minefield. We could create a guide like this for basically everything and demonstrate 99% of the web isn't compliant.