I don't think this is a solution. I've been thinking about this for the past couple of days, after watching some Alan Kay talks and revisiting some of Bret Victor's articles.

I think the fundamental problem here is about structured semantic content and its presentation. When those two domains meet, it gets messy very, very quickly. At a certain point it gets hard to tell the two areas apart, especially when it comes to interactive applications.

Hardcore HTML advocates such as Zeldman seem to have the worldview of 19th century librarians (no offense intended). I find it outright irritating that a board could define some semantic elements (header, article, section, etc.) and expect the world to be happy with this limited array for expressing 'meaning' and 'intent'. And again, it's often hard to divorce the meaning of content from its actual presentation.

Yes, the problem is that CSS's structural presentation is ultimately tied to the DOM. Funny you bring this up, as I commented earlier here:

"GSS was created b/c our company's main product, the Grid (still in stealth mode), is doing some radical things with design of newsfeeds, we need layout to be completely decoupled from the DOM. A fairly developed Float / Flexbox-based layout becomes as much of a CSS affair as an HTML one; changing layouts requires a whole new set of div wrappers. CSS was designed to separate presentation from content, and that ideal has unforeseen manifold benefit when actually realized."

Here's an example, http://gridstylesheets.org/demos/apple/ notice the button & panel layout as you change the screen size. Now, view-page-source & notice how every element is a direct child of <body>, no parent-child nesting... Here's a recording of talk I recently gave at FluentConf that delves deeper into this: https://vimeo.com/91393694

You say you don't think this is a solution, but you don't say why.

If HTML's limited expressiveness is your gripe, I'd say React has already alleviated that for us. Components can be named very expressively, and your tree structure ends up reading very well. Really, HTML becomes the compile-to language.

Web components could step in and help this further, and there's no reason they couldn't be used within React to make even the output HTML more semantic.

I specialize in building responsive frontends and I've hit the limit of what CSS can offer me. I've learning how to use JavaScript to add:

- element-width media queries, instead of browser-width

- auto-centering two objects on the page

- and hopefully I can get it to watch a container and tell you how many children it has, or if it's a text element how many chargers it contains.

Imagine being able to switch responsive CSS styles for an element based on how wide IT was, instead of how wide the screen is. The problem is that some pages have sidebars, some don't but use the same widgets. A widget may be 'cramped' by other objects at a wide browser size, then snap down to a single column view and actually be wider on the page when the browser was narrower than before. This looks awkward and element-size-based styles would prevent that and allow TRUE atomic design.

Imagine being able to align items to other items on the page or to a grid that is superimposed over the browser window. Useful for modals and alerts and all sorts of 'off layout' content that you need to align. Much better than trying to use CSS to centre things because you can centre an object whose width or height you don't know or can allow to change after the page has loaded.

Imagine being able to set a different style on an input that had 21 characters using CSS because you knew how many characters were in the input field and could style for different character amounts? What about a playlist that has three pre-made sizes for list items that keeps reducing the size according to pre-made styles to make sure they all fit as you add more list items.

The problem isn't so much that CSS rules fall short of being powerful, it's not the rules we need to super-charge, it's knowing WHEN to apply the rules and using JavaScript to add real time feedback from the rendered page is the best way to do that right now. I'm already using custom data attributes and regular expressions in my CSS selectors and I need more logic to power them. I need to be able to measure objects and respond to them as data changes on the site with user interaction.

Basically, long story short, I want to mix THIS with THAT in the near future

THIS https://ballr.com/new_design/tables THAT http://staticresource.com/alijn/demo

Element queries are a great idea. It's a shame the W3C won't touch them with a 10-ft pole.

In my humble opinion the best solution for layouts is CSS is the CSS Grid Layout Module[1]. Both powerful and easy to grasp. Sadly, it works only in IE (from version number 10, I believe)[2], but others[3][4][5] are getting there. And, of course, there's a polyfill[6].

1) http://www.w3.org/TR/css3-grid-layout/ - specification;

2) http://ie.microsoft.com/testdrive/graphics/hands-on-css3/han... - examples;

3) http://updates.html5rocks.com/2014/03/Get-on-the-CSS-Grid - Chrome/Opera/Blink;

4) https://bugs.webkit.org/show_bug.cgi?id=60731 - Safari/Webkit;

5) https://bugzilla.mozilla.org/show_bug.cgi?id=616605 - Firefox;

6) https://github.com/codler/Grid-Layout-Polyfill - JS polyfill.

I think gridstylesheets aren't that brilliant, at least not as a general solution. They don't deal well with ambiguity or over-specific (impossible) solutions, leading to fragile layouts that have odd behavior in corner cases.

Furthermore, there's quite a few basic constraints that CSS implies that you'd need to reimplement in GSS (if we can call it that) all over the place to get a comparable layout engine, namely normal flow, margins, wrapping, justifying...

All in all, I'm not holding my breath for this to become a huge success.

Author of GSS here. The brilliance lies with guys like Badros (Cassowary), Ken Ferry (Apple Auto Layout), Alex Russell (Cassowary.js), etc.

GSS was created b/c our company's main product, the Grid (still in stealth mode), is doing some radical things with design of newsfeeds, we need layout to be completely decoupled from the DOM. A fairly developed Float / Flexbox-based layout becomes as much of a CSS affair as an HTML one; changing layouts requires a whole new set of div wrappers. CSS was designed to separate presentation from content, and that ideal has unforeseen manifold benefit when actually realized.

Cassowary powered constraints allow for layouts not possible with a CSS unable to resolve cyclic dependencies in layout arithmetic. Of course, you could easily shoot yourself in the foot & define fragile, ambiguous and/or impossible layouts. But, w/ great power comes great... I always prefer expressive freedom over easy-to-comprehend limitations.

GSS is very new - much is needed like better debugging, implementing floats, etc.. Constraint-based layouts isn't a silver bullet, it takes practice & thinking more like a programmer. Fortunately, Apple Auto Layout demonstrates the viability of all this craziness.

What's the browser support like?

Well, no browsers support it natively. It's a Cassowary-based layout engine implemented in JavaScript. AFAIK it works correctly in the last few versions of Chrome and that's pretty much it. It's not much more than a proof-of-concept, really.

It should work with all the latest stable browsers on both desktop and mobile. Some ugly issues linger with older IEs though

My apologies. I looked at it a few weeks ago and that appeared to be the case then. Glad you were here with more recent information.

This is really cool! Thanks for the pointer. I thought flexbox was cool but this has potential too.