This morning I tweeted a blog post about Back to Basics: Non-Navigating Links for JavaScript Handling and rightfully incurred the wrath of the Gunnar pointing out the flaws of the article.

In essence, the article asks which of the five following examples is the correct one to create a link that invokes some JavaScript functionality:

<a href="">
 
<a href="#">
 
<a href="#" onclick="return false;" />
 
<a href="javascript:void(0)">
 
<a href="javascript:{}">
 
<a href="#0">

The correct answer is none. This is not what anchors < a > are for. An anchor element should have a href attribute that points to a valid URL resource. In other words:

You use an anchor if you want to create an interactive element in the your site or app that takes you to another web resource. You do not use an anchor element to trigger scripting functionality. That’s what the button element is for.

Both are simple to use and come with a boatload of accessibility benefits, like keyboard access and native state indicators in the browser.

When to use an anchor/link

You use an anchor element when you link to a URL or an API endpoint:

<a href="https://www.w3.org/TR/html52/interactive-elements.html">Interactive elements in HTML</a>
 
<a href="/inbox">Inbox</a>

Or when you link to a destination in the same document:

<a href="#terms">Our Terms and Conditions for you to ignore</a>
 
... truckloads of HTML ... 
 
<div id="terms">... </div>

You can then use JavaScript to intercept the link and overwrite its default behaviour to keep the users on the page. If JavaScript fails for some reason, users will reload the whole UI and still go to where they need to go. In this example to the w3c web site, the /inbox endpoint UI for your app or the terms DIV. They could also open any of those in another tab. I do that all the time in WordPress. This is good, solid, design that keeps the user in control. However, when there is no URL or in-page target to go to, you give a promise you don’t keep.

When to use buttons

If, your app has no URL endpoints for the different states and all the handling happens in JavaScript, there is no point in confusing your users with a link that goes nowhere and won’t open anything in another tab. Use a button and you won’t promise any functionality you don’t have.

<button>Inbox</button>

This HTML element is custom made exactly for that purpose and works fine – even with a keyboard.

Buttons even work without JavaScript. If you put them in a form element pressing them will send the form data to the server and you can react to which button was pressed in your backend. Of course you can also override this functionality and do all in the script – you just need to hope that it will work.

Don’t confuse users

This is especially important when it comes to accessibility concerns. Screen reader users, for example, can navigate a document in various ways. One of them is getting a list of all the links in the document. This prevents them from having to listen to the whole document to find a certain part of it. If you create a lot of links that point nowhere, you fill this list with nonsense. If you create buttons and label them accordingly, even people who can’t see your UI will be able to navigate it.

Why is this still a problem?

Fans of markup and a simple web know this for ages and we keep having to repeat it every few years. Yet, links keep getting used for functionality that doesn’t go anywhere on the web or in the document.

The reasons are largely historical and cargo-cult horror stories of browsers doing things wrong. Browser of the past had a few issues with buttons. It was tough to override their in-browser style. Very old versions of Internet Explorer had a bug that only the first button was included in the form data, not the one that was pressed.

Styling is probably still the main reason why people wrongly use a link where a button should be used. Buttons are much more complex interaction elements than links and they have more styles attached to them. Links are part of the text renderer, buttons are traditionally part of forms and much more complex. So if someone who doesn’t like CSS and is worried about “things looking wrong”, it is tempting to use a link as it is easier to style. That, however, is an indicator that there is something wrong with the project management of your product. End users shouldn’t get the wrong interaction model because the person who had to style the product doesn’t know how to or want to.

The last reason is probably that it works and we’ve seen other people do it. That’s an entitled and lazy reason. Browsers have to be forgiving in what they show to avoid end users getting a broken experience. However, not everybody has the same setup, abilities and ideas what a great interface is that we have. By using the right element for the right job, we hand a lot of the responsibility to create a working interface to the browser and the OS instead of having to do it ourselves. Just because links don’t break for us doesn’t mean they don’t for others when a button is a much sturdier, custom-made solution.

The issues with buttons in older browsers have been fixed now. There is no excuse these days not to use a button, especially when considering how much accessibility benefits you get for free.

The Techdays Finland people asked me to record a quick video about my talk at this year’s event.

See you 28th of February!

As people complained that I post too many links to follow on Twitter (it is my stream of consciousness – as I find it, I post it), I’m starting to release these link lists every few days now. Hopefully that helps.

Accessibility

• Tools & strategies for developing accessible web apps is
  a showcase how to build inclusive web apps/SPAs/PWAs in different JavaScript frameworks, currently working on the VueJS part.
• Vasilis van Gemert wrote his Master thesis trying to find the answer to the question What if we design websites exclusively for people with disabilities? .
• Building a Progressively-Enhanced Site is a step-by step explanation.
• @aardrian on what can be learned of the accessibility issues of rolling out WordPress’ new editor. Lessons from Gutenberg

JavaScript

• 15 Useful JavaScript Examples of .map, .reduce and .filter by Alex Permyakov has some very interesting examples.
• Luciano Mammino explains JavaScript iterator patterns

The web is broken

• Everything is terrible (but more so inside a keypress event handler) – Mike Taylor explaining how making keypress work across browsers is not as easy as we think it is.
• Convert a String to a Number in JavaScript
  Quite a few diferences in Number() and parseFloat();
• Beyond the interface – why do all apps look the same nowadays? Why do all websites look the same?

Geek

• SCRIPT-8 is a fantasy computer for making, sharing, and playing tiny retro-looking games (called cassettes). It’s free, browser-based, and open-source. Cassettes are written in JavaScript.
• The Modem Dialup Sound, Analyzed

Tools

• Archivarix is a wayback machine online downloader with CMS.
  Restore a fully functional copy of the site – 200 files for free!
• Trigger a action on element when keyboard hotkey is pressed.
  Lovely implementation by GitHub, just add data-hotkey attributes

<a href="/new" data-hotkey="n">New Issue</a>

As people complained that I post too many links to follow on Twitter (it is my stream of consciousness – as I find it, I post it), I’m starting to release these link lists every few days now. Hopefully that helps.

Performance

• Doug Sillars telling us that not all your base belong to us in Performance Anti-Patterns: Base64 Encoding
• Katie Hempenius gives in-depth information on when to use and when not in All about prefetching
• Jordan Irabor has some good insight into Browser Rendering Optimizations for Frontend Development

Algorithms

• On Algorithms and Interviewing talks about the painful experiences of interviews not matching with your job
• On the other hand Obosi Philip gives us a Gentle introduction to algorithms and data structures

Cool demos:

• Software Galaxies visualizes dependencies among most popular package managers. Every star in this visualization represents a package.
• Peter Barr gives you a great reason to shout at your screen with Variable font by volume demo
• Don’t you miss the beauty of WordArt? Katherine Kato is here to help with her CSS Word Art generator

Every few weeks the webdevelopment Twitter world gets in a frenzy over terrible HTML. HTML that is only DIVs and SPANs with random classes on them. HTML lacking any sensible interfaces like anchors or buttons. HTML lacking any structure like headings and lists. Non-semantic HTML. Unreadable HTML.

HTML is well defined. It is also robust, inasmuch that it is forgiving. We tried to make HTML less forgiving in the XHTML days but the web was not in a state to allow for that. Developer mistakes should not result in user lock-out. Instead, browsers should be lenient with HTML and fix things on the fly when rendering. This should worry us, as we are forced to carry with us years of horrible browser decisions. That’s why – amongst other things – browsers are fat and slow.

HTML is forgiving

This leniency, however, helped the web survive. It ensures that today’s browsers can show age-old content without us having to go back and change it. Years of Flash content now not available proves that this is a sensible thing to do in an environment as fluctuating as the web.

It does mean, however, that there is no perceivable punishment for non-semantic HTML. DIVs and SPANs work, Table Layouts still work (oh, hai, hackernews).

Browser showing anything should worry us as it makes writing “clean” and “semantic” HTML a nice to have. A special skill. The caligraphy of writing for the web, where most of the other content is random smeared scribbles on dog-eared sticky notes.

Semantic HTML is better, there is no question about it. You get a lot of free accessibility benefits from it. It tends to perform better. It often means that you have no third party dependencies. It is also much easier to read and understand. And many of us learned about the web by looking at the source of other web sites. This is an anachronism, and I wrote about this in length a few months ago.

It is time we start dealing with this on a more mature level rather than re-iterating the same complaints every few months.

HTML is and has always been a compilation target. The wonderful world of “hand-crafted HTML” is one for a very small group of loud enthusiasts.

I am part of that group and I have been ever since I started blogging 14 years ago. I love that the web is accessible to all. All you needed was a text editor, some documentation and you’re off to publish on it.

Hand-written HTML is a rarity, a collector’s item

However, even 20 years ago when I started as a web developer, this was not how people worked. This was not how most web products were created. In fact, it was even that uncommon that in any job description I wrote we specifically asked for “hand written HTML/CSS/JS skills”. It was an elite, highly interested and invested group who cared about that. Good people to hire if you want to make a change for a cleaner, more semantic web. But was that change even in demand?

The larger part of the web was based on other technology:

• Server-Side-Includes (remember .shtml pages)
• CGI/Perl templating systems
• Content Management Systems with own templating languages rendering out HTML
• WYSIWYG Editors that created something resembling HTML
• Templating languages like PHP, ColdFusion, Template Toolkit, ASP and many others
• Online editors and page generators like Geocities
• Forum and Blog editors with sometimes own languages (remember BBCode?)

None of these were necessary to publish on the web. In the case of some of the enterprise CMS I worked with they were ridiculously complex and inflated. But people used them. Because they promised an easier, more defined and clearer publication path of web content. They solved developer and manager problems, not end user experience. In the case of Geocities and similar services they made it easier for people to publish on the web as they didn’t even need to write any code.

What you see in the browser is almost never the source code. If you want to improve its quality, we need to go higher up the chain.

Even back then looking at the source of a document wasn’t the document that someone wrote. It was the result of lots of includes being put together by some server-side code, maybe even optimised and then thrown to the browser.

And that makes total sense. Having lots of different components allowed people to work on them in parallel. Often your site navigation was a global one even written and maintained by some other department or company. You didn’t even have access to the HTML, and – if you were lucky – you could fix a few issues with CSS.

HTML is a compilation target

Fast forward to now. HTML is not cool. Writing your own templating language is. Markdown, Pug, Jade and many others keep getting invented. Meant to save us from the complexity of HTML and the compatibility issues it has with this or that environment.

HTML has a bad reputation for being something that should work, but doesn’t reliably deliver. A framework that gives you more control and promises to be “modern” is much more exciting than an age-old technology that promises not to break.

It is irrelevant to most that the web shouldn’t be controlled by us but that our users need to cater the outcome to their needs. Most developers don’t get paid to think in those terms – they get paid to roll out a certain interface in a certain amount of time. We need to fix that.

HTML is not seen as a thing to worry about – as the execution environment is lenient about its quality. It is generally seen as a much better use of your time to learn higher abstractions. People don’t want to build a web site. They want to build an app. That in most cases they don’t need an app is not important. We dropped the ball in keeping HTML interesting. We wanted the web to give us more capabilities, to be on par with native code on mobiles. And this always results in more complexity. The extensible web manifesto pretty much nailed that a publisher on the web needs to have a more developer mindset than a writer or publisher. We wanted control, we wanted to be in charge. Now we are.

What does this leave us with? For one thing, we need to come to peace with the fact HTML on the web in most cases is the result of some sort of compilation. Looking at the final result and bemoaning its quality makes no sense. Nobody ever edits this and it is not meant to be readable.

I am not giving up on semantic HTML and its merits, but I understand that we won’t sell it to developers by telling them their end product is terrible. We need to work with the framework developers, the creators of components. We need to help with the template code source, the framework renderers. We need to ensure that the conversion stage results in good HTML - not easy HTML.

And we need to work with tool developers to make sure that people learn about the value of semantics. In-editor linting and autocompletion goes a long way. We have a much bigger toolbox to choose from these days to make sure that developers do the right thing without having to think about it. I like that idea. Let’s fix the problems at the source rather than complaining about the symptoms.