
Grid Style Sheets – CSS polyfills from the future - Brajeshwar
http://gridstylesheets.org/
======
crazygringo
If this is what I think it is (a new layout engine that runs in JavaScript, so
that CSS is used just for styling, not layout), it is what I've been waiting
YEARS for.

Unfortunately, the site is deafeningly silent on specifics. What browsers does
it support? Is there any kind of tutorial for getting started? When would this
be appropriate to use, and when not? What is performance like with rendering
times, both on desktop and mobile? Window resizing? How does it handle boxes
that depend on the size of their content? What about non-visible boxes, when
browsers often lie because they haven't actually rendered the text to be able
to tell?

If anything ever needed a comprehensive FAQ, it's this.

But this has the potential of freeing us from the horrible disaster for layout
that is CSS, and giving us a sane replacement, without waiting for browsers or
the W3. If it really is what it promises, and works flawlessly, I wouldn't be
suprised to see it become as ubiquitous as jQuery.

~~~
d4tocchini
Yes, yes, the site needs much more. Released only a couple weeks ago and
probably needs a big fat "BETA" or something.

More language features, docs, demos, etc coming soon. Right now works down to
IE11, and we will work our way further down, but once we get precompilation of
a static GSS layout to raw CSS (difficult b/c must account for every possible
screen size), it will be bullet proof on any crappy browser!

~~~
prewett
Could you change the site so that the front page gives a very clear idea of
how my CSS (and HTML if relevant) would look different? What size JS is
included? Performance considerations (and if performance is poor, why this is
so cool that I won't care).

It sounds cool, but maybe overkill for what I need, but the menu items don't
sound relevant to me figuring out whether this is what I want.

------
RaphiePS
Finally! I've been consistently bothered when people hype preprocessors like
SASS and LESS as "the future of CSS" or "fixes to the CSS problem."

Yes, they make things somewhat nicer by adding variables and macros and the
like, but it's still fundamentally CSS, a language that was designed to style
documents rather than implement complicated and dynamic layouts.

My bar for programming/markup languages is how close they come to _intent_.
For example, centering something in CSS is a mess of absolute positions and
table-cells -- it couldn't be farther from the simple intent of "I'd like to
center this."

So, that's why I'm so excited about this. Writing normal CSS seems like
writing Assembly, and SASS/LESS just adds some nice macros... to your
Assembly. This feels like writing real code.

~~~
hiphopyo
For sure. I've always refused SASS and LESS as well. The reason being, if your
design is simple enough, you don't need that stuff in the first place.

~~~
scarecrowbob
Much as if your program is simple enough, you shouldn't need C?

FWIW, I think that CSS is no great language, and yes, writing LESS feels very
much like writing macros rather than using a language, but the requirements of
the designs I have to implement are generally complex enough that a
preprocessor and CSS framework greatly simplify my work, leaving me more time
to focus on intent (which I think is a reasonable goal) rather than details of
implementation.

If it works well for you to refuse to learn a preprocessor, then that is a
good thing, but the fact that one makes my life easier doesn't necessarily
imply that the designs I am implementing are overly complex, as your statement
seems to imply (though perhaps I am misreading so...)

------
bbx
_" why can't we position & size elements relative to each other"_

It already exists. It's called _margins_.

But it might be hard to handle when half of the elements in the page have the
following style applied:

    
    
      position: absolute;
      margin: 0px;
      top: 0px;
      left: 0px;
    

If your title needs to have a "width: 1121px" and your container a "padding-
right: 377px;" in order for your layout to work, you're doing it wrong.

I seriously don't understand the point of calculating and generating such
arbitrary positioning values.

A web page's layout is meant to stay _fluid_ , because it should adapt to the
content it's styling. Margin, padding, font-size, line-height... These are all
meant to provide rules to position elements _relative_ to both its
surroundings and its content.

These Grid Style Sheets might be powerful but they're not for the web.
Definitely not.

~~~
hiphopyo
True indeed. Grids are only meant for architecture and graphic design. If
needed, they should only be transferred to websites and apps visually (ie.
[http://hashgrid.com/](http://hashgrid.com/)). Transferring them
programatically is a waste of time. Basic CSS will do just fine.

[http://subtraction.com/pics/0703/grids_are_good.pdf‎](http://subtraction.com/pics/0703/grids_are_good.pdf‎)

~~~
d4tocchini
W3C has been hashing out new grid-based specs for quite some time now, because
as admitted in the Grid Layout Module working draft, "As websites evolved...
floats, were not necessarily well suited for application layout."

[http://www.w3.org/TR/css-grid-1/#background](http://www.w3.org/TR/css-
grid-1/#background)

Dozens & dozens of CSS grid systems have emerged, but without retooling the
internals of the browser's layout engine and adding new CSS language features,
such attempts retain the flaws of CSS float & will taint content semantics.

But, of course, the W3C's grid-based efforts is not without flaws, see:

[http://www.markboulton.co.uk/journal/rethinking-css-
grids](http://www.markboulton.co.uk/journal/rethinking-css-grids)

~~~
specialist
Thanks for mentioning this. I had peeked at those specs, proposals. Looks like
a CSS version of GridBagLayout. No mention of canonical grids. (See my other
comment.)

------
specialist
Compiling to CSS, very interesting strategy. Will definitely try it. Porting
my layout manager to the browser is on my to do list.

I created DesignGridLayout for creating visually correct UIs using canonical
grids (a la Mullet and Sanno, many others). You specify rows and components.
DGL figures out columns, spacing, alignment, baselines, etc.

[https://designgridlayout.java.net](https://designgridlayout.java.net)

[Shout out to Jean-François Poilprêt, who's now the project owner and greatly
extended the functionality.]

I used to be very bullish on constraint solvers for UI, Cassowary included. I
found that creating visually correct forms continued to be very difficult.
Partially because the UI components do not have the built-in smarts, such as
anchors for text baselines.

So I decided that capturing (encoding) the heuristics of canonical grids was
best implemented (at the time) with explicit imperative code.

Constraint solvers still have great potential for document layout, a la
responsive designs.

I have no doubt that a future bottom up redo of a UI component framework
(UIMS) will embrace constraints for both document and form layout.

~~~
kenferry
> I have no doubt that a future bottom up redo of a UI component framework
> (UIMS) will embrace constraints for both document and form layout.

Welcome to the future! Cocoa's new(ish) layout system, Auto Layout, is
constraint based.

> Partially because the UI components do not have the built-in smarts, such as
> anchors for text baselines.

In Cocoa, you can constrain two views to align by baseline, and each view
handles what "baseline" means for itself. Built in views (labels, buttons,
etc.) behave as you'd expect.

~~~
specialist
Thanks. I should look at Auto Layout. My hobby iOS project (a few years back)
made me want to stab myself.

------
coldcode
Yet another cool thing in Javascript. Once you understand the power of
Autolayout in iOS you don't want to go back to the old way (and in iOS7 you
almost can't). Once this matures and people understand it (constraint thinking
takes a while to puzzle out) I think it could simplify a lot of web design. Of
course, anyone that refuses to turn on JS can't see anything. But that's
almost pointless these days anyway.

Looking forward to it maturing.

------
pornel
This seems to mimic OS X's "Auto-Layout" approach where you define layout by
specifying constrains between pairs of elements.

I've recently converted a couple of applications to Auto-Layout and I don't
like it at all. If you add too few constrains the layout is unstable, elements
get 0 sizes, and all kinds of weird things happen. If you add too many
constrains then it suddenly becomes a fixed layout.

------
neonode
"GSS is a CSS preprocessor & JS runtime that harnesses Cassowary.js, the JS
port of the same constraint solving algorithm Apple uses in Cocoa Autolayout
for iOS & OS X. GSS & Cassowary are based on “Constraint Programming” - a
paradigm where developers focus on declaring the “what” and relying on a
mathematical solver to figure out the “how”... This makes Constraint
Programming a natural fit for declarative languages like CSS."

------
Kiro
I don't understand what this is.

~~~
fredgrott
okay simple from mobile web apps its a way to native layout like the mobile
apps do but in css..ie one step closer to full parity between native mobile
apps and mobile web apps

~~~
sergiotapia
Ok, but seriously, no jokes: What is it? I'm utterly lost and feel like a
gringo in Colombia with no way to communicate.

~~~
kenferry
You know how in Keynote or Powerpoint, when you drag elements around they snap
to certain guidelines? Like, if you drag a text box close to the center of the
slide, it'll snap to being exactly centered. Or if you drag something close to
a margin, it'll snap to a standard distance from the edge.

A "constraint" captures a relationship such as those. "Block A is horizontally
centered in its container." "Block B's right edge is 20 pixels from the right
edge of its container".

The layout is then based on those captured relationships.

CSS sorta works like that too. The difference is that this system has one
general thing (a constraint), where CSS has a lot of very specific interacting
properties (margin, padding, etc).

A constraint has basically the form

    
    
        y = m*x + b
    

where x and y are geometric attributes of blocks. For example,

    
    
        blockA.left = 1 * blockB.right + 20
    

The = could also be <= or >=.

Last, you can say that a constraint should hold with strength one of
{required, strong, medium, weak}. In this demo:

    
    
        http://gridstylesheets.org/demos/apple/
    

the "Change Mode" button is weakly centered in the panel, but there is a
required constraint that it be to the right of the "Add" button. So, when the
panel gets too narrow, the "Change Mode" button stops being centered.

~~~
dreamfactory2
Helpful, thanks. Can anyone articulate in simple terms why that is better (and
not worse even) than CSS?

------
al2o3cr
Can somebody just give the JS crowd a raw pixel blitting engine and let them
get on with reinventing every piece of the browser because reasons?

~~~
vdm
<canvas> ?

------
zghst
The page isn't showing up in IE10 for me and is sluggish performance wise on
Webkit (OS X and Windows). You can see the layout stutter when recalculating
whereas with natural properties, layout recalculation is smooth. In Chrome,
the layout barely reaches 30fps.

Using CSS grids or flexbox would be more appropriate, and there is an outright
lie on their section of flexbox. Flex items can be relatively sized according
to their siblings using the flex property and aligned using the justify-
content, align-items and align-content properties. In fact you do not need to
change the HTML to reorder elements individually or as a column or row or
reversed. Horizontally centering elements is now solved by flexbox (display:
flex; on parent and margin: auto; on targeted element) and for legacy
browsers, use display: table.

Trying to replace the browser's layout engine, instead of compliment existing
technologies, is a terrible approach. It will always be slow and result in
degraded performance. And shame on these guys building a so called 'layout'
engine but not using requestAnimationFrame.

Anyone concerned about layout performance should visit these:
[http://jankfree.org/](http://jankfree.org/)
[http://wilsonpage.co.uk/preventing-layout-
thrashing/](http://wilsonpage.co.uk/preventing-layout-thrashing/)

~~~
d4tocchini
I agree about using Grids, in fact we're currently working on a Grid Layout
Module polyfill, but with constraint-based sugar. Really excited for this one,
relative constraints can get tedious, abstract grid-based primitives make high
level layouts much more intuitive.

Concerning Flexbox, it is not a lie! Flexbox is still dependent on the source
order / parent-child relationships within the DOM. With constraints, you get
true source order independence, so you can layout any group of elements within
any other regardless of DOM structure... When I get time, will push demos on
how to simulate Flexbox and show examples not possible with Flexbox...

Amazingly, IE 11 just worked, yes need to tackle lower versions...
Unfortunately, there is no other way to accomplish GSS's constraint-based CSS
extensions without a runtime replacement for the browser's float-based layout.
That being said, precompiling the computed results for a static page for all
screen sizes, thus eliminating the need of 99% of the runtime, will make it
viable for the jankiest of browsers, and resolved to ID selectors would be
potentially faster than native language extensions!

We're still in very early days of the lib, specific issues and comments
welcome on the repo:

[https://github.com/the-gss/engine](https://github.com/the-gss/engine)

~~~
lightblade
> With constraints, you get true source order independence, so you can layout
> any group of elements within any other regardless of DOM structure...

That would be awesome. Does that means you can have a modal dialog box
centered to the appropriate parent view and still allows user to dismiss it
anywhere in the viewport?

~~~
d4tocchini
yes, the HTML of the dialog can exist as direct child of body, or wherever,
and then be aligned to any element...

------
dictum
This page scrolls slower than most pages on Safari (OS X 10.9.2).

EDIT: And the page is blank with JS disabled. I didn't know about the
Cassowary Constraint Solver and it's interesting to see a project thinking
outside of CSS and its flaws, but please don't use it in production.

EDIT II: gss.js is 653KB (would be much smaller if minified, I also didn't
check the gzipped size) and worker.js is 64KB.

~~~
bergie
We're working on precompiling to CSS, which should fix those issues.

The GSS build can also be a lot smaller if we drop the three grammar parsers
(VGL, VFL, and CCSS), and you pre-parse GSS to the AST in for example Grunt

~~~
tavoe
I'm not sure why, but the fellow you're replying to doesn't like javascript.

You plan to solve it by compiling to css beforehand.

What if I told you I like to remove all custom css from my page. Do you have
any recourse?

~~~
dictum
I like JavaScript. I do most of my browsing on a browser with JS enabled. I
only browse with JS off when I think the sites I'm about to visit are sketchy.

However, I also like saving resources and separating concerns. We have CSS to
make pages look good (or at least half decent). We can make them look even
better with JS, and GSS in a later version may very well do that: compile a
stylesheet that does the basic layout/typography/effects and then patch what
CSS cannot do with JS.

If I decide to disable CSS, I should still be able to see the HTML, and if I
disable JS, I should still be able to see the content with most of the
styling, except dynamic content and anything that CSS can't do.

I'll be watching GSS, a precompiled solution would be really useful.

------
dangayle
I don't see anywhere that discusses browser compatibility. If I can't use it
on anything but bleeding edge browsers, it will be a long time before I can
even think about something like this.

~~~
crisnoble
It does not appear work in IE9/10 yet: [https://github-
camo.global.ssl.fastly.net/5ee9a304678365bec6...](https://github-
camo.global.ssl.fastly.net/5ee9a304678365bec6a435e8a3bdf1506f421dcb/68747470733a2f2f73617563656c6162732e636f6d2f62726f777365722d6d61747269782f6773732d656e67696e652e737667)

from their github page: [https://github.com/the-
gss/engine](https://github.com/the-gss/engine)

~~~
clight
[http://bit.ly/1cG0PlA](http://bit.ly/1cG0PlA)

------
adwf
I wonder what the performance hit is like when calculating comparitive
constraints. Rather than just looking up x = 100, you now need to look at x ==
y == z == a == 100, etc...

I can imagine some complicated websites getting out of hand quite quickly.

~~~
smrtinsert
Another article I've seen recently pitted Yahoos engineers simple set of
equations vs the Carroway solver and it was slower by a 1000-10000 times or
so, hah. I think ultimately the time is negligible since you'll run it maybe
one or twice on a complete page.

The point is that you don't have to re code an entire set of equations for a
new layout. That's big for designers to not have to involve coders (in
theory).

~~~
bergie
Well, web developers already have to implement design constraints into CSS.
Now you just do it by manually calculating and hardcoding positions and sizes.
With GSS you can offload a lot of that effort to the constraint solver.

------
prewett
If anyone is familiar with Qt's layout system and Apple's constraint system,
can you comment on which you like better? I've thought that having QLayouts
for my HTML elements would be really handy.

------
didierbrun
Hello guys, little demo with this lib :
[http://bbfwe.com/projet/bbs/gss/#/](http://bbfwe.com/projet/bbs/gss/#/) I've
discovered this lib yesturday, I've spend just 2 hours to install and make
this little demo. The layout file (layout.gss) is really light. This lib is
very promising to build one-page-app-fluid layout !

~~~
d4tocchini
Awesome! what twitter handle should I attribute it to?

------
ultimatedelman
I know I'm a little late to the party, and it's very likely no one will read
this comment, but after having read all these comments, it just sounds like
the people who are poo-pooing CSS just... don't know how to use it very well.
Sure, CSS has its quirks, but it's EXTREMELY powerful if you know what you're
doing.

Try learning how to use the thing before you decide to change the thing...

------
lewispollard
#iphone[center-x] == #ipad[center-x]; #iphone[bottom] == #ipad[bottom];

Why are they assigning values using what's traditionally a comparison
operator?

~~~
bryanlarsen
That's not an assignment. That's telling the solver "Do whatever you need to
do to satisfy this condition". Either the right or the left or both may
change.

~~~
d4tocchini
Yeah, common in the Constraint-based, or Logic, Programming paradigm. This
particular spec was established in Greg Badros & Alan Borning's Constraint CSS
(CCSS):

[https://www.cs.washington.edu/research/constraints/web/ccss-...](https://www.cs.washington.edu/research/constraints/web/ccss-
uwtr.pdf)

~~~
lewispollard
Interesting, thanks.

------
pete_b
The design of the site is excellent, but...

Vanilla CSS isn't that bad. Existing preprocessors have made it much nicer to
use without changing the basic formula and workings of CSS.

GSS is a fairly radical departure and as such it should offer big returns
which I'm not seeing. Moreover, I don't see that it's solving a problem that
needed solving in the first place.

------
hughlomas
This looks intriguing and I will likely try it out.

As an aside, half of the links under "Features" are not actually links, and
half of ones that are links go to the same page without any anchors. It is
confusing from a design perspective. Please at least consider changing the
ones that are not links to not appear the exact same as links.

------
steren
Reminds me some logic and constraint based programming such as Prolog.

------
gpmcadam
Aside from anything else, this site has a pretty unique and fun design, so
kudos for that.

------
andyhmltn
Cool idea but just looking at the source of that page gives me nightmares

------
jbeja
And do i need this because?

