I don't know how to say it politely but what has been achieved by using ad-hoc syntax such as this gem (and similar complex CSS syntax):<p><pre><code> display: grid;
grid-template-rows: 150px [nav-start]
auto 100px [nav-end];
grid-template-columns: [header-start]
minmax(200px, 3fr) 9fr [header-end];
</code></pre>
CSS fans for some reason seem to think that its somehow better to have rendering/presentational properties in an ad-hoc language. Originally, plain markup attributes where designed to accomodate rendering properties, with type checking and all. The naive dichotomy established by putting "semantics" into markup and "presentational" properties into CSS was accidental, and it didn't make sense back then, nor does it now.
If we all had something like Display Postscript, this layout thingamajig would be delegated to libraries, and we wouldn't have to ask the browser deities to bestow new gifts upon us. Good adaptive layout would be closer to a new version of jquery and less Windows XP Service Pack 51.0.2b.<p>(We also would have more sites that looked liked late 90s Flash, but then again, we're moving that direction anyway, just with more effort and convoluted design)
This is excellent. And with the fast pace of browsers, and the improved habits of users (or automatic updates), it should be available for 95%+ of users within a year (It's in the current Safari Technology Preview, so Safari should get it with the next macOS point update).<p>This is also a good moment to remind people that you don't need Bootstrap and the like as much as you used to. Grids were 90% or the reason people started using these frameworks, and CSS (already with flexbox I'd argue, but definitely with grids) has caught up and is now easier to use and more flexible than any framework was.<p>It's also time to reconsider the atrocity that is class="col_xs_12". I've never undestood why people would lynch anyone using style="..." but happily littered their code with those grid classes. With the invention of sass at the latest, actual semantic class names should have once again become the only acceptable best practice. With html5, there's also a range of semantic tags[0], and using them improves both code readability, as well as allowing all sorts of new ideas in clients (not just browsers, but also text-to-speech and other accessabiity tools, or spiders, or brosers on new device classes)<p>o:
<article>
<aside>
<details>
<figcaption>
<figure>
<footer>
<header>
<main>
<mark>
<nav>
<section>
<summary>
<time>
Makes you wonder why HN won't budge with those <table> tags in the source code. One day I hope to see "Table layouts are back with <table> tags" and the HN programmers would have saved themselves so much work.
> Short of taking care of sizing the elements yourself, sadly, you can't have both a vertical and horizontal rhythm by just using flexbox alone.<p>Accompanied by <a href="https://developers.google.com/web/updates/images/2017/01/css-grid/alignproblem.png" rel="nofollow">https://developers.google.com/web/updates/images/2017/01/css...</a><p>I'm pretty familiar with Flex but I simply don't understand and the diagram doesn't help. What does 'rhythm' mean in terms of layout?<p>Taking a guess (which I shouldn't be), I can make <a href="https://developers.google.com/web/updates/images/2017/01/css-grid/examplelayout.png" rel="nofollow">https://developers.google.com/web/updates/images/2017/01/css...</a> with flex, but I'd have header and rest-of-page as columns, then have rest-of-page as a row with nav and content, then content as a column with content and footer. I <i>think</i> the article is saying:<p>> CSS grid means I can do it all at once rather than continually having to make rows and columns.<p>But it doesn't actually say that anywhere (and again I'm guessing).
I've used grid layout a fair amount in the last 6 months or so. It's very exciting but it can feel quite daunting; the new mechanics and new grammar do not make the spec an easy read.<p>Fortunately, I've found that it's quite easy to get to grips with - especially if you have been around long enough to have sliced designs into table layouts!<p>Now for a rather shameless plug for my own article on the subject (I hope with a closer to real world example):<p><a href="http://maketea.co.uk/2016/09/28/css-grid-layout-is-a-step-change.html" rel="nofollow">http://maketea.co.uk/2016/09/28/css-grid-layout-is-a-step-ch...</a>
The biggest game-changer to me seems to be the last example, with `grid-template-areas`. I could probably explain this in a matter of minutes (as opposed to flexbox).
This doesn't really fix much - if the idea is to continue to use pixel-based positioning. I've got devices with a range of dot-pitches (surface 4 pro, external older monitor, cellphone) - with various physical screen sizes -- A "150px sidebar" doesn't work the same across these devices - and more importantly, for a low-resolution 24" screen I'd probably want a similar 3" side-bar as for a "retina"-resolution 24" screen?<p>But at least we seem to be moving forward from the abuse of [ed:float]-layouts for grid-systems...
I've been waiting for the WPF/UWP/XAML grid to come to the web for years and am delighted to see that it's finally happening. Best layout container I've ever used.
Does this include subgrids? As I understand, these are necessary for handling some basic use cases[1], but browser vendors were refusing to implement them?<p>[1] <a href="https://blogs.igalia.com/mrego/2016/02/12/subgrids-thinking-out-loud/" rel="nofollow">https://blogs.igalia.com/mrego/2016/02/12/subgrids-thinking-...</a>
I'm really excited for this. I've been using pure flexbox layouts for a while now, but it still has one major problem, in that your HTML structure still contains layout and positioning information.<p>Everything is either a column or a row, so in the example layout in the link, you'd need two container divs. Whereas the grid example can be done without any.
It was 2003 on a day like this when I was doing table layout design for one of my websites. Somehow it feels like it holds up well. <a href="http://dnalib.sourceforge.net/" rel="nofollow">http://dnalib.sourceforge.net/</a>
Maybe I sound like a broken record, but I still don't understand how layout can ever be a style.<p>Why does an HTML <Grid>-element not exist?
But does the Grid layout change flow responsively? I mean, will the sidebar move below the content if the size of the screen is reduced?<p>With flexbox I can do that implicitly without Media queries
Both Android (ConstraintLayout) and iOS (Auto Layout) use Cassowary. Why not just implement this with CSS as well so we can use the same layout tech for every platform?
My first experience as a young kid in the 90's doing web design was taking the msn.com home page (I thought it looked nice back then) looking at the source, and learning. Turns out layout was done using tables. Cool, putting it into practice though it was really really hard.<p>The primary force you were always fighting against was inconsistency between browsers. You might get everything perfect in IE, then load it in Netscape and there's huge gaps between your awesome solid colored navigation side blocks. Then making it adjust to the size of the browser was another struggle. After a while I learned to just make everything fixed size. Then content inside continues to nest you have to keep subdividing, and things would start to get out of whack. You adjust one block here, and the side suddenly has these weird gaps. A large part of it was almost certainly the fact that I was about 13 or 14 years old at the time, and I learned only by looking at example code... but It was really difficult.<p>flexbox doesn't really seem to suffer from the problems that made table layout really suck. I use it mostly indirectly by using the library Bulma, but it's really wonderful.
This is one of the things that frustrated me about the web world. Stuff that you could do in 2000 with real UI kits is finally making its way to the browser. Java/Swing and Qt could do this years ago, and more elegantly.<p>I don't suppose there is any momentum for starting over with something not based on a simple word-processing model, but with a real UI foundation.
IMhumbleO the redundancy is at issue, because CSS is simply nested key pairs and so say that HTML should handle only text and tagged divisions in text with IDs and classes, and leave all the semantics up to the sheets. Folks who point out that style is semantic are correct, so it's redundant to allow all these structural tags in HTML that are intended to give semantic formatting to text, and instead CSS should be reliably the only source of semantic formatting. Therefore, only one HTML element and everything else attributes or key pairs in the sheets.<p>Also I find js2css works well to keep component style in place with MVC web components.<p>(This comment is a response to the multiple inevitable discussions on the merits of HTML/CSS and what is bad or good and how it all should be different, great stuff, thanks for it)
Yes, please. Putting 'styles' in charge of layout was always madness.<p>Every time I hit the wrong link because the browser engine finally figured out it should move things around one more time just that millisecond, my soul gets blackened by the wish to strangle someone.
It looks like this is getting released in the next major version of most browsers[1].<p>For Chrome, that means no sooner than 03/14/17. That version, Chrome 57, will also come with automatic background tab throttling[2].<p>[1] <a href="http://caniuse.com/#search=grid" rel="nofollow">http://caniuse.com/#search=grid</a><p>[2] <a href="https://news.ycombinator.com/item?id=13471543" rel="nofollow">https://news.ycombinator.com/item?id=13471543</a>
What CSS really needs is a canonical standard, and a tool for generating CSS compatible styles for ALL browsers down to IE8. Until then, I'm more than happy to skip these new layout techniques.
Link to CanIUse for anyone wondering if this might be practical to use in a real project:<p><a href="http://caniuse.com/#search=grid" rel="nofollow">http://caniuse.com/#search=grid</a>