There are two kinds of documentation: there's a list of all the individual things you can do, and there's a "The fundamental abstraction is this". The second is rare, and rarely done correctly, and much more important.

A lot of people assume that X is like Y, but with Z, and they know Y, so they just need to learn about Z. A lot of time that isn't true, the fundamentals are different. The natural way do perform W in Y might be profoundly wrong in X. Examples:

* git is like subversion, but distributed.

* C++ is like C, but with classes.

* C++ is like Java, but you have to remember to delete stuff.

I love git. I love C++. I think these things are the bee's knees. They're so simple and elegant. But I totally understand how people think they're arcane eldritch horrors when you're holding the sword by the pointy end.

In most cases, I'd settle for "what problem this is trying to solve" (although this is obvious for CSS, it isn't nearly as obvious for things like React and Vue).

How many people here could explain the link between Working Memory and React.js?

The issue for me is the format these courses and resources take. CSS is the most jam packed with non-intuitive technology I've met. How many dozens of pages or segments of video would I have to go through in a course to learn what the author in OP summarised in two or three sentences? Any time I've considered the structured approach for something like CSS, the material drones on and on with technically correct explanations and example code, but somehow against the odds, almost nothing of substance.

Worse yet are the top google result reference resources. Look no further than the top result for "css grid" if you're in the mood to claw your brain from its stem, and flush it down the toilet.

Link: https://css-tricks.com/snippets/css/complete-guide-grid/

Behold, 8 zillion words and symbols across 7 trillion seemingly randomly organised boxes full of both all of the information, and simultaneously none of the information, about css grids.

Which brings me to where I am now, cobbling. It's more effective for me to cobble, than to spend an entire day figuring out css grids "the right way". If the going gets tough I'll just use some grid tool, or look up some sandbox examples, and be on my way.

If there was more material like the OP, and someone organised it well, well, I'd actually get around to learning it rather than cobbling. It's the best bit of writing I've ever seen on CSS. This is shocking. Not that there is anything wrong with the writing, but it's very, very simple. What on earth have all of the other CSS wizards with basic writing skills been doing? Confusing the issue, that's what.

Which leads me to a sort of meta frustration with learning CSS. I know it's not hard, I know that if someone just wrote about it even half decently it would take only a moment to digest each concept, but watching learner-disconnected authors create resources I can tell have lost sight of what it's like to learn, turns me off.

This was solved trivially by just reading the history of CSS. It was shocking to finally have made clear all of the quirks and weird aspects of CSS that always made it difficult for me to connect the dots and feel myself lost in a messy tangled up language.

By far the best source I went through was found here: https://news.ycombinator.com/item?id=22215931 - it's a long read, but extremely enlightening!

https://www.w3.org/Style/CSS20/history.html was also useful.

I find it very difficult to learn the whats and hows of a new thing without the whys. I tend to construct mental frameworks of things, revising the inaccurate bits as I go, until theory starts meeting practice. (I always did poorly with math "teachers" whose method was, "doesn't matter, just do it." But it did take a while to realize that they were failing, not me.)

So when I encounter complicated, new things with a history, I usually try to start with at least a bit of the history.

It absolutely is.

The web was meant for static documents and some link magic.

Now allmost every complex programm can run in the browser with web technologies. And in the time between you had lots of powerful organisations with their own agenda, as well as millions of single developers with a agenda and a loud voice. How could a sane, clear spec be made, under these circumstances?

Besides, it would be very hard, to make a clean spec that satisfies the needs of the whole population. So by now I say, all in all, it works pretty good.

Serious answer: By respecting and supporting the organisation that had for a long time codified realistic web standards reasonably well. When the Web was younger, you could (and many of us did) learn all you needed to know about things like HTML and CSS by reading the documentation produced by the W3C. In many cases, the official recommendations themselves (the documents that were informally called "web standards") were very readable and short enough for normal developers to go through the whole thing.

And no. I don't think you can expect the whole world to wait for some spec commitee.

The whole ecosystem reminds me of why I did not study synthetic biology or medicine. I prefer the systems I work with not to have evolved but to have been designed by some intelligence with a limited memory for random details.

It's interesting, because that's my go to resource for CSS Grid. I find it super handy when I forget something. Although, I'm not learning grid, I'm using it.

Precisely. What CSS-Tricks calls a guide is actually almost entirely a reference. It makes a tolerable reference if you already know what you’re looking for. It’s a poor reference if you don’t know what you’re looking for because it’s insufficiently structured and takes waaaaay too much scrolling to explore. (It used to be more manageable—it used to be more a guide. It has been allowed to grow far beyond a healthy point.) And it’s atrocious as a guide.

And, typically, there are several levels of textbook. e.g. high school, then freshman physics, undergrad electrodynamics, then Jackson, then specialist references.

My point is you go over the subject completely several times, at increasing levels of sophistication.

See also: https://css-tricks.com/lets-define-exactly-atomic-css/ "Atomic CSS is the approach to CSS architecture that favors small, single-purpose classes with names based on visual function."

Or from: https://acss.io/ "CSS is a critical piece of the frontend toolkit, but it's hard to manage, especially in large projects. Styles are written in a global scope, which is narrowed through complex selectors. Specificity issues, redundancy, bloat, and maintenance can become a nightmare. And modular, component-based projects only add to the complexity. Atomic CSS enables you to style directly in your components, avoiding the headache of managing stylesheets. Most approaches to styling inside components rely on inline styles, which are limiting. Atomic CSS, like inline styles, offers single-purpose units of style, but applied via classes. This allows for the use of handy things such as media queries, contextual styling and pseudo-classes. The lower specificity of classes also allows for easier overrides. And the short, predictable classnames are highly reusable and compress well."

Mostly though, Atomic CSS is a state of mind or design pattern. So you can do it from scratch without support from something like Tachyons etc. -- but it helps.

You might even find it fits right in with your "cobbling" style of development. As an example, if you want to make some text red, you add the style "red" to it. If you want a border all around something, add a "ba" class. If you develop using HyperScript (like from Mithril) to define your UIs, code might look like this: h("div.red.ba", "This is red and has a border")

I refer to the Tachyons style sheet as essentially a menu of options: https://github.com/tachyons-css/tachyons/blob/master/css/tac...

In the rare case something is missing I do an inline style or add something to a single supplemental stylesheet written in a similar way.

There is also a verbose version of Tachyons without the abbreviations, so "ba" would be "border-all" (though I prefer the abbreviations): https://github.com/tachyons-css/tachyons-verbose/blob/master...

I am a front-end dev by trade and I could really easily say similar things about the tech stack you work with daily.

If you want a good reference and a learning guide start with this: https://developer.mozilla.org/en-US/docs/Web/CSS it is what us professional use.

For us professionals that use CSS in our jobs, that have put the same amount of hours into front end technology as you have done for back-end, CSS is a perfectly cromulent technology. It is easy to work with, it is intuitive, it is easy to find a good reference (go to MDN not random blog posts from people that are admittedly not masters of the craft).

If I try to cobble together a back-end I expect to be frustrated with it, I expect not to be able to do everything, I expect I’d need to find poor example and try to hammer them in to fit my needs, I don’t expect to be able to understand all the example snippets. Why are you on your high horse judging my tech stack this way?

If you need a good well crafted front-end for your project, you should hire a professional front-end developer. Or find a friend who is one that is willing to it in their spare time. Or spend a few thousand hours learning and mastering the craft. Alternatively you can cobble together a good-enough front-end that works, just don’t complain about how hard it is because “technology hard wheee wheee”. Us professionals use it every day and are fine with it.

Multiple accounts of people not in your position telling you a problem exists. Ok, great, you worked through it. Doesn't mean it's as good as it should be.

I am here to argue that this sort of attitude is problematic. If you browse through this thread you will find no shortage of comments describing how absolutely basic this article is (and a little void of insight, and a little out dated), and that there are people in the industry getting six figures while not knowing this stuff. Frankly it is a little insulting. And I think the attitude that you presented above is part of the problem. There definitely exists a lack of respect for the craft of front-end development within our industry. This sort of attitude is not helping.

There is xenophobia involved in people's attitudes toward kebabs. It doesn't change the impact of phosphates on the human body.

Here: https://www.bbc.co.uk/news/world-europe-42238363

Your argument doesn't change the impact of poorly-encapsulated complexity on the brains and mental health of your fellow programmers.

https://blog.codinghorror.com/programmers-and-chefs/

> Well you come across as an outsider telling us that the tools that we use—and do a fine job with—are no good, and that our literature sucks.

https://en.wikipedia.org/wiki/The_Jungle

---------

Backend programming has this problem too. So does systems programming. The problem of unencapsulated complexity is core to the craft of software engineering.

So is joining the fight against this problem. https://tonyarcieri.com/would-rust-have-prevented-heartbleed...

Surely the point is that you shouldn't need to spend thousands of hours "mastering" something like CSS? It's not that complicated and it's not that important. If you told a developer working on desktop or mobile applications that they'd need to spend years "mastering" the design tools in whatever GUI framework they were using before they'd be able to independently build a good user interface, you'd be ridiculed.

Anyone with the aptitude and interest to become a web developer, which isn't a particularly high bar as technologies go, should be able to get the hang of all the important parts of modern CSS in at most a week even starting from scratch. The fact that we don't reliably train new developers up that efficiently is a damning indictment of the current state of the industry.

After spending a few hours reading up on topics I thought would be relevant, I find that I am significantly more productive with CSS. Instead of trying to find answers on google, I find that I’m better equipped to build things and diagnose issues on my own.

The amount of suffering I've endured in Latex, PDF, different native layout systems, or even React Native's slightly restricted version of CSS that would have been resolved by a stylesheet is immense.

One under-appreciated value that actual books have over online documentation is that you know immediately what order you're supposed to read them in.

I feel like it's getting both better and worse now with docs getting better in general(no of times I end up on stackoverflow has gone down significantly), however a lot of times I end up on medium posts with a list of steps and absolutely zero reason why. Whenever I try cobbling from those articles, I end up very frustrated

- regexps (this is a big one, being able to write a complex regexp without thinking about it is amazing)

- Git

- basic JS when it was mainly used to add snow on your page

Taking the time to properly learn things is extremely valuable.

CSS suffers massively from this info overload.

What I tell every new programmer who will listen, is that they should first grasp the absolute basic building blocks, and then learn to read the docs. That's really all you need. Unless the particular language or technology their are using sucks, you can essentially compose anything from the basics. Once you've done that, the sortcuts and sugar you learn naturally actually make sense, rather than appear before you as spooky magic boxes and incantations.

My ideal CSS course would just be the absolute basics of syntax and concepts, a primer on understanding and incorporating information from the docs, and then an index of well organised resources, such as the OP's.

This way, it's impossible to overload, and I'm left in a state where I can expand at my own personal rate. Anything that tries to set the pace for you is going to be suboptimal for 99% of readers.

Furthermore, anything that flows easily and without extremely explicit DO NOT PASS GO UNTIL YOU ARE EXCELLENT AT THE LAST CHAPTER, will lead to overload. You can't overload if you don't provide the information one can overload with. Simply ending your course after the basics and docs, absolutely guarantees against this problem. "Leave the learner in a known good state", would be my rule of thumb.

For myself, that's a feedback loop where bugs during cobbling naturally present themselves as theory questions needing an answer, rather than practical questions needing a solution.

It is rare to find documentation of such high quality that grasping the fundamental abstraction does not require theory-attentive debugging.