11 ms·

The right tag for the job: why you should use semantic HTML

184 points by tmfi 5y ago

throw_m239339 5y ago
CTRL+F "microdata": no result. Yeah, I thought so too... The Semantic web has failed. ARIA tags are important for accessibility though, but semantic HTML has been irrelevant for a decade, I haven't seen a single successful product based on that or a single use case that yielded something interesting SEO wise.
- eyelidlessness 5y ago
  Oddly, I had to use microdata to fix reader mode on my site recently.
- extra88 5y ago
  Using semantic HTML in web authoring is not the same as the concept of the “semantic web” [0]. The article makes it clear what it is about and it’s not about the goals of the semantic web. [0] https://en.m.wikipedia.org/wiki/Semantic_Web https://en.m.wikipedia.org/wiki/Semantic_Web
- chipotle_coyote 5y ago
  The article, and the comments on the article here, and even the ARIA documentation itself as quoted in comments explain why semantic HTML is important to accessibility. "Yeah, but it doesn't yield something interesting SEO-wise" leads us to make web sites that are trash fires, and not just from an accessibility standpoint.
  - deleted 5y ago
    [deleted]
- crazygringo 5y ago
  It's very unfortunate that the term "semantic" is overloaded -- the "semantic" web you're referring to which I agree was basically a total failure, but also "semantic" HTML which is used for accessibility, essentially as a shortcut for ARIA tags. I think it's led to a lot of confusion, especially since it's often not clear which purpose is being referred to in a context.
  - worik 5y ago
    "semantic" is not overloaded in this case. It has the same meaning in both cases
- ctoth 5y ago
  Semantic HTML != ARIA tags. Also, isn't the semantic web the reason that we get things like link previews with titles and content and images and... Considering [0] is a SEO website, and it was in the top three for my search for og:title I'd say the problem is rather that SEO infected the whole thing, not that it's not useful to SEO. [0]: https://seosetups.com/open-graph/ https://seosetups.com/open-graph/
willeh 5y ago
Most of the heavy lifting in accessibility is in the ARIA attributes and being thoughtful about actually including those. The problem faced by semantic tags is that not all websites use them and that the information that they carry is of very limited use for a screen reader. A section-element without any other information is just a div. Unfortunately adding semantic information to website has gone from a promising avenue for building websites usable from many different kinds to part of the SEO cat-and-mouse game played by Google et al. Unless you're doing SEO, everything semantic is just a distraction. That said do take accessibility seriously, it will never be justified by profits but doing the right thing is a feeling no amount of money can buy.
- wwweston 5y ago
  > Unless you're doing SEO, everything semantic is just a distraction Accessibility and SEO are (usually) desirable system effects that rely on meaningful semantic code-inputs to the system. But that doesn't mean that only software system effects matter, and everything else is a distraction. Consider that when you're programming your various identifiers -- the names of variables, functions, classes, types that you choose -- are largely without any semantics to your system. To the computer, they're simply keys. And yet we sometimes say that one of two the hard/important problems in computer science (besides cache invalidation) is naming things. Why? Because the actual system isn't just the software & machine. The system includes the developers groking and shaping the software. And names and their relationship with domain concepts matter to people and help them manage their work. I've found that the first benefit to semantic markup -- not necessarily the most important, but the first -- is helping me better conceptualize the domain and my code. It functions as an orientation anchor when I'm working with components that look different between their source and rendered as part of a sprawling document in the browser. And it helps me get reoriented faster when I've been away from it for days/weeks/months. The heart of "semantic" anything is the idea that code is for people too. Maybe not all people, but definitely at least anyone who's writing it.
- eyelidlessness 5y ago
  > Most of the heavy lifting in accessibility is in the ARIA attributes and being thoughtful about actually including those This isn’t true. Semantic HTML is also very important, often more so. > Unless you're doing SEO, everything semantic is just a distraction. This is also not true. Besides actively harming accessibility (or making it substantially more difficult to improve), non-semantic HTML also breaks Reader Mode. And it can also add cognitive burden to maintenance and future feature work.
runawaybottle 5y ago
Oddly enough, I think semantic HTML might be more important for React developers than anyone else. React developers are very vulnerable to creating copious amount of abstract components due to the freedom composability gives you. Over time, it’s possible different people literally speak different languages (even in the same codebase) because of how they see the structure of tags. Thinking in Semantic HTML might help normalize the variances.
- jeroenhd 5y ago
  I've run into some bugs because of composition, something about <a> tags nesting breaking everything, but only in release mode (minified etc.). Not fun to hunt down. I don't remember the details, but I've also seen warnings about other semantic stuff that's enforced (it at least complained about) by the framework. Technically you could make everything a div or a text element, but most frameworks you use come with certain expectations: the closer you are to using semantic tags, the less likely you'll be to violate those external expectations. If you're not using any frameworks, I don't see why you wouldn't use semantic tags by default. Sure, you can override the onclick if an anchor with no href and call preventDefault, but why not just use a button instead?
chrisjshull 5y ago
For all those saying that ARIA trumps semantic elements, consider that for basic interactions semantic elements come out of the box keyboard accessible. For example, a <button> will have default tabindex=0 and respond to spacebar key presses, but you'd have to add that yourself if you put role=button on a <div>. In short, if there is a semantic element that matches your need, use it.
- extra88 5y ago
  > In short, if there is a semantic element that matches your need, use it. Yes! This is known as The First Rule of ARIA.
- admax88q 5y ago
  If the browser would make the semantic elements actually look good out of the box a lot of developers would use them by default.
  - shadowofneptune 5y ago
    It would be equal effort to restyle something done with ARIA compared to a semantic element, yes?
    - admax88q 5y ago
      Depends on the element, the select and input elements are notoriously difficult to style, which is why people often remake them with divs and JS. Combo boxes are a fucking nightmare to style, as are checkboxes and radios. Buttons arnt as bad, but you still spend a lot of time fighting against browser defaults which differ across browsers.
  - pjc50 5y ago
    Isn't that an extremely moving target? What looks good is very subject to changes of fashion. Your comment below about being difficult to style is more to the point.
  - anoncake 5y ago
drummer 5y ago
Excellent article thanks for sharing
aimor 5y ago
The better control I have over styling the more empowered I feel to use semantic HTML. It was frustrating, years ago, to jump on board wide eyed only to realize that styling is a minefield. I believe this is much improved today.
coldtea 5y ago
I don't see any reason to use semantic HTML. It's cargo cult. At some point web designers (at the time in the early 00s web development was not as involved as it has been post Ajax) learned the term "semantic" and went wild with it (made you sound smart, and you could charge a little more than the unsophisticated shop down the road), without understanding the science behind data. Instead we should have separation of concerns, with structured raw information (you know, like what we have in our relational and document databases), served with different represenations: for accessibility, for data access, for web, for syndication, for print, for reading devices, and so on. Of course the web being the web, it needed to make this too in the most inefficient and multi-layered way (and leave it up to the web designers/devs to have "proper" semantic tags).
Animats 5y ago
Here's Google's test page for "canvas rendering".[1] Try that with a screen reader. [1] https://docs.google.com/document/d/1N1XaAI4ZlCUHNWJBXJUBFjxSTlsD5XctCz6LB3Calcg/preview https://docs.google.com/document/d/1N1XaAI4ZlCUHNWJBXJUBFjxS...
- pimlottc 5y ago
  Wow, that's really interesting, thanks for the link. It looks great, but it's kind of a jolt to right-click on a selection and not see the normal browser context menu...
  - Vinnl 5y ago
    And right-clicking without selecting anything not even popping anything up at all. And hovering over a link not turning the pointer into the link icon. And not being able to <Tab> through links.
    - saagarjha 5y ago
      I just opened this on my iPad and it feels pretty bad to use.
brutal_chaos_ 5y ago
Protip: Semantic HTML != Semantic Web Accessibility is important, learn this stuff!
LAC-Tech 5y ago
I think HTML is considered too challenging or 'low level' in modern front end development. Components are created with material UI, or bootstrap. No one seems to be doing it by hand. I like coding html (and css) by hand. I find it easier to do that than to deal with frameworks and tooling. So I read articles like this and often find something new (TIL about fieldset). But I've yet to see anyone else do this professionally. So I don't think most people will ever care about this stuff, in the face of modern "best practices". It's just going to be nested div soup, from here on out.
- notjustanymike 5y ago
  I just went through an ADA compliance audit and we got dinged pretty hard for semantic markup inconsistency. It's certainly become more common in production apps, much like making things SEO optimized before. Keep doing real HTML, it's still important!
- eating555 5y ago
  I write html by hand as well but I still prefer to use div as general block tag. It's just because I want it be difficult for bots to crawl XD
- brundolf 5y ago
  Bootstrap is just CSS, though? You still have to write your HTML (or JSX) by hand I haven't seen much to back up your view of things
  - LAC-Tech 5y ago
    Misspoke slightly. I'm thinking back to my experience of a bootstrap in react package. The HTML it produced was meaningless.
The_Amp_Walrus 5y ago
An article like this, comes up every few months. They tend to give an intro to the technical how-to but miss the step of convincing the readers that supporting screen readers is desirable. Ok sure, it'd be _nice_ if blind people could navigate my website. But... how nice? How many screenreaders can I reasonably expect as a % of traffic? What difference will it make to their quality of life? What decision process should I use to decide if _my_ website needs to support this? Does my personal blog to support a screen reader? What about this bank login page? This motivating information is a cruicual step in actually getting people to care enough to do something different. A contrasting example is the discourse on "bloated" webpages being slow and hard to use on shitty old phones. The upshot is that if your website needs to download and run 1MB of JavaScript then someone viewing it on a 5 year old low cost smartphone on a crappy 3G is going to have a bad time. The statistics around how many people have bad internet motivated me to try and reduce download sizes. It would also be nice to have a guide on convincing your boss to give you time to support accessibility. The technical details are good (and this article is quite readable) but probably aren't the key bottleneck in more people writing accessible markup. <edited for less unnecessary snark>
- madeofpalk 5y ago
  Yes badgering developers to do such onerous things like… use a <button> element for buttons. Rather than ask "why should I support screen readers" maybe ask "why would I actively break them and make my website unusable?"
  - The_Amp_Walrus 5y ago
    Writing HTML/CSS is one of the hardest and most frustrating things I've done as a programmer. It sucks. I would actively break my website to get the job done without losing my mind. I would need to be very _motivated_ to change my behaviour. I amended my comment to be less snarky I was coming on a bit to strong.
    - madeofpalk 5y ago
      "Just" learn the tools you're using.
makeupsomething 5y ago
I don't need to be convinced of the benefits of semantic HTML anymore. It's been made clear in numerous similar articles. What I would like to see are examples that are not trivial news/blog type apps.
- burntcaramel 5y ago
  What sort of apps do you think are difficult to get right, and would make good examples?
  - makeupsomething 5y ago
    I think something like a google maps type app where the results in the sidebar can be a fairly complex set of items would be great to see. Or a typical SaaS app dashboard with cards, a sidebar, charts etc.
- blacktriangle 5y ago
  The problem is that the semantics of HTML are the semantics of trivial news/blogs. Didn't they say that when HTML5 came out that many of the tag names and concepts were distilled by looking at the frequency of class names used across the internet, and isn't most of the open, indexable internet blogs and forums. The semantics of the web and the semantics of an application are almost completely different, so those of us trying to ship actual applications over the web are torn between trying to find the closest possible HTML element and customizing it, resulting in non-standard behavior, or just rolling our own div with our own needs.
dgb23 5y ago
The demonstration is neat and the advice is sound. One thing that rarely gets mentioned however is that well structured HTML, including templates and JSX, is easier to develop with. Semantic tags at least give you common consistency for free. Adhering to some reasonable degree of consistency is the bare minimum we should aim for in respect to code readability.
axilmar 5y ago
Instead of using special tags to convey meaning, couldn't we just use special attributes? say, a div tag with an 'aria-role' attribute set to menu would indicate a menu, a div tag with an 'aria-role' attribute set to 'checkbox' would indicate a checkbox etc. That would make creation of visual elements more versatile, keep the number of hacks to minimum (like the hidden input trick for checkboxes), and also make ARIA possible.
- extra88 5y ago
  Adding an ARIA role only adds the role, you'd then have to add more to name the element (in place of the missing <label>), to put the element in the tab order, and JavaScript event listeners to handle keyboard input correctly. Doing all that is more complex than using a style reset on an input element and even if you do it all correctly, it's less robust.
kevincox 5y ago
I wish there was a way to tell the browser to add more default styles to my document. For example we have reader mode but this completely munges your document and kills all custom styles and scripts. It would be cool if you could tell the browser to apply a nice pretty style (customizable by the user of course) but then possibly opt out small sections of the page (like an interactive example) where you could add custom scrips and styles. Obviously this works best with simple "document" websites but it always seems so weird telling the browser how to style the document when I know very little about the user or the device. It is getting "better" in a way with media queries for information about the device and user preference (like dark/light colour scheme) but it still is relying on each site to interpret those settings themselves, and progress is slow because everything needs to be standardized. This also opens the door to a "clean" mode with no default borders, margins, padding, sizes, styles which would help when making interfaces where you want to control every pixel and don't want to be surprised in differences in default browser style sheets.
- extra88 5y ago
  > I wish there was a way to tell the browser to add more default styles to my document. Non-Chrome browsers still have modifiable user stylesheets (though I think only Safari for Mac still has a GUI option to do it) but more realistically, you can use a browser extension like Stylus to apply your own styles, even defining them on a per-domain basis. Enabling the user to change the appearance of your site is much easier if you heed the advice of this article and use the appropriate semantic HTML. > "clean" mode with no default borders, margins, padding, sizes, styles Web developers have been starting projects with "reset" stylesheets for decades.
  - kevincox 5y ago
    > Non-Chrome browsers still have modifiable user stylesheets This doesn't solve the problem I describe because it breaks websites (unless you are very minimal with your usage). I am talking about an opt-in feature where you concede control to the browser so that it can apply "aggressive" styles such as it would for reader mode. For example changing the current usage-agent style sheet to a "dark theme" is completely infeasible to ship as it would break way too many sites. Furthermore just being possible isn't enough. It would also need to provide nice defaults to make this a feasible proposition at all. I can't have my blog being barely readable for 99% of viewers. > even defining them on a per-domain basis. I also don't want to fix specific websites. I'm talking about something that works by default. (Of course site-specific tweaks are nice, but that is nearly orthogonal to what I am looking for here.) > Web developers have been starting projects with "reset" stylesheets for decades. Yes, and this is an unfortunate hack. It would be nice to remove the necessity to remove the need for these and remove the maintenance required (even if the cost of both is small).

184 points by tmfi 5y ago

CTRL+F "microdata": no result. Yeah, I thought so too... The Semantic web has failed. ARIA tags are important for accessibility though, but semantic HTML has been irrelevant for a decade, I haven't seen a single successful product based on that or a single use case that yielded something interesting SEO wise.

eyelidlessness 5y ago
Oddly, I had to use microdata to fix reader mode on my site recently.
extra88 5y ago
Using semantic HTML in web authoring is not the same as the concept of the “semantic web” [0]. The article makes it clear what it is about and it’s not about the goals of the semantic web. [0] https://en.m.wikipedia.org/wiki/Semantic_Web https://en.m.wikipedia.org/wiki/Semantic_Web
chipotle_coyote 5y ago
The article, and the comments on the article here, and even the ARIA documentation itself as quoted in comments explain why semantic HTML is important to accessibility. "Yeah, but it doesn't yield something interesting SEO-wise" leads us to make web sites that are trash fires, and not just from an accessibility standpoint.
- deleted 5y ago
  [deleted]
crazygringo 5y ago
It's very unfortunate that the term "semantic" is overloaded -- the "semantic" web you're referring to which I agree was basically a total failure, but also "semantic" HTML which is used for accessibility, essentially as a shortcut for ARIA tags. I think it's led to a lot of confusion, especially since it's often not clear which purpose is being referred to in a context.
- worik 5y ago
  "semantic" is not overloaded in this case. It has the same meaning in both cases
ctoth 5y ago
Semantic HTML != ARIA tags. Also, isn't the semantic web the reason that we get things like link previews with titles and content and images and... Considering [0] is a SEO website, and it was in the top three for my search for og:title I'd say the problem is rather that SEO infected the whole thing, not that it's not useful to SEO. [0]: https://seosetups.com/open-graph/ https://seosetups.com/open-graph/

willeh 5y ago

Most of the heavy lifting in accessibility is in the ARIA attributes and being thoughtful about actually including those. The problem faced by semantic tags is that not all websites use them and that the information that they carry is of very limited use for a screen reader. A section-element without any other information is just a div. Unfortunately adding semantic information to website has gone from a promising avenue for building websites usable from many different kinds to part of the SEO cat-and-mouse game played by Google et al. Unless you're doing SEO, everything semantic is just a distraction. That said do take accessibility seriously, it will never be justified by profits but doing the right thing is a feeling no amount of money can buy.

wwweston 5y ago
> Unless you're doing SEO, everything semantic is just a distraction Accessibility and SEO are (usually) desirable system effects that rely on meaningful semantic code-inputs to the system. But that doesn't mean that only software system effects matter, and everything else is a distraction. Consider that when you're programming your various identifiers -- the names of variables, functions, classes, types that you choose -- are largely without any semantics to your system. To the computer, they're simply keys. And yet we sometimes say that one of two the hard/important problems in computer science (besides cache invalidation) is naming things. Why? Because the actual system isn't just the software & machine. The system includes the developers groking and shaping the software. And names and their relationship with domain concepts matter to people and help them manage their work. I've found that the first benefit to semantic markup -- not necessarily the most important, but the first -- is helping me better conceptualize the domain and my code. It functions as an orientation anchor when I'm working with components that look different between their source and rendered as part of a sprawling document in the browser. And it helps me get reoriented faster when I've been away from it for days/weeks/months. The heart of "semantic" anything is the idea that code is for people too. Maybe not all people, but definitely at least anyone who's writing it.
eyelidlessness 5y ago
> Most of the heavy lifting in accessibility is in the ARIA attributes and being thoughtful about actually including those This isn’t true. Semantic HTML is also very important, often more so. > Unless you're doing SEO, everything semantic is just a distraction. This is also not true. Besides actively harming accessibility (or making it substantially more difficult to improve), non-semantic HTML also breaks Reader Mode. And it can also add cognitive burden to maintenance and future feature work.

runawaybottle 5y ago

Oddly enough, I think semantic HTML might be more important for React developers than anyone else. React developers are very vulnerable to creating copious amount of abstract components due to the freedom composability gives you. Over time, it’s possible different people literally speak different languages (even in the same codebase) because of how they see the structure of tags. Thinking in Semantic HTML might help normalize the variances.

jeroenhd 5y ago
I've run into some bugs because of composition, something about <a> tags nesting breaking everything, but only in release mode (minified etc.). Not fun to hunt down. I don't remember the details, but I've also seen warnings about other semantic stuff that's enforced (it at least complained about) by the framework. Technically you could make everything a div or a text element, but most frameworks you use come with certain expectations: the closer you are to using semantic tags, the less likely you'll be to violate those external expectations. If you're not using any frameworks, I don't see why you wouldn't use semantic tags by default. Sure, you can override the onclick if an anchor with no href and call preventDefault, but why not just use a button instead?

chrisjshull 5y ago

For all those saying that ARIA trumps semantic elements, consider that for basic interactions semantic elements come out of the box keyboard accessible. For example, a <button> will have default tabindex=0 and respond to spacebar key presses, but you'd have to add that yourself if you put role=button on a <div>. In short, if there is a semantic element that matches your need, use it.

extra88 5y ago
> In short, if there is a semantic element that matches your need, use it. Yes! This is known as The First Rule of ARIA.
admax88q 5y ago
If the browser would make the semantic elements actually look good out of the box a lot of developers would use them by default.
- shadowofneptune 5y ago
  It would be equal effort to restyle something done with ARIA compared to a semantic element, yes?
  - admax88q 5y ago
    Depends on the element, the select and input elements are notoriously difficult to style, which is why people often remake them with divs and JS. Combo boxes are a fucking nightmare to style, as are checkboxes and radios. Buttons arnt as bad, but you still spend a lot of time fighting against browser defaults which differ across browsers.
- pjc50 5y ago
  Isn't that an extremely moving target? What looks good is very subject to changes of fashion. Your comment below about being difficult to style is more to the point.
- anoncake 5y ago

drummer 5y ago

Excellent article thanks for sharing

aimor 5y ago

The better control I have over styling the more empowered I feel to use semantic HTML. It was frustrating, years ago, to jump on board wide eyed only to realize that styling is a minefield. I believe this is much improved today.

coldtea 5y ago

I don't see any reason to use semantic HTML. It's cargo cult. At some point web designers (at the time in the early 00s web development was not as involved as it has been post Ajax) learned the term "semantic" and went wild with it (made you sound smart, and you could charge a little more than the unsophisticated shop down the road), without understanding the science behind data. Instead we should have separation of concerns, with structured raw information (you know, like what we have in our relational and document databases), served with different represenations: for accessibility, for data access, for web, for syndication, for print, for reading devices, and so on. Of course the web being the web, it needed to make this too in the most inefficient and multi-layered way (and leave it up to the web designers/devs to have "proper" semantic tags).

Animats 5y ago

Here's Google's test page for "canvas rendering".[1] Try that with a screen reader. [1] https://docs.google.com/document/d/1N1XaAI4ZlCUHNWJBXJUBFjxSTlsD5XctCz6LB3Calcg/preview https://docs.google.com/document/d/1N1XaAI4ZlCUHNWJBXJUBFjxS...

pimlottc 5y ago
Wow, that's really interesting, thanks for the link. It looks great, but it's kind of a jolt to right-click on a selection and not see the normal browser context menu...
- Vinnl 5y ago
  And right-clicking without selecting anything not even popping anything up at all. And hovering over a link not turning the pointer into the link icon. And not being able to <Tab> through links.
  - saagarjha 5y ago
    I just opened this on my iPad and it feels pretty bad to use.

brutal_chaos_ 5y ago

Protip: Semantic HTML != Semantic Web Accessibility is important, learn this stuff!

LAC-Tech 5y ago

I think HTML is considered too challenging or 'low level' in modern front end development. Components are created with material UI, or bootstrap. No one seems to be doing it by hand. I like coding html (and css) by hand. I find it easier to do that than to deal with frameworks and tooling. So I read articles like this and often find something new (TIL about fieldset). But I've yet to see anyone else do this professionally. So I don't think most people will ever care about this stuff, in the face of modern "best practices". It's just going to be nested div soup, from here on out.

notjustanymike 5y ago
I just went through an ADA compliance audit and we got dinged pretty hard for semantic markup inconsistency. It's certainly become more common in production apps, much like making things SEO optimized before. Keep doing real HTML, it's still important!
eating555 5y ago
I write html by hand as well but I still prefer to use div as general block tag. It's just because I want it be difficult for bots to crawl XD
brundolf 5y ago
Bootstrap is just CSS, though? You still have to write your HTML (or JSX) by hand I haven't seen much to back up your view of things
- LAC-Tech 5y ago
  Misspoke slightly. I'm thinking back to my experience of a bootstrap in react package. The HTML it produced was meaningless.

The_Amp_Walrus 5y ago

An article like this, comes up every few months. They tend to give an intro to the technical how-to but miss the step of convincing the readers that supporting screen readers is desirable. Ok sure, it'd be _nice_ if blind people could navigate my website. But... how nice? How many screenreaders can I reasonably expect as a % of traffic? What difference will it make to their quality of life? What decision process should I use to decide if _my_ website needs to support this? Does my personal blog to support a screen reader? What about this bank login page? This motivating information is a cruicual step in actually getting people to care enough to do something different. A contrasting example is the discourse on "bloated" webpages being slow and hard to use on shitty old phones. The upshot is that if your website needs to download and run 1MB of JavaScript then someone viewing it on a 5 year old low cost smartphone on a crappy 3G is going to have a bad time. The statistics around how many people have bad internet motivated me to try and reduce download sizes. It would also be nice to have a guide on convincing your boss to give you time to support accessibility. The technical details are good (and this article is quite readable) but probably aren't the key bottleneck in more people writing accessible markup. <edited for less unnecessary snark>

madeofpalk 5y ago
Yes badgering developers to do such onerous things like… use a <button> element for buttons. Rather than ask "why should I support screen readers" maybe ask "why would I actively break them and make my website unusable?"
- The_Amp_Walrus 5y ago
  Writing HTML/CSS is one of the hardest and most frustrating things I've done as a programmer. It sucks. I would actively break my website to get the job done without losing my mind. I would need to be very _motivated_ to change my behaviour. I amended my comment to be less snarky I was coming on a bit to strong.
  - madeofpalk 5y ago
    "Just" learn the tools you're using.

makeupsomething 5y ago

I don't need to be convinced of the benefits of semantic HTML anymore. It's been made clear in numerous similar articles. What I would like to see are examples that are not trivial news/blog type apps.

burntcaramel 5y ago
What sort of apps do you think are difficult to get right, and would make good examples?
- makeupsomething 5y ago
  I think something like a google maps type app where the results in the sidebar can be a fairly complex set of items would be great to see. Or a typical SaaS app dashboard with cards, a sidebar, charts etc.
blacktriangle 5y ago
The problem is that the semantics of HTML are the semantics of trivial news/blogs. Didn't they say that when HTML5 came out that many of the tag names and concepts were distilled by looking at the frequency of class names used across the internet, and isn't most of the open, indexable internet blogs and forums. The semantics of the web and the semantics of an application are almost completely different, so those of us trying to ship actual applications over the web are torn between trying to find the closest possible HTML element and customizing it, resulting in non-standard behavior, or just rolling our own div with our own needs.

dgb23 5y ago

The demonstration is neat and the advice is sound. One thing that rarely gets mentioned however is that well structured HTML, including templates and JSX, is easier to develop with. Semantic tags at least give you common consistency for free. Adhering to some reasonable degree of consistency is the bare minimum we should aim for in respect to code readability.

axilmar 5y ago

Instead of using special tags to convey meaning, couldn't we just use special attributes? say, a div tag with an 'aria-role' attribute set to menu would indicate a menu, a div tag with an 'aria-role' attribute set to 'checkbox' would indicate a checkbox etc. That would make creation of visual elements more versatile, keep the number of hacks to minimum (like the hidden input trick for checkboxes), and also make ARIA possible.

extra88 5y ago
Adding an ARIA role only adds the role, you'd then have to add more to name the element (in place of the missing <label>), to put the element in the tab order, and JavaScript event listeners to handle keyboard input correctly. Doing all that is more complex than using a style reset on an input element and even if you do it all correctly, it's less robust.

kevincox 5y ago

I wish there was a way to tell the browser to add more default styles to my document. For example we have reader mode but this completely munges your document and kills all custom styles and scripts. It would be cool if you could tell the browser to apply a nice pretty style (customizable by the user of course) but then possibly opt out small sections of the page (like an interactive example) where you could add custom scrips and styles. Obviously this works best with simple "document" websites but it always seems so weird telling the browser how to style the document when I know very little about the user or the device. It is getting "better" in a way with media queries for information about the device and user preference (like dark/light colour scheme) but it still is relying on each site to interpret those settings themselves, and progress is slow because everything needs to be standardized. This also opens the door to a "clean" mode with no default borders, margins, padding, sizes, styles which would help when making interfaces where you want to control every pixel and don't want to be surprised in differences in default browser style sheets.

extra88 5y ago
> I wish there was a way to tell the browser to add more default styles to my document. Non-Chrome browsers still have modifiable user stylesheets (though I think only Safari for Mac still has a GUI option to do it) but more realistically, you can use a browser extension like Stylus to apply your own styles, even defining them on a per-domain basis. Enabling the user to change the appearance of your site is much easier if you heed the advice of this article and use the appropriate semantic HTML. > "clean" mode with no default borders, margins, padding, sizes, styles Web developers have been starting projects with "reset" stylesheets for decades.
- kevincox 5y ago
  > Non-Chrome browsers still have modifiable user stylesheets This doesn't solve the problem I describe because it breaks websites (unless you are very minimal with your usage). I am talking about an opt-in feature where you concede control to the browser so that it can apply "aggressive" styles such as it would for reader mode. For example changing the current usage-agent style sheet to a "dark theme" is completely infeasible to ship as it would break way too many sites. Furthermore just being possible isn't enough. It would also need to provide nice defaults to make this a feasible proposition at all. I can't have my blog being barely readable for 99% of viewers. > even defining them on a per-domain basis. I also don't want to fix specific websites. I'm talking about something that works by default. (Of course site-specific tweaks are nice, but that is nearly orthogonal to what I am looking for here.) > Web developers have been starting projects with "reset" stylesheets for decades. Yes, and this is an unfortunate hack. It would be nice to remove the necessity to remove the need for these and remove the maintenance required (even if the cost of both is small).