[thundermuffin]

It isn't necessarily a "problem", but I personally am a fan of keeping simple use cases as simple as possible. In my eyes, bringing the syntax to barebones makes it easier to read and more maintainable for these ultra simple use cases (for instance this 3x3 equally sized grid).

    grid-rows: 3;
    grid-columns: 3;

Is it an excruciating pain to need to currently type repeat(3, 1fr)? Nope, not at all, and I'd gladly do it if my team wanted to plain CSS or SASS, but to me that statement doesn't feel nearly as succinct or (dare I say) elegant as other areas of CSS, such as:

    margin: 2rem;
    padding: 1rem 0.5rem;

What I meant by variable sized rows & columns was to keep the rest of the spec as close as possible to what it is now, but layered on top of my suggested simpler syntax from above. That way if I wanted to do something that isn't just n equal-sized columns, I could just write out

    grid-template-columns: 1fr 2fr 1fr;

and it would work as CSS grid currently does. It's the best of both worlds!

I'm also a frontend developer who has spent a pretty significant chunk of time studying CSS. Maybe I gave off the impression that I'm too incompetent to learn the latest features of the language and write them in plain CSS, but that wasn't what I meant. It is way more that I find little pleasure in writing CSS compared to other frontend responsibilities.

Am I happy and grateful that grid, container queries, and the rest of the new features exist? Yes, I am, and grid is one of the tools I reach for the most. In the end, I only had tiny things I wish could have been different about it after using it and realizing "rats, that syntax could have been made a tiny bit simpler for how I use it a lot of the time," or wishes for features that would just make life easier even if the current way of doing things is trivial.

Haha, you know what they say, different strokes for different folks! I didn't feel insulted in the slightest when our lead frontend developer suggested we give Tailwind a trial run. As a group, we were searching for a way to have consistency and a friendlier developer experience[0] throughout our many different projects & internal tools, but without having to bike shed with 10 different frontend developers or saddle someone with the responsibility of adding new CSS helpers as features rolled out (and the inevitable bike shedding that would happen every time). Some of my coworkers were upset about it because they prefer CSS and styling over JS and other frontend bits, but I think even the most fervent "vanilla CSS/SASS or nothing" holdout came around when she had to cover a project while someone was on vacation, and she found a level of consistency and naming that hadn't existed in our codebases.

--

[0] A couple of very old projects in a siloed team had a CSS guru building his own framework in SASS, but it's utility left a lot to be desired. In my opinion, you can't even place all of the blame on him, because his project was extremely standalone (and therefore had lulls when waiting for approvals and this was a way to pass the time and learn) and the company had very little guard rails to prevent this sort of thing. The combination of a small development team splintered between many different projects (no guidelines stating "this is how we are going to do this as a group" existed), everyone being overworked and burned out, and larger projects "winning" eyes of senior developers who held them to higher standards left him in a spot where I think he believed wholeheartedly that he was making a maintainable masterpiece that would end up being used in the rest of the projects when he finally finished it. Sadly, the framework never reached anything resembling a production-ready v1.0, but it did showcase some of his impressive knowledge of CSS.