A collection of bad practices in HTML
htmhell.dev
htmhell.dev
People have been using HTML tags non-semantically for a very long time and, to be honest, before HTML 4 you often didn't have a lot of choice in the matter.
Still, when I was getting back into web development in 2013 I became aware of an "I can just use <div> and <a> for everything, and then stick Bootstrap classes and event handlers on to get it to look and behave the way I want" attitude that had become pervasive amongst developers.
Now, to be fair, at the time this was legitimate: in 2013 older versions of Internet Explorer were still quite prevalent. They didn't support newer HTML5 constructs, or proper styling of certain elements. The <div>/<a> approach was often the only way to get things to look good, or even to look the same, across all browsers.
Those days are long since gone (for most of us, anyway[1]), but I wonder if the reason we continue to see this style of HTML is that we're still living in a sort of post-IE hangover period? Old habits die hard[2].
[1] I'm aware that even now not everybody has the luxury of pretending that IE doesn't, and never did, exist.
[2] Again, reminds me of the migration from earlier versions of HTML, where you'd really had to do things like use tables for layout and use various HTML elements for styling (with variable cross-browser support), to HTML 4, where you nominally didn't (except, of course, that not all browsers were created equal).
This is begging the question! You start with the assumption that assistive technologies can handle table-based layouts well, and then work backwards from the conclusion that you’re trying to prove.
It may shock or surprise you, then, to learn that in actual fact, table-based layouts caused problems for screen readers (and still do, if I am not mistaken). There are a number of other ways that websites break screen readers, and the difference today is that (1) table-based layouts are hardly necessary or even popular these days and (2) more people are suing over ADA violations for inaccessible web pages.
The screen-reader tools do not fully rely on HTML semantics, but they do need some logic to differentiate between tabular content and purely presentational <table>. The reason for this should be fairly obvious once you look at any actual web page—when you navigate tables, you want to go by columns and rows, but if you are reading a table used for layout, you probably just want to flatten it and go through the entire thing in linear order (more or less). The process can be disorienting for people with screen readers if your site is poorly designed.
Of course, if you just make assumptions and guess about how screen readers and assistive technologies work, there is a good chance that your guesses are wrong.
I am pretty sure at least as old as IE6 it was really simple to enable the newer HTML5 constructs via JavaScript (leading to small libs like HTML Shiv). Just a couple lines of JS to tell the browsers the element(s) exist, via document.createElement("blah") enabled the elements and allowed styling.
IMO, it's more about developers just using Bootstrap without reading the documentation. The examples are pretty well done, they use semantic elements and are accessible.
For example, the Navbar[1] element has a good HTML structure and uses `aria-label`s that announces what's going on to assistive technologies.
Another one is the modal example[2], it has semantic elements, the `tabindex="-1"` attribute to make it accessible to keyboards and the correct use of the `aria-label` as well.
So, their documentation pretty much teaches you how to use it correctly. I'm not a fan of Bootstrap myself, but I think throwing the blame at it is unfair.
Good to see they improved, i guess :-)
(I probably paid a lot more attention in 3.x documentation than most because of the mistake in a past life of forking Bootstrap 3 for an enterprise project and trying to keep it in sync with upstream. Never again would I consider doing that.)
[1] https://getbootstrap.com/docs/3.4/components/#navbar
#10 Making a simple webpage with 9 things on it and spanning it across two pages instead of just letting people scroll.
While I'm ranting about web experience, how about Bitbucket hijacking the normal behaviour of ctrl-f in pull requests? Just.. why?!
Maybe using the "correct" element structure is going to be much more complex in a given situation due to the fact that you've got CSS rules that will be in scope that will style it for another purpose, and you'll have to undo and override all that work bit by bit to get it to match what the designer envisaged in this particular placement.
So instead you just use some divs, stick a few generic classes on stuff and get on with your day.
The tools are supposed to be the slave of the workman, not the other way round.
I'm not saying that all of these are examples of this situation of course!
Today, people praise CSS Flexbox and Grid, and they're no doubt a step-up from a practical PoV. But what has really just happened is that another ad-hoc syntax was introduced as a replacement for what previously went into HTML attributes, and worse, a syntax that needed to be able to roundtrip through HTML attributes via quoting and escaping. The notion of "semantic" markup and the HTML-CSS-JS trinity is really an after-the-fact rationalization of this syntax soup accident. From a comp.sci. PoV, there is no rationality and progress in piling up syntaxes over syntaxes with identical purposes, nor in equipping CSS with the power to rearrange element order, insert content, and whatnot, especially since HTML always had adequate typing based on a formal ISO standard (using SGML) whereas CSS lacks this completely.
> there's a mismatch between how HTML is designed and what it actually has to do in the wild.
There is an entire HTML spec[1] that explains what specific elements are for. And I agree that is not perfect, but this is what we have and if we at least don't follow it, we will be building even more shitty websites.
> Maybe using the "correct" element structure is going to be much more complex in a given situation due to the fact that you've got CSS rules that will be in scope that will style it for another purpose, and you'll have to undo and override all that work bit by bit to get it to match what the designer envisaged in this particular placement.
> So instead you just use some divs, stick a few generic classes on stuff and get on with your day.
Some "web developers" want to use `div`s instead of `button`s because it takes less CSS to style the former, but what they don't realize is that they are making theirs (the "developer") life easier, but are giving a bad UX to people that use assistive technologies and someone else, guess who? Search engines!
Search engines are basically blind entities that only use the keyboard. So, if you use a `div` they will see it as a `div`, they won't see the bunch of classes you added to make it look like a button.
So, it's a better good experience and search engine optimization to use semantic HTML. This means if you need a button use a `button`, if you need a link use an `a`, if you need an image that when you click on it it will take you to another page, surround the `img` with an `a` tag and use `aria-label` to announce what clicking on that link will do for the user, e.g.,
<a href="/learn-semantic-html" aria-title="Visit the learn semantic HTML page">
<img src="/img/surprised-pikachu.jpg" alt="Surprised Pikachu meme">
</a>
A good craftsman knows its tools and the best way to use them because each one of them has a purpose. You shouldn't use a screwdriver to hit a nail.
We have a situation where these "correct" elements have different sets of default styles in different browsers and require different sets of styling rules to make them look how the designer wishes in each.
If your starting point is that is it any wonder that sites are generally so shitty? A good starting point would be true separation between the semantic and the visual.
To resolve this, it should be easier to make hyperlinks into buttons and buttons into hyperlinks. The difference should be aesthetics only. They are both a "span with an action". The action and styling (button versus hyperlink) should be attribute-based. Examples:
<action type="post" look="link">Action 1</action>
<action type="post" look="button">Action 2</action>
<action type="link" look="button">Action 3</action>
<action type="none" look="link" onclick="myJS()">Action 4</action>As of this comment, there are 9 entries, and more than half have to do with similar link/button behavior (#8, #5, #4, #2, #1... and also kind of #3).
Some of these are also semantically invalid (e.g., #7). That's less a "bad practice" and more "invalid HTML".
I don't love hyperlinks in headings, and would prefer a more explicit link to each good example, tabs for good and bad, or even inline content to show the good examples below the bad, but it's a bit strong to be calling it "terrible".
Nowadays people are pretty slack about links: good UX generally mandates either a different colour to body text, or underlining, or both.
Blue has for many years been the default rather than the standard: people have been heavily deviating from it since the 90s. Underlining tends to be optional if there's some other way of distinguishing links (here there isn't).
If I want my images to execute on click events, and so on, I probably have a reason for that. If that thing looks and works horrible, I'll learn that, but it may also work perfectly, or in 99% nobody cares.
... only eventually, a quick fix will have morphed into a destroyed engine.
Just because you can't see it doesn't mean it doesn't have an effect
It’s a bit strange to me that in my last position all these great JavaScript engineers were still using div’s for everything when there’s so much you can harness directly from the browser’s interpretation of these elements to give you a pleasant and consistent user experience for your clients.
Besides that, it makes trawling through your elements in your web inspectors a lot easier to read when you actually have lists, sections, headers, buttons, etc.
There's a semantic way to accomplish that. If the click event you want to add triggers an action inside the page you can do
<button aria-title="Open modal">
<img src="/img/surprised-pikachu.jpg" alt="Surprised Pikachu meme">
</button>
<a href="#" aria-title="Visit the learn semantic HTML page">
<img src="/img/surprised-pikachu.jpg" alt="Surprised Pikachu meme">
</a>
<form action="link.html" method="get" target="_blank"> <button type="submit">Link</button> </form>
Just a dick move.
H1 for main page heading h2's for sub headings and <tables for tabular data eg a list of ingredients or technical data
One use I have seen for table of the basic details of a yacht, displacement, speed , length etc
On the other hand, I have found that most of the time the "I don't care, it works for me" people are just lazy or incompetent. Others mentioned blocking your site for screenreaders and ethical scrapers, I can add non standard (mobile) browsers to the list.
You might say you don't care about them. I say that is the same as throwing your household waste over the fence and let others fix it. It doesn't exist if you can't see it! The web as a whole becomes more inaccessible, it fortifies existing monopolies and mono culture.
It does not have to be perfect, you don't have to spend days. A little effort and awareness goes a long way.
\s
It’s also interesting because certainly you must have come across those engineers and developers who’re so well versed in their particular portion of the field that they know to tweak VM settings for memory leaks, or how to shard databases for faster queries, or why your Z-index isn’t working.
Those people most likely spent time studying their crafts and learning the “correct way” to do things.
This is your perception, but if you don't use semantic HTML, you are building elements that look like something (for sighted users) but in reality, is something else (for assistive technologies and search engines).
So, it only works for a part of your users. And maybe it works for the majority of your users, but that means that you are making it hard for people that use assistive technologies and search engines to navigate your site.
Leave alone people with disabilities because you don't seem to care. Search engines need semantic HTML to crawl correctly your website, so it's an important part of any project.
that is not 100% correct. a formular with a submit button will actually trigger on enter. but not a button per se. especially not a <button type="button">.
The html may as well be the bedrock of your entire website, why not put in the extra work to find the best solutions?
That is just untrue, it that was the case, people wouldn't go for hacks, I agree the web for some parts are in a better state now that a few years ago, but for me it is still a nightmare, between features / tags / attributes that only works with X or Y browser, the number of bugs, the number of features still not released after being requested for years. Also if you want a specific design for your websites, sometimes going for <div> instead of "that more correct element that adds loads of shitty css by default" prevents some headache and allows you to prototype faster.
They do, we have a standard for that, https://html.spec.whatwg.org/
> yeah, it's on a live production site still running
like HN. :)