5 ms·

Screen readers and other assistive technology fully expects your HTML to be semantic. It doesn’t always matter, but it matters often enough. CSS tends to be ha

Screen readers and other assistive technology fully expects your HTML to be semantic. It doesn’t always matter, but it matters often enough. CSS tends to be hard because (1) people insists on having a single page with a single stylesheet and (2) only divs are used, and so they use class names for everything. If you didn’t use a SPA you’d have scoping. If you used semantic HTML you could target based on semantic structure. Both of these makes CSS easier. JavaScript is fine to use if you have to. But using JavaScript when you don’t is just wasting time. I’ve seen people essentially re-implement default <form> behaviour too many times to count, and spend time looking for solutions to problems they only have because they insist on using technology for making interactive sites when they’re making something largely static. If you want a simpler life, choose the simplest technology that will solve your problem.

lmm 2y ago
> Screen readers and other assistive technology fully expects your HTML to be semantic. No they don't. They were developed to work on the web as it existed at the time and handle it fine. A screenreader doesn't magically do something different and better with an <em> tag than a <b> tag, and only confused thinking and propaganda has made people think so. (And anyone who actually cared enough to test with a screenreader would know this - but people don't actually care about screenreaders, they just use them as a stick to beat technologies they don't like) > CSS tends to be hard because (1) people insists on having a single page with a single stylesheet and (2) only divs are used, and so they use class names for everything. > If you didn’t use a SPA you’d have scoping. If you used semantic HTML you could target based on semantic structure. Both of these makes CSS easier. You still need class names, because you're always going to have some distinctions that matter in your domain but can't be mapped onto the fixed list of HTML tags. So either you use divs and class names for everything, or you use a mix of tags and use a mix of class names and tag names, which just ends up being less consistent and more confusing. You have components that are shared between pages, so you either have to include all your CSS on every page, you manually figure out which components are used on which pages and make mistakes sometimes (leaving you with missing styles), or you use a Javascript UI framework. > JavaScript is fine to use if you have to. But using JavaScript when you don’t is just wasting time. I find the opposite. You're always going to need JavaScript eventually. Trying to do stuff with CSS and HTML tags just wastes your time and the end result ends up being more complicated because it's a mishmash of both. If you use a well-known JavaScript UI framework from day 1, it's so much easier to end up with a simple, consistent, maintainable site.
- Skinney 2y ago
  > No they don't. They do. They use tags and semantic structure to figure out what to read when. You also skipped the "and other assistive technology" part of my sentence. Tools for navigating, or alternative rendering, improves when your site is semantic. I use these tools every now and again, I'm not basing this on theory. > You still need class names, Not as many. If you use divs and classes everywhere, you end up using classes for semantic meaning. > You have components that are shared between pages, so you either have to include all your CSS on every page Use classless CSS as far as you can, use site-specific (layout) stylesheets, and use webcomponents for those components that are truly novel. Webcomponents with shadow dom means it can include it's own stylesheet without affecting the rest of the site. In many cases, you get by with just classless CSS. Site-specific layout is a one-liner. Webcomponents bring their own styles. So no, you don't need to bring an entire JS UI framework for this. > You're always going to need JavaScript eventually Depends entirely on what you're building, and a lot of the time you can get away with something simple like HTMX and JQuery. But even if you do end up needing a JS framework for some portion of your site, limiting the amount of stuff that needs to be handled by this framework _greatly_ reduces the amount of complexity, and amount of code, that the developer has to write.
  - lmm 2y ago
    > If you use divs and classes everywhere, you end up using classes for semantic meaning. You're always going to use classes for semantic meaning anyway, because the HTML standard doesn't and can't define all the semantic distinctions that will be relevant in what you're making. > use webcomponents for those components that are truly novel. Webcomponents with shadow dom means it can include it's own stylesheet without affecting the rest of the site. I guarantee you the author of this rant hates webcomponents even more than they hate Javascript. (Indeed I'm pretty sure they qualify as a "JS UI framework"). > But even if you do end up needing a JS framework for some portion of your site, limiting the amount of stuff that needs to be handled by this framework _greatly_ reduces the amount of complexity, and amount of code, that the developer has to write. You can draw an arbitrary line and say JS is "code" and HTML and CSS are "not code", but that doesn't actually make them any simpler to understand. Expressing your whole site in the same framework used the same way results in something that's much easier to read and maintain.

lmm 2y ago

> Screen readers and other assistive technology fully expects your HTML to be semantic. No they don't. They were developed to work on the web as it existed at the time and handle it fine. A screenreader doesn't magically do something different and better with an <em> tag than a <b> tag, and only confused thinking and propaganda has made people think so. (And anyone who actually cared enough to test with a screenreader would know this - but people don't actually care about screenreaders, they just use them as a stick to beat technologies they don't like) > CSS tends to be hard because (1) people insists on having a single page with a single stylesheet and (2) only divs are used, and so they use class names for everything. > If you didn’t use a SPA you’d have scoping. If you used semantic HTML you could target based on semantic structure. Both of these makes CSS easier. You still need class names, because you're always going to have some distinctions that matter in your domain but can't be mapped onto the fixed list of HTML tags. So either you use divs and class names for everything, or you use a mix of tags and use a mix of class names and tag names, which just ends up being less consistent and more confusing. You have components that are shared between pages, so you either have to include all your CSS on every page, you manually figure out which components are used on which pages and make mistakes sometimes (leaving you with missing styles), or you use a Javascript UI framework. > JavaScript is fine to use if you have to. But using JavaScript when you don’t is just wasting time. I find the opposite. You're always going to need JavaScript eventually. Trying to do stuff with CSS and HTML tags just wastes your time and the end result ends up being more complicated because it's a mishmash of both. If you use a well-known JavaScript UI framework from day 1, it's so much easier to end up with a simple, consistent, maintainable site.

Skinney 2y ago
> No they don't. They do. They use tags and semantic structure to figure out what to read when. You also skipped the "and other assistive technology" part of my sentence. Tools for navigating, or alternative rendering, improves when your site is semantic. I use these tools every now and again, I'm not basing this on theory. > You still need class names, Not as many. If you use divs and classes everywhere, you end up using classes for semantic meaning. > You have components that are shared between pages, so you either have to include all your CSS on every page Use classless CSS as far as you can, use site-specific (layout) stylesheets, and use webcomponents for those components that are truly novel. Webcomponents with shadow dom means it can include it's own stylesheet without affecting the rest of the site. In many cases, you get by with just classless CSS. Site-specific layout is a one-liner. Webcomponents bring their own styles. So no, you don't need to bring an entire JS UI framework for this. > You're always going to need JavaScript eventually Depends entirely on what you're building, and a lot of the time you can get away with something simple like HTMX and JQuery. But even if you do end up needing a JS framework for some portion of your site, limiting the amount of stuff that needs to be handled by this framework _greatly_ reduces the amount of complexity, and amount of code, that the developer has to write.
- lmm 2y ago
  > If you use divs and classes everywhere, you end up using classes for semantic meaning. You're always going to use classes for semantic meaning anyway, because the HTML standard doesn't and can't define all the semantic distinctions that will be relevant in what you're making. > use webcomponents for those components that are truly novel. Webcomponents with shadow dom means it can include it's own stylesheet without affecting the rest of the site. I guarantee you the author of this rant hates webcomponents even more than they hate Javascript. (Indeed I'm pretty sure they qualify as a "JS UI framework"). > But even if you do end up needing a JS framework for some portion of your site, limiting the amount of stuff that needs to be handled by this framework _greatly_ reduces the amount of complexity, and amount of code, that the developer has to write. You can draw an arbitrary line and say JS is "code" and HTML and CSS are "not code", but that doesn't actually make them any simpler to understand. Expressing your whole site in the same framework used the same way results in something that's much easier to read and maintain.