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.
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!
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.
> ... 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.
I said this exact thing when I threw together my attempt at solving the problem a month ago[1]. (Except mine used a physics engine to simulate springs.) I am now cynical about a JS-based page layout engine approach being adopted at all. There are just too many people who, after mastering CSS, believe it is the only real, performant, and compatible way to do things.
As for the rest, it looks like this is early days. The menu on the left does tell you at least how to get it installed and how the VFL language works. I wouldn't quite call it "tutorial" level, but it's probably enough to start hacking.
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.
Imagine you didn't know anything about CSS and look at your examples. What the heck is margin, and why is it auto? Why would that center something? What are table cells doing in here? To me, it's just completely divorced from the actual meaning.
At the risk of repeating my original comment, CSS poorly encapsulates the intent. Yes, it works and it's short, but it's sorta hacky, sorta circuitous. Instead of just telling the computer to center something, you're giving it detailed instructions, instructions it easily could (and thanks to GSS, can) figure out.
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...)
I agree. In addition, with each year comes a new "super-duper-real-correct-semantic" way of doing it. That word semantic. It grates me. Everyone uses it to back their argument, then throws their hands up and "case closed". The meaning has been lost.
Which "old me" says is disgusting and breaks the rules of semanticism. The DOM loses meaning and becomes a vessel for the form / appearance. But I get why people do it. It's pragmatic. I don't like it, but it works.
Regardless of the real real true real true way of doing things and all the arguments that people like to have about that, it's obvious why people are constantly trying to find these conventions and rules of thumb. It's because form and function are not properly separated with CSS alone. Using the DOM purely as a vehicle of function makes forming difficult, while pulling form into the DOM level muddies up the goal of semantic documents - the idea that a machine should be able to comprehend the nature of (X)HTML content has fallen to the wayside but that's a separate argument (should documents be sources of truth, isn't that what REST is for, are entities documents, etc).
The thing is that XML & XSLT got us oh-so-close. Nice, lovely pure XML documents with clean semantic tags and attributes with strongly typed definitions that had meaning to both humans and machines. A transform step converted these into an XHTML presentation format, adding whatever DOM sugar was needed for the CSS and JS to do its thing. It was almost there.
Where it fell down is where I think you hit the nail on the head. Both CSS and JS are needed currently to do very basic things, with a lot of overlap for things like positioning or animating transitions.
A single layout language that handles _everything_ in an intuitive way without having to navigate the CSS+HTML+JS love triangle would be fantastic.
Sorry for the somewhat longwinded response for what is otherwise a "me to" comment. I guess I just needed to vent a little - long day at the office and all :/
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.
CSS is one approach to laying out a page (which ignored grids, columns, relative positions for elements which are not nested, sane vertical positioning, min/max measure (which makes your fluid layouts rather difficult to actually do properly e.g. on this site measure is way too long) and a ton of other graphic design principles which seemed inconvenient to the authors). CSS has been improving, however it is well suited to RFCs and similar articles and not great for more complex illustrated content.
There are many other different possible approaches to styling content, and even if they are not successful they might inform a more effective and succinct CSS of the future which doesn't actively get in the way of designers.
iOS developers have the power of using constraints for their layouts. Why not give the same to web development?
As for fluidity, this is something GSS can provide very easily with the conditionals. Imagine being able to do media query-style rules, but not only for the screen size but also for sizes of other elements. "If the image is bigger than X, change the layout so-and-so".
A little example: open the toolbar layout demo (http://gridstylesheets.org/demos/apple/) in a browser window, and resize that around. See how the button that prefers to be in the center, but even more strongly doesn't want to overlap with the other buttons behaves.
> iOS developers have the power of using constraints for their layouts. Why not give the same to web development?
Because the web is meant for documents first, not applications.
The example who linked to is a nice demo, and I understand how the GSS is meant to be used. But for all the fancy CSS techniques that hit the HN frontpage (and that are usually frowned upon because there is no "practical" use case), there's probably one just as suitable for this particular situation.
> Because the web is meant for documents first, not applications.
Which is, ironically, why something much better than CSS is necessary. Right now you simply can't have rich presentation and a presentation independent document because CSS just doesn't actually give you that. Need to re-arrange your document's presentation with CSS? You'll have to move your html around to make that happen. Need a grid layout? Throw a bunch of stupid classes all over your html for your ridiculous CSS framework to latch onto. To rearrange them? Switch them around.
A richer presentation layout will help the web be for documents first, not hinder it. And more so than trying to pretend that it's still 1994 and no one's ever tried to do anything remotely complex on the web yet.
While we clearly disagree on whether the web is a viable app delivery platform, there is no reason why documents couldn't look beautiful on the web either.
Compare a nicely designed magazine or a book to a typical website. Which one is more readable? The reason why so much of the web is not nice to read is because complex layouts in CSS are hard.
Most books don't have complex layout. What they have is extremely high quality typography and careful attention to how the text appears on a specific page. Book designers tweak prose to avoid rivers (a series of whitespace on successive lines that happen to line up with each other), widows (the final line of a paragraph appearing on its own at the beginning of a page), orphans (the first line of a paragraph appearing on its own at the beginning of a page, or when the last line of a paragraph contains only a single word), and hyphenation.
The web, which doesn't have well-defined pages or even page sizes, precise control over typography, or designers who agonize over how the actual text appears in the context of the layout, lacks all of those. Typography is slowly getting better, but text layout algorithms are still relatively primitive.
Most books have trivial layout and typography - simple, successive paragraphs with a few very minor embellishments such as the occasional large header, page-breaks before chapters, and page numbers in the footer. Preventing widows and orphans is definitely not the norm - just browse your local library or bookshelf. I seriously doubt people worry much about rivers, too.
Books with diagrams and side-notes tend to have more complex layouts, sure - and that's most educational books. Maybe there these typography issues are given more attention, but it's pretty clear that the typical paperback has demonstrated they aren't that important to readers (which isn't a judgement, it's just the way it is), so I wouldn't be surprised if almost no books worry about these issues anymore, beyond perhaps using software which addresses them insofar as they can be automatically.
I don't know about the person you replied to, but I have been developing for that very web for the past decade and a half. I agree about web not going away any time soon, and I am not sure about it being the largest app platform, but of one I am sure: it is a lousy platform for the applications. So I do not want it to go away, just to go home.
(and let's not confuse the web with the internet).
>A web page's layout is meant to stay fluid, because it should adapt to the content it's styling.
The content it's styling it's, more often than not, not fluid.
It's a text that has to have a certain number of characters per line, in order to be legible. It's images that the author intents to be a certain size, and only that.
>These Grid Style Sheets might be powerful but they're not for the web. Definitely not
The Web has not been what you desribe for most of it's life. It might have been the intention of Tim Berner's Lee to be so, but that never caught on. And no real reason for it to catch on.
Disagree. I would argue content should fit the layout, and its just frontend ideology that puts a premium on using css as the main way to do it.
Constraint solvers are used in typical (do we still call them fat clients?) gui toolkits, the web is just finally catching up after a decade or so of little to half-baked solutions.
I'm excited that projects like this are finally getting visibility.
> 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.
Which is exactly what GSS's constraint-based approach to stylesheets seems like it does better than vanilla CSS. The name is probably bad ("Grid" doesn't refer to positioning on a grid but is because it, as well as being its own open-source thing, also underlies a bigger project called "the Grid".)
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/). Transferring them programatically is a waste of time. Basic CSS will do just fine.
> Grids are only meant for architecture and graphic design.
This isn't a grid, its constraint-based layout. the "Grid" in GSS isn't because its grid-based (which it isn't), but because its part of the platform for a stealth startup called "the Grid".
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."
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:
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.)
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.
[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.
> 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.
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.
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.
"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."
It replaces browser layout engine with it's own. Layout engine is the thing that computes where and how elements should be drawn on a web page. If you inspect the web page, all elements are absolutely positioned and the positions are calculated in JS.
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
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.
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.
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:
> 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?
Unfortunately on two machines that I'm using that i7 cores, 16GB of ram, they both seem to have performance problems with layout recalculation.
Also I believe that many problems that this is trying to solve is already alleviated in existing technologies that will work in modern browsers, including IE10+, and web documents do not necessarily need constraints.
I think contributing to Mozilla or Webkit, or proposing a specification to the W3C would be more advantageous for your cause.
W3C will be the way to go long-term, but first we want to have as much real-world experience with this thing as possible. And that is what the current JavaScript implementation enables for us and others. Specs should never be made in ivory towers!
As for performance, that sounds very dubious given that even my Nexus 7 does this thing at 60fps
Running into the same jank issue as well. Chrome 33, Macbook Pro i7 w/ 16gb RAM. While I'm not at 30fps (averaging in the 40s), there are definitely some frames being dropped.
could this be happening because of bad video drivers? gss uses css transforms to speed up rendering and a bad video driver can cause a browser to automatically switch down to software rendering of 3D transforms.
If GSS requires 3D acceleration to get good performance, I'd say that it needs some serious optimization somewhere.
Adding another slow layer is not really helping anything: by the time you have browser-C++-overhead + DOM overhead + JS interpretation/V8/SpiderMonkey overhead, adding another layer on top of this all is really not wanting to make me develop on this platform.
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.
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
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.
Web without CSS and JavaScript would be a quite boring place.
But hey, at least with GSS there is no need to rearrange your content in weird ways to accommodate to CSS layouts. So what you'd get is just the plain, semantic HTML.
that's with all the generated PEG grammars in the compiler. build w/o the compiler stuff, which should be handled node.js side anyway, will be approx jQuery's size.
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.
It should work on most recent browsers - but it will be much more performant on browsers that support web workers. If all of the calculations have to be done in the same main thread, it has no chance. Since it is targeting mobile apps, and all the mobile browsers can do web workers - that should be fine. Chrome and Firefox are fine back farther than it matters. But, IE9 and earlier will be slow because IE10 was the first IE to have web workers.
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.
The Cassowary Constraint Solver used in GSS is considered the most viable & perf-sensitive linear arithmetic constraint solver for real-time use-cases, hence Apple's adoption of Cassowary across iOS & OS X.
The GSS website is a good example, with about 400 atomic constraints on the homepage. Major bottleneck is reading / writing DOM, resolving element queries; not Cassowary's constraint resolution.
GSS uses the canonical JS port of Cassowary maintained by Alex Russell:
Just an anecdatum: I used lpsolve, a general linear programming solver, to layout constraint based user interfaces with no perceptible delay to the user in a desktop situation (no network to blame)… in 1996, on an Intel 486dx50 with 16MB of RAM. I think my cell phone with 80 times the RAM and 40 times the CPU speed can probably swing it too.
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).
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.
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.
Hello guys,
little demo with this lib : 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 !
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...
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.
Yeah, common in the Constraint-based, or Logic, Programming paradigm. This particular spec was established in Greg Badros & Alan Borning's Constraint CSS (CCSS):
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.
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.
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.