3 ms·

Is `my-card` not a declaration of what something is (supposed to be)? The attributes are then encapsulating the state of the thing e.g. "is-loading", "size", et

Is `my-card` not a declaration of what something is (supposed to be)? The attributes are then encapsulating the state of the thing e.g. "is-loading", "size", etc. And the style then naturally follows, becoming a function of state e.g. "large loading indicator". The extend selector solves the problem of one style definition inheriting styles from another style definition, but the author is trying to solve the problem of how styles are mapped to stateful elements. It's the mapping process that introduces the combinatorial problems of class names.

the_other 2y ago
`.my-card` is semantic, but `.big` is presentational/visual. You could maintain the semantics with rules like: .my-card { width: normal; } .homepage .my-card { width: bigger; } .sidebar .my-card { width: smaller; } (where 'normal', 'bigger', and 'smaller" should be replaced with real values). BEM suggested state labels (e.g. `.my-card__loading`). I'm on the fence about those vs `.my-card.loading`. The class-based syntax seems shorter than either BEM-style or attribute selectors, and thus I prefer it. You might get a bit more rigour from the more longer-form methods, but I'm not convinced the energy isn't better spent training your team to be more careful. Shared code, CSS toolkits, shareable widgets present bigger challenges... the thing is that none of the tools suggested actually fix the problems. Your code can still break 3rd party code and vice-versa because of the global nature of CSS. Specificity needs management, but so do type systems and class hierarchies. Stop pretending the cascade and global namespace don't exist and just do the work.
- wruza 2y ago
  .big is what it really is, big. Inventing a new name for it like emphasized, enlarged or attention-grabbing is just unnecessary pedantry. Naming things what they are and then styling with how they must look like creates an additional linguistic layer in an already csessed up system. “What things are” must become component names, not a part of markup. If there’s no reason to componentize a chunk, it doesn’t get a name (and vice versa).
  - the_other 2y ago
    It's only visually big. To a blind person, it doesn't matter what size it is. It's big to fulfil some layout concern, and the layout concern is there to fulfil some attention or intent concern. And also, I didn't say one should use `.emphasised`. I said to change the size based on the container: `.hero .card {}` would be big but `.articles .card {}` would be normal sized. `.card`s are always just cards; their context makes them different variations. "But `.hero` is just another way of saying big, or emphasised"... Not really. A `.hero` is "the focus of the page. EVERYTHING (`.card`, `button`, `.btn`, `q` etc) inside `.hero` might all be big, or bold, or a contrasting colour, or surrounded by extra negative space, or in italic, or a mixture of those. Back when there were going to be aural style sheets [0], you'd have a way to specify alternate modality presentations using the same class names. It doesn't always make sense that something is aurally louder when it's visually bigger. `.big` is not "what things are". `.big` is "how do we express what that thing is in this situation". [0]: https://www.w3.org/Style/CSS/Speech/speech.html https://www.w3.org/Style/CSS/Speech/speech.html

the_other 2y ago

`.my-card` is semantic, but `.big` is presentational/visual. You could maintain the semantics with rules like: .my-card { width: normal; } .homepage .my-card { width: bigger; } .sidebar .my-card { width: smaller; } (where 'normal', 'bigger', and 'smaller" should be replaced with real values). BEM suggested state labels (e.g. `.my-card__loading`). I'm on the fence about those vs `.my-card.loading`. The class-based syntax seems shorter than either BEM-style or attribute selectors, and thus I prefer it. You might get a bit more rigour from the more longer-form methods, but I'm not convinced the energy isn't better spent training your team to be more careful. Shared code, CSS toolkits, shareable widgets present bigger challenges... the thing is that none of the tools suggested actually fix the problems. Your code can still break 3rd party code and vice-versa because of the global nature of CSS. Specificity needs management, but so do type systems and class hierarchies. Stop pretending the cascade and global namespace don't exist and just do the work.

wruza 2y ago
.big is what it really is, big. Inventing a new name for it like emphasized, enlarged or attention-grabbing is just unnecessary pedantry. Naming things what they are and then styling with how they must look like creates an additional linguistic layer in an already csessed up system. “What things are” must become component names, not a part of markup. If there’s no reason to componentize a chunk, it doesn’t get a name (and vice versa).
- the_other 2y ago
  It's only visually big. To a blind person, it doesn't matter what size it is. It's big to fulfil some layout concern, and the layout concern is there to fulfil some attention or intent concern. And also, I didn't say one should use `.emphasised`. I said to change the size based on the container: `.hero .card {}` would be big but `.articles .card {}` would be normal sized. `.card`s are always just cards; their context makes them different variations. "But `.hero` is just another way of saying big, or emphasised"... Not really. A `.hero` is "the focus of the page. EVERYTHING (`.card`, `button`, `.btn`, `q` etc) inside `.hero` might all be big, or bold, or a contrasting colour, or surrounded by extra negative space, or in italic, or a mixture of those. Back when there were going to be aural style sheets [0], you'd have a way to specify alternate modality presentations using the same class names. It doesn't always make sense that something is aurally louder when it's visually bigger. `.big` is not "what things are". `.big` is "how do we express what that thing is in this situation". [0]: https://www.w3.org/Style/CSS/Speech/speech.html https://www.w3.org/Style/CSS/Speech/speech.html