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.

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.

https://en.wikipedia.org/wiki/Dynamic_HTML

I think that was known by meindnoch and was a joke.

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.

Not sure if a joke but this is factually inaccurate.

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.

Be sure to correct all the people who are using the term “cool” for things other than relative temperature, as it was originally defined.

See also the dictionary fallacy, and again descriptivism vs prescriptivism.

Additionally, even leaving alone the div/dynamic language issue, there really isn’t a point in usage history where DHTML came without JS — believe me, I was doing it when the term first came into usage. JS was required for nearly all dynamic behavior.

> See also the dictionary fallacy, and again descriptivism vs prescriptivism

DHTML is an acronym that expands to: Dynamic HyperText Markup Language.

There is no dictionary fallacy or descriptivism vs prescriptivism or defined meaning. It was simply an industry standard way to shorten all those words.

Changing one of the letters to stand for something else reassigns the pointer to something else entirely, or is the making of a joke, which I think the above may have been.

Wow, you should try out for the olympics with those acrobatics. I didn’t realise it was possible to miss every point so hard.

Man I live for takedowns like these, nice work

what takedown?

You can work it out, I believe in you.

DHTML is literally just HTML that is dynamically modified by JavaScript. DHTML became a term when JavaScript became ubiquitous. It was not an extension.

Javascript was not ubiquitous when the term DHTML was last seriously used. And yes, CSS and javascript were extensions at the time, not very widely supported across all browsers.

We had table based layouts and then divs when CSS started to take off, mostly used by artists rather than companies at first.

Javascript had vanishingly limited uses at first, too. I don't remember exactly how long it took us to get XHR but before that we had "Comet frames", before iframe security was given much focus. Javascript couldn't do that for a while. It was also dodgy and considered bad practice for quite a while, too.

I don't remember when the term javascript was even really used in regular vernacular but DHTML was not so much referring to CSS as it was the myriad of weird mechanisms introduced to make pages dynamic. It was never "Div-based HTML" or whatever, the div craze came way later once CSS was Good Enough to eschew table layouts - after which, Dreamweaver died and photoshop's slice tool finally got removed, and we started inching toward where the web sits today.

I also do distinctly recall needing a doctype for DHTML for some browsers.

> Javascript was not ubiquitous when the term DHTML was last seriously used.

It wasn't as fast or as usable as it is today, but Javascript has been in every mainstream browser since before Microsoft started pushing "DHTML".

Interestingly, in my memory, it seemed like we had JS for a long time before DHTML, but it was only a couple years between Eich writing it and IE4, which was the start of the "DHTML" moniker. Looking back at the timeline, everything seems much more compressed than it felt at the time.

That could be. And yeah, DHTML came and went pretty quickly even by today's standards.

DHTML was just JavaScript that mutated the DOM. That’s literally all it ever was. There was also not a DHTML doctype. There was also not anything even called “an extension”. There were Java applets, ActiveX controls, and ActionScript -> JavaScript bridges, which the concept of DHTML (dynamic HTML) eventually fully replaced.

Divs weren’t a “craze”. They were popularized by the (brand new) XHTML spec, which did have its own doctype.

JS was ubiquitous when DHTML was pushed by Microsoft, because DHTML required JScript aka JS.

CSS was not there in the '90s because Netscape didn't implement, and MS did its own subset.

JS and CSS both suffered from wildly inconsistent support between Netscape and IE, but JS at root had interop enough to support hotmail, later OddPost, much more. CSS had no extension mechanism based on JS then, so it suffered browser-specific support that was IMHO worse than JS suffered. No way to polyfill.

(There was no DOCTYPE for DHTML. The one for HTML 4.01 was not equivalent to a DOCTYPE for DHTML.)

Not sure why you're being downvoted, but actually yeah, this isn't far off from my recollection either.

Man, I love it when I find a good <table>

https://matthodges.com/posts/2025-09-30-visidata/

What does SHTML stand for?

The classical answer is that the S stands for Server-Side-Incude (SSI). SSI source typically uses the extension .shtml. More info:

https://en.wikipedia.org/wiki/Server_Side_Includes

SPAN-HTML, obviously.

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.

It's short for SHiTML.

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.

Developers of all people should be in a position to notice how tag semantics can keep them oriented in a document or target behavior and styling…

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 seems to still work if you have a div with article text in it. I would be interested to see a comparison of what works and what doesn’t if such a reference exists though!

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.

The point of the reply was that they actually do. It's just not obvious that they do if you don't use that method yourself.

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.

My 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

please elaborate, how is <output> a better example for only doing half of what a developer would want? what is missing?

> 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?

In some cases, because there was a period of time where it might not have been in HTML in all browsers, and javascript was used instead, and then HTML had it.

Then no one checked, and the javascript train had already left the station.

People who already have a habit of solving a problem a specific way are generally unlikely to switch when a new solution appears unless it is considerably easier. If it's not immediately easier, it will feel easier to continue the ingrained habit.

Then you might as well use a single instance of the canvas tag.

Doesn't Flutter do exactly that?