4 ms·

I can't believe people find even half of this acceptable, do they never use a browser inspector in their work?

by micromacrofoot 1y ago

aidos 1y ago
I do, and it’s great having the styles right there and hackable.
- recursive 1y ago
  How can styles ever not be hackable? Inline styles always take precedence. What can ever stop you from slapping in more inline styles?
- ericwood 1y ago
  To be fair, this is the case with any styling approach; if the style is applied to the element, it's there for you to toy with in the inspector.
- thaumasiotes 1y ago
  Huh? You have the styles right there and hackable regardless of your tooling. That's what browser inspectors do.
- pheres 1y ago
  No matter what you are using, they are always there, editable/hackable. However I would argue that it makes it slightly harder to make any change. You no longer have a single class with all the styles that are affecting that element. You can change the classes in the harder to read html, or override the single element. There is no longer the possibility to, for example, affect all .primary-btns.
  - phatskat 1y ago
    > You can change the classes in the harder to read html, or override the single element. There is no longer the possibility to, for example, affect all .primary-btns. Sure there is, the only thing is that instead of having 20 <button class=“primary”> tags, you have a <ButtonPrimary> component. Change the component once, and all instances get the update. This applies regardless of Tailwind. But if you’re repeating classes on the same kind of element over and over, then the question is less about how you’re styling it and more about how you’re organizing things.
Alupis 1y ago
If you write enough CSS for a site... eventually you end up building utility classes anyway. Now, you re-invented Tailwind... but in your own proprietary way that nobody else understands. Tailwind takes the inverse approach. The example posted by the parent above is completely unambiguous - what you see is what you get, and it's done the same way everywhere Tailwind is used. You can read the component's styles and understand what it should look like without having to do a bunch of look-ups, or alter classes which might impact other areas. So now instead of memorizing a bunch of custom classes like `pad-left-20` (because you didn't discover the `leftp-20` your colleague added 8 months ago)... you now have a standard way.
- squidbeak 1y ago
  There's a big difference between using utility classes for utilities and using utility classes for everything.
  - 9dev 1y ago
    And here we’re on firm bike-shedding territory. Where does a utility stop being a utility and start being… a non-utility?
    - H1Supreme 1y ago
      It's less of when it becomes a "non-utility", and more that it becomes an incomprehensible mess of classes on a div.
      - phatskat 1y ago
        For me, `class”btn btn-primary btn-primary—title”` says close to nothing about the underlying CSS - I have to go look that up. But `class=“rounded p-2 flex gap-2 items-center font-semibold bg-aqua-300 text-white”` actually tells me something: “this button has rounded corners, padding of 8px on all sides, it’s got flex display with a gap of 8px, items are aligned along the center of the cross axis, font weight is 500, the background is a lighter shade of aqua and the text is white.” What shade of aqua, exactly? I couldn’t tell you, but my IDE sticks a color block right next to any Tailwind color class. Is that rounded corner a radius of 6px or 8px? I don’t remember off the top of my head, but again my IDE will tell me with a quick hover of the “rounded” class. To me, the first set of classes is “incomprehensible” because those names, while semantically descriptive, tell me nothing about what the classes actually apply - they describe what they’re styling, not _how_ they’re styling it. But the long list of Tailwind classes tells me exactly what they do and how they do it, and if for some reason I need to go beyond the LSP to figure out what a class does, the Tailwind docs are miles easier to search than grepping the codebase for “.btn-primary \{“, not that I’ve run into that. In fact, the Tailwind LSP will compute selectors like “[&>div]:hover:border-2” and show you the actual generated CSS selector right in the hover window so you can see what the eventual output will be - it’s not just a dumb lookup of “m-2 is the margin 8px class”
mejutoco 1y ago
There was a time when not having css and html completely separate was considered sacrilege. And having html in javascript would have been a mortal sin. Eons ago I was at a job where we dynamically generated css on the server (php in that project). Anyone would have said: what about separation of concerns? Now everyone says it is best practice to have components with css, html and (gasp) Javascript all in one unit, because someone, for ex. Facebook said it (React). And the truth is it is very useful, and it is another way to structure frontend code. My point is: it is a spectrum and it can be useful to change the styling right there in the browser inspector. That works with tailwind the same as css. And with components, you can hide the repetition, although the browser will still have the repeated classes. Is this better than having css on another file with maybe some unused classes? I have done both and I can see each has pros and cons.
- vehemenz 1y ago
  The thing is, they were never really separate. The source files were separated, sure, but the way 90% of the world did CSS, there were hidden abstractions relating the class definitions in the .css file and the DOM structure in the .html that weren't documented anywhere.
tshaddox 1y ago
This Chrome extension is widely recommended when using atomic CSS: https://chromewebstore.google.com/detail/atomic-css-devtools/cbjhfeooiomphlikkblgdageenemhpgc https://chromewebstore.google.com/detail/atomic-css-devtools...

I can't believe people find even half of this acceptable, do they never use a browser inspector in their work?

aidos 1y ago

I do, and it’s great having the styles right there and hackable.

recursive 1y ago
How can styles ever not be hackable? Inline styles always take precedence. What can ever stop you from slapping in more inline styles?
ericwood 1y ago
To be fair, this is the case with any styling approach; if the style is applied to the element, it's there for you to toy with in the inspector.
thaumasiotes 1y ago
Huh? You have the styles right there and hackable regardless of your tooling. That's what browser inspectors do.
pheres 1y ago
No matter what you are using, they are always there, editable/hackable. However I would argue that it makes it slightly harder to make any change. You no longer have a single class with all the styles that are affecting that element. You can change the classes in the harder to read html, or override the single element. There is no longer the possibility to, for example, affect all .primary-btns.
- phatskat 1y ago
  > You can change the classes in the harder to read html, or override the single element. There is no longer the possibility to, for example, affect all .primary-btns. Sure there is, the only thing is that instead of having 20 <button class=“primary”> tags, you have a <ButtonPrimary> component. Change the component once, and all instances get the update. This applies regardless of Tailwind. But if you’re repeating classes on the same kind of element over and over, then the question is less about how you’re styling it and more about how you’re organizing things.

Alupis 1y ago

If you write enough CSS for a site... eventually you end up building utility classes anyway. Now, you re-invented Tailwind... but in your own proprietary way that nobody else understands. Tailwind takes the inverse approach. The example posted by the parent above is completely unambiguous - what you see is what you get, and it's done the same way everywhere Tailwind is used. You can read the component's styles and understand what it should look like without having to do a bunch of look-ups, or alter classes which might impact other areas. So now instead of memorizing a bunch of custom classes like `pad-left-20` (because you didn't discover the `leftp-20` your colleague added 8 months ago)... you now have a standard way.

squidbeak 1y ago
There's a big difference between using utility classes for utilities and using utility classes for everything.
- 9dev 1y ago
  And here we’re on firm bike-shedding territory. Where does a utility stop being a utility and start being… a non-utility?
  - H1Supreme 1y ago
    It's less of when it becomes a "non-utility", and more that it becomes an incomprehensible mess of classes on a div.
    - phatskat 1y ago
      For me, `class”btn btn-primary btn-primary—title”` says close to nothing about the underlying CSS - I have to go look that up. But `class=“rounded p-2 flex gap-2 items-center font-semibold bg-aqua-300 text-white”` actually tells me something: “this button has rounded corners, padding of 8px on all sides, it’s got flex display with a gap of 8px, items are aligned along the center of the cross axis, font weight is 500, the background is a lighter shade of aqua and the text is white.” What shade of aqua, exactly? I couldn’t tell you, but my IDE sticks a color block right next to any Tailwind color class. Is that rounded corner a radius of 6px or 8px? I don’t remember off the top of my head, but again my IDE will tell me with a quick hover of the “rounded” class. To me, the first set of classes is “incomprehensible” because those names, while semantically descriptive, tell me nothing about what the classes actually apply - they describe what they’re styling, not _how_ they’re styling it. But the long list of Tailwind classes tells me exactly what they do and how they do it, and if for some reason I need to go beyond the LSP to figure out what a class does, the Tailwind docs are miles easier to search than grepping the codebase for “.btn-primary \{“, not that I’ve run into that. In fact, the Tailwind LSP will compute selectors like “[&>div]:hover:border-2” and show you the actual generated CSS selector right in the hover window so you can see what the eventual output will be - it’s not just a dumb lookup of “m-2 is the margin 8px class”

mejutoco 1y ago

There was a time when not having css and html completely separate was considered sacrilege. And having html in javascript would have been a mortal sin. Eons ago I was at a job where we dynamically generated css on the server (php in that project). Anyone would have said: what about separation of concerns? Now everyone says it is best practice to have components with css, html and (gasp) Javascript all in one unit, because someone, for ex. Facebook said it (React). And the truth is it is very useful, and it is another way to structure frontend code. My point is: it is a spectrum and it can be useful to change the styling right there in the browser inspector. That works with tailwind the same as css. And with components, you can hide the repetition, although the browser will still have the repeated classes. Is this better than having css on another file with maybe some unused classes? I have done both and I can see each has pros and cons.

vehemenz 1y ago
The thing is, they were never really separate. The source files were separated, sure, but the way 90% of the world did CSS, there were hidden abstractions relating the class definitions in the .css file and the DOM structure in the .html that weren't documented anywhere.

tshaddox 1y ago

This Chrome extension is widely recommended when using atomic CSS: https://chromewebstore.google.com/detail/atomic-css-devtools/cbjhfeooiomphlikkblgdageenemhpgc https://chromewebstore.google.com/detail/atomic-css-devtools...