Hacker News Reader

Hacker News

Comment by matheusmoreira | Hacker News Reader

Parent Full thread

matheusmoreira

> mapped one class to one CSS rule

So they essentially reinvented the style attribute in a less verbose form?

View on HN

Less verbose? Ha, far from it. Look at the tailwind examples. One div tag now has 6 or more classes attached

Well I suppose it's less verbose than a lengthy style="..." attribute that accomplishes the same thing.

Now it's a lengthy css instead. It seems to me we are going backwards...

Out of interest, have you built anything non-trivial with tailwind?

I've used CSS, and Tailwind and not worrying about naming everything correctly and not skipping around different files is a dream for me. Perhaps that's my brain, Idk.

Further I have gone over old code, and haven't had any problem with maintainability

> Well I suppose it's less verbose than a lengthy style="..." attribute that accomplishes the same thing.

It's not actually the same thing. What you're talking about is inline styling which takes precedence over class-based styling. It's generally considered bad practice to rely on inline styles. The traditional approach is `style="card"` not `style="...a bunch of rules..."`

  <div class="block text-black">...</div>
  <div style="display: block; color: black;">...</div>

Looks like the same thing to me. Only shorter.

With traditional css you'd most likely have a class for all the relevant attributes.

Of course. That's how I learned CSS and how I wrote the CSS for my site. Apparently that's not how things are done these days. People have one class for every property and value combination now and essentially write the entire class inside the class="..." attribute. Can't understand why.

Like I said. It's not at all the same thing. Inline styles have different behavior from class-based styling

Some of the other 10% is stuff around theming and design systems. This isn't something that injects cleanly into inline styles. Also media queries and hover states etc can't be done inline.

If it's a reinvention it's objectively better at least.

I think you're confused. What they're saying is it's a reinvention of

  ```css
   .card {
     ...
   }
  ```
  ```html
   <div class="card" />
  ```

RATHER than a reinvention of

  ```html
   <div style="..." />
  ```

I meant this tailwind framework looks like a reinvention of style="..." inline styles.

  <div class="block">...</div>
  <div style="display: block;">...</div>

https://tailwindcss.com/docs/display

So we've gone from inline styling to separating markup and presentation with CSS but now we've gone back to inline styling.

The whole separating markup from presentation doesn't quite work for any non trivial web-app type of webpage.

Because the presentation affects markup. You'll have to add wrapping divs to accomplish any kind of complex layout for example.

Once you can't separate it in your mental space, it doesn't matter that its in two different files.

But the solution is to turn CSS into inline styles?

> You'll have to add wrapping divs to accomplish any kind of complex layout for example.

I don't know about that. I think selectors are pretty powerful. Have managed to avoid littering the HTML with structural nodes by using them creatively. CSS has gained a huge number of features since I first learned it, there's even better ways to do stuff now.

You can think of it like the style attribute, but with support for CSS media queries, pseudo classes, variables and everything else. If the style attribute let you do that from the beginning of the web, would we have ever felt the need for separate stylesheets? Web development might have turned out quite different.

Yes, along with the variations. So you can do things like “text-green hover:text-red”

Which was always what anyone with any sense wanted. CSS selectors were a mistake, no-one actually writes web pages like the CSS Zen Garden nor should they. The only problem with inline styling was the verbosity (and even then, we've had transparent compression in HTTP for about 30 years now).

I think it's nice I can change "color: red" to "color: blue" and "padding: 1rem" to "padding: 1.5rem" in one place and have it take effect everywhere it's relevant.

You can do this with CSS variables now I suppose, but this very quickly becomes "CSS classes, but with extra steps".

> I think it's nice I can change "color: red" to "color: blue" and "padding: 1rem" to "padding: 1.5rem" in one place and have it take effect everywhere it's relevant.

I agree, but that place is normally the code/templating engine that generates your webpage. So it really shouldn't matter if it's repeated on the wire.

> You can do this with CSS variables now I suppose, but this very quickly becomes "CSS classes, but with extra steps".

Variables are much simpler and easier to understand than selectors.

> CSS selectors were a mistake, no-one actually writes web pages like the CSS Zen Garden nor should they.

I see, we finally reached the root of the issue.

Why are CSS selectors a mistake? Doesn't seem that way to me. Why shouldn't I use them?

Complete lack of encapsulation. You never know when changing one element is going to change another, seemingly unrelated element - e.g. you add a class to a high-level element expecting to get a border around your page, and it gives you a border around your page but also around some small elements on your page that are picked up by that same selector. You can't reliably reuse your styling or components between pages, because the exact same element placed in two different pages might end up with radically different styling.

> You never know when changing one element is going to change another, seemingly unrelated element

Isn't this a symptom of the selectors not being specific enough?

> You can't reliably reuse your styling or components between pages, because the exact same element placed in two different pages might end up with radically different styling

Can you give concrete examples of this happening?

I can provide an example I think is a good use case for highly specific selectors: turning HTML lists into file system trees.

https://www.matheusmoreira.com/css/tree.css

  ul.tree,
  ul.tree ul {
    list-style-type: none;
    padding: 0;
  }

  ul.tree li {
    margin-left: 1em;
    border-left: 2px solid var(--tree-color);
  }

  ul.tree li code {
    display: block;
    position: relative;
    padding-left: 1em;
    padding-bottom: 0;
    line-height: 1em;
  }

  ul.tree li:not(ul.tree > li:first-child) code::before {
    content: "";
    position: absolute;
    left: -2px;
    width: 0.75em;
    height: 0.5em;
    border: 2px solid var(--tree-color);
    border-top: 0 none transparent;
    border-right: 0 none transparent;
  }

  ul.tree li:last-child {
    border-left: 2px solid transparent;
  }

  ul.tree li:has(ul) > code::after {
    content: "/";
  }

  <ul class="tree">
    <li><code>~/.files</code>
        <ul>
          <li><code>~</code>
              <ul>
                <li><code>.bash_profile</code></li>
                <li><code>.bashrc</code></li>
                <li><code>.vimrc</code></li>
                <li><code>...</code></li>
              </ul>
          </li>
          <li><code>GNUmakefile</code></li>
        </ul>
    </li>
  </ul>

That sort of thing feels like a perfect fit for CSS selectors to me. I admit it's not a super complex design (or even a beautiful one, I suck at design) but it does demonstrate the value of selectors.

> Isn't this a symptom of the selectors not being specific enough?

Well, yeah, but that's a "you're holding it wrong" argument. If you make your selectors specific enough then they will apply to the right elements, and if they applied to the wrong elements, well, they weren't specific enough. In practice people resort to only ever using a classname as a selector because anything else is too likely to break; there's no way to find out which selectors apply to which elements or which elements are covered by which selectors (e.g. you can't do the equivalent of "find references" on a variable).

> Can you give concrete examples of this happening?

Only on the level of, like, "my company's whole webapp" (but I've seen it cause real bugs in prod if that's what you're getting at). Getting surprised by which selectors get applied isn't a problem you can show in small examples, because it doesn't happen with small examples; it's only when the selectors and DOMs are too complex to keep in your head that you have a problem.

> That sort of thing feels like a perfect fit for CSS selectors to me.

Why does it need selectors though? It doesn't change based things at higher level (which is the failed ideology that the likes of the CSS Zen Garden were pushing - the idea that you want your component's styling to magically change to fit in with the page it's on or what's happening around it). What are you doing here that you couldn't do with a self-contained component that knew how to style itself?

Reply on news.ycombinator.com