

Constraint CSS - strictfp
http://gridstylesheets.org/guides/ccss/

======
spiralganglion
One of the devs of this project gave a talk about the motivation behind it,
how it works, and other interesting details [1].

Of note, this project goes a fair bit deeper into advanced layout
possibilities than the flexbox and grid modules included in the current CSS
spec/drafts. Flexbox, for instance, prescribes a very particular pattern to
the layouts that it affords. You must be rather methodical in how you break
your layout into nested rows and columns. This focus on rows and columns
causes quite a bit of visual shoehorning, or forces you to resort to hacks, at
which point you've lost most of the benefit of using flexbox at all. Though
for simple- to medium-complexity layouts where the visual arrangement is
composed of nested rectangles following simple rules (as most of the web seems
to be), flexbox is wonderful once you get the hang of it.

I'm very fond of constraint-based layout systems (and rule systems in
general), having written a few of them myself. I feel that while this GSS
project isn't a complete realization of the promise they offer, it is a nice
step in that direction. I worry about the performance and complexity burdens
this project seems to impose, though I say that only looking at the docs, the
generated code, and the discussions that emerged the last time this was posted
to HN. I will be using it for an in-house dev-facing tool in the near future,
and about that I am quite excited.

[1]: [https://vimeo.com/91393694](https://vimeo.com/91393694)

~~~
d4tocchini
And here's a GSS screencast [1] that accompanied a tutorial in most recent
issue of Net Magazine [2]

[1]: [https://vimeo.com/99873002](https://vimeo.com/99873002) [2]:
[http://www.creativebloq.com/net-magazine](http://www.creativebloq.com/net-
magazine)

~~~
notduncansmith
Thanks for the link. It did help cement some of the concepts presented on the
website, but the presenter did a really poor job of selling some of it:
"This... [points to screen] ... I don't know, it's crazy. [next slide]". How
does that in any way convey the value of this thing?

Also, his answer to the question "How do we debug GSS styles?" was pretty
worrisome: "Just add and remove constraints, and see what breaks it". That
sounds to me like what a lot or people are doing with CSS right now, and the
idea is horrifying. It's tough to imagine embracing a nondeterministic system
where there's no telling what rules you've given it will be obeyed, and which
will be ignored - at least in CSS, it's pretty clear when something will be
overridden.

------
notduncansmith
Does anyone have any real-world examples of GSS? I like the idea, but I'm
struggling to imagine what this would look like in an actual system. Maybe I'm
nuts but I don't feel constrained by CSS too often. Everything I need, I get
from CSS + a decent preprocessor (usually LESS these days). Maybe this is a
symptom of using CSS, but I rarely even encounter people describing layouts in
the way GSS appears to want me to code them.

I don't have much experience with constraint-based layout systems in general,
but from what I read it looks like it's a common practice when developing
native solutions. This gives me the impression that systems like GSS are just
"CSS for people who are used to building native apps and don't grok CSS".

I don't mean to say that CSS isn't without more than it's fair share of flaws,
but I take issue with the statement that doing laying out views on the web is
in any way difficult.

~~~
mtdewcmu
>>Everything I need, I get from CSS + a decent preprocessor (usually LESS
these days). Maybe this is a symptom of using CSS, but I rarely even encounter
people describing layouts in the way GSS appears to want me to code them.

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.

~~~
wmeredith
I totally hear what you're saying abut the horse analogy: I don't know what I
don't know.

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.

~~~
lomnakkus
CSS is fundamentally broken -- it lacks a property which is pretty basic to
all systems, namely abstraction. I think Paul Chiusano put it way better than
I could: [http://pchiusano.github.io/2014-07-02/css-is-
unnecessary.htm...](http://pchiusano.github.io/2014-07-02/css-is-
unnecessary.html)

~~~
notduncansmith
Try using a preprocessor.

~~~
mtdewcmu
Needing a preprocessor to be usable doesn't argue for CSS not being broken. On
the contrary.

~~~
notduncansmith
It would take some pretty interesting circumstances for me to argue that using
raw CSS is a good idea. As I've said before, the language has plenty of flaws,
and using plain CSS without a preprocessor would be, in the majority of cases,
irresponsible. Sorry for any confusion.

~~~
mtdewcmu
Thanks to CSS not having that from the start, it led to the situation we have
today, where there are at least two different preprocessors to choose from:
Sass and Less

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

------
bshimmin
The output from PEG.js for this is... intense: [https://github.com/the-
gss/engine/blob/master/dist/gss.js#L1...](https://github.com/the-
gss/engine/blob/master/dist/gss.js#L11492) (scroll down a few thousand lines
to see what I mean)

~~~
mmnumbp
[https://github.com/the-
gss/engine/blob/master/dist/gss.js#L1...](https://github.com/the-
gss/engine/blob/master/dist/gss.js#L11963-L13464)

This holy if statement from the gods..

~~~
d4tocchini
LOL. Currently gss.js includes the generated PEG parsers with this madness.
When the CLI tools come out, will include a build without the parsers, as it
should be...

------
AshleysBrain
With new layout modes coming to CSS, including flex and grid, I don't think
the statement "float-based & table-based layouts that have remained unimproved
to this day" is fair.

~~~
d4tocchini
Flexbox is a step forward, Grid Layout is awesome but is starting to look like
CSS Vars, another spec lost in years of limbo

The myriad of incompatible CSS layout modes, present & coming, are evidence of
the lack of a holistic & future-proof foundation. The Constraint CSS
primitives can be used to implement Flexbox & Grid Layout in total, not true
the other way around. And, such implementations would be fully compatible with
each other. BTW, a Grid Layout implementation in GSS is well on its way.

The 2 fundamental layout features lacking in future CSS specs is 1) relative
positioning & sizing & 2) true source order independence. Less this is
addressed, layout will be tightly coupled with the DOM & good luck centering
things

~~~
AshleysBrain
I'm all for improving what we have, and the new GSS system does look
interesting and could possibly influence CSS. But I think you're reacting too
strongly to CSS. AFAIK the normal, flex, and grid layout modes are compatible
(in the sense that you can mix them in one page and have things like flex
inside grid elements and vice versa). Being a lurker on some standardisation
email lists some of the best engineers in the world are on there taking
everything very seriously, including future-proofing since everyone is well
aware anything they add now will basically have to be supported forever.

I'm not sure I understand your two complaints (isn't there already position:
relative and percentage sizes?), but I think good engineering is always about
making tradeoffs, and while I don't understand GSS enough to criticise it I
feel it's unlikely to be a silver bullet that magically fixes everything in
itself, and will likely have its own quirks and pitfalls as well.

------
chton
How does this work with changing style from Javascript? Can I change
constraints at runtime and have the entire page be recalculated? I'm not
familiar with the Cassowary solver, can it do partial invalidation? or would
it need to recalculate the entire layout if only a minor part changes?

~~~
d4tocchini
It keeps things up to date with DOM changes using Mutation Observers & it does
so intelligently so it won't redisplay whole page.

Cassowary is an incremental solver & is optimized for adjusting constraints in
runtime.

~~~
chton
Awesome, that's what I hoped to hear. I'll definitely be trying it out then,
anything over CSS :p

------
samwillis
Some of the layouts that CCSS would solve can be done with the new 'display:
flex;' [1] tools. This can now be used in all browsers including IE10 [2].

[1]: [http://css-tricks.com/snippets/css/a-guide-to-flexbox/](http://css-
tricks.com/snippets/css/a-guide-to-flexbox/)

[2]: [http://caniuse.com/flexbox](http://caniuse.com/flexbox)

~~~
notduncansmith
I'm a bit jealous of anyone that doesn't have to support IE8. Thankfully we
just moved our standard lowest-supported-version of IE to 9, but we still have
plenty of projects from when we supported IE8 (even a few from the IE7 days),
so it's far from a past problem.

------
tkubacki
IMHO single most important new CSS tech web badly needs is ShadowDOM - this
will make web dev suck less compared to native toolkits development

[edit added below]

...since we will be able to componentize web apps.

Thinking in terms of components is much easier than trying to manage div soup.
Please don't by shy and say why I'm wrong instead of downvote.

~~~
pothibo
ShadowDOM isn't that much needed and I have concern as to how good this is
going to be. ShadowDOM IS a div soup. It's just hidden from you.

From a developer standpoint, the DOM still need to be handled. Moreover, I
haven't seen any discussion with regards to strings in shadowDOM that needs to
be pluralized/genderized.

Also, ShadowDOM is outside the scope of the article. This is probably why you
got downvoted.

~~~
tkubacki
1\. "shadowDOM isn't that much needed"

I gave you an argument why I think it's (components) - you just say your
opinion - it' not an argument

2\. "I have concern as to how good this is going to be"

It IS WORKING already in Chrome. You can try it out [1].

"ShadowDOM IS a div soup." \- no it's not. Web component tags are tags like
any other HTML tag. You don't get the idea. Div's are like thinking about
computer program in terms of electrical signals whereas web components is
thinking in terms of program logic. See example video [2] with Google maps
component. It just hides unnecessary complexity.

" I haven't seen any discussion with regards to strings in shadowDOM that
needs to be pluralized/genderized."

Sorry. Don't get what do you mean. Could you please evaluate ?

"Also, ShadowDOM is outside the scope of the article" well I just express my
opinion that there are bigger unsolved issues in webdev than those solved by
Constraint CSS

[1] [http://www.polymer-project.org/](http://www.polymer-project.org/)

[2]
[http://youtu.be/8OJ7ih8EE7s?t=28m26s](http://youtu.be/8OJ7ih8EE7s?t=28m26s)

~~~
masklinn
> I gave you an argument why I think it's (components)

No you did not. "it sucks less" is not an argument (and it's pretty faint
praises), it's just your opinion.

> "ShadowDOM IS a div soup." \- no it's not. Web component tags are tags like
> any other HTML tag.

And what do you think lives inside the tags, pray tell?

> It just hides unnecessary complexity.

That's the point, the complexity is still there, just hidden.

> "Also, ShadowDOM is outside the scope of the article" well I just express my
> opinion that there are bigger unsolved issues in webdev than those solved by
> Constraint CSS

That's not a very on-topic opinion to express in a thread dedicated
specifically to discussing layout in CSS.

It's also wrong, web components make it somewhat easier to reason about the
existing mess, they don't actually fix issues. Actually having layouting tools
in CSS fixes issues, namely the issue that layouting in CSS is currently
intractably brittle.

~~~
tkubacki
>"it sucks less" is not an argument

Yes it's not an argument. It's conventional wisdom that it's easier and faster
to create app in native toolkit than in HTML/CSS.

I refereed to my components argument not to "suck less".

>>tags are tags like any other HTML tag. >And what do you think lives inside
the tags, pray tell?

You don't have to think about it (you just import the component) as you don't
have to think what's current CPU pin state. You just use attributes to
communicate with the component.

>"That's the point, the complexity is still there, just hidden."

And there is a value in this. Higher level langs hide complexity as well (eg.
C# vs C) and that makes them usable.

>It's also wrong, web components make it somewhat easier to reason about the
existing mess, they don't actually fix issues

I don't agree. In my entire web dev career single biggest pain in the ass was
more or less like "what CSS rule is breaking my div style".

Since ShadowDOM brings CSS fence between components as you probably know (do
you?), ShadowDOM makes it way easier to create HTML/CSS ui simply because it's
hard to make CSS rules breaking whole app view.

I do agree layouting is an issue - it's just not that important at least for
me - joe average web dev

[edit added what gives us Shadow DOM CSS boundry]

[edit2 - hell yea! no arguments? just downvote!]

~~~
pothibo
You must have never done any kind of development outside the web if you think
for one second that native toolkit development is faster/easier than HTML/CSS.

You have absolutely no idea what you are talking about. Please stop talking.

~~~
tkubacki
>You must have never done any kind of development outside the web

Well actually I started as a Windows.Forms Silverlight/WPF .NET dev

>if you think for one second that native toolkit development is faster/easier
than HTML/CSS.

With MS tooling and/or paid e.g Devexpress controls average .NET dev is way
faster building LOB apps than average web dev and you don't have to test on
multiple browsers.

Additionally if you have to support older browsers you will get extra penalty

Do I have to add how much JS sucks compared to C# ?

There is a trade-off - you can't skin your app as much as you can with CSS.

>You have absolutely no idea what you are talking about. Please stop talking.

Native toolkits are usually easier to dev once you know them.

It's a conventional wisdom - at least one other person in this thread seems to
agree with me on this.

------
Mithaldu
It seems to need some browser compatibility work:

[https://www.dropbox.com/s/5ipil0xd12z7a54/Screenshot%202014-...](https://www.dropbox.com/s/5ipil0xd12z7a54/Screenshot%202014-07-04%2013.47.31.png)

~~~
Torn
what browser are you using?

~~~
Mithaldu
Opera. :)

------
NaNaN
I wonder how to use it harmoniously with jQuery plugins...maybe a lot of them
would be refactored.

~~~
iamstef
i would like to see two jQuery plugins work harmoniously with each other :P

