6 ms·

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 frustrat

by _answ 2y ago

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.

emseetech 2y ago
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 2y ago
  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.
  - CraigJPerry 2y ago
    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.
    - Joeri 2y ago
      If you're interested in learning about this stuff, I recently made a website about it: https://plainvanillaweb.com/ https://plainvanillaweb.com/
      - majoe 2y ago
        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.
      - CraigJPerry 2y ago
        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.
        Joeri 2y ago
        I'll add it to the todo list :)
        1oooqooq 2y ago
        how every accessibility effort ends
    - mbo 2y ago
      this is a good article on styling with custom elements too: https://www.keithcirkel.co.uk/css-classes-considered-harmful/ https://www.keithcirkel.co.uk/css-classes-considered-harmful...
- arcanemachiner 2y ago
  Wait... I can just declare one of these in HTML without doing all the CustomElement JS jiggery-pokery?
  - xigoi 2y ago
    No need to declare anything, just use the tag.
    - simultsop 2y ago
      Sounds like you did not jump into the pool of flexibility and reusability.
      - lelanthran 2y ago
        > 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.
- jillesvangurp 2y ago
  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 2y ago
  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.
  - emseetech 2y ago
    Custom elements are for when semantic elements run out, don't apply or are unnecessary. Semantic elements are always preferred.
- _heimdall 2y ago
  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.
  - Joeri 2y ago
    Safari (Webkit) is the hold-out on having this: https://caniuse.com/mdn-api_customelementregistry_builtin_element_support 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#issuecomment-1328880274 https://github.com/WebKit/standards-positions/issues/97#issu...
    - _heimdall 2y ago
      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.
  - extra88 2y ago
    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_attributes/is https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...
dleeftink 2y ago
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.
threatofrain 2y ago
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 2y ago
  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-element https://html.spec.whatwg.org/multipage/sections.html#the-nav...)
  - threatofrain 2y ago
    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.
- extra88 2y ago
  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 https://skipto-landmarks-headings.github.io
tannhaeuser 2y ago
> 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 2y ago
  > 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 2y ago
> 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 2y ago
  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.
notpushkin 2y ago
> 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-outline/ https://html5doctor.com/computer-says-no-to-html5-document-o...
- chuckadams 2y ago
  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.
  - extra88 2y ago
    <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.
    - chuckadams 2y ago
      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.
magicink81 2y ago
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 2y ago
  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.

by _answ 2y ago

emseetech 2y ago

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 2y ago
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.
- CraigJPerry 2y ago
  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.
  - Joeri 2y ago
    If you're interested in learning about this stuff, I recently made a website about it: https://plainvanillaweb.com/ https://plainvanillaweb.com/
    - majoe 2y ago
      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.
    - CraigJPerry 2y ago
      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.
      - Joeri 2y ago
        I'll add it to the todo list :)
        1oooqooq 2y ago
        how every accessibility effort ends
  - mbo 2y ago
    this is a good article on styling with custom elements too: https://www.keithcirkel.co.uk/css-classes-considered-harmful/ https://www.keithcirkel.co.uk/css-classes-considered-harmful...
arcanemachiner 2y ago
Wait... I can just declare one of these in HTML without doing all the CustomElement JS jiggery-pokery?
- xigoi 2y ago
  No need to declare anything, just use the tag.
  - simultsop 2y ago
    Sounds like you did not jump into the pool of flexibility and reusability.
    - lelanthran 2y ago
      > 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.
jillesvangurp 2y ago
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 2y ago
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.
- emseetech 2y ago
  Custom elements are for when semantic elements run out, don't apply or are unnecessary. Semantic elements are always preferred.
_heimdall 2y ago
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.
- Joeri 2y ago
  Safari (Webkit) is the hold-out on having this: https://caniuse.com/mdn-api_customelementregistry_builtin_element_support 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#issuecomment-1328880274 https://github.com/WebKit/standards-positions/issues/97#issu...
  - _heimdall 2y ago
    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.
- extra88 2y ago
  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_attributes/is https://developer.mozilla.org/en-US/docs/Web/HTML/Global_att...

dleeftink 2y ago

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.

threatofrain 2y ago

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 2y ago
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-element https://html.spec.whatwg.org/multipage/sections.html#the-nav...)
- threatofrain 2y ago
  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.
extra88 2y ago
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 https://skipto-landmarks-headings.github.io

tannhaeuser 2y ago

> 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 2y ago
> 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 2y ago

> 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 2y ago
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.

notpushkin 2y ago

> 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-outline/ https://html5doctor.com/computer-says-no-to-html5-document-o...

chuckadams 2y ago
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.
- extra88 2y ago
  <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.
  - chuckadams 2y ago
    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.

magicink81 2y ago

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 2y ago
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.