

Grid Style Sheets for Constraint-based Layouts - _query
https://raygun.io/blog/2014/06/next-gen-constraint-layouts-browser-grid-style-sheets

======
_query
Would love to see the same concept applied via some kind of css preprocessor
so you don't need to calculate everything at runtime. One could build the
whole layout for a set of static resolutions, like in twitter bootstrap: one
default resolution for each kind of device. Then one would deliver the
generated css instead of the gss and the runtime.

~~~
DomKM
Dan Tocchini, a GSS author, said that this was on the roadmap:
[http://domkm.com/posts/2014-01-08-garden-cssom-
ccss/#comment...](http://domkm.com/posts/2014-01-08-garden-cssom-
ccss/#comment-1252520636)

~~~
ollysb
Quite a challenge by the sound of it, their solution is to precalculate the
resolved constraints for various different screen sizes.

~~~
bybjorn
What does that even mean ..? Is that like every pixel width/height combination
from 200 to <size of your desktop> ? .. If so, that's a lot of CSS. If not,
you won't get the current responsiveness you see when you resize your browser
on a responsive website.

~~~
jrsnyder
It just means precalculate a small number of fixed screen sizes.

So portable devices, and maximized desktop browsers would benefit, as they
have regular dimensions.

I imagine they would precalculate the constraint "solutions" in the variables
used inside the solver. GSS would still be supplied, and would still need to
translate the solver variable values to CSS style values.

This way, if the window resizes, or has an initial size that is not
precalculated, it can still be accommodated.

~~~
d4tocchini
GSS author here. What we're working on is a lot crazier than that! Using
phantom.js we precompute layout for every possible screen size & generate pure
CSS.

Precomputation - From small phones to large desktop, there are ~2million width
& height combinations, even if solving a single screen size takes 10ms, were
talking ~6hours. To get around this, using a sort of bisection method, we
selectively solve for as few screen sizes as possible to test linearity of
each variable's solved values. With Cassowary each variable is linear between
breakpoints, making this possible.

Pure CSS Generation - Generate media queries & styles with calc() where calc
is a linear function with respect to vw & vh units. A little JS we only be
needed for browsers that don't support calc or viewport units.

Limitations - Precomputation will only work for deterministic / static
layouts. For a highly volatile DOM, runtime will be needed, but that's
probably OK given the fact that you're already using JS to mutate things in
runtime.

------
nikso
For an AngulaJS flavor of this, there is angular-autolayout:
[http://thenikso.github.io/angular-
autolayout/](http://thenikso.github.io/angular-autolayout/)

------
zghst
The JavaScript solution to everything has to stop, it's madness.

Why not instead push for standards? Just a few months ago these guys were
hyping this up even though it has tons of performance issues, bugs that the
explicitly ignore, it doesn't work in IE and forget about getting this to work
on mobile.

I'd really like to see for once, a dev get down and dirty and work on an
actual standard instead of pushing out a JS solution that will be abandoned in
12 months time.

~~~
d4tocchini
GSS was built not for standards, but for our flagship product, that's our
priority right now. Our approach to organically influence standards is to make
the APIs work in real world products, and if enough momentum builds to begin
the necessary working drafts.

I'd like to see more polyfills of potential standards. Waiting years on end
for things like CSS Vars or the Grid Layout Module is getting real old.

Instead of hating on JavaScript, the only turing complete tool we have in the
browsers, we should be pushing for extensibility standards. API hooks into the
internals of CSS selector resolution, layout calculations, etc so devs can add
new features in a performant & predictable manner that may never trickle down
from the ivory tower of standards.

------
namanyayg
Stuff like this and famous.us is changing the way we develop, for the good.
All welcome changes. The question is, what about IE?

~~~
zghst
Really? Famo.us the hype ware that has been coming soon for years?

All that hype led to nothing but an ugly API that is confusing and going
toward nowhere. There are no scientific or studious concepts behind it, I
really feel like those guys let us down.

~~~
malandrew

        "Famo.us the hype ware that has been coming soon for years?"
    

It's available at [http://famo.us/](http://famo.us/)

    
    
        "There are no scientific or studious concepts behind it"
    

A retain-mode scene graph, the basis of famo.us, is definitely a tried and
true computer engineering concept.

Quick question: Have you actually used famo.us?

Disclaimer: I'm an engineer at famo.us.

