I know, many folks love css, but I find it a big mental discontinuity from html and js. It's solving a different problem
This is actually the misconception that leads to confusion with (and ultimately, poorly written) CSS.
It comes from a misunderstanding of what creating a web page actually is.
As Alan Kay once remarked, “A change of perspective is worth 80 IQ points.”
This is no less true with CSS.
Most developers view CSS an annoying 'styling' language, that's 'not really a programming language'. Which separates it in your mind from the engineering frame of view that tends to excite you as a developer.
This makes CSS tedious to use.
In truth, HTML and CSS are parts of a holistic language of layout construction. They work in unison, not as individual components. Very much an engineering toolset. Just that the problems to be solved are more visual in nature than you're probably used to.
Instead of seeing CSS as an annoying way to 'style' pages, see it instead as a visual programming language for constructing visual guides (UI's) for your user.
You don't 'style' pages, you 'construct' and 'architect' them. It sounds weird to use these words, but they have a massive effect in changing your perception of what you're doing. And that has a massive effect on your impression and willingness to learn how to do it well.
I think that understanding this is one of the key differentiators between developers who are good with CSS and those that struggle.
Tools like TailwindCSS (that lead to a massive increase in both productivity with CSS as well layout maintanability) are based on this fundamental premise.
Sidenote: I'm also working on a book that aims to help you gain mastery over CSS, showing you how to truly understand it, by learning how to debug its most common issues as well as re-framing how you see it in the way I've described above. You can check that out here: https://gumroad.com/l/Debbg/z823cp8.
> Instead of seeing CSS as an annoying way to 'style' pages, see it instead as a visual programming language for constructing visual guides (UI's) for your user.
> You don't 'style' pages, you 'construct' and 'architect' them. It sounds weird to use these words, but they have a massive effect in changing your perception of what you're doing. And that has a massive effect on your impression and willingness to learn how to do it well.
I honestly don't understand what this means (I read the corresponding blog post but am still confused, unfortunately). Could you expand, possibly?
Have you ever found that your enthusiasm towards something changed once somebody explained it to you from a different perspective?
A lot of the problem developers have with CSS, has to do with the way they see it.
Developers don't typically like to 'design' things in the artsy sort of way. But they do like to engineer them. CSS can be viewed from both of these perspectives very accurately.
The latter however, generates more enthusiasm for the developer. And enthusiasm is key to everything else.
Yeah I mean, sure you 'construct' and 'architect' the web page but you definitely still 'style' it and using different words doesn't make CSS any less annoying to use
Semantics do actually matter quite a bit. They are what ultimately determine your frame of reference, and ultimately, how you use a thing.
It's more of a mental model with which to see it. If you view a webpage as something to be 'architected', rather than as simply something to be 'styled', every else you do (as well as how you feel when you're doing it) changes.
I am happy that you think that works for you but I have a hard time believing that it will have any actual meaningful effect for most people. You can describe an activity in any different set of synonyms but the activity at its core does not change.
Your approach reminds me of a cross between "neurolinguistic programming" and the character Tom Sawyer when he convinces everyone that painting a fence is fun.
> You don't 'style' pages, you 'construct' and 'architect' them.
> I think that understanding this is one of the key differentiators between developers who are good with CSS and those that struggle.
Yeah, no.
HTML is a single-root hierarchy whose only primary job is to display text and maybe some images. That's it and it pretty much sucks even at this job.
CSS is and will remain a bunch of hacks trying to force the web page into something it's not. Saying that CSS and HTML are meant to be used together to construct and architect pages is some serious re-writing of history and evolution of CSS and some impressive mental gymnastics.
For a great immediate overview why that is, it's enough to look at this page: https://csstriggers.com When changing text-shadow causes your entire page to reflow and repaint, there's no "architecting" or "constructing". It's piling hacks on top of each other in the hopes it somehow works.
For most of its life since inception in 1996 CSS was nothing but simple styling of HTML pages. There were a few feeble attempts like `display:float` and `position:absolute` to pretend it's not, but the enduring resilience of the Holy Grail kept obliterating that idea. This changed around 2008 with the meteoritic rise of mobile phones and mobile apps (thanks, Apple and Google). It still took w3c 5 years to come up with a solution that could barely place boxes in a relative position to each other without increasing developer suicide rates. I'm talking about flexbox, of course.
Side note: Terrainformatica's Sciter had already had a solution to this for several years, and it was simpler, faster, and required significantly less cognitive load: [1] Not to mention Cassowary which was proposed all the way back in 1999 (can't find the link now).
I think it took MS and then w3c a combined of 10 years to get Grid off the ground.
And all that to be able to finally say: hey, we can barely position an element vertically. Of course, they still can't, as the OP link demonstrates: you need a brand new layout module + a brand new alignment directive to achieve something most GUI libraries in the world have had since Palo Alto's Xerox in 1979. And yeah, it still has cons that has to be remedied by "Gentle Flex".
And, of course, all of this is as brittle as the tail of Prince Rupert's drop. You even glance at it sideways, and it breaks in countless unimaginable ways. Attempt a slightly different layout? Just lift the layout with the markup and attempt to place it in a different position on the page? Adjust sizes in the most minuscule way? Place these things side-by-side? Oh, great constructing and architecting work guys, everything is broken.
And, of course, it cannot be in any way, shape or form properly refactored because it's a flat system where everything is global, styling a single tree tailored to display text and images.
As a result 12 (sic!) new flexbox-only-properties were added to already huge CSS property namespace (200 properties and counting). All that just to make FlexBox anyhow useful.
But the biggest problem of the solution is that the flexbox breaks existing CSS box model – dimensions of elements are now defined not just by width/height properties but bunch of others like align-items and align-self.
Go figure out why “align” property shall change dimensions and why explicit height:100px declaration shall be ignored
Languages (and technologies in general) evolve. And as they do, it's helpful to evolve your perspective towards them alongside it.
Mobile phones started off as simply ways to call people. Are they not much more than that now? Would approaching them with only their original perspective be as helpful today?
No. The perspective has completely changed. Now, the more accurate one would be to approach them as full-blown computers.
> HTML is a single-root hierarchy whose only primary job is to display text and maybe some images. That's it and it pretty much sucks even at this job.
While HTML and CSS started in the ways that you've described. That's not what they are for now.
> Saying that CSS and HTML are meant to be used together to construct and architect pages is some serious re-writing of history and evolution of CSS and some impressive mental gymnastics.
I'm not rewriting history. I'm re-framing the CURRENT perspective of these technologies, in a way that is much more helpful. What use does framing HTML and CSS from the perspective of their origins have?
How does this help you create with it today?
With modern considerations that are more in the realm of architectural thinking than they were before?
> While HTML and CSS started in the ways that you've described. That's not what they are for now.
Has HTML eveolvd beyond a single tree? No. Has HTML evolved beyond displaying (barely) just text and images? Also, no [1]. Have HTML and CSS evolved to a point where it doesn't involve a reflow/repaint of the entire page or large chunks of a page to do the simplest things? Also, no. Have there been significant updates to the DOM model? No.
> What use does framing HTML and CSS from the perspective of their origins have?
It helps you understand what the are, not what people pretend they are. It also helps you understand why things are they way they are, why so many things are complex, or impossible, or interact in unintuitive ways with each other, or why a 10-page essay on how to center an element ends up with a yet another "gentle flex" hack reminiscent of the "Search for the Holy Grail Layout" of 10 years ago.
Because no matter how many times you use "holistic" and "unison" in your speeches, it doesn't change what HTML + CSS are essentially are at their very core that permeates everything: a way to display (rather poorly) static content that consists of text and a few images, in as few render passes as possible (because it was developed for the 90s era computers). Everything else is a series of gargantuan efforts costing millions of dollars to try and mold them into something they are not.
[1] There is a reason why most UI frameworks for the web (doesn't matter whether it's pure CSS or it's Javascript through and through) implement the same half-a-dozen to a dozen components: a button, a label, a badge, breadcrumbs, a text input. Very few dare to implement a date picker. Even fewer go for complex elements (actually working accessible modal dialogs, virtual lists, tree views etc.). Because the moment you step outside the "text + images" capabilities of HTML, you're screwed. And no amount of hacks added to CSS can help you with that. I won't even mention the impossibility of high-performance animations. Sure, you can CSS-transform something... as long as the original element stays in place and never moves because actually doing proper stuff in "CSS and HTML that's not the same now" is just as expensive and nearly impossible as it ever was [1.1]
This is actually the misconception that leads to confusion with (and ultimately, poorly written) CSS.
It comes from a misunderstanding of what creating a web page actually is.
As Alan Kay once remarked, “A change of perspective is worth 80 IQ points.”
This is no less true with CSS.
Most developers view CSS an annoying 'styling' language, that's 'not really a programming language'. Which separates it in your mind from the engineering frame of view that tends to excite you as a developer.
This makes CSS tedious to use.
In truth, HTML and CSS are parts of a holistic language of layout construction. They work in unison, not as individual components. Very much an engineering toolset. Just that the problems to be solved are more visual in nature than you're probably used to.
Instead of seeing CSS as an annoying way to 'style' pages, see it instead as a visual programming language for constructing visual guides (UI's) for your user.
You don't 'style' pages, you 'construct' and 'architect' them. It sounds weird to use these words, but they have a massive effect in changing your perception of what you're doing. And that has a massive effect on your impression and willingness to learn how to do it well.
I think that understanding this is one of the key differentiators between developers who are good with CSS and those that struggle.
Tools like TailwindCSS (that lead to a massive increase in both productivity with CSS as well layout maintanability) are based on this fundamental premise.
I expand on this more in a recent post called "How To Get Better At CSS", which you can read here: https://planflow.dev/blog/how-to-get-better-at-css
Sidenote: I'm also working on a book that aims to help you gain mastery over CSS, showing you how to truly understand it, by learning how to debug its most common issues as well as re-framing how you see it in the way I've described above. You can check that out here: https://gumroad.com/l/Debbg/z823cp8.