Comment by froobius 3 days ago
So there's useful html tags from 2008 that no one uses or knows about... How can that be the case? Because there's just so many tags? Because people don't read the docs? Because the benefits are not obvious?
The D in DHTML is usually short for "Dynamic".
Around the time that abbreviation became fashionable using a lot of DIV elements also did, but that wasn't what the "D" stood for.
I'd say DHTML was more of a thing in the early 2000s when we were still using tables for layout. The divs came later, when the abbreviation had fallen out of fashion because all HTML kinda was dynamic by default.
Accurate to some substantial usage, whatever definitional inaccuracy or backronym action is in play.
Descriptivism usually reflects some reality no matter the intended prescriptives.
No, sorry. It's factually inaccurate. DHTML stood for Dynamic HTML, it was an extension before Javascript and whatnot was added.
Man, I love it when I find a good <table>
The classical answer is that the S stands for Server-Side-Incude (SSI). SSI source typically uses the extension .shtml. More info:
This is a legacy of old apache configurations, the common mime type configuration files used .html to send the straight file, and .shtml to turn on the server side processing instructions. Server side includes could be static files or executable scripts that generated text on STDOUT. If you were using a lot of server side includes, it was cleaner just to turn on server side parsing for the whole site.
Because a lot of web frontend developers are addicted to <div> soup and fancy CSS and JavaScript libraries.
It's also due to browser not doing anything useful with the additional tags, if I use <article>, <section> or <div> doesn't make any difference, my browser doesn't use that to generate a TOC or let me open an <article> in a new Tab. Even the, in theory, incredible useful <time> tag seems to be completely invisible to my browser and many other potentialy useful tags don't exist in the first place (e.g. <unit> would be useful).
> It's also due to browser not doing anything useful with the additional tags,
It's clear that you are sighted and never use reader mode.
Exactly this. I really wish browsers would use semantic html to make content more accessible for me, a sighted user! Why does my browser not give me a table of contents I can use to navigate a long page?
I think the parent has a good point: browsers don't do anything with these tags for sighted users, who are unfortunately the majority of developers. If they were to notice benefits to using semantic tags, maybe they'd use them more often.
It’s interesting, because if you imagine sites actually using these tags to be maximally compatible with reader mode and other accessibility modes, they’re setting themselves up perfectly to be viewed without ads.
I use reader mode by default in Safari because it’s essentially the ultimate ad blocker: it throws the whole site away and just shows me the article I want to read.
But this is in opposition to what the website owners want, which is to thwart reader mode and stuff as many ads in my way as they can.
It’s possible good accessibility is antithetical to the ad-driven web. It’s no wonder sites don’t bother with it.
Reader mode is based on a whole slew of heuristics including tag names, class names, things like link-to-text-content ratio, and other stuff I can't recall. IIRC it considers semantic tag names a stronger signal than e.g. class names, so having <article> in your page isn't necessary but helps a lot.
Yes, I think that is what browser should spend money on instead of inventing new syntax. Google Chrome still doesn't support alternate stylesheets. But I refuse to not use them simply because a rich company can't be bothered to implement decades old standards.
Maybe not the browser itself, but in combination with semantic CSS [1], it's incredibly useful.
[1] - eg https://picocss.com/
Not true. Using semantic HTML and relying on its implicit ARIA roles allows the browser to construct an accurate AOM tree (Accessibility Object Model) which makes it possible for screen readers and other human interface software to create TOCs and other landmark-based navigation.
> Not true. Using semantic HTML and relying on its implicit ARIA roles allows the browser to construct an accurate AOM tree (Accessibility Object Model) which makes it possible for screen readers and other human interface software to create TOCs and other landmark-based navigation.
Sure, it allows the browser to do that. GP is complaining that even though browsers are allowed to do all that, they typically don't.
We just don't have enough tags that we can really take advantage of on a semantic or programmatic level, and that has lead to other tags getting overloaded and thus losing meaning.
Why don't we just have markup for a table of contents in 2025?
That'd open a whole new can of worms. Browsers are already gargantuan pieces of software even with the relatively primitive tags we have today. We don't need to further argue with each other what the <toc> tag should look and behave like, deal with unforeseen edge cases and someone's special use cases which end up requiring them to implement the whole thing with <ol>s and <li>s anyway.
Then let the edge cases use <ol> and <li>, and in some sense all those website style simplifiers that comes built-in with Safari will just have to deal with those edge cases. Similarly we have a built-in date picker, and if you don't think it's good enough then build a better one.
If you want a specific behavior for <time> then write a browser plugin which e.g. converts the <time> content to your local time.
But if you are a developer you should see value in <article> and <section> keeping your markup much much nicer which in turn should make your tests much easier to write.
Semantic tags were never widely used, even before the overuse of JavaScript.
Because no one cares about HTML except as a payload carrier for the real website: the JavaScript output from React/Tailwind/Typescript compilation.
You have to remember, this is an industry that thinks having code without syntax errors was too unreasonable a requirement for XHTML, there is no reason to expect them to know anything beyond div and maybe a dozen other tags.
For anybody wondering, there are 112 of them:
a
abbr
address
area
article
aside
audio
b
base
bdi
bdo
blockquote
body
br
button
canvas
caption
cite
code
col
colgroup
data
datalist
dd
del
details
dfn
dialog
div
dl
dt
em
embed
fieldset
figcaption
figure
footer
form
h1
h2
h3
h4
h5
h6
head
header
hgroup
hr
html
i
iframe
img
input
ins
kbd
label
legend
li
link
main
map
mark
menu
meta
meter
nav
noscript
object
ol
optgroup
option
output
p
picture
pre
progress
q
rp
rt
ruby
s
samp
script
search
section
select
slot
small
source
span
strong
style
sub
summary
sup
table
tbody
td
template
textarea
tfoot
th
thead
time
title
tr
track
u
ul
var
video
wbrMy guess would be that most people just copy (mimic) what is already there. I sometimes work as a freelance web administrator and I can assure you 95% of people who create websites for a living have never read through a list of HTML tags, have only a slight idea of the semantic web and in the end they are more like people who cobble existing things together and are out of their depth pretty quickly.
Not that this is problematic per se, everybodies milage may vary and we're all out there to learn. But if I told one of them about the output tag thry probably wouldn't even understand why that would be important.
Maybe because most HTML tags are not well supported by browsers, because they are doing by themselves only half of what a developer would want, hard to style, hard to enhance the native behavior, ... most recently-added tags have those problems (ex: <progress>), this one from 2008 is an even better example
> Update 7 Oct 2025: Some screen readers have been found not to announce updates to the tag, so explicitly emphasising the role attribute might be worthwhile for now until support improves: <output role="status">.
Maybe it's because like most things html/css related, it's a semi-broken implementation of a half-feature?
I mean with modern javascript/dom manipulation tools the only tag you really need is div.
In before comments - not advocating for div only development, just that the nature of www moved from html with some js to well ... only js.
Then you might as well use a single instance of the canvas tag.
Most sites today are not using HTML in the way it was originally envisioned. They use something called "DHTML" instead. The D stands for DIV, because people seldom use any other tag. E.g. in normal HTML you would use the TABLE, TR and TD tags to build a table. In modern DHTML (aka DIV-HTML) people build the table from fixed size DIVs, and calculate the column sizes via JavaScript.