I enjoyed this refresher and I agree there's more to markup than divs. With that said, the current crop of available HTML tags are a little confining. They seem biased towards newsy, bloggy, content-heavy sites (section, article, header, footer, p, aside etc). It would be great if there were a few tags aimed at web applications - tags like controlbar, preview, settings, livecontent, and user etc. I often find myself trying to map the meaning of some "thing" I'm working on to the nearest-matching standard tag. In the absence of more semantically appropriate choices, this all-to-often turns out to be a div.
Full-time web dev; JS lover since 2002; CSS fanatic. #CSSIsAwesome
I try to stay up with new web platform features. Web feature you don't understand? Tell me! I'll write an article!
He/him
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.
Florens Verschelde
@fvsch
So I kinda share this sentiment, but as a UI dev I also have a hunch that it's a bit uninformed and too optimistic about the cost of defining and building complex & stylable standard UI components. Even native ecosystems, with far fewer platforms to support, are pretty bad at it. twitter.com/tjholowaychuk/…
1.3mb of React UI components for regular things like popovers, tooltips, auto-complete etc, maybe the browsers can focus on things like this that we actually need instead `try{}catch{}` without an error 😉
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.
Full-time web dev; JS lover since 2002; CSS fanatic. #CSSIsAwesome
I try to stay up with new web platform features. Web feature you don't understand? Tell me! I'll write an article!
He/him
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!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I enjoyed this refresher and I agree there's more to markup than divs. With that said, the current crop of available HTML tags are a little confining. They seem biased towards newsy, bloggy, content-heavy sites (section, article, header, footer, p, aside etc). It would be great if there were a few tags aimed at web applications - tags like controlbar, preview, settings, livecontent, and user etc. I often find myself trying to map the meaning of some "thing" I'm working on to the nearest-matching standard tag. In the absence of more semantically appropriate choices, this all-to-often turns out to be a div.
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.
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.
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!