3 ms·

> A `<div class="user_profile">` is clearly a container for a user profile, a `<div class="here comes a shitload of tailwind class names because inline styles

by hbn 5y ago

> A `<div class="user_profile">` is clearly a container for a user profile, a `<div class="here comes a shitload of tailwind class names because inline styles are now apparently cool again">` tells you absolutely nothing about what the hell is going on. You know what's going on if you're in a component called user-profile.component.html How often are you writing something like a user profile component in the context of something much larger? Also, what styles would the class "user_profile" even have? You say the second one "tells you nothing about what's going on," but I'd say it's the opposite. If you actually put real tailwind classes in the second one, I'd know exactly how that div is styled whereas the first one requires cross-referencing another file. "user_profile" probably has CSS implementation that have almost nothing to do with a user profile. It's probably a container that has maybe a margin, a max-width? The important styling details all come from the inner HTML and stylings on those things. So your "user_profile" class is mostly just another generic wrapper that you had to come up with a name for.

seanwilson 5y ago
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.

by hbn 5y ago

seanwilson 5y ago

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.