Yet another article on button vs. link

Published:
Categories: HTML

When trying to explain the difference between link and button, <a> and <button>, and when to use each of them, i mostly start with the link. I've seen other people do so and i adopted it. I suppose it's because the link is the very fundament of the world wide web.

Basic definition

Usually, the explainer boils down to: If it leads to another page, it's a link. If it changes something on the current page, it's a button.

However, life's complicated and so are definitions.

Moments of confusion

Back to top or scroll to top links, table of content

In it's wider sense, this is about anchor links being on the same page. Tables of content usually don't evoke confusion. It's a list of links, a navigation.

The back to top links, however, i've seen a couple of times now implemented as a button. Why could that be so?

Assumption 1: It's mostly an icon-only component. Those tend to be called "buttons". So the everyday communication amongst devs and clients kicks in when choosing the HTML element.

Assumption 2: It's not linking to another page. It also doesn't change anything on the current page. Somewhere in here, this seems to be enough for some people to not count it as a link anymore. (And no judgement here! Sure, this whole article is about helping to use the appropriate semantic where "appropriate" has an underlying normative sense. But i'm a descriptive linguist, i observe and try to understand.)

The handling thesis

What happens with an anchor link is: The user's focus is moved to another part of the current page. In this case, the browser moves the focus. From a user's perspective, is that any different than a modal popping up and the focus is moved to the close button? Yes and no. No, in the sense that the focus is moved to another part of the page. Yes, in the sense of who/what handles the focus move, the browser's internal functionings or an author's JavaScript? Alas, this differentiation between browser and author handling doesn't lead very far, certainly not since the advent of the command/commandfor attributes.

Developer frameworks that add to the confusion

Lately i've dabbled again in a rails app. It uses the hotwire-turbo-thingy (basically ajax in the rails world, in my understanding). What happens is: you have an HTML snippet on your server, reachable via a URI.

This somewhat abstracted "link to modal" can be found anywhere, see (exhibit 1)[https://rubydev.org/turbo-frames-modal-example-ruby-on-rails/], (exhibit 2)[https://jetrockets.com/blog/async-modal-on-rails-with-native-dialog-element], (exhibit 3)[https://medium.com/@outlawandy/turbo-frame-modals-869801e37591], (exhibit 4)[https://github.com/michaelwapp/bootstrap_modal_turbo_frame], (exhibit 5)[https://mattbrictson.com/blog/turbo-modal], , etc.

<%= link_to "Link label", href_path, data: { turbo_frame: :modal } %>

link_to with href Can this be done with a

link vs action, see here https://codecurious.dev/articles/rails-link_to-vs-button_to-when-should-you-use-each

Sometimes beginners think: "A link and a button look different, but they do the same thing, they click."

nice list in the "Mini Recap — Your Cheat Sheet" section, however it doesn't account for the modal/popover use cases

Notes

initial thought:

Wann ist es ein Link `<a>` und wann ein Button `<button>`? 
Es ist nicht immer ganz trennscharf. Aber: Wenn man zu einer Seite oder einem Seitenabschnitt verlinkt, dann `<a>` (Links im Menü, scroll-to-top). 
Wenn nach dem Klick etwas auf Neues auf derselben Seite erscheint, dann `<button>`. 

Focus management ist in diesem Falle nicht dasselbe wie Verlinken, 
aber hier beginnt die Unschärfe, denn der Browser handlet im Kern auch den Fokus der User. 

Vllt so? Wenn der Browser Fokus handlet, dann link, wenn JS den Fokus handlet, dann button.

why confusion?

  • developers between their developemnt environment, framework, etc. and testing their work: switch between developer hat and user hat.
  • the typical. whenever i read docs in the php world, so many tutorials are about forms. and yes, forms are an integral part of web development. nonetheless, on php related sites i sometimes have the impression every site is about forms. i guess, this is due to forms being the basic communication tool between a client-facing page and a server. let me just say, as a frontend developer, forms are but one of many components of a web site. amd what do forms use? buttons. initially
  • components have several names. think banner/hero/stage.