Grid Style Sheets for Constraint-based Layouts(raygun.io)
raygun.io
Grid Style Sheets for Constraint-based Layouts
https://raygun.io/blog/2014/06/next-gen-constraint-layouts-browser-grid-style-sheets
4 comments
For an AngulaJS flavor of this, there is angular-autolayout: http://thenikso.github.io/angular-autolayout/
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.
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.
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.
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.
The JavaScript solution to everything is the best way to explore which ideas are actually worth converting into a standard. It's much better to implement something as JavaScript that can then be used with any browser than for some half-baked idea to be implemented in a browser, that the other browser makers end up copying and now we're stuck with yet another standard, but half-baked way of doing things.
Every javascript solution that becomes popular ends up informing those ideas the browser makers end up standardizing. CommonJS and RequireJS have both informed the ES6 modules API. All the promise implementations out there have informed the promises API in ES6. etc. etc.
Every javascript solution that becomes popular ends up informing those ideas the browser makers end up standardizing. CommonJS and RequireJS have both informed the ES6 modules API. All the promise implementations out there have informed the promises API in ES6. etc. etc.
This is how things start. This could be the future of CSS that becomes part of browsers some day.
Stuff like this and famous.us is changing the way we develop, for the good. All welcome changes. The question is, what about IE?
Did you perhaps mean to reference http://famo.us/?
In this video the author says it works in IE11 and will be working in IE10 "within a couple of weeks" http://vimeo.com/91393694 .. which would mean it's working in 10 now .. also, if they manage to make the preprocessor stuff, then it will work in "all" browsers (that understand the generated css of course..)
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.
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.
"Famo.us the hype ware that has been coming soon for years?"
"There are no scientific or studious concepts behind it"
Quick question: Have you actually used famo.us?
Disclaimer: I'm an engineer at famo.us.
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.
Dan Tocchini, a GSS author, said that this was on the roadmap: http://domkm.com/posts/2014-01-08-garden-cssom-ccss/#comment...
Some early work at https://github.com/the-gss/gss2css
Quite a challenge by the sound of it, their solution is to precalculate the resolved constraints for various different screen sizes.
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.
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.
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.
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.
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.
[deleted]