15 ms·

Why do you assume there's no semantic clarity? Tailwind is made for the age of apps and components. The semantics are on component level.

by troupo 2y ago

skydhash 2y ago
So you can name a component, but you cannot name the styles attached to that component?
- 9dev 2y ago
  It’s naming one component, perhaps a sidebar, versus naming the fifteen children of the sidebar and their state transitions, in a way that’s consistent with the other 137 components that comprise your app. It’s not about not being able to name all these things, it’s that it’s pointless to do so.
  - jaggederest 2y ago
    You don't need to name subcomponents in a way that is consistent with the rest of the app, or even at all. That's what nesting is for. You can use simple names, or anonymous tags, that don't overlap because they live in a top level component with its own class/id.
  - skydhash 2y ago
    Isnt that what scoping is for? So you name you conponent and use selectors for styling sub components. My issue with most styling is that they want to use composition when it does not make any sense. Like spliting styles and using the pieces on things that has no relation to each other. If two things are not likely to change together, you shouldn’t use the same class for them, unless you consider the class as primitive. Tailwind is an extreme case of this, and like all extreme things, it’s a path to ruin.
    - 9dev 2y ago
      > If two things are not likely to change together, you shouldn’t use the same class for them, unless you consider the class as primitive. That is exactly the kind of dogma that I'm referring to—Tailwind makes thinking about that pointless. You apply style composition to achieve the result you want to achieve; not more, not less. > Tailwind [is] a path to ruin. Well, I can only speak from the experience of quite a few very successful projects relying on Tailwind: They look consistent, development is easy, style bundling an issue unheard of, and making changes to the design system requires a single line in the config file. New developers are productive from day one, there's no bike-shedding over the styles, and nobody adds ad-hoc colors they just pulled out of their hat. For me, styling on the web is solved.
      - skydhash 2y ago
        I get your point, but isn't this contingent on the colors and other properties being stable? I don't see why this can't be achieved with pure CSS instead of adding a (big) set of names as a layer of abstraction and then optionally pruning the build for performance. Because consistency is achieved only at UI design time (see design system). Unless you're prototyping your design at development time, I don't really see the improvements compared with Pure CSS. > style bundling an issue unheard of But then you need to have a component system to have any benefit from that (if you're using the raw classes name from Tailwind). Which was easily done with just naming the component (class or ID) either automatically or not.
        troupo 2y ago
        > Because consistency is achieved only at UI design time (see design system). Unless you're prototyping your design at development time, I don't really see the improvements compared with Pure CSS. So, every class now repeats the same properties and values (because CSS has no mixins or composition), there are dozens of classes that try to replicate scoping and nesting through BEM or similar, styles are completely divorced from actual components where they are used...
        skydhash 2y ago
    - troupo 2y ago
      > Isnt that what scoping is for? The one that hasn't been available in CSS until 2023? > So you name you conponent and use selectors for styling sub components. So how can you do that with CSS?
      - skydhash 2y ago
        > So how can you do that with CSS? The old: .card > .card-header > The one that hasn't been available in CSS until 2023? That was nesting, IIRC. Sugar syntax, so you don’t have to fully specified the whole selector.
        troupo 2y ago
        > .card > .card-header And we know that it never worked well. That's why BEM and many other naming strategies exist: to try and replicate scoping purely through naming discipline. > That was nesting, IIRC. Sugar syntax, so you don’t have to fully specified the whole selector. Nesting partly solves the naming and the "keep all of a component's style close together". The other partial solution is CSS Scoping: https://developer.mozilla.org/en-US/docs/Web/CSS/@scope https://developer.mozilla.org/en-US/docs/Web/CSS/@scope And this still doesn't solve the issue of repetition where every component has to spell out the margins, the paddings, the borders, the...
- troupo 2y ago
  Because you honestly don't need to, and shouldn't need to. CSS missed out on scoping, nesting, and composition even though most of these things have been available elsewhere (notably, SASS) for 20 or more years. What you really want is to have a component and all styles scoped to it. In the absence of that you want as few names replicating scoping, nesting, and composition, as possible. And you want to compose repeatable patterns across all of your components (something that is possible with mixins, and is impossible with vanilla CSS). So you cut down on repetition across class names until you're left with utility classes and a separation of concerns that cuts a different way: https://x.com/simonswiss/status/1664736786671869952 https://x.com/simonswiss/status/1664736786671869952 Note: no one is stopping you from having your own arbitrary classes when you need to. See e.g. Cube CSS approach https://piccalil.li/blog/cube-css/ https://piccalil.li/blog/cube-css/
  - skydhash 2y ago
    What I’m arguing about is that composition isn’t necessary in most cases. Because all components evolve independently. Also nesting is syntactic sugar, nice, but orthogonal to these discussions. And scoping is done with selectors. CSS isn’t an imperative language. It’s a declarative one. And what’s most important is understanding what it is trying to solve (mostly not styling elements with tag’s style). Which is what Tailwind is replicating. Tailwind may help you in some cases, but not because of a defect in CSS. It’s like using an ORM, then past a certain treshold, you find yourself doing (badly) SQL but in $language.
    - troupo 2y ago
      > Also nesting is syntactic sugar, nice, but orthogonal to these discussions. What is it with you and nesting? We were talking about scoping styles to a component. > CSS isn’t an imperative language. It’s a declarative one. So what? Doesn't mean you can't provide nice declarative ways of doing things. Like SASS has provided for 20+ years. > Which is what Tailwind is replicating. I fail to see the logic or, indeed, the meaning of your assertion.
      - skydhash 2y ago

Why do you assume there's no semantic clarity? Tailwind is made for the age of apps and components. The semantics are on component level.

by troupo 2y ago

Why do you assume there's no semantic clarity? Tailwind is made for the age of apps and components. The semantics are on component level.

skydhash 2y ago

So you can name a component, but you cannot name the styles attached to that component?

9dev 2y ago
It’s naming one component, perhaps a sidebar, versus naming the fifteen children of the sidebar and their state transitions, in a way that’s consistent with the other 137 components that comprise your app. It’s not about not being able to name all these things, it’s that it’s pointless to do so.
- jaggederest 2y ago
  You don't need to name subcomponents in a way that is consistent with the rest of the app, or even at all. That's what nesting is for. You can use simple names, or anonymous tags, that don't overlap because they live in a top level component with its own class/id.
- skydhash 2y ago
  Isnt that what scoping is for? So you name you conponent and use selectors for styling sub components. My issue with most styling is that they want to use composition when it does not make any sense. Like spliting styles and using the pieces on things that has no relation to each other. If two things are not likely to change together, you shouldn’t use the same class for them, unless you consider the class as primitive. Tailwind is an extreme case of this, and like all extreme things, it’s a path to ruin.
  - 9dev 2y ago
    > If two things are not likely to change together, you shouldn’t use the same class for them, unless you consider the class as primitive. That is exactly the kind of dogma that I'm referring to—Tailwind makes thinking about that pointless. You apply style composition to achieve the result you want to achieve; not more, not less. > Tailwind [is] a path to ruin. Well, I can only speak from the experience of quite a few very successful projects relying on Tailwind: They look consistent, development is easy, style bundling an issue unheard of, and making changes to the design system requires a single line in the config file. New developers are productive from day one, there's no bike-shedding over the styles, and nobody adds ad-hoc colors they just pulled out of their hat. For me, styling on the web is solved.
    - skydhash 2y ago
      I get your point, but isn't this contingent on the colors and other properties being stable? I don't see why this can't be achieved with pure CSS instead of adding a (big) set of names as a layer of abstraction and then optionally pruning the build for performance. Because consistency is achieved only at UI design time (see design system). Unless you're prototyping your design at development time, I don't really see the improvements compared with Pure CSS. > style bundling an issue unheard of But then you need to have a component system to have any benefit from that (if you're using the raw classes name from Tailwind). Which was easily done with just naming the component (class or ID) either automatically or not.
      - troupo 2y ago
        > Because consistency is achieved only at UI design time (see design system). Unless you're prototyping your design at development time, I don't really see the improvements compared with Pure CSS. So, every class now repeats the same properties and values (because CSS has no mixins or composition), there are dozens of classes that try to replicate scoping and nesting through BEM or similar, styles are completely divorced from actual components where they are used...
        skydhash 2y ago
  - troupo 2y ago
    > Isnt that what scoping is for? The one that hasn't been available in CSS until 2023? > So you name you conponent and use selectors for styling sub components. So how can you do that with CSS?
    - skydhash 2y ago
      > So how can you do that with CSS? The old: .card > .card-header > The one that hasn't been available in CSS until 2023? That was nesting, IIRC. Sugar syntax, so you don’t have to fully specified the whole selector.
      - troupo 2y ago
        > .card > .card-header And we know that it never worked well. That's why BEM and many other naming strategies exist: to try and replicate scoping purely through naming discipline. > That was nesting, IIRC. Sugar syntax, so you don’t have to fully specified the whole selector. Nesting partly solves the naming and the "keep all of a component's style close together". The other partial solution is CSS Scoping: https://developer.mozilla.org/en-US/docs/Web/CSS/@scope https://developer.mozilla.org/en-US/docs/Web/CSS/@scope And this still doesn't solve the issue of repetition where every component has to spell out the margins, the paddings, the borders, the...
troupo 2y ago
Because you honestly don't need to, and shouldn't need to. CSS missed out on scoping, nesting, and composition even though most of these things have been available elsewhere (notably, SASS) for 20 or more years. What you really want is to have a component and all styles scoped to it. In the absence of that you want as few names replicating scoping, nesting, and composition, as possible. And you want to compose repeatable patterns across all of your components (something that is possible with mixins, and is impossible with vanilla CSS). So you cut down on repetition across class names until you're left with utility classes and a separation of concerns that cuts a different way: https://x.com/simonswiss/status/1664736786671869952 https://x.com/simonswiss/status/1664736786671869952 Note: no one is stopping you from having your own arbitrary classes when you need to. See e.g. Cube CSS approach https://piccalil.li/blog/cube-css/ https://piccalil.li/blog/cube-css/
- skydhash 2y ago
  What I’m arguing about is that composition isn’t necessary in most cases. Because all components evolve independently. Also nesting is syntactic sugar, nice, but orthogonal to these discussions. And scoping is done with selectors. CSS isn’t an imperative language. It’s a declarative one. And what’s most important is understanding what it is trying to solve (mostly not styling elements with tag’s style). Which is what Tailwind is replicating. Tailwind may help you in some cases, but not because of a defect in CSS. It’s like using an ORM, then past a certain treshold, you find yourself doing (badly) SQL but in $language.
  - troupo 2y ago
    > Also nesting is syntactic sugar, nice, but orthogonal to these discussions. What is it with you and nesting? We were talking about scoping styles to a component. > CSS isn’t an imperative language. It’s a declarative one. So what? Doesn't mean you can't provide nice declarative ways of doing things. Like SASS has provided for 20+ years. > Which is what Tailwind is replicating. I fail to see the logic or, indeed, the meaning of your assertion.
    - skydhash 2y ago