Hacker News Reader

Comment by _answ | Hacker News Reader

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.

View on HN

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>

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.

I didn’t know any of this.

I feel like a huge door just opened on an idle Saturday morning. I need to experiment to form some opinions.

Thank you & parent poster too.

If you're interested in learning about this stuff, I recently made a website about it: https://plainvanillaweb.com/

This was recently posted to HN and I started to read it. I think your explanation for web components is the best I encountered so far.

That site is good - i might have missed it in your site but one thing I’ve run into with custom elements today is accessibility - testing with a screen reader has shown up lots of issues. Maybe custom elements aren’t perfect but they are handy.

I'll add it to the todo list :)

how every accessibility effort ends

this is a good article on styling with custom elements too: https://www.keithcirkel.co.uk/css-classes-considered-harmful...

While I believe you are entirely right from a developer perspective. I do wonder if the same is true from a UX and more specifically accessibility perspective as the author in the article describes.

If you are unsure what I mean, from the article

> I show them that a span with an onclick-event might seem to be behaving like a link, but that there are many layers of UX missing when you look a bit closer: right-click on this span, and a generic context menu opens up. When on the other hand you right-click on a proper link like this one a specialised context menu opens, with all kinds of options that are specific to a link. And I show them that proper links show up when you ask your screen reader to list all the links on a page, yet spans with an onclick-event don’t. Moreover, a span doesn’t receive focus when you tab to it. And so on. My students see this and they get it. And they love the fact that by being lazy they get much more result.

Accessibility will rely on correct use of landmarks [1] and aria attributes, as well as real links (like the article mentions). Custom elements can do that just fine, by either decorating them with aria attributes manually and placing them in or around landmark elements, or by having the JS side of the custom element take care of that automatically. The JS class can generate any necessary markup inside of the element to help make it accessible, just like a component built with a JS framework would, and by using shadow dom and slots this markup can wrap around the child elements (though I think it's best to try to avoid shadow dom, as it is quite a cumbersome API to deal with). UX is a bit of a similar story, any kind of UX can be achieved once you register a JS class for the custom element.

[1] https://developer.mozilla.org/en-US/blog/aria-accessibility-...

I didn't know this was possible. I thought you were forced to use Javascript to define a custom element - this severely reduced its attractiveness. Why use JS for static UI ?

I don't know why custom elements never became common knowledge. I've had PR's blocked by people convinced I was doing arcane black magic by using them.

But they've been worked this way for decades. Now they weren't officially added to the spec until browser support for v1 of custom components, but that was still back in 2016.

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

No need to declare anything, just use the tag.

Sounds like you did not jump into the pool of flexibility and reusability.

> Sounds like you did not jump into the pool of flexibility and reusability.

Quite a good analogy: a pool is responsible for more drownings than you'd think.

Most people in the pool of flexibility and reusability are drowning in it.

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

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.

Custom elements are for when semantic elements run out, don't apply or are unnecessary.

Semantic elements are always preferred.

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.

Safari (Webkit) is the hold-out on having this: https://caniuse.com/mdn-api_customelementregistry_builtin_el...

The reasoning for choosing not to support it is here: https://github.com/WebKit/standards-positions/issues/97#issu...

Thanks! I was pretty sure Safari was the only major holdout but didn't have a link handy and didn't want to speak out of turn there.

That kind of support is a really tough one to work around with a major browser lacking support. For certain features its not a big deal, but when it comes to extending to get full accessibility support the only substitute is avoiding the feature and rolling it all custom. It really is a shame in my opinion, extending built-ins is extremely powerful.

Blame Safari. The standard includes the `is` attribute, it's supported by all browsers except Safari, but Safari not only hasn't worked on supporting it, they've stated they won't do so.

https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...

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.

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.

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.

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...)

I'd look to what Wikipedia provides as a document reading experience. The problem with nav is that there weren't enough tags so developers will rightly use them for other things, such as breadcrumbs. I'm looking for exclusive ToC that will allow reader mode to go further.

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

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

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.

<header> and headings are very different. A heading is how you semantically signpost the beginning of a different section of content. A <header> other than one at the beginning of a page, is basically a DX convenience.

Headings are the major way people using assistive technologies can skim a page and navigate around. I think a <header> will still be treated as a landmark, even if it's inside other landmark elements, but it will be nameless so not nearly as useful.

It can be a struggle for some people in some situations to create pages with a heading level hierarchy that accurately reflects the content. Sometimes I think when there's any difficulty, authors should basically give up and follow a simple guideline: have one <h1> that says what the page is about and use <h2> for all the other headings.

The words put inside the headings are far more important than the accuracy of the heading level.

It looks like <header> is treated specially when it’s directly under the <body> tag, but generic everywhere else. This is actually what I want for some widgets which may be arbitrarily nested and aren’t really contributing to a hierarchy, but not others where I would want to be able to navigate between the sections using the headings. I like the idea of just using <h2> for all depths below the very top, I think I’ll start doing that for headers that should be navigation targets.

Edit: looks like that’s basically the WAI approach too, in that role=heading will default to aria-depth=2.

Yes, my recollection was wrong. There are some landmarks that can be nested inside other landmarks and still be conveyed but <header> (ARIA role "banner") isn't one of them.

Using <header> elsewhere for developer convenience is fine but that's all it is.

Headings are especially helpful for screen reader users are especially helpful but their value for sighted users are often underestimated. Developers think that by putting something in a box and by its styling that people will understand what it is, what it's for, when using a heading to put a name on it would be very clarifying.

horrific ux. makes html harder to read for people that dont have the time to learn all this obscure bs.

and for screenreaders this will work maybe sometimes inconsistently. I hope visual llms solve it for our brothers and sisters with special needs. ( and for webscrapers)

BECAUSE THIS NONSENSE IS NOT SOLVING ANYTHING FOR ANYBODY

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.

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.

> 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.).

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

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

To be honest I consider Java Swing better than current "fancy web UI". At least it's more consistent and at least try to match the OS... I loath the "creative bunch" that tries to re-invent the wheel and be all flashy and whatnot.

Every app should try to match to the best possible way native OS. Yes, it's not possible 100% of the way but it would go a long way.

Currently we live in a world led by brainded bunch of "let's care about brand" and try to have same UI on all platforms as if users were switching constantly between windows/mac/linux or between iphone/android... no, they don't. At least in the mobile space they do try to be more native-looking and follow the theme but it's not all that great either.

Also. Java/Swing loose (especially on the desktop) because it was slow at the time and wasn't open like "web". Besides learning curve for the web was easier (hey, you can open web console, write `alert('bam!')` and it DOES stuff, wild!... and then it went downhill from there...

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

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.

Reply on news.ycombinator.com