DEV Community


Discussion on: Stop using so many divs! An intro to semantic HTML

kenbellows profile image
Ken Bellows Author

That's a pretty good point, and one that a lot of people have discussed in the last couple of years.

As for most of the semantic tags being biased toward content-heavy sites, I'd say you're like 75% right. Tags like <p>, <aside>, and <article> are pretty specifically defined in terms of representing that kind of content. But some of the others, like <header>, <footer>, and <section>, while arguably still defined with content-heavy applications in mind, are IMHO still pretty useful for web applications if you focus on the idea of an "outline" for your site, and how that impacts accessibility in particular. Assistive tech like screen readers uses elements like these to build an outline of the parts of the page for the user, so you could still have the main interactive regions wrapped in sections, with <h1>-<h6> tags to label them, and <header>s and <footer>s where they make sense, though those are probably rarer, especially <footer>.

As for introducing new elements that are more focused on web applications, I have three thoughts.

First, I think this would be much more difficult than it might seem at first glance. How to structure and divide up the parts of a web application is pretty controversial even within a single team, let alone trying to standardize semantic markup for the whole industry. There actually have been some discussions about this, and several proposed (and even partially implemented) elements have been retracted; see <menu>, for example.

Second, there already is a way to do this, though it's not quite as clean as semantic elements: the Roles Model, which uses the role="" attribute to define pretty specifically what elements in the page are for, and it has a pretty large selection of "widget roles" that are super useful within web apps. I also expect it would be 100x easier to add a new role than a new semantic element.

Third, there is also another approach that's been floating around for a few years now and gaining some steam that will allow the community to develop and share these elements, maybe create some community de facto standards, without waiting on the W3C for it: Custom Elements. They aren't just for widgets: you can register custom elements to play semantic roles as well, if you want, and define some amount of semantics and behaviors for them. I haven't played with them too much, but have heard good things from those who have.

As a final note, I just saw a super interesting thread on Twitter on a very closely related subject, then switched to Dev and saw your comment in my notifications. This is the first tweet of several, and I recommend clicking through and reading the whole thread.

afingret profile image

Thanks for your response. Of course you are right about all of it, but roles and custom elements seem a little verbose, if not downright complicated for app design and scaffolding. HTML tags are so basic by comparison - you can write and read and understand them immediately. I'm not saying the web needs to be simple - heaven knows it's not, but there is something to be said for brevity when it can be had. In my HTML fantasy, there would be just a handful of common, handy tags for web applications and I would be universally heralded and financially rewarded for my contribution to humanity.

Thread Thread
kenbellows profile image
Ken Bellows Author

Well that's the awesome thing about custom elements, once they're written, they are just HTML tags. The idea with them is to pass them around like any other library. So hey, give it a try, write that fantasy set of web app tags, share them around and get your fame!