A problem I find with Semantic HTML
I am making a dashboard website for a mobile game I enjoy. The problem I encountered with the lack of tags and I end up using too much <section> tags and not everything is a section but without it there is nothing else to use. Sure I use <header>, <nav>, <main>,<footer>, <section> but for example <article> is way too specific it's a dashboard not blog post or a cooking recipe and it doesn't have any headings.
So I am wondering there is NO SHOT screen readers gonna use it.
And is this even worth learning more, because the more I read it the more divs with class names and comments sounds less complex.
And semantics at this point is ironic because since html5 nothing about that has meaning, or rather it has meaning but the meaning is more specific rather being general.
Such as <item>, <container>, <content>,etc.
33 Replies
An
<article> does not have to be a piece of written text, like a blog post. It represents any element that makes sense on its own, like a product card or search result.
It can also have an identifier in the form of a heading tag (h1-h6), and can be nested multiple times if needed.
With more details about what you're trying to do it'd be easier to help out.
And semantics at this point is ironic because since html5 nothing about that has meaning, or rather it has meaning but the meaning is more specific rather being general.Well, of course it's going to have more specific tags, otherwise there would be no need to create more tags that are equally generic as a div. Speaking of divs, don't be afraid of using them, not every single element needs to be a precise description of its specific role. When in doubt, use div. You can always change it later.
When in doubt always using div well I am always in doubt.
So I am mostly using the very specific tags like main, nav, I use section for mostly related content based on main container and if there are no semantic I just use div with aria-label. For example:
Also I would change <article> to <content>
Use custom elements.
Sounds like you're overcomplicating it, you should have a basic layout e.g like this image. Inside all of those elements is loads of divs and other generic html.
Using semantic html isn't about excluding the use of divs, it's about including the use of semantic elements where it is relevant.
Take your basic all-div html, the main container of your header becomes header, the main container of your footer becomes footer etc, but the rest is fine.
If you inspect element on a big brand website like apple you'll see an in practice example of their HTML
If it's not any of the semantic elements you know, use a div :peeposhrug:
If you want help with it post your design and someone might help you understand how to lay it out semantically
I'd use custom elements for missing semantic elements. custom elements mean as much as divs, but are much more readable for the developer
I've never used custom elements, I would likely advise to stay away from them until you have a solid understanding of HTML instead of overcomplicating it
I would definitely not advise staying away from custom elements. They're just elements with a hyphen. You can name them semantically and they act layout-wise like span elements. Its not overcomplicating
Having divs everywhere makes the code less readable and therefore actually more complex (to understand)
I just hate that they're
display: inline; by default. You want block more often than inline.Jumping in just to be pedantic, but that sounds like non-standard elements, not custom elements.
A custom element, these days, is when you create a new element, and define it for the browser, which you'd do when making a web component.
And technically speaking, non-standard elements can run into issues as a browser might not treat them as expected. I think all browsers handle them the same these days, but that wasn't always the case, and there is nothing in the HTML standards to say how a non-standard element should be treated by the browser, so, at least in theory, you are leaving it up to chance that they'll all do the same thing (though, realistically, they aren't about to change this or anything). I also have no idea how assistive technologies will handle them either...
But as far as I know, custom elements are not non-standard. My information is that they are standardized and specified.
But let me prove it
It seems illogical that custom elements on their own wouldnt be spec conform. 1. There is no gurantee that the js that registers the component, ever loads or executes. In that case it cant be "okay" to have unspecified elements in your dom. And 2. All custom elements would always be unspecified until the javascript class executes, which, as stated in 1, is not guaranteed to happen.
Do you have a mockup design that you can share? Or maybe put something together quickly on codepen to have a rough idea of what the dashboard would look like.
Things like summarized stats e.g. hours of game play, number of quicksaves, etc, I would place in articles, since that's the kind of stuff that you can move around without losing context. A main area with a graph could be a section, whereas a navigation bar would be a nav. You can use asides for sidebars that don't necessarily have navigation purpose, popups, notifications or other details realted to the graph you are looking at currently.
I cant find a phrase in the specs that unambiguously specify hyphenated elements as standard, but neither can I find a phrase that unambiguously specifies custom elements without a javascript class to be non-standard...
Standard elements are those that are defined in the HTML standard, and none of them have hyphens.
Custom elements are elements created by the users using the
CustomElementRegistry API and (per the spec) are required to include a hyphen in the name.
Non-standard elements are…all the rest 🤷
You won't find a definintion of "non-standard" because it's, really, defined by not being defined, right?https://web.dev/articles/custom-elements-v1#misc_details
[...] The same is not true for custom elements. Potential custom elements are parsed as an HTMLElement if they're created with a valid name (includes a "-"). [...]
web.dev
Custom Elements v1 - Reusable Web Components | Articles | web.d...
Custom elements allow web developers to define new HTML tags, extend existing ones, and create reusable web components.
It seem like @Psyzen is getting a bit too hung up on "too many of the same element" (that's how I read it, anyway):
I end up using too much <section> tags and not everything is a section but without it there is nothing else to use.I find it best to read the MDN page on the
section element to get a good grasp on when to use it and when not.
First sentence:
The <section> HTML element represents a generic standalone section of a document, which doesn't have a more specific semantic element to represent it.
From there, check out the usage notes to see more examples of when to (not) use section. Basically, use div for styling-only purposes, article if that bit can be copy/pasted elsewhere with little-to-no context and still make sense by itself, main for the main section of the page, and section for most everything else.Well I just simply set nav on the left side vertically and the rest is main content. I used grid on body tag with grid-template-colums of min-content and 1fr
So the navigation takes min-content and the rest is for main.
And my website will never be scrolled vertically.
It also could be the lack of css knowledge more then HTML issue.
Especially since I am using grid. I create more html wrapper tags then needed. Tho I play around with grid-area: grid-row-start/ grid-column-start / grid-row-end / grid-column-end; + span
As a perfectionist I have trouble on deciding CSS properties order, HTML class naming(EXTREME HARD even with BEM). I used tailwind while it solved the issue of naming it made my html mumbo jumbo + repetitive atomic css.
Honestly the only thing I wish that there were some standard to write HTML classes much easier.
In my personal opinion as a beginner the naming of HTML classes is the biggest problem I have to climb over and once I do the CSS is very nice refreshing experience, almost like a puzzle and the names are preset 😄
According the the w3:
If we want our HTML page to work without Javascript, it should only be written with standard HTML elements (non-custom). During the loading of the page, certain elements can then be replaced by custom elements, like pollyfills.https://www.w3.org/community/html-dynamic-extensions/2023/07/20/custom-elements-and-unobstrusive-javascript
I did read it and it says sections should be used with headings and only with few exceptions not. But I do not need headings for anything.
You cant guarantee your javascript executes. That would mean that would always have to use this polyfill
Ok, then either use
divs. Or use sections and know that your site is one of the exceptions talked aboutFair point.
Sections are, easily, the most frustrating semantic element because they are essentially a div, unless you use aria... Semantics are very frustrating, but that sort of goes with the territory of defining language
Frontend compared to backend is a nightmare for me 😂
Thank you for everyones suggestions, tips and tricks.
This is not official though. Its a community post.
for anyone who wants to follow me and Wonderbear's convo, I moved it off to it's own discussion: https://discord.com/channels/436251713830125568/1205156917551308800
There is a lot more wiggle room with a lot of front-end stuff, lol.
HTML is easy, until all of a sudden it's not 😅. It might not help, but you might enjoy this article about semantics: https://thinkdobecreate.com/articles/a-call-for-consensus-on-html-semantics/
A Call for Consensus on HTML Semantics | Stephanie Eckles
HTML is supposed to be easy to learn. And sure, the basics are pretty clear, but how are we supposed to make the "right" choice in nuanced situations?
Thank you very much.
The first I think I saw is <a> vs <button> great another issue made me remember.
Also why not <input type="submit" /> 🙂
On the
a vs button it's super simple: links take you to other pages (or other locations within the same page) while buttons are interactive elements that don't change the location of the page.
hashtag-sorryNotSorry but a/button arguments boil my blood (as someone who actually cares about semantics and using helpful code instead of lazy-ass code)Well then sorry because I am using button for everything haha I will change to a.
I know the input version is used for forms but even then should you use input vs button.
Can you explaind me more where would you use button ?
Is this something like a use case for dynamic js like moving object but can be clicked which makes them to be selected like an item ?
So far I understand that <a> tag is for redirecting and <button> for non-redirecting dynamic styling.
@Kevin
This is exactly what I was thinking:
You'll find a few opinions on each of these things (particularly section vs article) but my point is that it's never clear cut and certainly not simple. Oh look, a dashboard has entered the chat.Why can't we just instead tag to have classes as tags so I could write <kevin>I really like your Youtube Channel.</kevin> and then we could use it as .kevin { background: lightcoral; } So in this way we wouldn't need to worry about which tags to use rather focus on naming that both will server as class and an html tag with actual meaning.
Thats literally what custom elements offer
Interesting.
Custom elements must have at least one hyphen somehwere in their name and cant be self closing, eg.
<custom-kevin /> is not allowed and will produce unexpected behaviour.
Other than that, they're default display style is inline, so they initially act like <span> elements layout-wise. But you can adjust this with css.
Just to be explicitly clear: keep in mind though, that these elements are not officially spec conform unless you add an unused line of javascript code. But thats just technical details and nothing you have to worry about. You can easily use custom elements without any javascript.Thanks.