[_answ]

Speaking from the experience of building small web apps for personal use, trying to follow semantic HTML in good faith has been nothing but a source of frustration. The rules are clearly molded around static, primarily text-based documents defined upfront, and anything that doesn't fit this format feels like a second citizen at best. Take headings, for example: in component-based development, I often don't know (and shouldn't care) what level a heading is in my reusable widget, but I am forced to choose regardless. As much as I want to be a good citizen, if I have to fight the platform for it, you're getting divs and h2's everywhere.

[prisenco]

It is perfectly reasonable and accepted html to use custom element names. Any element with a `-` is styled like a span by default.

  <article-content>
    <author-byline><author-byline>
    <content-text></content-text>
  </article-content>

This has the benefit that you can describe your markup however you'd like if it doesn't fit into the standard elements, and if you find yourself in "div soup", often times this is mitigated through class names, but using custom elements, the closing tags are much more readable than

      </div>
    </div>
  </div>

[Joeri]

Custom elements are incredibly powerful. Not only do they have their own tag name for easy selecting from css without having to use a class, but by adding custom attributes (eg size=“large”) you can basically eliminate the need for css classes entirely. Combine that with attr() to put the attribute value anywhere in or around the element with pure css and plenty of interactive components can be built purely with css, no scripting required. You can even use the @media scripting block to add noscript behavior to custom elements from css.

And then you can register a javascript class with customElements.define to add more dynamic behavior, and the sky becomes the limit. Custom elements are like a hidden framework built right into the browser.

[arcanemachiner]

Wait... I can just declare one of these in HTML without doing all the CustomElement JS jiggery-pokery?

[_heimdall]

This would be way more helpful if browsers all supported extending built-in elements and inheriting accessibility features.

For example, if `class DropdownMenu extends HTMLSelectElement` worked, you could have full control of styling and functionality without having to recreate all the a11y support baked into `<select>`. As it stands today, this will be treated as a div and its all on you to make it accessible.

[jillesvangurp]

Interesting, I did not know this was a thing. I just gave it a try and it seems to work as advertised. I'm definitely going to use that more. Div soup is super hard to untangle when you are debugging layout issues and I love having more readable html

[polydevil]

It is the same div soup for a screen reader, because there is no behavior attached to those new tags. They can not be a landmark, there are not marked as headings, they have no roles. Just a container with a text. And to attach the behavior you need to use javascript. So without js it wont work.

Why bother and try yo create half-baked non working solution if you can just use html?

Well, it easier to style, maybe. But hey, there is a class attribute.

[magicink81]

I had the advantage of having a mentor early in my career hold my code to the highest standards with regards to using the semantics of HTML. We were working on a big redesign of a large website for BigCorp, but we were still a small team on a deadline. She would not accept any excuses, and she guided me to think through HTML element selection until we found what we considered the best choice. I was taking the bus to work most days and used the time to read on the bus and at home the thick book "CSS: The Definitive Guide" by Eric Meyer cover to cover.

As you mention, working with HTML, and even more so CSS, can be a source of frustration. The UX of actually working with them is tedious work. However I can write today that all these years later, the high standards that my mentor held me to (and the project required) helped me to master HTML and CSS in a way that made doing that work less tedious, and easier over time. I was being paid to be educated by an expert - I considered it a great opportunity, and believe I have been proven correct.

In the post Vasilis writes that they told their students the assignment "doesn’t have to be semantic and shit". I consider this a missed opportunity to hold them to higher standards and help the students build a strength that can help them for years to come. More broadly, I believe this to be an example of current generations being limited by their mentors and educators lowering standards, and potentially robbing them of opportunities. Impedimentum Via Est.

[itishappy]

I'd argue that the semantics of <bigcorp-career> vs <into-webdev-class> are different enough that it's a bit of an antipattern to apply the same style to each.

[threatofrain]

Even for text documents... for the love of documents, why wouldn't you have an official table of contents element?

Someone in a nearby thread mentioned custom elements. If we don't agree on meaning then it's not very semantic! Part of the power of agreement on semantics is that the more we have of it, the more we have things like Firefox or Safari's reader mode, which remolds the website to the user's desire.

[dieulot]

What would a specific table of contents element bring over a <nav> inside your <main>/<article>?

(As demonstrated in the first example of https://html.spec.whatwg.org/multipage/sections.html#the-nav...)

[extra88]

The heading hierarchy is the table of contents. Rather than some magic that creates a set of anchor links that link to the page's headings, I want browsers to provide what screen readers do, list the headings and let people keyboard navigate to them without site authors having to do anything.

"SkipTo Landmarks & Headings" is a browser extension that somewhat does what I'm describing. It's harder for an extension to handle this smoothly compared to a browser. https://skipto-landmarks-headings.github.io

[notpushkin]

> Take headings, for example: in component-based development, I often don't know (and shouldn't care) what level a heading is in my reusable widget, but I am forced to choose regardless.

We could have used <h1>s everywhere with Document Outline:

  <body>
    <h1>top level heading (parent sectioning element is body)</h1>
    <section>
      <h1>2nd level heading (nested within one sectioning element)</h1> 
      ...
    </section>
  </body>

Unfortunately, this was never implemented in browsers and was removed in HTML 5.1.

https://html5doctor.com/computer-says-no-to-html5-document-o...

[extra88]

As I mentioned in another comment, I think developers would have fucked up way too often and the hierarchy still wouldn't be right. Having the right heading levels is not something that can be solved by an algorithm, it depends on a human understanding of the content.

I agree that when developing a component, or even a discrete piece of content, you shouldn't have to care about its place in the heading hierarchy of whichever pages it appears on. But someone needs to care.

There's an HTML spec idea kicking around that's currently called `headinglevelstart`. I think the idea is you put it on an element like <section> and give it a value and the heading level of any heading element within is incremented by that amount; use `headinglevelstart="2"` and an <h1> within is treated as an h3, an <h2> as an h4, and so on (I think extending the valid heading levels from 6 to each least what ARIA supports, 9, is along for the ride). It can even be a negative value so an <h2> heading that's typically lots of other pages could be "elevated" when it's by itself on its own page by adding `headinglevelstart="-1"` to a parent.

I don't know if `headinglevelstart` is a particularly good idea or if it will happen but it's definitely an aspect of the web in need of improvement.

[chuckadams]

I usually just use <header> for section headers. Technically you’re supposed to put an h[1-6] tag inside a header tag, but I just drop the header text in there raw and style it with scoped CSS.

[dleeftink]

I think in part, it's also a case of there being some agreement on standard textual mark-up but not universally. And for good reason: books aren't journal articles, journal articles aren't poems, and heading and paragraph boundaries differ between languages.

Even practically, are sections part of articles? Or aticles part of sections in the context of a collection? Why do we need six heading levels, not four or seven? The semantic hierarchy does equally apply across publication contexts.

[tannhaeuser]

> The rules are clearly molded around static, primarily text-based documents defined upfront

I mean yeah, that‘s what the web was created for after all. There was no need to invent yet another operating system and desktop environment to replace the ones already existing. The advertising industry capturing the web and brainwashing one generation after another of „web developers“ locking in with said web developers seeing the web primarily as an economical niche to carve out and a means for job safety, is what happened. The end result is that the majority of actually interesting information you want to read is on archive.org nowadays, and on „platforms“ when easy self-publishing was the entire point of it.

Yes HTML is stuck being a markup language for casual academic publishing. Starting in 1997, people wanted to add entire new vocabularies, but W3C botched it by focussing too much on „meta“ stuff, subsetting XML from SGML but then not using it for actual emergent text formats apart from SVG and MathML such as blogs, drama, novels, wikis, etc. Instead they diverted into unproven XForms and SemWeb, leaving HTML in an organizational lock for ten years during the forming years such that everything else (CSS, JS) had to bend around HTML inflexibility, finally having the gall to call that failure a virtue (the structure-vs-presentation dichotomy, „semantic“ HTML, tunneling JSON through HTML, etc.).

[kaoD]

> There was no need to invent yet another operating system and desktop environment to replace the ones already existing.

Actually there was. My web apps can be used in Windows, Linux, Mac, Android, iOS, Meta Horizon OS, etc. thanks to it being a standard that is more or less not controlled or gatekept by a single entity (browser monoculture aside). Java applets died because of it.

You could argue that it wasn't wise to shoehorn interactive functionality in what was essentially a document presentation format, but that's another story. Having documents and applications intertwined is often cited as a drawback, but I disagree with that since we often want to have app-like behavior for parts of documents, or document-like behavior for parts of apps. Think e.g. interactive programming tutorials with executable REPLs and code examples... we have the ability to create books that are alive, and that's simply amazing.

Thing is, the Web platform is what won, and for good reasons. GTK, Java Swing, and other supposedly multiplatform toolkits did not lose just because -- they lost because the Web is objectively better.

HTTP is awesome. HTML is awesome. CSS is awesome. JS is awesome. JSON is awesome. WAI-ARIA is awesome. The whole web stack is awesome.

I feel that all the negative sentiment around it is just because we cannot fathom how much worse it could have been had the HTML5 effort never happened.

[the_other]

> I often don't know (and shouldn't care) what level a heading is in my reusable widget, but I am forced to choose regardless.

The sectioning algorithm proposed by early iterations of HTML5 mostly solved this and it’s a great shame browsers didn’t implement support for it.

[extra88]

I'm fine with it failing. I think in practice developers would have fucked up regularly so the hierarchy still wouldn't match the content.