5 ms·

I can't understand why people bother about HTML with long class attributes so much. If you use "btn" instead of a long string of Tailwind classes, you just move

by 9dev 3y ago

I can't understand why people bother about HTML with long class attributes so much. If you use "btn" instead of a long string of Tailwind classes, you just move the actual CSS properties into a stylesheet file, which you need to switch back and forth to just to change the looks of that button. And having said that, when using Tailwind with some kind of component-centred framework, those classes will be local to a <Button> component anyway, which is exactly the same as some kind of custom component the author praises (that also needs styles within.)

omer_balyali 3y ago
If you need to adopt the HTML to fit a certain style, you're doing it wrong. HTML should be a semantic markup, it shouldn't change much when you need to change the styling/CSS. So you don't really go "back-and-forth" to architecture CSS, you just write your CSS. But maybe it's a Tailwind thing that you need to add additional elements to HTML just to be able to style it correctly, I'm not sure. It's like saying you shouldn't have JSON files (and embed the data inside the business logic) as you need to change the JSON file when you need to change the logic of the app. In short, you adopt your CSS architecture to your semantic markup, not the other way around.
- 9dev 3y ago
  I don't know about you, but I've never seen anyone create a user interface by writing down the full, semantic markup, and then proceed to create CSS for that finished HTML structure. Instead, it's usually an iterative process of adding HTML, styling that, then adding more content. That isn't even related to Tailwind, or any other CSS framework -- just that Tailwind allows you to stay in the HTML (or component) context, without having to switch to a stylesheet there. Your JSON comparison doesn't fit: We're talking about styling, not business logic. But if you mean that I would need to define `"userAgeOver21": true` in a JSON file instead of having some `{{ %if user.age > 21 }}` in the code, then yes, I'm firmly in the latter camp. Not having to switch context often overrules pedantic purity every time.
  - ricardobeat 3y ago
    > I've never seen anyone create a user interface by writing down the full, semantic markup, and then proceed to create CSS for that Indeed, not in the past 7-8 years. But we used to do it, and the outcome was great - semantic, accessible and machine-readable HTML was the norm. It’s unfortunate that we lost this in the transition to components.
    - 9dev 3y ago
      Is that so? From my memory, most people used tables for layouts, or full-out relied on div tags for everything. At some point, HTML5 brought headers and footers and navs and more, and if anything, that made the situation better since. But if the working groups continue to pretend HTML is for text documents instead of web applications, things will never get more semantic.
      - troupo 3y ago
        > But if the working groups continue to pretend HTML is for text documents instead of web applications, things will never get more semantic. I mean, HTML is and will always forever be a system to display a few pages of text with some images thrown in. And even for that it sucks big time. Anything standards committees have been throwing at it over the years are just haphazard hacks to make it into something it's not with no coherent goal in mind.
      - ricardobeat 3y ago
        Tables for layout started dying around 2008. Eight years ago is 2016, so there is quite a large period in between.
    - troupo 3y ago
      > But we used to do it, and the outcome was great - semantic, accessible and machine-readable HTML was the norm You know, there are still people alive who lived through this Golden Age of 10 years ago? 20 years ago? And they call bullshit on your statement.
deleted 3y ago
[deleted]
ricardobeat 3y ago
“Need to switch back and forth” is a strangely negative way of putting it. Do you “switch back and forth” to a function definition, and is that an argument for procedural code and repetition? Then your second paragraph is a great point against the need for Tailwind and the long class attributes, as you’re going to encapsulate all of that in a component (and “switch back and forth” to see its styles) anyway.
- 9dev 3y ago
  You've pretty much answered this yourself - a function, just like a component, is a self-contained unit. If you're working within the scope of a function, you don't switch back and forth; but I'm pretty sure you wouldn't want to have to declare the names of any local variables in that function in some kind of global variable table in another file ("let's add a loop here.. switch to vars.file, add someFunction_firstLoop_i as 0... back to the loop, add the variables...").

by 9dev 3y ago

omer_balyali 3y ago

If you need to adopt the HTML to fit a certain style, you're doing it wrong. HTML should be a semantic markup, it shouldn't change much when you need to change the styling/CSS. So you don't really go "back-and-forth" to architecture CSS, you just write your CSS. But maybe it's a Tailwind thing that you need to add additional elements to HTML just to be able to style it correctly, I'm not sure. It's like saying you shouldn't have JSON files (and embed the data inside the business logic) as you need to change the JSON file when you need to change the logic of the app. In short, you adopt your CSS architecture to your semantic markup, not the other way around.

9dev 3y ago
I don't know about you, but I've never seen anyone create a user interface by writing down the full, semantic markup, and then proceed to create CSS for that finished HTML structure. Instead, it's usually an iterative process of adding HTML, styling that, then adding more content. That isn't even related to Tailwind, or any other CSS framework -- just that Tailwind allows you to stay in the HTML (or component) context, without having to switch to a stylesheet there. Your JSON comparison doesn't fit: We're talking about styling, not business logic. But if you mean that I would need to define `"userAgeOver21": true` in a JSON file instead of having some `{{ %if user.age > 21 }}` in the code, then yes, I'm firmly in the latter camp. Not having to switch context often overrules pedantic purity every time.
- ricardobeat 3y ago
  > I've never seen anyone create a user interface by writing down the full, semantic markup, and then proceed to create CSS for that Indeed, not in the past 7-8 years. But we used to do it, and the outcome was great - semantic, accessible and machine-readable HTML was the norm. It’s unfortunate that we lost this in the transition to components.
  - 9dev 3y ago
    Is that so? From my memory, most people used tables for layouts, or full-out relied on div tags for everything. At some point, HTML5 brought headers and footers and navs and more, and if anything, that made the situation better since. But if the working groups continue to pretend HTML is for text documents instead of web applications, things will never get more semantic.
    - troupo 3y ago
      > But if the working groups continue to pretend HTML is for text documents instead of web applications, things will never get more semantic. I mean, HTML is and will always forever be a system to display a few pages of text with some images thrown in. And even for that it sucks big time. Anything standards committees have been throwing at it over the years are just haphazard hacks to make it into something it's not with no coherent goal in mind.
    - ricardobeat 3y ago
      Tables for layout started dying around 2008. Eight years ago is 2016, so there is quite a large period in between.
  - troupo 3y ago
    > But we used to do it, and the outcome was great - semantic, accessible and machine-readable HTML was the norm You know, there are still people alive who lived through this Golden Age of 10 years ago? 20 years ago? And they call bullshit on your statement.

deleted 3y ago

[deleted]

ricardobeat 3y ago

“Need to switch back and forth” is a strangely negative way of putting it. Do you “switch back and forth” to a function definition, and is that an argument for procedural code and repetition? Then your second paragraph is a great point against the need for Tailwind and the long class attributes, as you’re going to encapsulate all of that in a component (and “switch back and forth” to see its styles) anyway.

9dev 3y ago
You've pretty much answered this yourself - a function, just like a component, is a self-contained unit. If you're working within the scope of a function, you don't switch back and forth; but I'm pretty sure you wouldn't want to have to declare the names of any local variables in that function in some kind of global variable table in another file ("let's add a loop here.. switch to vars.file, add someFunction_firstLoop_i as 0... back to the loop, add the variables...").