Grid Style Sheets – CSS polyfills from the future
gridstylesheets.org
gridstylesheets.org
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.
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!
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.
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.
They have that on the github page: https://github.com/the-gss/engine.
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.
Very exciting stuff though.
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.
> #container {display:flex;}
> #foo {margin: auto;}
> display: table-cell;
> vertical-align: middle;
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.
Like now we have to:
<div class="write">
<div class="write__our">
<div class="write__our__classes">
<div class="write__our__classes__like">
<div class="write__our__classes__like__this">
</div>
</div>
</div>
</div>
</div>
<div class="instead">
<div class="of">
<div class="like">
<div class="this">
</div>
</div>
</div>
</div>
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 :/
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...)
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;
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.
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.
A somewhat related example, with just a few JS lines: http://toki-woki.net/lab/fluid-corners/
That train has left the station long ago.
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.
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.
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.
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.
Where have you been for the past decade? The web is the world's largest app platform, and it's not going away any time soon.
What year is it?
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.
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.
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".)
This alternative scheme lets you position an element relative to any other element on the page.
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:
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".
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
[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.
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.
Looking forward to it maturing.
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.
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
blockA.left = 1 * blockB.right + 20
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/
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://wilsonpage.co.uk/preventing-layout-thrashing/
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:
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?
But on modern browsers GSS can already solve and lay things out in 60fps.
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.
As for performance, that sounds very dubious given that even my Nexus 7 does this thing at 60fps
Runs a bit smoother in Firefox.
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.
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.
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
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?
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.
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.
from their github page: https://github.com/the-gss/engine
I can imagine some complicated websites getting out of hand quite quickly.
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:
https://github.com/slightlyoff/cassowary.js
Adam Solove had a good JSConf talk on Constraint Programming in the Browser that touches on Cassowary.js & perf benefits:
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).
Try learning how to use the thing before you decide to change the thing...
Why are they assigning values using what's traditionally a comparison operator?
https://www.cs.washington.edu/research/constraints/web/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.
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.