The problem is that links provide a very reliable way to perform a controlled HTTP request to get a dynamic response from the backend.... without using JavaScript. I love JavaScript, but if device reusability is a serious concern then JavaScript is the elephant in the room, not this topic. Is it available? What version is supported? What quirks does the engine have? To be fair... it was posted in 2013 :D.
The only working alternative (editing if I stand corrected!) using buttons is to make them form buttons. Now otherwise intuitive behaviors (e.g. forward/back, refresh) are laden with "you're about to resend data!" warnings that completely break the flow.
To me, it makes perfect sense why this trend evolved. Most people agree with the underlying premise about user expectation on button vs link. Dressing links up as button is a direct response to that. I understand the technical arguments, but users care what it looks like and how it behaves, not how you implemented it.
Edits:
- Yes, you can use <form method="get"...> without scary browser warnings. It just gets a but ugly if you have lots of buttons, as each needs its own form wrapper.
- 303 redirects to POST request are a handy pattern to be aware of no matter what :)
> The only working alternative (editing if I stand corrected!) using buttons is to make them form buttons. Now otherwise intuitive behaviors (e.g. forward/back, refresh) are laden with "you're about to resend data!" warnings that completely break the flow.
You can make a form with method="GET" that doesn’t do this, works the same way a link would, and can send form data.
> The only working alternative (editing if I stand corrected!) using buttons is to make them form buttons. Now otherwise intuitive behaviors (e.g. forward/back, refresh) are laden with "you're about to resend data!" warnings that completely break the flow.
If anyone is looking for a solution to this, you can respond to a POST with a 303 (See Other) redirect. There's even a Wikipedia page for this pattern: https://en.wikipedia.org/wiki/Post/Redirect/Get
The author argues to NOT use fake anchor tags like <a href="#"> and then add functionality to it via JavaScript. Instead you should use <button type="button">.
Either way, JavaScript is required.
What you’re suggesting means your link is actually a link to another page, which works without JavaScript and that’s not the point of the article.
Never ceases to amaze me that I've been using HTML for more than 25 years, and every now and then I still learn a new nugget this and wonder how I could have not known!
You know a link starts with the exact same height and font that surrounds it, and then you can style it to predictably know exactly what you'll get.
A button shows up in a new font -- a font of unknown size at that, because it utterly ignores the font size of its container -- with extra height that introduces line-spacing issues -- and all of this by totally unpredictable amounts because it varies radically across both browser and platform. And if you want to undo all that styling, have fun delving into the quirks of each browser of how to do so.
If you're building something simple where appearance really doesn't matter, then sure throw in a button. But if you actually want to have predictable results, then the only straightforward way is with a link you style.
Huh, TIL. Looking it up on MDN, looks like that was implemented in WebKit in 2016. Even HTML5 didn't have that, while <button> has been around since the late 1990's.
Well, very happy to know that's no longer the case then, thanks! One more thing in CSS that's finally been addressed.
I really dislike this because it now makes the buttons not look like my platform’s buttons. I know this ship has sailed, but there are resets out there that allow you to fix most of the styling issues without making the buttons look like not-buttons.
Take a look at the HN voting buttons. Or, better yet, the expand/collapse button for each comment thread. They are implemented as links, not buttons. Presumably, this makes it easier to align with the text that they are within.
Everything is a button now that javascript applications have replaced HTML documents. And there are no such things as anchors or links anymore. They are not URLs but instead triggers for more javascript execution. We're, unfortunately, well past this minor problem and onto much more serious ones that eclipse it.
The FUD about SPAs and Javascript on HN is insane. Here's my personal site: https://chadnauseam.com/. It's a SPA. It loads fast. There are such things as anchors and link (inspect element if you like). They have URLs and you can ctrl-click to open in a new tab.
(The biggest proble with it is that I've been playing around with some js to animate a fade-in effect on page load, and it seems a little laggy and makes the site not work with javascript disabled. If I can't fix those issues I'll probably remove that in a few days.)
I'm not sure its FUD, your main page takes 63.5KB + 38.7KB for the gatsby reactified framework? + an extra 39.8KB in some js bundle and another 51.7KB in some other js bundle.
Also you end up thrashing 5MB of browser storage when I hovered a link check out Application -> Storage in Chrome.
Maybe I'm crazy but your page should not need that much, your site is making 20 requests to resources (thankfully you have http2) and the longest request took about 7s on a slow 3g connection. For comparison here is Tom MacWright's page https://macwright.com/ which does 2 requests at 14kB total taking 2.3s on a slow 3g connection.
I will give you the prefetch trick is superslick in the Gatsby framework for blogs but no reason to have a whole React framework around it. Just use https://instant.page/
I say all this and I do love the component nature of React and SPA's (I love Svelte the most at the moment) but it does really not feel like the right tool for 99% of personal blogs.
When I hover over most links on your page, I see the link URL in the bottom left corner of the browser window. But when I hover over the discord and twitter buttons, I don't. And when I command-click those buttons they don't open in a new tab.
So you used buttons (spans?) instead of links and broke the very functionality the article talked about.
>And when I command-click those buttons they don't open in a new tab.
One of my greatest annoyances. I’m an open in new tab guy. When I see this annoying pattern I end up clicking, middle clicking the back button (only possible on desktop), then switching the tab positions, so I can get the correct outcome.
To be fair, your browser probably has a history menu option in the top menu that opens a sidebar with your recent history. You can probably right click the top page and click “open in a new tab”. This is highly discoverable and does the same thing (just in more steps). You can also select the text in your URL bar, right click and copy, then open a new tab the usual way and paste the URL there. Also the same results but highly discoverable with extra steps.
As far as I know highly discoverable means there is no hidden functionality, not that every shortcut is advertised.
I’m a regular laptop user and I often use this trick. In Windows you can ctrl+click the back button to pop open a tab for the previous url, I’d guess command+clicking the back button does the same on a Mac.
The Discord/Twitter "buttons" on your site actually highlight one of the issues here. You can't open them in a new tab, or hover to see where they're taking you. They also don't make the mouse react properly to being on something clickable (though that could be fixed with a `cursor: pointer` style)
Which is actually a clear illustration of the point: that you have to go out of your way to make "link-like" things that aren't actual links. Clearly whatever framework or rendering library the site is using supports client-side navigation via real working anchor tags. But for some reason, they decided to not use those for the social media widgets.
Historically, only links got the pointer (hand) cursor, not all clickable things. Buttons and everything else kept the regular arrow cursor. Desktop software on all operating systems has always worked like this.
However, this convention has been muddied a lot on the Web in the past few years, but I still like to follow it.
This is a page that displays nothing but static text.
- It does 71 requests
- It loads 2 MB or resources for this static page
- Saves at least 6.7 MB of data in storage on load, no idea where that comes from (service workers maybe?). It jumps to ~16 MB on page refresh
- Running Lighthouse on your website gives 2.9s until first contentful paint. 3 seconds to display less than a kilobyte of text. And that's for the front page. It's significantly worse for longer pages.
- And on top of that it has buttons-for-links for discord and twitter (that are also, funnily enough, removed by ad blockers like AdGuard)
Oh yeah, I see how the "FUD about SPAs" is in reality fully justified criticism.
It's a blank page for me. It does not load at all.
I want my browser to display documents, not to run code. I don't want documents to be apps. The browser already has very sophisticated code to render documents well.
Unless I am really running an app - then this is somewhat fine to use the browser as a runtime. I'll make sure to only run open source apps with it, unless I really don't have a choice.
edit: wait, your page is so close to render perfectly without JS! You can fix this by avoiding opacity:0 in the HTML!
This is great example of what is wrong with many SPAs. They should not be applications in first place. Why is it using tons of JS to display few paragraphs of static text? It could be hosted as static html pages. It also kind-of works in lynx, but totally don't in FF without JS.
I'm not sure you are aware that everybody that activates JS just to see this type of content (which can be done in a static html only manner) will be heavily disappointed when they've loaded your page.
It's like waiting to load a WebGL demo of a damn teapot. Afterwards you have a negative impression, such as me now thinking of chadnauseam, that I now think has no effing clue about webdev if this person can't create two damn paragraphs without a JS framework.
If you throw a heavy JS framework on a website, make sure the content is at least as heavy. If the content is two paragraphs of text, why would you disappoint users so much when they visit from mobile?
Gatsby actually works extremely well for no-JS users. It is a static site generator, after all, that serves you raw HTML with a secondary JS payload. It's just that the author broke his website by setting the opacity to 0 on load so he could do a fade-in effect with JavaScript, even though there are much easier ways to do that in CSS. All the text is still there, just invisible.
Hm, wait a minute. I'm not a webdev by any stretch, so I could be talking out of my ass here. But, couldn't you "fix" the issue by leaving the opacity alone in the HTML, and setting it to 0 in the beginning of the JavaScript?
Your site is broken on some browsers that do not support darkmode. On Firefox 78.9 ESR the text is #EBEBEB on #FFFFFF, so it's illegible. Firefox 78 ESR is supported till September this year.
So you do care since only links follow your browsers’ behavior. Nothing else can be right-clicked to show “Copy link address” in the dropdown for example.
The golden rule is that if a button opens a link to a page that has its own URL, it should be a plain anchor tag.
You can apply whatever JavaScript on top of it to “ajaxify” it, as long as you ignore altered clicks (ctrl, cmd, shift, etc)
I have one of those fancy gamer mice (Logitech G700S) and I bound the most prominent thumb button to middle-click. Haven't looked backed, making scroll-wheels clickable was a mistake.
Scroll wheels themselves are a bad implementation of a good idea. I bought a cheap USB volume control knob and used AutoHotKey to rebind volume up/down events into wheel scrolls. Productivity increased like crazy! Scrolling is no longer a chore, it's a pleasure. I even went the extra mile and coated it with rubber for a good grip.
I have always used Gesturefy to make right-click and drag down to open in a new tab. I don't know where I originally picked up this gesture...maybe Opera in 2003? But I've always loved it and use it a hundred times a day.
It's tricky to balance user expectations with semantic HTML now that the web has evolved so far.
The easiest example I have from my industry is a product card in a grid of products. There really is no correct spot to link it in some designs, but the user expects to click any part of the box and be taken to the product page. So you wrap the whole box in an anchor tag, which has its own host of problems.
As you said though, that is a bygone problem, this ship has sailed in the land of SPAs. Even a simple blog is an SPAs these days.
In my experience, the effective expectations of users are remarkably low. If you were to survey users, you'd get the impression that users are very particular. In reality, users tolerate all sorts of things that most of us on HN would consider primitive or nearly broken. If most web applications actually relied mostly on constructs provided by the browser/DOM rather than JavaScript, the average user wouldn't notice or care.
But there are product owners who power trip on the possibility that they too could be just like The Google, so they want everything to be unnecessarily animated and dynamic. On top of that, many of them want Silicon Valley programming at San Fernando Valley prices, so not only do they request that their web applications be unnecessarily complicated, but the junior devs they hire are given no direction and the code gets bloated, wrecking performance (which matters more than "delightful" UIs).
I am entirely inclined to agree with you. It is definitely perpetuated by project stakeholders, even developers wanting to try new tech.
But now that we have spent years training eCommerce user behaviours you do find that people will be busy clicking everything but the product title, arguably the most semantic place to put the anchor, so it may take a user a few goes to get where they're going. The user might not care but many of the project stakeholders do.
While I am an evangelist of a utilitarian, semantic web, I feel it's an idealism that hasn't survived it's encounter with the real world in commercial software. We went from being worried about javascript image sliders being too heavy, to making the client compute and render the entire application, in about 8 years. I think the trajectory is clear, and I doubt we'll have a watershed moment where the whole tree of stakeholders suddenly wants less.
If this particular thing of clicking everything but the title is really a thing, nothing is blocking you to add some minimal JavaScript which « onclick » on the item div element, triggers a click on the link. Add some « cursor: pointer » in you Stylesheet and you are done.
It’s literally 2 loc, it doesn’t affect accessibility and it’s using JavaScript for what it was meant : adding some optional convenience.
I realize I’ve not done real server rendered sites for years, but adding good old « optional convenience » JS without jQuery and broken browsers, but with ES6, modules, and maybe WebComponents would probably be a really pleasant experience.
Yes you are right, that's a good approach. Another commenter linked a great article on accessibility and "card" style content which also recommended that approach, worth a read as it discusses a lot of the caveats and your approach tackles the majority of the issues you can encounter.
You can't have interactive elements inside anchor tags. Very often the box will have some additional buttons for different actions, like "Save for later". I like the approach of using an anchor tag just for the title and have another click handler on the box to serve as a fallback, but you don't get to ctrl-click on the box anymore. Alternatively you can have the link be a sibling of the buttons in the DOM, but visually cover the whole box and appear behind the buttons. As you can imagine, any solution like this is going to add more work and be a potential source for bugs.
This is one of the two things that I really wish browsers would fix, instead of cramming in completely new features. The second is how hard is it to make popovers work correctly, especially inside scrollable containers.
Cant you just use event.stopPropagation on the inner button’s event handler to stop the browser from following the link? Of course this requires JS but I assume you’re using Js if you have custom buttons.
You can, but you can also see how it isn't an elegant solution. What if the user has javascript disabled? Do you also have to capture the click for the space around the interactive spots so a misclick into whitespace doesn't click the link?
The post I was replying to was specifically lamenting the inability to have interactive elements inside of anchor tags, which I think is solved by event.stopPropagation. If you have a button in an anchor tag and it's not a submit button, you need JS for the button to work anyways.
Sites breaking "ctrl+click" or open in a new tab shortcuts are the worst. Even JIRA does it on text ticket links, and it's a power user focused tool. Very frustrating.
Yeah, the voting and collapse buttons should really be actual buttons, not links. It's fairly trivial to make buttons look like links if that's the desired effect.
I think the converse—buttons are not links—doesn't get enough attention. The litmus test is that if clicking it is supposed to navigate, you should also be able to shift+click or middle-click to open it in a new tab, or drag it up to your toolbar to make a bookmark.
I don't know what it is that people do that breaks being able to open a link in a new tab, but there's little I hate more than that. Especially on an ecommerce site where I'm likely to open several products in a separate tab.
Some break middle clicking but I can still right click and select "open in new tab" from the menu. But there's others that don't even allow that. It's awful.
I was recently required to add some JS to our product links from the search results pages. It’s a click-jacking script that sends tracking data to Google Analytics. There is a callback that fires when GA is happy that it got the goods. When that signal arrives, we then forward the user to where they wanted to go.
The entire thing makes me feel dirty. The data collected is never even looked at. And yes, it breaks middle-click and right-click behaviour.
<button> is not commonly mis-used as a link. I do agree that <div onclick="goTo('/contacts')"> and its equivalents are too damn common and just show complete lack of knowledge of the platform. <a> is the core element of the World Wide Web, without which there wouldn’t be a web.
I think wrapping a div with an <a> element is now valid, you probably want to only wrap inline elements like a <span> with an <a> when possible. Imo it's a better practice.
It also avoids having large "white space" areas that are clickable, when only the text should be clickable. (Like when you wrap an <h1> with an <a> for example.)
To add on, clickable whitespace is more of a feature than a bug generally now, because at least in mobile-web world the worst possible thing you could do is make your touch target extremely small by making it only the icon rather than a standard touch target size centered on said icon.
Well shit ... okay ... if they made it easier to code web pages maybe we'd have a more consistent experience. It seems if you do the intuitive thing you always break it for one user or the other, and it's designed such that you have to do a non-intuitive thing to serve everyone.
Intuitiveness is in the eye of the beholder. I'd argue that if you're experienced with accessibility, doing things the "accessible way" becomes more intuitive.
You have to follow the specifications. None of this is remotely intuitive if you haven't read and studied the specs. If your intuition is wrong that's probably because you've been doing "whatever seems to work" rather than reading the specs and following them.
Well... all the way back to HTML 1.0, form submission buttons also "went somewhere". It was quite a while before the concept of any interaction not reloading the entire page came along. There's nothing wrong with buttons that go somewhere, and a lot of the web is designed around this.
No, form submit buttons did something i.e. submitted the form. While this had the effect of going somewhere the expectation was straight forward and obvious. Using forms as links was roundly advised against.
There are many applications where "doing something" technically means going into another URL, and interacting with it. Those should be links anyway (the technical meaning beats the UX one), but I see no problem on styling them as a button.
I mean, they don't _realize_ they're doing this. But they will have an element on the page where a user clicks on it to do some action (not navigate to another page), and they will style it to match the site's links. It unfortunately seems to be a very popular pattern.
I think 90% of the misuse arises from devs not realizing that they can use a <button> or <a> (or whatever else is correct in that context) and still style it however they want.
The other 10% is from people giving up unstyling buttons. If I remember correctly they need more than 10 lines of CSS to undo all kinds of weird specific CSS that <button> has. Maybe nowadays it can be done with `all: initial`
I just think that a form button is something that looks a specific way for a reason, and that styling shouldn't break fundamental expectations. But that's obviously a subjective opinion, people can style their pages however they like, I just don't personally like design that lies to me.
Big pet peeve: Web apps where some buttons look like buttons and some buttons look like links. Everything that initiates an action of some sort should look the same, damnit.
Kinda, but there’s no way a “Contact us” call-to-action in the middle of a hero is going to look acceptable as a plain underlined blue text. Some links need to be boxed and that makes them look like buttons. Not a lot of wiggle room there.
I see your point, and used to share it. But recently I’ve worked with professional designers that use this pattern quite a lot and my mind is now changed. For example I see nothing wrong with a link to e.g. a creation form looks like a button, nor is nothing wrong with a destructive action to have the lower visual weight of a link (e.g. delete this repo; flag this comment; etc.).
Historically, styling buttons wasn't supported. The result of styling an input element of type submit and a button element were different too. It eroded adherence to proper semantics. I think people are still used to the workaround which is use an anchor element.
His main points are about accessibility but there's a lot of overlap between accessibility and SEO. Google needs semantic tags to understand your site. It will treat any <a> as navigation and won't do the same for <button> or any other approach. The basic premise that <button> is for CTAs and <a> is for navigation is the golden rule. You can style either anyway that you want.
Fixing your own website is fine, I’m just saying that unless a standard to fix this in a systematic way comes along, 99% of the web is still going to be unusable. For example a reasonable solution would be <button href=‘...’>
Sure, <divs> and <spans> are not buttons and should not ever be used as those. Knowing and adhering to standards, especially when they are there for accessibility, is an excellent thing.
But in some cases, making links links instead of buttons (and similar scenarios) just means exposing internal works to the user. Say I have a SaaS with the classic "GET STARTED NOW" button on the landing page. Now I change my tech stack from something classic like Rails or Lavarel, where "get started" probably means a link to the signup page to some fancy JavaScript which triggers the action of overlaying a signup form. Would you really agree that the HTML for my "GET STARTED NOW" button should change depending on what kind of method my app uses?
> Would you really agree that the HTML for my "GET STARTED NOW" button should change depending on what kind of method my app uses?
Indeed not! “Get started now” should always be a link. If you want to give it fancy behaviour, you can attach an event listener to it that cancels the default one (mind the modifier keys).
The only working alternative (editing if I stand corrected!) using buttons is to make them form buttons. Now otherwise intuitive behaviors (e.g. forward/back, refresh) are laden with "you're about to resend data!" warnings that completely break the flow.
To me, it makes perfect sense why this trend evolved. Most people agree with the underlying premise about user expectation on button vs link. Dressing links up as button is a direct response to that. I understand the technical arguments, but users care what it looks like and how it behaves, not how you implemented it.
Edits:
- Yes, you can use <form method="get"...> without scary browser warnings. It just gets a but ugly if you have lots of buttons, as each needs its own form wrapper.
- 303 redirects to POST request are a handy pattern to be aware of no matter what :)