4 ms·

Could you expand on this? Class names in CSS are just as important, if not moreso, than naming variables in typical programming. Back in the late 90s and early

Could you expand on this? Class names in CSS are just as important, if not moreso, than naming variables in typical programming. Back in the late 90s and early 2000s, the dominant ideology is to use semantic class names, e.g. ".sidebar" instead of ".blue_bar" or similar. Essentially, don't describe how something looks with its name. Even when building JS apps, I use CSS classes semantically with ".selected" ".menubar", etc. I am interested in reading your philosophy on CSS classes.

zztop44 3y ago
The exception is when using a framework which isolates CSS at the component level, in which case your class names don’t matter anywhere near as much because you’ll only ever see them alongside the corresponding HTML.
- zlg_codes 3y ago
  Can't say I'm familiar with this type of webdev. How is the CSS isolated at a 'component' level? Is that not what selectors already do? I'm having trouble picturing how this is built or how it works. Traditionally you put your template HTML or just HTML in one place, CSS in another, and JS in yet another, then tie them together via <style> and <script>. Are you saying there are frameworks that tie HTML and CSS together into the same unit? That is rather strange to me. In such an environment, do people decide on no structure for their class names? I'd still want reusable CSS in such a situation.
  - zztop44 3y ago
    It’s quite a common pattern in modern frontend frameworks. Each component includes just the CSS required for that component (plus any global styles). At built time, the bundler will generate unique class names for each of the HTML elements in the component and output an optimized CSS bundle matching those unique class names. It definitely adds extra complexity in the build step, and the resultant randomly generated class names aren’t very nice aesthetically. However, this approach allows you to read and modify the CSS, HTML and JS that affect a component all in the same place, instead bouncing around between different files. It also avoids the problem of naming (and remembering) globally scoped CSS selectors, and generally results in less CSS over the wire.

zztop44 3y ago

The exception is when using a framework which isolates CSS at the component level, in which case your class names don’t matter anywhere near as much because you’ll only ever see them alongside the corresponding HTML.

zlg_codes 3y ago
Can't say I'm familiar with this type of webdev. How is the CSS isolated at a 'component' level? Is that not what selectors already do? I'm having trouble picturing how this is built or how it works. Traditionally you put your template HTML or just HTML in one place, CSS in another, and JS in yet another, then tie them together via <style> and <script>. Are you saying there are frameworks that tie HTML and CSS together into the same unit? That is rather strange to me. In such an environment, do people decide on no structure for their class names? I'd still want reusable CSS in such a situation.
- zztop44 3y ago
  It’s quite a common pattern in modern frontend frameworks. Each component includes just the CSS required for that component (plus any global styles). At built time, the bundler will generate unique class names for each of the HTML elements in the component and output an optimized CSS bundle matching those unique class names. It definitely adds extra complexity in the build step, and the resultant randomly generated class names aren’t very nice aesthetically. However, this approach allows you to read and modify the CSS, HTML and JS that affect a component all in the same place, instead bouncing around between different files. It also avoids the problem of naming (and remembering) globally scoped CSS selectors, and generally results in less CSS over the wire.