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.
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.
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:
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”.
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.
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.
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.
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.
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.
That's a footgun if I've ever seen one.
In my experience it results in more consistent designs because everything must come from what you make available in your tailwinds config.
(but not out of line with your general conduct here, I suppose. I often wonder what people such as yourself get out of it...)
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.
Some people say sure but when are you ever going to change a style? Surprisely more often than hunting every h1
Nobody is writing "random" styles, we just found that selfs sufficient components are more reusable than something that's split out across technologies.
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.
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.
Whether components are a good thing in this particular context is debatable. But you can create them without JS.
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.
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.
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.
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.
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.
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.
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.
Extracting out components and using @apply when I desire is fast and easy too.
https://github.com/WICG/webcomponents/blob/gh-pages/proposal...
https://github.com/WICG/webcomponents/blob/gh-pages/proposal...
Tailwindcss is solving those 3 issues.
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".
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.
I said neither of these and am not interested in debating a strawman.
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.
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.
Since then I directed development on a number of absurdly rich and powerful platforms across telecom and the financial world. We were leading the respective industries when everyone was pushing Java, Flash, XAML/WinForms, etc at various junctures (each coming and faltering). We had a better than native mobile "app" using web tech.
I was one of the early and vigorous public proponents of SVG.
These applications, going back up to two decades ago, demolish the overwhelming bulk of web apps people are working on today in design complexity, actual functionality, and so on.
Yeah, I have a pretty good notion about "modern web technology", and often it feels like farce. Like it's a parody and I'm left wondering if I should say something because I missed the joke. The amazing self-congratulatory praise about, again, trivial nonsense just boggles.
Or, and maybe this is just my old man dementia talking, millions of extremely low-skill developers have flooded into the market, primarily building "web apps". An endless procession of "make trivial stuff easy for really incompetent developers" solutions appear to pander to them -- and their brother-in-arms "make trivial stuff seem complex and engineer-ee" solutions -- and this is a group that finds each of these variations on an obsolete theme revolutionary.
Humorous that multiple people have been triggered by the notepad comment. Yet...many extremely rich pages and apps have been built in exactly such a manner! That this is seen as outlandish is pretty telling.
After dealing with a sea of generally pretty junk libraries and patterns for a while now, I know what I like and what I think works well.
Tailwind is nice. It provides utility css classes to help you write css faster. Trying to do responsive work in regular css is a pita with media queries - tailwind improves on that dramatically. It’s proper regular css, just like you know and love. With a bunch of classes that let you a) tidy things up so the design is a bit more honoured b) give you utilities for common patterns and c) allow you to be more expressive without having to reach for more clumsy css nesting. It’s just css. Old school css. You can give classes your own names like you always did before.
If anything, tailwind is the pendulum swinging back to how things used to be. It’s just being misrepresented here.
Back in the day, before we had all the build pipeline, npm, utility-first, etc css people were already building websites and those also worked just fine.
I sort of agree. There was very little you couldn't do that was a result of the tools to build the sites. The only real constraints were imposed by what technologies were in the standards and which were implemented by browsers.
If you want to build a website today with what is 'normal' tech, you have to learn a whole lot more and people spend tremendous amounts of time in bootstrapping code in order to produce some JavaScript and CSS that in the end provides hardly any added value compared to server-side rendered views with sprinkles of JavaScript.
Apps like Slack are probably an exception to the server-side rendered argument, but I think you'd be better off building those in non-web technology to begin with.
Either way, if you want to spend your days building layers upon layers of abstractions in order to prevent having to fetch some HTML from the server, be my guest.
I had no idea my comment would make so many so insecure.
People used tables for positioning and as containers. More data was present compared to whitespace and mobile reduced sites.
People had different screensizes back than. How do you deal with that? You take a 3x3 cell. You cut a picture into 9 slices. You take the top, left, right and bottom images and make them a background at 100% width (top/bottom) or height.
That is the basics of a simple flexibile container.
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.