Hacker News Reader

Comment by chmod775 | Hacker News Reader

That example also encapsulates everything that wrong with how CSS is used today.

The markup contains no information about what the contents are anymore, so you lose the ability to target anything that is X: for example an email, an avatar within a 'people-card' etc.

HTML/CSS was supposed to separate content from looks. Of course that ship has sailed long ago, since modern day development seems to be insistent and mushing HTML, CSS and JS together in the same file. Looks is logic is content is looks is a mess.

HTML/CSS was also supposed to be re-usable. Now instead the re-usability is within react/angular/etc. components, so you now have to use react and javascript everywhere you want to show similar elements - if you want to have the ability to easily change them later.

Of course this isn't the point. If you have the ability to work with react components, you probably are knowledgeable enough to use CSS.

So the only remaining use-case is "way for non-technical people to write objectively bad HTML and have it look nice".

Which again, is fine. Sometimes bad is good enough when the alternative is nothing at all.

I'm still not a fan.

View on HN

Check out the Tailwind author's reasoning: https://adamwathan.me/css-utility-classes-and-separation-of-...

I find it more compelling than I expected.

The truth of the matter is that as much as the idea of separation of html vs css sounds good, it's so hard that I rarely see it done. Without constant vigilance, you end up with premature abstractions, things you can't actually reuse, and an append-only accumulation of CSS.

The dream sounds good but leaves all the hard details for you to work out yourself. And frankly, after over a decade, I remain unconvinced and ready to look for new ideas.

Breaking the rule with Bootstrap since it first came out never stopped me from building great things, yet trying to obey the rule slowed me down and had me constantly refactoring CSS. It feels like a cargo cult.

We've been pointing to CSS Zen Garden for 17 years as an example of the benefits, but giving everything a class so that you can address it from a .css file isn't the hard part, and that's all the garden shows. The hard parts are organization, maintenance, coming up with a unified strategy, playing CSS whack-a-mole when you change HTML, deciding where to define what, finding where you defined what, etc. The garden demonstrates none of that.

I read that article and it appears that his arguments for developing this framework boil down to: "what if you could create inconsistently designed pages easily?"

That's a footgun if I've ever seen one.

Tailwinds also acts a design system for your site, you have a set of paddings, margins, colors, font sizes, breakpoints, etc that make up your design system.

In my experience it results in more consistent designs because everything must come from what you make available in your tailwinds config.

> The truth of the matter is that as much as the idea of separation of html vs css sounds good

So why not just use <center> and <font>? That was my immediate thought the first time I saw Tailwind HTML: it's the HTML1 tags, but they are now attribute values.

...because they don't compose as well?

But you are correct. The idea of functional css libraries is to go back to putting presentational information in the html. And the justification is that it is a better approach when you are building a webapp with a component library.

for one thing, they are not responsive.

I didn't follow what was wrong with his Option 2 solution. A hybrid approach between that and Option 3, where you define a "base class" like he does in Option 3, but don't use it directly in the HTML, instead use @extend or @mixin to reuse it for the semantic classes that are styled similarly seems like the best of both worlds. A core "style library" like CSS, but you apply to semantic chunks in CSS instead of in the HTML.

That's actually the recommended way to componentize Tailwind using @apply once the styles grow too large and repetitive (no naming convention guidelines as far as I know, though). They got a big improvement in version 2 since now you can @apply styles with media rules and state modifiers like hover.

Tailwind is the first coherent CSS framework that makes that mixin design pattern work in my experience. Before, such designs usually drifted towards a spaghetti meta layer over regular CSS, creating an exponential mess. The added benefit of being able to go inline utility classes -> class names only when you want to (like when you've got a better view of the big picture) should not be underestimated.

The hard parts are organization, maintenance, coming up with a unified strategy, playing CSS whack-a-mole when you change HTML, deciding where to define what, finding where you defined what, etc. The garden demonstrates none of that.

100% this.

The moment I started to see HTML and CSS as a holistic system of layout construction, rather than as simply two separate but complimentary technologies, my productivity in both skyrocketed.

'Bugs' in my CSS became infinitely easier to not only find, but also solve. And the benefits of tools that both unified and abstracted layout construction, like Tailwind, became immediately obvious.

Shameless plug: I talk more about a lot of these mindset shifts and how they've helped me finally feel like I truly understand CSS in a book I'm working on called "How To Debug CSS" [1].

It goes over not only the mindset shifts that have helped me gain a decent level of mastery over CSS, but also shows you how to solve the 50+ most common issues that you'll come across when developing with it. Like when you have an overflow on your page for example, and have no idea what's causing it.

[1] - https://gumroad.com/l/Debbg/z823cp8

I don’t personally mind the plug, but please give something concrete to help us understand what you mean when you say “holistic system of layout construction” and others.

Happy to expand.

One of the concepts I share in the book is on the idea of viewing HTML as a relational structure. Like a database. And how viewing it in that way helps you to better understand positioning (even with CSS). Because re-framing it in this way automatically gets you thinking about your elements, and the CSS that binds them, more holistically.

The most common way that people trip themselves up when working with HTML and CSS is by becoming myopic with regard to the specific section or element they're dealing with, and not seeing the whole forest so to speak. Making them unable to see why a problem in their CSS is happening.

Or to know what they need to do to create a certain thing in their layout.

A lack of a holistic understanding (how elements relate to other elements, and how CSS fits into this), and thereby view is what causes this.

My two latest articles goes into more detail re this:

https://planflow.dev/blog/how-to-get-better-at-css

https://planflow.dev/blog/what-makes-css-hard-to-debug

I hope you understand when I say that your reply still does not contain anything concrete. Nor for the most part do the articles you posted.

I put some significant time trying to understand exactly what you’re going for and it seems like you’re trying to help people shift their high-level thinking, but it’s a lot of words and almost nothing to get my hands on. As someone who needs to try and work with things in order to properly understand them, this material just does not give me any “meat”.

I appreciate the feedback. The reason why it feels like this is because I haven't included any real CSS based examples here (which I do in the book) of what I mean.

These are not easy concepts to digest without visual examples. I will try to edit my posts with some concrete examples to get them to be closer to the book.

Awesome. If/when you do, try to reply here as I’m genuinely curious.

I think the main advantage of Tailwind is actually the fact it's a preset design system, rather than it being utility first.

If you defined a design system upfront you could do practically the same thing that Tailwind does except at a component level. On the flip side, it seems like even in Tailwind it seems like there are opportunities to create a mess.

I'm not a fan of the utility level of abstraction Tailwind is at, but I see the value. It seems wrong to view Tailwind as a CSS solution though, since in my opinion it's actually a design system solution.

The real problem is that tools like this appeal to people who dislike or not willing to learn or to do anything with CSS. And if we accept that tools are written by the authors to save their own problems, then we get what the tools like this are written by people who do not understand/like/whatever CSS. And the cycle continues.

That's just dismissing all of us who like Tailwind /and/ have a decade+ of experience doing all of this 'the right way' without bothering to properly argue. It's a very cheap comment.

(but not out of line with your general conduct here, I suppose. I often wonder what people such as yourself get out of it...)

What do you get out of ad hominem? You are the answer why people such as myself do not "properly argue".

Lol.

> HTML/CSS was supposed to separate content from looks. Of course that ship has sailed long ago, since modern day development seems to be insistent and mushing HTML, CSS and JS together in the same file.

As a developer, what incentive do I have to scrupulously maintain the separation between content and appearance? Users do not appear to demand it, and customers or employers will not demand it either - they might care if the users hassled them about it, but this does not happen.

> HTML/CSS was also supposed to be re-usable. Now instead the re-usability is within react/angular/etc. components, so you now have to use react and javascript everywhere you want to show similar elements - if you want to have the ability to easily change them later.

If HTML/CSS was supposed to be re-usable, then it might have been a good idea to have designed those languages to support the kinds of re-use that are actually needed. One of the useful features of Tailwind, for instance, is that it becomes possible to copy HTML from one page to another while preserving consistent appearance, because all of the information necessary to display the element is contained within the class names. With most CSS, this is not the case: styles will depend on complex selectors, such that an element may appear completely differently depending on its ancestor elements.

The brittleness of CSS leads to various hacks and abstractions, and it is these hacks and abstractions that make re-use difficult. In reality, CSS depends on the structure of the HTML to work properly, and HTML has to be structured to suit the needs of CSS. This makes it hard to write general-purpose CSS that can effectively re-skin a HTML page, and to write HTML that is easy to lay out in the desired manner with pure CSS. It just doesn't work well enough to make the dream of decoupled content/styling workable in enough cases.

If you write using random style tags everywhere the next time you want to change all h1s you have to go file by file.

Some people say sure but when are you ever going to change a style? Surprisely more often than hunting every h1

That is what components are for.

Nobody is writing "random" styles, we just found that selfs sufficient components are more reusable than something that's split out across technologies.

It works fine and have worked for 15+ years.

> HTML/CSS was supposed to separate content from looks.

IMO the problem is that HTML is woefully inadequate for expressing the sort of content we have today on the web.

It’s a document container that we’ve shoe-horned an application platform into. Much of what is displayed on some of the most popular sites can’t even be described as “content”—it’s interface, and that’s where things fall down.

It’s hard to follow semantics when the only option you have is positioning and styling divs. In that regard the style becomes part of the content. Nested divs have no meaning, and there’s no way to give them meaning in the same way that <p> is a paragraph. Aria labels help on the accessibility front, but outside of that the only way to express meaning of something like a modal or a popover is visually.

> Nested divs have no meaning

That's pretty much true now[1], but the original meaning of "div" was "document division"[2] — i.e. they were similar to the current "section" element.

> outside of that the only way to express meaning of something like a modal or a popover is visually.

That is (was?) the point of 'semantic' CSS and the separation of concerns. A div is (now) just a generic block, but a div with an id or a classname means something dammit.

1. https://html.spec.whatwg.org/#the-div-element

2. https://www.w3.org/TR/2018/SPSD-html32-20180315/#div

You don't have to use React and JS to get components. You can still get components with server or build time rendered HTML. About the only time you can't is if you are writing html and css files by hand. If you have some kind of css preprocessing going on, you can still get there with Tailwind's @apply with hand written html.

Whether components are a good thing in this particular context is debatable. But you can create them without JS.

What templating library do you use that provides components? And no, partials are not a substitution.

Stencil to build WebComponents ?

Why aren't partials a substitution in the context of Tailwind? The only goal is to keep classes DRY.

You can do server-side JSX I believe. Almost all front-end frameworks (eg Vue, Svelte, Riot) support SSR but you have to use JS on the server. Why PHP/Python haven't caught on and reworked their template syntax to look like nestable tag components with props is beyond me. Maybe an idea for a new open-source lib, JSX for PHP?

> If you have the ability to work with react components, you probably are knowledgeable enough to use CSS.

If you are building a webapp, nobody is knowledgeable enough to use css because css is broken for this use case. Tailwindcss is absolutely aimed at css experts. There is nothing for non-technical people in tailwindcss because it exposes all the existing css properties, just with a selection of values.

and that's a big reason for why I love it! I'm so tired of seeing a bunch of divs being added to components just to get them aligned to the page's main grid. Give me a couple of classes for applying gutter width and as either padding/margin/gap and I'll apply it as actually needed!

Please excuse if my questions seem rude, but I'm very curious:

1. How many UIs for websites / webapps have you written by yourself?

2. How many while working within a team?

I have a modest web UI dev experience myself and Tailwind doesn't seem that crazy to me. I've tried the techniques you seem to be advocating, but the idea of them sounded better than they actually were in practice.

When you are asking questions like those on HN of all places there's a decent risk you picked the wrong hill to die on.

Avoid trying to get into a situation where people are just quoting their credentials at each other, playing a game of who will run out things to list first, being none the wiser once they're finally done a decade from now.

In case it wasn't meant the way I believe your comment was meant, you probably still shouldn't judge my comment by whatever I did in the past. If my personal experience was somehow relevant, I would have included references.

It was an honest question. I didn't try to "quote my credentials" or claim that I'm a frontend expert. If anything I meant to say that my frontend experience is limited.

My point was that: in this case the experience might be relevant, because the ideals of traditional HTML/CSS sound good, but don't turn out as great in practice.

The way I see it, some commenters here keep holding on to their 'html is content, css is styling' mantra because, well, all of us old-schoolers have held to that for a long time.

Some of us realized it never really works in practice, and never really made sense in the first place (as many here and in the past have argued). Others decide to hold on to the mantra and feel a need to be arrogant or dismissive to those they disagree with.

I respect fellow front-enders who are happy doing things their way. Not everyone needs Tailwind. But it's frustrating to and honestly somewhat baffling to see a bunch of them dig their heels in the sand and defend their approach by assuming all the rest of us just "don't know CSS". It's a minority, but a vocal one.

If you're working on the content and the looks at the same time, and you don't 100% know where the project is going, it's helpful to consider them as a combined unit, so you can alter and/or discard that unit without delving into separate CSS and HTML trees. (Or, worse, not being sure what HTML or CSS you should alter or throw away when its corresponding CSS or HTML ends up in the garbage).

Separate content and presentation is a great final outcome, but when a project is in flux as it's being built, it's a burden.

EDIT: Moreover, it's not just that the "ship has sailed long ago"; the ship was attacked and sunk. Frameworks that combine CSS and HTML aren't doing so out of neglect; they're aggressively rejecting the separate looks/content paradigm.

I'm not a fan either. The always cited rationale does not click with me, it even pushes me more away from the concept.

For me it tells in short: "Well, you could have nice and clean semantic CSS if you created and followed a design doc. Use tailwind and cryptic classes that could be whatever in any other project, if you don't bother about design docs."

I believe things like tailwind make developers less knowledgable of their craft. This has a big advantage though - you can have more people doing code for you, they don't need to know CSS at all to some extent.

Having used it for the better part of a year, I can tell you that using Tailwind has vastly improved my CSS. Now, I'm basically using CSS all the time, with the ability to do media queries quickly; so I guess my thoughts are the exact opposite- it helps you learn CSS even better than you ever would have.

Extracting out components and using @apply when I desire is fast and easy too.

+1 from me. When I started as the sole (junior) Dev at work I wasn't very good with css. I made use of things like bootstrap etc heavily. Eventually I found tailwind and started using that to augment what I was building, and now I use it solely.Thanks to tailwind I have a much better understanding of css.

there is nothing stopping you from using @apply in custom classes if you really want to - or using data attributes for targeting, depending on your use case.

Frameworks like Tailwind CSS will go the way of the dodo, once CSS gets proper scoping, isolation and inheritance. (No JS needed). Then you can truly have semantic HTML with presentational stuff separated cleanly without needing any toolchain or 1k+ deps library to do this.

When is that going to happen?

Ok that sounds fantastic, how long should we wait until that's the case and is adopted by all browsers and is backward compatible? That's the issue here.

Ballpark guess - less than 5 years. There is the work ongoing on CSS and HTM modules at:

https://github.com/WICG/webcomponents/blob/gh-pages/proposal...

Scoping is one part of the problem. Complex selector is another one. Design consistency is yet another one.

Tailwindcss is solving those 3 issues.

One of the reasons I moved away from web presentation projects is overwhelming frustration at just this: There is no other area of technology where there is so much running to stand still: Massive amounts of make-work and "innovation" to do pretty much exactly what people did in 1999. It is extraordinary how many libraries and magical solutions can be embedded to create something that a 15 year old in Notepad threw together with basic CSS and HMTL twenty years ago.

I apologize to the web community at large for the snarky, dismissive tone, but seriously it just seems extraordinary how it's just an endless march of new approaches and new silver bullets to do absolutely trivial things. Arguments about maintainability or extensibility fall by the wayside when that trend du jour is discarded next month because now it's being rebuilt on Backwind on the Spry framework using the TypelessScript stack, etc.

I am absolutely in awe at the advancement in virtually every other area of technology, almost all of it worth every bit of attention and learning. Where we are building enormous, hugely complex projects. Then we have the web where after countless "toss it all and throw it all away" cycles, the community is heralding this. This is what has, to quote the linked article, " taken the frontend world by storm".

I have no idea about Tailwind and have never used it. That being said, your apprehension at making this statement is valid. To call it "absolutely trivial" is absurdly dismissive. Just because you don't think design and layout are important or difficult does not make it so. I know several designers that would take serious offense to you comparing their work to that of a 15 year old's throwaway.

Visualization and UI design are a maturing field, and the constant iteration on HTML and CSS is to support the designer's ability to take their vision and realize it on the page.

"Just because you don't think design and layout are not important or difficult"

I said neither of these and am not interested in debating a strawman.

What exactly do you think all these libraries and magical solutions are trying to address then? 15 year olds putting a spinning link gif on a static HTML page?

In fairness those pages offered more content per square inch than modern whitespace centric design.

They try do address the fear of dealing with CSS by people who do not know nor want to know it.

I'm not sure why your dismissive tone is somehow upvoted here. I rarely comment and do not see how this as a strawman. If this is not a strawman, then explain how a 15yo with notepad can do the same as these solutions with a defensible stance. Is it because the person replying to you wasn't nice and give you fluffy kind words? I'm not understanding why the thin skin here. If you make a bold statement, it should be able to be backed up. Problem is here that you can't, so just ad hominem instead.

You pulled this account out -- one that had been untouched for seemingly seven years -- to make these insults?

If you can't separate design from Yet Another Trivial Variation on a Theme, that's a you problem. Trying to conflate the two is disingenuous.

Yep, 7 years. Reflective of the quality of conversation here, where I read daily but don't interact. However, seeing quality lower even further by baseless well-written opinions prompted me to respond. I'm especially disappointed to see when someone challenges an opinion that it got downvoted. This type of voting behavior makes having a dialog impossible. I'm not even saying you're wrong here, just the reaction is lacking substance.

I stated a general sentiment of the trends in web development, where there is an extraordinary amount of work to effectively reinvent the wheel, and then to uninvent the wheel and herald why using a cube is superior, until eventually you herald the wheel again. It's bizarre.

The work product of teams chasing each of these innovations is virtually unchanged, decade over decade. Which is exactly why you see a circular procession of revolutions, each displacing the last to the dustbin of history, while empirically offering nothing unique.

Clearly there are a lot of people that empathize with it. There is nothing "baseless" about that, however uncomfortable some find it.

Bizarre that you claimed that my comment was an "ad hominem", when your own reply included multiple personal attacks and mine included none. They (you?) literally tried to discount my comment by contriving a strawman that if this application and management of CSS is trivial, therefore I'm saying that design is trivial. That is absurd, and is completely orthogonal.

Your entire criticism boils down to "what waste of time trying to solve trivial things" without defining what you regard as trivial.

It doesn't, but you are welcome to enjoy your own bias in your interpretation.

If it doesn't, surely, you can define what you mean by "trivial things"?

Reply on news.ycombinator.com