4 ms·

As an example, I'd say this isn't semantic HTML: <div>heading</div><div>bob is a person</div> This is better: <h1>heading</h1><p>bob is a person</div

As an example, I'd say this isn't semantic HTML: <div>heading</div><div>bob is a person</div> This is better: <h1>heading</h1><p>bob is a person</div> This is less clean but has the same level of semantic detail in the HTML: <div class="container"><h1 class="home-heading text-center">heading</h1><div class="m-10"><p class="home-body color-blue"><div class="first-name">bob</div> is a person</div></div> Am I missing something? I think people conflate semantic class names (read by programmers and maybe ad-hoc web scrapers) with semantic HTML (read by screen readers, SEO bots). Semantic HTML is HTML that uses the appropriate semantic HTML tags, but including wrapper divs and CSS class names on top of this doesn't make it less semantic to a machine. For styling, when a utility class is all you need to style a particular tag and it's obvious from context what that tag is being used for, I don't see to reason to spend time trying to come up with a semantic name e.g. `home-hero-wrapper-inner`. To me, this is people dogmatically sticking to a "best practice" without thinking about the pros/cons and reason behind it. This is also related to the pipedream that HTML is for data only with nothing about presentation and CSS should be able to style the HTML without you editing the HTML.

hbn 5y ago
> This is also related to the pipedream that HTML is for data only with nothing about presentation and CSS should be able to style the HTML without you editing the HTML. Which I also think is weird, because the hierarchy of HTML is inherently styling/presentation. If HTML was truly decoupled from styling, you'd just throw all the tags that you want into an HTML file and then arrange them around with CSS. That's why when you're using child selectors in CSS (or the nesting in SCSS that's transpiled to child selectors), you're forced to keep two hierarchies in sync, which makes it a huge PITA to refactor.
- seanwilson 5y ago
  > That's why when you're using child selectors in CSS (or the nesting in SCSS that's transpiled to child selectors), you're forced to keep two hierarchies in sync, which makes it a huge PITA to refactor. Yep, trying to keep data and presentation separated like this comes with a lot of pain. Why bother? I don't see the practical benefits in real-life projects as long as you're still using semantic HTML tags. There's this other pipedream that the HTML is generated/written by people that aren't concerned with the presentation and then the CSS can be swapped in to style it however you want. You can and should do this in a sense that you keep your data/articles/posts in Markdown, SQL databases, behind APIs etc. - I think trying to split this further at the HTML/CSS level isn't gaining anything.

hbn 5y ago

> This is also related to the pipedream that HTML is for data only with nothing about presentation and CSS should be able to style the HTML without you editing the HTML. Which I also think is weird, because the hierarchy of HTML is inherently styling/presentation. If HTML was truly decoupled from styling, you'd just throw all the tags that you want into an HTML file and then arrange them around with CSS. That's why when you're using child selectors in CSS (or the nesting in SCSS that's transpiled to child selectors), you're forced to keep two hierarchies in sync, which makes it a huge PITA to refactor.

seanwilson 5y ago
> That's why when you're using child selectors in CSS (or the nesting in SCSS that's transpiled to child selectors), you're forced to keep two hierarchies in sync, which makes it a huge PITA to refactor. Yep, trying to keep data and presentation separated like this comes with a lot of pain. Why bother? I don't see the practical benefits in real-life projects as long as you're still using semantic HTML tags. There's this other pipedream that the HTML is generated/written by people that aren't concerned with the presentation and then the CSS can be swapped in to style it however you want. You can and should do this in a sense that you keep your data/articles/posts in Markdown, SQL databases, behind APIs etc. - I think trying to split this further at the HTML/CSS level isn't gaining anything.