Well, that was what HTML was on track to give us. But once JS and CSS were introduced, semantic HTML that was actually semantic stopped developing, under the assumption that if someone needed, for example, a tab area or slide show, they could develop those themselves with CSS/JS. What we've gotten instead is extremely vague elements like "section" that don't communicate what the elements are.

If HTML were truly semantic, browsers could implement accessibility features around it, but because they're so vague, there's no real way for browsers to do that, which offloads the responsibility onto web developers, who in most cases aren't granted budget to do it. There are a handful of features such as alt properties, but these are pretty limited.

So yeah, HTML should give us that, but that's part of what users gave up when we decided it was acceptable to allow random websites to run code on our machines and tell us how our content should be displayed.

I agree with you, but also I think the section tag is one of the biggest leaps forward we've had. Putting an id on a whole section instead of a name= crap for references, and actually using nesting for hierarchy.

All the HTML5 input types are also an example of semantics impriving. It could be way better, but it's not a total stalemate

> I agree with you, but also I think the section tag is one of the biggest leaps forward we've had. Putting an id on a whole section instead of a name= crap for references, and actually using nesting for hierarchy.

How does this differ from how <div> was being used before?

I've switched to using <section> simply because it's a better name, but I'm not sure it's made any meaningful difference in my code.

> All the HTML5 input types are also an example of semantics impriving. It could be way better, but it's not a total stalemate

That's true, but I think we'd be moving forward a lot more quickly if we weren't devoting most of standards development resources toward giving companies more fine-grained control of our browsers through CSS/JS.

My e-book reader shows <em> text with teal color and I like it, it's better visible than italic and the font remains upright and readable, I doubt it will be comfortable to read lots of text in italic. I didn't notice any discrepancy with <i>. But for some reason <strong> doesn't override <em> and they multiply, though I saw it used once when an exclamation was repeated several times with increasing emphasis for extra dramatism.

This...does not match history.

There was never a golden era like you describe (it was a time of conflicting philosophies, people saying "eh, let's add this, that would be sweet", and browser vendors competing to add as much as possible to out "innovate" each other and the limited specs), semantic HTML helps in some cases but is never going to give you automatic accessibility, and a one size fits all browser style is still not going to give you what you need even as you add increasingly unsemantic tags to try to improve it (which is exactly what was happening pre-CSS).

> This...does not match history.

I've been writing web code since 1995ish, so...

> There was never a golden era like you describe (it was a time of conflicting philosophies, people saying "eh, let's add this, that would be sweet", and browser vendors competing to add as much as possible to out "innovate" each other and the limited specs)

I did not describe a golden era of HTML, because a golden era of HTML was precluded by the introduction of JS/CSS. Had JS and CSS never been invented, we might have achieved a golden era of HTML, but we would have needed web standards to mature before that could happen. What happened was, web standards did mature, but they matured to serve websites rather than users. As a result, mature web standards center around JS and CSS, leaving HTML anemic and weak.

What we have now is a time of conflicting philosophies, with websites competing to add as much as possible to out "innovate" each other. Users still suffer the same inconsistent interfaces they did in 1997, it's just that instead of browsers being inconsistent, it's websites that are inconsistent.

Well, there was a previous garbage area, when HTML was, rather than being semantic, laid out using tables and \<color\> and \<font\>. I remember telling people to not do that, especially when the first version of CSS came out, and you could make websites look nice with semantic HTML that also worked in Lynx.

Table layouts are still superior to CSS in that they achieve the Holy Grail layout. As far as I'm aware, CSS still fails to achieve the Holy Grail within any reasonable realm of effort.

Hell, the entire reason the internet moved from Holy Grail layouts to singular sidebar and vertically integrated layouts was because CSS can't into Holy Grail.

With how wide most users' monitors are ever since 16:9 became commonplace, Holy Grail should be the ideal content presentation layout because it uses all that free space on the sides for non-content (eg: navigation) so precious vertical real estate can be dedicated to content.

This doesn't add up. CSS grid, flex box, etc all do the "holy grail" layout with a couple lines. The tables mess that was early www was and remains an absolute mess of markdown to maintain for layout. Semantics and accessibility are practically out the window with table.

HCI dictates how humans use interfaces and with that comes many defacto reasons why a plain text page does not solve the problems users want to solve. Do you not think websites test into the optimal performing layouts and content distribution? If it worked better, we'd all be using it (it doesn't).

>Do you not think websites test into the optimal performing layouts and content distribution?

No, I think most website devs left to their devices optimize for least effort to create and maintain.

> No, I think most website devs left to their devices optimize for least effort to create and maintain.

...which is definitely not tables. Flexbox is much easier.

Sure, but there were a lot of ways that could have been solved with HTML standards.

It would be so great if there were more built-in interactive elements like tabs, modals, and tooltips. How many times have these incredibly basic things been re-created?

Yeah, all this time browser vendors should have been taking a "pave the cowpaths" approach to natively implementing stuff that everyone ends up reimplementing in CSS and JS. And HTML5 did a little of this, with e.g. date and color input fields. But they could have gone farther.

To disagree with my own point a bit, it’s unfortunate that the controls HTML5 added look different in every browser, and can’t be styled with CSS at all.

Somewhat subtle, but: Yes and No.

I'd say HTML for itself just gives us a way to give meaning or imply how something should be styled "headline of first order". In the end it's a markup language, not some magic styling tool.

How it is actually styled (in absence of CSS) is in the hands of the default rendering of your browser. That might very well be a very bad rendering, due to lack of knowledge/time/engagement of the people building/maintaining that renderer.

Also those renderes might come from a time and system where technical limitations where different, markup was different, lots of things were very different.

So I don't think we should expect HTML alone to "look nice" or work well in regards of readability.

> I'm quite certain that a large part of the web would need no CSS or just a few lines of it, if the basic (browser applied styles) were good. As in: designed

I think we would win a lot if browsers default styles were beautiful (as in: really good, not merely fancy) designed. Many websites then would need just a few lines to set some colors, style that weird-custom thing they do or make it feel just a bit more personal.

I think the bigger thing would be to have more semantic HTML. <dropdown>, <tab-area><tab>Content</tab></tab-area>, <carousel><slide>Content</slide></carousel>, <rich-text-editor>, etc. Instead we've got a million immature implementations of these that are slower because they are written in JS instead of native code, slowly break over time as they aren't maintained, and typically have terrible accessibility.

Yes. HTML gives the structure and hierarchy (if done properly) which is also what then gives the accessibility. CSS can do lovely things that will help a blind user with a screenreader not one bit unless you're kludging in "hacks" to give them extra hints for specialized use.