I don't think that's the case… think of how when you're dragging elements around in Keynote or Powerpoint, how you get guidelines that snap in relationships between elements.

This is centered in that, these things have the same width, the space between these two things is 10, the left edges of these things align.

Those relationships are what's expressed. When someone is designing a layout, those are the terms they're going to be thinking in.

The appeal of GSS definitely lies in how similar it is to how I conceive of layouts functioning. As a designer I want the grid to be based on divisions of the page, and every piece of software I work on appears in many different "page" sizes depending on the device, resolution, &c.

It's not just that I want my grid fields to proportionally resize themselves, but that the elements themselves need to reorganize themselves to suit different grid conditions.

All of that is really just to say that I also want to see answers to your first question. GSS seems like a reasonably good way to think about this, but I want to see more examples of it in the wild, esp. in production.

http://gridstylesheets.org/

I'm not sure how you could possibly know whether or not CSS is good enough without knowing what else may be possible. It sounds like you work with CSS professionally, so it isn't going to bother you if something takes an hour -- that's a perfectly good, billable hour.

Supposedly, people in the past did not know that horses are slow. For my part, I hate CSS. I can't quite imagine what this new system will be like, but it's wonderful to think that progress may be coming.

> it isn't going to bother you if something takes an hour -- that's a perfectly good, billable hour.

I don't particularly care for the implication that I find working slowly to be acceptable. My company rewards developers well for finishing fixed-bid (i.e. almost all) projects early, since it directly results in more revenue for the company - thus, it's in my direct best interest to get any work done (styling or otherwise) as quickly as possible. Plus, I like anything that makes me more efficient / makes things easier for me.

> I'm not sure how you could possibly know whether or not CSS is good enough without knowing what else may be possible.

You've made an error in your reasoning. It would not be possible for me to know that CSS is the best, but it's certainly possible to know that CSS is good enough. There's a certain, explicit bar for "good enough" and that is being able to complete a project in a number of hours that is less than or equal to the amount we quoted our client. I'm able to meet or exceed that bar with regularity - thus, I can conclude that my toolchain as a whole is "good enough".

> Supposedly, people in the past did not know that horses are slow.

My mind is definitely open to a better alternative - however, I feel entitled to a healthy degree of skepticism, given that I'm already doing better than "good enough".

I work in web development, myself, though I haven't been doing it consistently through the years. It seems to be somewhat of a low-margin business, and the day-to-day challenges are mostly around producing reliable results within a budget. In that context, complaining about CSS is beside the point, because the day-to-day concern is doing CSS quickly and well, not replacing CSS with something entirely different. If styling became 5x faster overnight, it wouldn't necessarily be a good thing for practitioners; just like it probably wasn't good for horse-related businesses when cars came along.*

*I'm not taking that analogy too seriously. I will not believe this new styling is a revolution until I see it.

This exactly. I don't think we're ever actually going to get rid of CSS (probably not during my career at least), so I'm very interested in technologies like GSS that ultimately don't try to change the behavior of the browser - just the behavior of the developers.

> If styling became 5x faster overnight, it wouldn't necessarily be a good thing for practitioners

I personally would love for styling to get 5x faster. There's be no reason for me to charge any less for the work, so that'd basically be 5x more dollars for the styling portion of any given project - however, styling already makes up a pretty low percentage of our projects' total spent time, so once again I'm pretty skeptical of anything that could reduce that.

Furthermore, I rarely do layout-related CSS to begin with: Bootstrap handles that pretty well, and most layout work beyond that is well within the capabilities of any intermediate developer.

I think that's the crux of the issue, really. Even though CSS is a subpar tool for doing layouts, the abstractions available today pretty much remove that pain: and CSS is quite good at the non-layout side of styling.

To me, it's not fully clear exactly what parts of the process GSS is trying to change and what the full consequences of it would be. Even if I knew what it was _trying_ to change, I wouldn't necessarily make the assumption that the intended change would be the only change, or even the most salient change, that we as practitioners would actually have to live with. I have to look at something like this from every possible angle before I would trust any such claim, because, well... that's just what I do.

>>I personally would love for styling to get 5x faster. There's be no reason for me to charge any less for the work, so that'd basically be 5x more dollars for the styling portion of any given project

That would be great as long as it lasted, I'm sure. But, I expect that sooner or later, the secret will get out that websites just got faster and easier to develop, and your clients will start to expect to either pay less or get more for the same money. Even if your company doesn't charge by the hour, there's little doubt that some of your competitors are hourly. However it played out, economics is going to prevail, eventually.

I've been feeling some pain from CSS lately, which is definitely at least partly because there are newer tools and techniques available now that I still need to catch up on. My company has a guy who basically does nothing but handle the look of sites, and he ends up putting in some amount of time on practically every project we do. I have always thought of myself as a backend developer first and foremost, but CSS is hard to completely avoid.

>>and CSS is quite good at the non-layout side of styling

I don't know that I've heard it split into layout and non-layout before, but I'm assuming that non-layout is things like attaching colors and fonts to text, etc. CSS isn't bad for non-layout things, but, as far as I can tell, that is all of the easy stuff where there was no real engineering-type problem CSS had to solve, so, to screw that up, CSS would have needed to really work very, very hard at doing some inexplicably weird thing in order to have gotten that part wrong.

What I DO know is that as an interaction designer working with CSS for about 8 years, I can say with some personal conviction that CSS is NOT my bottleneck when it comes to building great software. It has limitations and quirks, like anything else that is reality-based, but it's REALLY powerful for layout in terms of variety and depth of interaction. Add SASS or LESS to your workflow and CSS becomes the bee's knee's so to speak with all the power of functions, variables, arrays, etc...

Everything can be improved, I suppose. However, I've seen poor knowledge of programming concepts in business leadership or toxic office politics dash months of work in an instant. As opposed to fiddly fluid layout issues in CSS. Which any skilled coder can do away with in a few minutes.

There are things I would like (computed properties like attr()), but things like this don't exactly trip me up: a solution is never more than a few lines of Javascript away.

Also, even if you're not a "skilled coder", there's always Google if you get stumped. The likelihood of you being the first person to have trouble doing [supposedly difficult thing] is close to 0.

Having two solutions is worse than having one solution, and we can credit CSS for creating this situation by not having its own.

I think the skill you're talking about must be skill with CSS. General programming knowledge doesn't help much in a CSS trainwreck scenario -- at least, it doesn't seem to help me.

Basically what you've said is that CSS can be efficient and powerful when in the hands of an experienced CSS expert. That's not an especially good reflection on the design of CSS itself.