What’s the story with Frontend Engineers and HTML these days? I’ve been speaking to quite a few recently who just don’t seem to understand it. I mean, they understand some of it. They understand what a
div is and what a
My big concern is at the bottom of that technology pyramid. The lowest common denominator of the Web. The foundation. The rhythm section. The ladyfingers in the Web trifle. It’s the HTML. And it is becoming increasingly clear to me that there’s a whole swathe of Frontend Engineers who don’t know or understand the frontend-est of frontend technologies.
A Web page is a document. A component, whether it’s part of a blog template, a news site, a marketing stats dashboard or a sign-up form, is a part of a document. Documents have structure. On the Web, that’s not just about the visuals or the architecture provided by your framework, it’s about choosing semantically correct elements to that make sure that your Web page, component, whatever, is correctly structurally formatted. Headings should be headings, lists should be lists, buttons should be buttons and tables should be tables. You can style them (pretty much) however you like - a heading doesn’t have to be big and bold with a bottom margin. That’s up to you, but it should definitely be a heading and I’ll fight you if you make it a
I’m a ‘frontend of the frontend’ kind of guy. My expertise is in HTML and CSS, so it’s easy for me to wax lyrical about why everybody should learn what I already know (for the record, I don’t know it all - we still have heated debates in the office about what the best way to mark up a certain component might be). This isn’t about ‘my job’s more important than yours. If you’re writing code that renders things in a browser, this is your job.
divs and they’re going to have to work bloody hard to figure that out.
“But my framework of choice takes care of all that. I just write
Nope. Write proper HTML in your JSX. You can do it. Just because you’re using React or Vue or whatever else, you don’t have to make everything from
divs. You don’t.
“This library adds WAI-Aria attributes to everything so I know it’s accessible because they’ve already done the work.”
Great. If you’d written proper HTML, most of those attributes wouldn’t be necessary at all. You get a whole heap of accessibility features for free just by using a real
button instead of a
div with an
onClick listener. For FREE. That’s accessibility and performance and user experience points, for free. FREE!
This stuff really matters. Not doing this stuff is slowly (actually not that slowly) breaking the World Wide Web. At the very least it’s making it more difficult to use for the people who would use your product. If you call yourself a frontend engineer, it’s your responsibility to learn and use the basics - the one thing that’s common across every browser, platform, device or household appliance that can access the Web.
Please do this. Make the Web a better place by building it responsibly. There’s a Web full of resources that can help you to do it, but here’s a few for starters:
- Learn how to markup a document in HTML. Try little thought exercises where you look at a concert poster or a newspaper page and imagine how it would be structured in HTML. If you have time, build it. Use those learnings in your day-to-day work.
- MDN is a great resource for blog posts, tutorials and references.
- Reach out to people in the community. Read blog posts (like Andy Bell’s recent post about using semantic HTML, Keep it simple) and watch videos.
- When I was coming up, View Source was still useful. We’ve collectively broken that for current and future generations, but I would impress upon you the power that comes with knowing how to use a browser’s dev tools
- Find out about how assistive technologies access the Web
- Look at the HTML specs, or even just at a list of HTML elements and their uses.
- If you work in a team of developers, have discussions about markup. Have lively conversations about whether something should be a
(The Description List Element - MDN). It’s great fun, I promise.
- Find out who the HTML expert in your team is and ask them to review your code. If that person is me, I’m always happy to have that discussion.
If you'd like to discuss any of this, I'm happy to have that chat. See my contact page for ways to get in touch.