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. 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. However, not everybody has the same setup, abilities and ideas what a great interface is that we have. Browsers have to be forgiving in what they show to avoid end users getting a broken experience. The last reason is probably that it works and we’ve seen other people do it.
ANCHOR LINKS WITH PRINCIPLE APP HOW TO
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. That, however, is an indicator that there is something wrong with the project management of your product. 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. Links are part of the text renderer, buttons are traditionally part of forms and much more complex. Buttons are much more complex interaction elements than links and they have more styles attached to them. Styling is probably still the main reason why people wrongly use a link where a button should be used. 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. It was tough to override their in-browser style. Browser of the past had a few issues with buttons.
The reasons are largely historical and cargo-cult horror stories of browsers doing things wrong. Yet, links keep getting used for functionality that doesn’t go anywhere on the web or in the document. Why is this still a problem?įans of markup and a simple web know this for ages and we keep having to repeat it every few years. If you create buttons and label them accordingly, even people who can’t see your UI will be able to navigate it.
If you create a lot of links that point nowhere, you fill this list with nonsense. This prevents them from having to listen to the whole document to find a certain part of it. One of them is getting a list of all the links in the document. Screen reader users, for example, can navigate a document in various ways. This is especially important when it comes to accessibility concerns. Of course you can also override this functionality and do all in the script – you just need to hope that it will work. 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. This HTML element is custom made exactly for that purpose and works fine – even with a keyboard.īuttons even work without JavaScript. Use a button and you won’t promise any functionality you don’t have. 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. However, when there is no URL or in-page target to go to, you give a promise you don’t keep. This is good, solid, design that keeps the user in control. They could also open any of those in another tab. In this example to the w3c web site, the /inbox endpoint UI for your app or the terms DIV. If JavaScript fails for some reason, users will reload the whole UI and still go to where they need to go.
You can then use JavaScript to intercept the link and overwrite its default behaviour to keep the users on the page. Our Terms and Conditions for you to ignore
0 kommentar(er)
