<div>
<div>
<img src="/media/really-motivated-person.jpg" />
<div>
List of things to be <div>done</div>:
</div>
<div>
<div>
First thing
</div>
<div>
Second thing
</div>
<div data-thing="an actual div that was printed in the DOM with no content in it 🤷‍♂️"></div>
<button>âž•</button>
<div>
Some content inside modal
<button>OK</button>
</div>
</div>
<div>
Some SEO important <div>content</div>
</div>
</div>
</div>
Either it was written in a test for a job interview or included in a pull request from team members, I couldn’t stop myself from thinking that HTML syntax is often not the most efficient or relevant. I can’t be the only one, right?
Don’t get me wrong, building a web app today doesn’t mean that you will need the most accessible or the most “valid” HTML. If you inspect the Slack application for example (which is a worldwide known product with a ton of users), you will find that the markup is essentially composed of a pile of tasteless <div> tags. And that makes sense! If you’re logged into your company’s workspace, there’s no crawling robot to please with a beautiful and tasty HTML salad and when it comes to keyboard navigation, you will find that the product has chosen the bias of taking it personally with their own built-in solutions to make your life easier as a keyboard-user (try it on Slack, it’s pretty good).
This is what I like to call “Some Photoshop HTML”. Let me explain:
If you’re familiar with Photoshop, After Effects or any other programs that allows you to manipulate images or videos, you will easily see what I’m talking about. In Photoshop for example, it doesn’t matter how you named, organized the project or even the technique you used to get to that result. There’s always multiple ways to accomplish what you want and what really matters is the end result. The average person looking at the .jpg that you finally rendered doesn’t care about how it looks like in the project file, what matters is that it looks good (or not, but it’s up to you). That the pile of layers that you arranged in you project provide the expected result. Talking about HTML, the final result of your project is not just how it looks, if it’s mock-up compliant, responsive or if it works when you click somewhere. It is ALL of that, but the end user will actually see and navigate through the “project file”. What you wrote is what makes all of that work but will also determinate how easily keyboard users and crawling bots will navigate through and like your pages.
<main>
<section>
<picture>
<source
srcset="/media/really-motivated-person_portrait.jpg"
media="(orientation: portrait)" />
<img
src="/media/really-motivated-person_base.jpg"
alt="A moron that looks really motivated, ready to write an article about a markup langage." />
</picture>
<h3>
List of things to be <b>done</b>:
</h3>
<ul>
<li>
First thing
</li>
<li>
Second thing
</li>
</ul>
<hr>
<button aria-label="Add a thing to do">âž•</button>
<dialog>
<p>Some content inside modal</p>
<form method="dialog">
<button>OK</button>
</form>
</dialog>
</section>
<footer>
Some SEO important <strong>content</strong>
</footer>
</main>
From a “valid” user POV, the job can be judged as “done” when it displays things , works when clicked and is eventually responsive. For apps that are actually made to be rendered fully on client side (CSR), it doesn’t really matter if they are not composed of relevant markup as they are not made to be SEO-friendly. Plus, most of the time, speaking from a keyboard-navigating user POV, most actions could simply be materialized with a button with text inside. That would just work as browsers and accessibility tools are actually pretty good to guide user’s focus on the web page.
There’s no need to make proper example to demonstrate how HTML is capable by itself and why you should really rely on it when it comes to some simple use cases. But still, I’m gonna list some gentle reminders:
onclick=”myFunction()”).form, a button with the attribute type=”submit” will trigger the onsubmit action of its parent form. There’s no need to handle a onclick event on it.<dialog> tag is really helpful and fully cross-browsers compatible (well, not IE). It comes with simple open and close methods and a method to get the user’s action in the modal. It even handles the tab index for you, something you should handle yourself if you decide to implement your own modal component (doc).accordion component? HTML has one that you can style to your needs: details (doc).focus inside a useEffect on an element referenced by a ref returned by the useRef hook.Talking about that last example (SSE) ****you certainly are still familiar with it as it is a WEB standard function that modern frameworks are getting back to. REMIX for example is labeled as WEB-based and use those actions to handle form submission for example. Next JS is Node-based but their last release (v14) is onboarding a stable version of their new APP folder based router which allows to use server actions, based on SSE.
Why is HTML so poorly written nowadays? Could be a lot of things. But looking at the last 20 years (30 actually, feel old yet?), devices going bigger or smaller and the evolution of frontend framework and libraries had the frontend developers changing their focus from integrating accessible and SEO friendly websites for desktop browsers to developing complexe apps with heavy logic that could be displayed on every devices from multiple methods. The race for the ability to master those technologies could be the cause of a neglected HTML, especially for young frontend enthusiast. Looking at the massive amount of knowledge that they must master while, at a time of history, their job was simply HTML and CSS rendered from a template engine.
Using the word “developing” talking about ****displaying and shaping content in a browser did became a real thing at one point of web history. We even started talking about APPS instead of WEB pages. And as complex and capable an app could be, it would really soon start using concepts and paradigms borrowed from mature technologies and conventions. Making it an heavier thing to master even more. DRY, SOLID and KISS principles for example did come handy when it comes to apply conventions across teams and building a solid codebase that would guaranty scalability as years passes by. It became more and more relevant to be applied in front APPS.
So yeah, I suppose developers (me first) tend to abandon good markup for a better focus on technologies and respecting conventions.
Source: https://twitter.com/fireship_dev/status/1737475143222317123