I’ve long given up trying to keep up with everything added to the spec since about `display: flex`. There’s just too much stuff, and the shoehorning of features into a syntax/spec from 1996 doesn’t appear to me to be a sustainable long term strategy to facilitate increasingly complex web applications.
Maybe it’s been considered, but some use of namespaces and modules in the syntax could at least help developers opt into specific CSS modules and let other developers know what magic they can expect to find in the stylesheet.
I don't want to make any judgements about you specifically, so this is more of a general observation. It's not meant to be personal or pejoritive.
When the Web exploded onto us the first time (late 90s) html and css were limited, and JavaScript mostly unused, so the door opened to lots of "untrained" [1] people to make a living building Web sites.
Explosion number 2 comes the the aughts, and is characterised by the split of "front end" and "back end". FrontPage, WordPress, and other site builders lower the barrier to entry, and make Web design accessible to the common man.
If one comes up through these ranks then the train of new css, new javascript, even new html can seem daunting.
For those who came in "easy" it just seems like things are getting more and more complex. Whereas to those who are used to "programming is hard", these are fantastic additions which make so much more possible.
The good news is that you dont actually have to keep up. A flex based site is perfectly fine. A marketing company, staffed with creatives, think WordPress is perfect, and discussions about CSS are pretty shallow. They find a theme and move on. The theme-makers however love this progress in css.
So yeah, whether you're writing css or c or whatever the language-of-the-month is this week, stuff moves quickly.
[1] by untrained here, I mean people without programming training. The language of that time was c++ or c, both of which required a deep understanding of programing.
I’m used to programming being “pointer arithmetic, manual memory management, higher kinded types and monads” hard and still find CSS to be hard to understand and use, often going with trial and error.
I mean, I've come from the other end and find manual memory management hard. I've picked up a lot of Rust, but there's still bits around pointer manipulation and bit fiddling where I just try stuff and see what works.
Software development is a big subject. It seems pretty natural to me that if you've mainly focused on one area, you'll have to go back to the basics if you want to do stuff in another area. And that will make things like CSS feel hard for you, but really trivial for me, whereas low-level stuff will be obvious for you, and I'll struggle to get my head around it. That doesn't speak to some objective scale, just personal experiences.
perhaps the problem space of display on an infinite canvas is more difficult than these other things, or, as I think, that many programmers lack a design sense and this is a necessary component of being able to envision what the effects the statements you are writing will actually have the same way you might envision what the results data manipulating code might have on the data.
Are you me? I occasionally have to touch CSS while working on technical docs and just spent more time with CSS than I have in a couple of years. Reading this article completely opened my eyes to how much has changed in this space. I thought I was cool for using flexbox last week.
Flex was added in 2009, but it had bugs as late as 2017. It is one of the problems with adding features as fast as they are. There is no point in having features if they don't work or are broadly supported
Yes. Many years ago I had the time to devote to keeping up with changes to CSS, JS, and all the other languages and technologies I use, but now I have increased responsibilities at work, a family that needs my time, a home that needs maintenance, etc. I simply do not have a minute to spare with updating. Maybe after I retire.
Good resource, w/ useful examples, from a "here's how to start incorporating some of the new stuff" angle. For more of a "building things from first principles" foundation, I continue to recommend https://every-layout.dev.
- From people who know CSS better than I do, do these features make TailwindCSS less useful / necessary? Though I'm sure much of the answer is "TailwindCSS is a different paradigm" since it's basically inline styles, and CSS is basically non-inline styles.
I thought it was a good article but I didn’t think it made tailwind more or less useful. It was largely orthogonal to tailwind.
If you like the ideas in the article you can apply them in tailwind if that suits you just fine. The obvious distinction is that in tailwind you’d be making your edits in the class information vs in a css file.
That’s a lot of red in usage-relative mode. I heard iOS updates are common even for older devices, but I do know macs can’t always update. So Safari Explorer might be a blocker for some time, once again.
> I heard iOS updates are common even for older devices, but I do know macs can’t always update. So Safari Explorer might be a blocker for some time, once again.
Probably not.
The oldest version of macOS that supports Safari 16.5 [1] which supports CSS Nesting is macOS 11 "Big Sur". Big Sur was released November 2020 and runs on Macs as old as the 2013 MacBook Pro.
So even Macs that are 10 years-old running an operating system from nearly 4-years ago will not only get CSS Nesting but tons of other new CSS features that shipped in the prior version, Safari 16.4 [2].
That's good, guess things got a bit better. A few years ago we had a js big in Safari, but the newest Mac (mini I think, one of those that look like a set top box) we had in the company couldn't run a modern enough version of Safari.
Sometimes I think I know everything that I need to know about web dev, but then I read something like this and learn about new features that I didn't know of.
I hope they think about deprecating some features or slowing down on adding features. Letting developers rely on transpilers is great way to keep the core language simple while letting people do anything they want.
It's true, but for any serious project, you set up tool chains for utilizing those files in pipelines for local servers, commit hooks, and build steps.
Things like linters, unit tests, and rules-based code standards would also be included. Development environments have gotten increasingly complicated because CPU time is cheaper than Dev time.
I’ve long given up trying to keep up with everything added to the spec since about `display: flex`. There’s just too much stuff, and the shoehorning of features into a syntax/spec from 1996 doesn’t appear to me to be a sustainable long term strategy to facilitate increasingly complex web applications.
Maybe it’s been considered, but some use of namespaces and modules in the syntax could at least help developers opt into specific CSS modules and let other developers know what magic they can expect to find in the stylesheet.
``` @use grid @use container @use layer
@layer layout { .layout-grid { --layout-grid-min: 30ch; --layout-grid-gap: 3vw;
}@layer layout { :is(.layout-grid, .flex-layout-grid) > * { container: var(--grid-item-container, grid-item) / inline-size; } }
```