(Rachel Andrew) Thank you.

Hello.

So, yes, I am quite old and I'm going to start with a little trip back down memory lane.

Because in 2004 I published, through SitePoint, the first edition of my book, The CSS Anthology, which promised 101 solutions to common CSS problems.

It even included help for people who still had to deal with Netscape 4.

And looking through that book now there are some absolute gems.

Now, when I was writing this I had actually pointed out to my readers that [INAUDIBLE] border radius existed but that it wasn't actually that useful unless all your users are using Firefox.

And so I gave this marvelous suggestion.

And there's the CSS.

Yes.

Don't try that at home.

To my credit, I did try and maybe point out to people that despite the fact this was in a book, maybe they shouldn't really use it much.

I have no idea where this idea first came from.

I don't think it's something I came up with myself.

I think it must've been out there.

You can all look for websites that include it.

But the alternative technique wasn't actually much better.

I mean, we were sticking inline images into one corner and then using a background image in the other because we didn't have support for multiple background images.

So the fact was that even though rounding corners was a fairly trivial thing, we were actually quite happy to stuff a whole load of markup into our documents to achieve it.

And we don't have to do a lot of that anymore.

We're not having to put huge amounts of markup in for small visual effects.

But where a lot of things have changed in CSS, and, you know, the actual changes to CSS from 2004, I mean, are huge.

There are some parts of CSS where, really, things have stayed very much the same where the advice in that book when I read through it, really you could have given-- you could give to a CSS beginner now.

And that's where layout's concerned.

We've still got floats.

We've still got positioning.

And in recent years we've been able to add the slightly weird sort of display table and we've been using inline block.

But the techniques we're using for layout haven't hugely changed.

And as the web and what we're trying to do with it has become more complex, we're finding that huge amount of developer hours are being spent sort of taming these layout methods.

Sometimes they mean we have to change the source order of our documents just to get the layouts that we want, particularly when we're talking about responsive.

You might be able to have the ideal source for one presentation but then you get to some other break point and you're kind of moving things around, hoping to get the layout that you need.

We're increasingly leaning on frameworks, something that didn't really exist when I wrote that book.

There were no kind of frameworks around.

But, increasingly, we're doing layout by way of using frameworks, and often we're adding quite a lot of extra markup in order to create grids.

And whether or not you worry about nonsemantic or semantic class names, it's not ideal to be describing our layout in markup and also using preprocessors quite extensively to deal with layout.

But there is hope, and it comes with this group of CSS modules that really will redefine how we do layout on the web-- that's Flexbox and Grid and the box alignment module.

And I'm going to ask you to suspend all thoughts of old browsers for just a little while because I want to show you some of the things that are becoming possible really, really soon.

And when we talk about these new layout methods, we tend to sort of think about the problems they will solve for us.

But the reason they can solve these problems is because they have some characteristics that we don't have in our existing methods.

So they properly separate documents source order and visual display.

They give us true alignment control, giving us the ability to center things horizontally and vertically.

They're responsive by default. They remove the need

to do all these complex calculations to work out sizes of things.

And they kind of do all this because they give elements in the layout relationship to each other, which is not the case for block layouts.

A lot of the problems we have with existing layout is because, essentially, everything we position is just this unique thing.

If I float two blocks left and right, and one of them's got a tiny bit of content in and one's got a lot, I don't have any way to tell one of the blocks to be as tall as the other because they just don't really know about each other.

We've been trying to create these full height columns for years.

I'm sure lots of you remember the faux columns technique, where we tile a background image to create the illusion of a full height column.

And this kind of worked until responsive came along and tiling images just didn't really hold up anymore.

And that's why people jumped on this idea of display table.

And the reason display table worked was because it gives the elements inside that layout, it gives them this relationship-- they know about each other when you're sort of creating this kind of fake table in CSS.

So Flexbox and Grid basically take this idea of giving things in a layout relationship and they run with it.

And this let's us do all sorts of really neat stuff.

So, full height columns.

That's pretty much the basic behavior of Flexbox and Grid.

This is a simple Flexbox example.

We take advantage of the initial default values of the flex properties.

A sidebar and content are inside a flex container, so the sidebar then runs to the height of the content all the way to the bottom.

And we get the same thing happening with GridLayout.

So here I've created a grid on my wrapper element and then I positioned my sidebar using line-based positioning.

I'm starting at line one and my content starts at column line two.

And, note, all the examples we'll look at, this concept of items knowing where they are in the layout is really important.

So for as long as I've been developing websites, and certainly since CSS came along and actually kind of pre CSS-- but once CSS came along, we talked about this separation of content and markup from display.

It was kind of the rallying cry of the CSS layout movement.

We tried to persuade our friends who were using tables that ours was the better way.

You can separate your source from the presentation.

And it was a bit of a failed promise, especially once responsive design came along.

You know, we can kind of get that, the ideal document structure for one break point, but we are making compromises usually if we've got lots of complex displays.

If we take a look at Flexbox-- so I've got navigation here.

It's very simply laid out with Flexbox, and I've used space between so that Flexbox will assign the space left over after displaying all the items.

The flex direction property is set to row, and that's the initial behavior of Flexbox if you don't specify anything.

You can also use column, and that would give you a column.

If we wanted to switch the order of flex items, we just do that by setting flex direction to row reverse or column reverse, and visually they're now displayed the other way around.

And we can go further than that.

We can explicitly set the order using the order property.

So I've got a bunch of items here that are displayed in source order, and I've given them a number which relates to their order in the source so you can see which order they're in.

So I can change their order around, and so now number one is three visually but it's not changing their underlying source order.

CSS Grid goes even further because it gives us the power to change the order of elements in not just one but in two dimensions.

So I've got a parent element here, set it to display:grid and I'm creating a three column grid.

And I can position my items using CSS Grid-- these are using the grid column and grid row properties.

If you've not seen these before, the value before the forward slash is the line the content starts on.

The value after is the end line.

So I can do things like this.

I can position my items around the grid in columns and in rows, the only constraint being that, like with flex, the items need to be a direct child of the element that's become a grid container.

And we can do more because as well as just placing things on a grid that we've created and explicitly saying where we want them, Grid also includes these auto placement rules.

And they let us take a chunk of content, hand it to a grid, and display it.

So this is the previous example but I've removed all the positioning information from the element.

So I've just created a grid, I've given it this list of content, it's displaying it.

Each item is in a grid cell.

If I add some more images and add some images that are portrait and some that are landscape-- and I'm going to give a class to any images that are landscape so I know that they're there-- and then I set the grid column end property to span two lines, this will have the effect of making our landscape images span over two grid tracks while portrait will stay in one to deal with the wider images.

So the order of placement algorithm lays out the items but sometimes it finds an image that won't fit.

So we've got the first image, and then we've got this landscape image, then the middle space there.

Well, that's too small for another landscape image, which is next, so grid just leaves a gap and moves onto the next line.

By default, grid is progressing forward.

It's keeping elements in source order.

But if we had a property of grid auto flow with a value of dense, Grid backfills the gaps.

So it moves through the content and it leaves a gap when there's not space to the next one.

It then finds the next image that's small enough and it puts it up in the gap.

Much magic.

But that's kind of scary.

If you're sat here and you're someone who cares about accessibility-- and I hope that includes everyone in this room-- this idea of being able to display things completely independently of the source order, that's actually quite a frightening prospect.

And I think that we're right to be concerned and it's probably the biggest question that comes up when I present about grid, is people are worried about this-- the potential for accessibility problems.

And I think we've got a lot to learn about these documents because ideally we should be able to use this really, really well.

We should be able to think about our source, create the best, the most accessible, the most logical source order using the best markup and then display things visually for different breakpoints.

That would be great and that would be using this really, really well.

But bad would be if people just kind of forget about the source.

That, "I thought it doesn't matter anymore.

We can just drag stuff around.

It's fine."

And, even worse, because elements needs to be the child of flex or grid parent to be able to lay themselves out, the temptation for people developing CSS-- but also for authoring tools-- will be essentially just to flatten out the grid, to flatten out the source, to remove semantic markup, to make everything a child of a grid and just be able to move things around.

I think that's a real danger.

This is being discussed by the working groups, and this is from the current draft of Flexbox, making sure the authors know that the order doesn't change how a document's read so we should ensure that any reordering we do is purely for visual purposes and doesn't change the logical order of the items.

I'm particularly concerned about the flattening of markup potential with Grid.

And this currently in the spec, a method by which you could avoid that temptation, which is a sub-grid keyword which would allow a child element to actually inherit the grid from the parent.

Now, that hasn't been implemented in any browser yet, and it's marked as at risk in the spec.

This article is where I've written up a bit more about this.

It's something I would like more people to be asking the browser vendors who are doing implementation just and for this property so that we get that and we don't run this risk of this sort of flattening out of markup.

So we have relationship between items and we also have a separation of content and display.

Grid also gives us the ability to control alignment.

And it seems like the hardest challenge in web design has been vertical alignment, and that's something that these new layout methods solve.

At this point I'm going to bring a new player into the picture.

This is the CSS box alignment module level three.

Now, this module contains all the features of CSS that relate to alignment, and basically what it's doing is taking all the cool alignment stuff out of Flexbox and creating it as a separate module that can then be used by other specs.

So it's being used in Grid and eventually it could be used in block layout.

So we should actually be able to vertically align all of the things.

This module also covers things like distribution of space, overflows, and logical positioning.

So we see all of this stuff in Flexbox and it's also starting to get into the grid implementations as well.

So we have this distributed alignment.

We've already seen one of those keyword values in the simple Flexbox example.

In Flexbox we use justify content and align content to align items against one of the two axes.

So I've got navigation here in a row and I'm using justify content with a keyword value of space between to line up my first and last items flush left and right, and then we distribute the rest of the space equally.

And space around.

Now all the space goes around the outside of the element so we get a kind of half-size space on each end.

By setting align or justify items in the flex container, we change the align self and justify self properties of the individual items inside so that's the default alignment.

So as we've already seen, items in a flex container have relationship and by default the value of align items is stretch.

And this means that the items stretch and are all the same height even though I've added some extra text to the first navigation point.

All the other items know that that one's that tall and so they're going to be that tall as well.

And here's that vertical centering.

We set align items to center and all the items center.

Of course, if you switch flex direction to column, their line item center will center the items horizontally.

You can get at individual items.

Justify self and align self are used on individual flex items to change their alignment properties.

So here I've added some rules and I've made the third item stretch rather than center, so you can kind of play around with this stuff to create all sorts of layouts.

So this works with flex items at the moment.

They say it's getting into Grid as we'll see.

But ultimately it's going to work with other kinds of layout, and if you know your Flexbox, the box alignment spec should make quite a lot of sense to you.

You can go and have a look at it and read how it all works, and there's explanations about how things should work when they're not flex items as well.

So it's fairly readable if you already know your Flexbox.

So as an example of how these properties and values work once they're ported to another module, most of these-- these sort of next few examples I think only work in Chrome Canary.

I don't think it's actually shipped into Chrome yet, but you can have a look at how the box alignment properties are making into Blink.

I'm actually enjoying following the implementation of Grid.

It's a bit like a little gift.

Every now and again something new pops up in Canary and I'm like, "Oh, something new.

I can build some new examples and we can actually see how it works."

So this is pretty new stuff.

So I create a grid here and I'm setting align items to center.

Now, this grid has a repeating pattern of 550 pixel tracks separated by 10 pixel tracks.

And we've got then 50 pixel rows separated by 10 pixel tracks.

And I can then just position my items.

So each of the four grid areas there cover four squares of the background image.

By default the item would stretch just like the flex items do and fill the area, but because we've set align items to center the items center within the area.

And the link there is to an example of this, which I think needs Canary.

We can then justify the items.

Same grid, same placement, but we've set justify items.

And so this time we get the alignment here horizontally.

And just like with Flexbox, we have the align self and justify self properties so we can target individual grid items with those.

So box a here is showing the default stretch that covers the grid area.

We've got one set to align self end, align self start, and align self center.

So this is really powerful in terms of being able to align items around our grids and our flex items and everything else.

And being able to align groups and individual items, it's really essential for responsive design where we don't know where things are really going to end up and how big they're going to be.

And it's really where a lot of our hacks which worked kind of OK with fixed-width layouts, where we started to really struggle with responsive.

And I think that's why a lot of layouts become quite simple because it's easier to do that stuff.

It's quite hard to do complex layout.

Back to the past-- not so far in the past.

But in 2009, Ethan Marcotte detailed in A List Apart article a technique for creating fluid grids.

While working with relative font sizes, Ethan noted that Grid could be treated in pretty much the same way.

That if we divided the target width of an element by the width of the context, that would give us a percentage that could be used in place of an absolute size for columns in a design.

And so it came to pass that we all started to calculate percentages and add these very unlikely looking numbers to our layouts.

And our new layout methods could actually mean it's time to retire that technique because they do this stuff for us.

They're essentially responsive by default.

We've already seen the more simpler Flexbox examples-- taking a list of items, declaring display flex in the parent, and adding the justify content property-- the value of space between.

That value flexes with screen width.

It adds and removes space as needed.

We can go further than that with Flexbox though.

We can proportionally distribute space between our items.

But the flex property is shorthand for three properties-- flex grow, flex shrink, and flex basis.

And the Flexbox draft suggests that we actually use the shorthand for these properties because they're essentially magic.

And the magic is where a lot of the confusion lies but also a lot of the power of Flexbox once you work out how to control them.

So here I'm setting flex grow and flex shrink to 1.

That means that every box is allowed to grow and shrink to fit into the space, but the ideal box width is 200 pixels.

And that basically gives us three boxes of equal width on a decent sized screen and they'll gets smaller and bigger if we change our screen width.

If we sort of drag the window smaller, we let the items wrap, and when the boxes get smaller than 200 pixels, the box should eventually wrap onto the line too to try and maintain that initial width.

Now, the final box is taking up all the space and not going to be 200 pixels because alignment is basically worked out on a row by row basis.

So that row only has one item.

It's allowed to grow, so it grows and it fills up all the space.

Of course, if you don't want it to be responsive, if you don't want the things to grow, you can set flex grow to 0 which will get you this at wide window sizes.

If you're allowing boxes to wrap, they still will do so but the box that drops onto the second line won't fill the line.

It'll stay its sort of width.

And you can get at individual items.

So here I've added rules to box three.

All boxes can grow and shrink from 200 pixels, but box three is not allowed to grow.

And then you get this.

Once the boxes have to stretch wider than 200 pixels, it will stay at 200 pixels.

The other two will get the share of the space.

So this is useful for using Flexbox in things like card layouts where you've got a top and a bottom section that need to stay a fixed height.

You don't want them to stretch in the way that the central area does.

But there's more than this because responsive design really, as we saw with Ethan's article.

It's about the proportions.

It's about allowing things to stay in proportion to each other.

So in order that we can do that, we can assign different values to flex grow and flex shrink properties.

So now I've set box three to flex grow 2, the other two boxes remaining at the default of 1.

This doesn't mean that box three becomes twice the size of the other boxes.

It means that after the initial size has been taken into account, the rest of the space is assigned to each item according to the flex grow value.

And if you do want to try and work out exactly what that means, then this is a really useful tool that lets you calculate that.

You can put in your different basis and shrink and grow and see what you end up with with your flex items.

That's quite a useful way to work it all out.

And then when we look at Grid we've got this new unit, and you'll see it in quite a lot of the Grid examples that are out there-- the fr unit.

It's a fraction unit.

And if you understand how flow grow works then you've got a real head start in understanding what this unit does, because like flex grow, it allows you to assign a fraction of the available space.

So let's take a quick look.

This is a very, very simple grid.

It's about as simple as it gets.

We've set display grid and we've got three columns.

They've all got one fraction unit as the width.

So in the image this gives us three equal width columns.

So I can change this up.

If I create the first column to be 600 pixels and then I've got two one fraction unit columns, Grid will first give the fixed width elements as 600 pixels And then it would take the remaining space and it would divide it into two because both of those need to have the same width.

If I change that last column to three fraction units, the remaining space after the 600 pixel column is taken into account.

It's divided into four and shared between the boxes in proportion.

So this-- just like with Flexbox-- allows us to create fully flexible layouts that have some fixed elements in them.

And this, if you're as old as me, is the holy grail layout we used a long for.

The holy grail was fixed sidebars and a liquid center-- the central column being able to come first in the source order, because that was the website that we all built.

We had two fixed sidebars and we had this stretchy central bit, so that's what we wanted to build.

And so you can do it like this with Grid.

If you've not seen this syntax before, this is the CSS Grid layout ASCII art layout, or Grid template areas.

That CSS basically gives you a layout.

We're defining the names with grid area and then we're basically displaying that layout in the value of the grid template areas property.

And that's it.

That gives you the holy grail.

Not that this is a layout that we're all particularly keen to build these days, but it's nice to know that finally we can actually do it.

So we've had a look at all this lovely stuff, and I'm sure that lots of you are wondering, well, when are we actually going to be able to use it? Because that's the question I get, really, when I present on this stuff is, "Oh, but what about old browsers? I've got all these old browsers.

I'll never be able to use this stuff."

And, yes, we have to deal with old browsers.

And we obviously need to make sure that the work that we're doing today serves the audience that it meets today.

But we mustn't use that as an excuse for not looking forward.

And this quote, again, takes me back to my 2004 book where I addressed the old browser question.

And my answer then-- because then as now I believed very strongly in progressive enhancement as being, really, the only way we could move forward.

But I think that reply being about rounded corners is also an indication of why CSS for layout hasn't moved on in the way that other parts of CSS have-- because it's really hard to not have your layout.

It's a lot easier to say, "Well, it's fine if we don't have rounded corners.

It's fine if we don't have a drop shadow."

It's easy to let those small enhancements fall back to something plainer.

But, yeah, it's really hard to let layout degrade to no layout.

That's not something that most people are going to be happy with doing.

But when I wrote those words in 2004, we had a very, very different browser landscape to what we are now looking at.

As I mentioned at the start, there were techniques in that book for dealing with Netscape 4 because some people were still having to deal with Netscape 4.

IE 6 was the current version of Internet Explorer.

I think it was about three years old.

We were right in the middle of that time where IE development had basically stopped, where that team just kind of went home when they've shipped IE 6, and we were starting to really hit up against issues in the browser-- those of us who were doing CSS for layout.

I'm so glad that all this stuff is still online.

There's some wonderful relics out there.

This was a site we all went to to figure out how to deal with IE 6 bugs.

If you are young enough or new enough to the web to not have had to deal with IE 6, go and have a look at some of the baffling things that used to happen.

You know, we'd just-- you'd use a certain combination of elements and half your content would disappear.

You know, massive, massive bugs, and we had users really stuck with that browser.

There wasn't another version of IE, so anyone who wanted IE was staying with IE.

And it was very hard to get people to move to another browser.

This concept of people being stuck with old browsers is going away.

And I understand the difficulty with old browsers.

You know, all this stuff with Grid is basically my weird hobby.

During the day, I, you know, I have a CMS, and although our website has quite good browser support because web designers have come to it, our customers are deploying content management systems to their end clients who are, you know, using IE 8 or whatever.

So we still have to deal with old browsers every day.

And even though Microsoft has now declared they're going to end support for anything less than IE 11 in January, they're still going to be around for a long time.

We're going to have really old browsers, we're going to have non evergreen browsers for awhile.

But I think that as people do move onto those evergreen browsers, we can really start to see feature support as a continuum.

If we enhance using newer techniques, our uses actually see our sites and applications improve over time without us needing to do anything.

And that's the business case for this stuff.

How long will a site that you built today-- how long is that actually going to be around? How many of these new features are actually going to be there in two years' time? In three years' time? So you can embrace these new features now even if only a small number of users see them and over time their experience will improve, even on a site that you're not actively updating.

And features are coming into browses at a great pace compared to how they were, even something huge like GridLayout.

So the features in their current form came from the IE team, so there's actually an earlier implementation of the spec in IE 10, 11, and the current version of Edge.

And when people look at Can I Use, they're like, "What? This is only supported in IE?" And it is, but it's an older version of the spec.

Now, it was an early version of the spec.

So the most complete implementation is the work that's being done by Igalia, actually sponsored by Bloomberg, which is quite interesting in itself.

And that is in Blink, so it's in Chrome and Opera, and you need to toggle the experimental web platform features flag if you want to have a play with it at the moment.

It's also in Webkit nightlies with the Webkit prefix.

And I haven't looked recently, but I think that implementation is pretty comparable with the Blink implementation because it's, again, being done by Igalia.

Last week it started to appear in Firefox nightlies.

Quite a lot of the work.

And Edge have put updating their Grid implementation as high priority on the backlog.

I think they're waiting for the kind of spec to be-- all the features to be sort of decided on, ironed out, and then they're going to ship their-- start working on their [INAUDIBLE] update.

So we're going to get Grid cross browser in the near future, and we'll be able to start using it in some cases.

But there are always going to be these old browsers around and people who don't have Grid, and we're in that situation now with Flexbox.

You know, a lot of us are going to have good Flexbox support for some of our users, not all, so what do we do with that? You don't need to see these things as being all or nothing.

You don't need to have an entirely Flexbox site.

You don't need to have an entirely Grid-based site.

You can begin to use them for small UI elements, and that's a lot safer way to use these things than relying on your entire layout on something that might not be there.

So use the methods that work for your target audience and then finesse using these more modern methods.

Flexbox-- I think that's quite obvious how can use that.

It's really been designed for small UI elements.

But even with Grid-- this is a little example I put together of how to use Grid to display a dl element in two columns using the auto placement properties.

So that's the Grid version going into two columns.

We've got some rules that mean that terms go on one side and definitions on the other.

And that's the linearized version.

But, you know, it's probably just fine if that's just a small UI element.

It might be absolutely fine that that linearizes and then people who do have Grid get it in the two column version.

And Zoe's talk, Flexbox-- enhanced responsiveness with Flexbox, that's a recent version of it.

I've seen her do a previous version.

It's an absolutely fantastic tool if you want to figure out how to start using Flexbox today for different elements to enhance your responsive design while still having good support for legacy browsers.

Now, she works at booking.com.

They obviously have the whole gamut of browsers come into their site, and so she's got a lot of experience in making Flexbox work across all these different browsers.

Do take a look at your stats before making assumptions about support.

And increasingly you should be checking feature support rather than just browser version.

You know, do the browsers that come to my site support these features that I'd like to use? We really like this too.

This is Gauges.

It's a sort of lightweight analytic tool, and it includes this great view of what the browsers visiting your site support.

And it's not just CSS.

They also have HTML5 stuff, all kinds of features that you can have a look and see whether you've got support.

Now, these are actually the stats for the Perch marketing site.

So on our marketing site with a target audience of web designers, we can pretty much go far [INAUDIBLE] with things like Flexbox.

I can promise you it's not the same within the product itself unfortunately.

It's also worth separating out, if you can, your mobile statistics and desktop.

You may well find you can start using some of the newest stuff at those mobile breakpoints earlier than you can do it for everything.

And actually, you know, those smaller screen sizes, being able to finesse the layout can be really, really useful, so things like Flexbox are ideal.

And we tend to concern ourselves with when we can actually use this stuff in production, but there's no reason not to use it for prototyping, and especially with something like Grid.

If you're designing in the browser-- and a lot of people tell me, you know, they're using Bootstrap and so on for prototyping and then they rebuild.

But why not use Grid for prototyping? The ASCII art layout example I showed you earlier, that's Grid template area's way of doing layout is brilliant for prototyping and designing in the browser.

You can mess around.

You can move things around.

You can see how things are going to work at different break points.

Yes, you're going to have to rebuild it and that's a bit of a shame, and we all sort of look forward to this future when we don't have to, but it's a very, very good tool for prototyping.

And then you get two wins-- you get a good prototyping tool and you get to learn how GridLayout works, so in the future you'll know how GridLayout works and you can actually start using it in production.

And the reason to start looking at this stuff early is because if you don't look at it early, you lose your chance to feedback.

You lose your chance to actually go to the working group and say this isn't going to work because.

As wild specs are being drafted, you get a chance to offer feedback, and that really works.

Yesterday, Igalia, who are doing the Grid implementation in Blink, posted to say that grid column gap and grid row gap features have been shipped into Canary.

Now, this is a feature that I-- I've been going around doing this talk like this and talking about Grid, and I've been asking the working group for proper gutters, essentially, in GridLayout, which we didn't have.

And finally enough pestering from me and some other people, it was actually put into level one spec.

It's now being implemented.

Now, if we, as the people who build the web, don't talk to the people in the working groups and say what we need, it won't get into the spec, it won't get into browsers.

And once things are out there and they're live in browsers, they're very, very hard to change.

So if you want to be able to influence how things develop, you need to get involved looking at the specs early.

So if you want stuff with GridLayout, the working group are hoping to get any final comments in this month before the face to face, and I've got a whole bunch of examples on gridbyexample.com.

Enable the web platform features flag in Chrome and in Opera and have a play around.

Have a look at those.

It's a really good time to report back.

Thank you very much for listening.

Slides, resources, all sorts of things there.

Thank you.

Excellent stuff, Rachel.

Please accompany me to the Sofa of Glory.

That's not a sofa, is it? That's a chair.

The Armchairs of Glory.

I want to reiterate what Rachel said about giving feedback because Rachel and I were at the CSS working group meeting in Paris in August, and about five times in the one day all the standards wonks would look at she and I and say, "What do authors think?" Like, you know, we are Mr. and Mrs. Author

and we represent all of you people.

We know what we think but we don't know what you think.

And if you don't tell them, they'll never know.

But they do take feedback on board, and they do change the specs.

And changing the specs before they're implemented is precisely 907 times better than changing the specs after they're implemented.

Yes.

We have some-- lots of very specific questions I'm not going to ambush you with.

I will go through Twitter and try and answer some bits and pieces.

OK, coz if somebody asked me on the stage can I animate GridLayouts, I would-- It is in the spec.

I couldn't tell you exactly which things can be animated off the top of my head, but it is actually in the spec, so you can have a look through and work out-- but, yes.

I mean, you should be able to animate most of those properties I think.

So I'm glad I ambushed you then.

Somebody said Flexbox is meant for-- isn't meant for page layout.

It's for UI.

And it's often asked, I know, what's-- what's the difference between GridLayouts and Flexbox? What's best used for what? Well, so, Flexbox is really-- is one-dimensional.

It's for things that can be laid out in a line.

I mean, the line can wrap, but it is essentially for things that are laid out in a line.

So GridLayout, you're laying things out in two dimensions.

You can put things across in a row or you can put them down in columns.

So that's really the difference.

Flexbox is pretty much for stuff that is gonna be in a single line that can linearize, whereas Grid is-- yeah, you're creating a grid.

You're sticking stuff into boxes on the grid.

All right, so if I've got a toolbar or I've got like an unknown different number of buttons, I don't know, because some buttons only show [INAUDIBLE] admin person in a line, use Flexbox for those.

But if you're doing a full-page layout, use Grid.

Yeah.

Yeah.

I think it's really where you want to have control of stuff in two dimensions.

And obviously at the moment, it's a bit early to know like how these things are going to perform stacked up against each other, which I think is-- soon it's going to be really interesting, you know, which layout method is the most performant.

And that's the sort of stuff that I think will come out as the specs develop and we actually get the full browser implementations.

You were saying to me as well that one of the reasons why it feels like Grid is taking its time to support, to come into browsers, is because the browser vendors are unwilling to repeat what happened with Flexbox.

Could you elaborate a little bit? Yeah, well, I think that generally, I mean, the sort of-- what happened with Flexbox is we kind of got bits of Flexbox into browsers then the spec changed, and so we've got this old version of Flexbox and this new version of Flexbox.

And we've got actually quite a lot of Flexbox bugs that people are having to work around.

With Grid it's essentially all staying hidden away so no one can use it in production, so we don't end up with this issue of having people with in production and old version of the spec, because that's just a general problem.

Add to that, it's tied up with a whole vendor prefixes issue and whether or not those were a good idea.

So it's not-- so it's not really an example of browser manufacturers being slow so much as browser manufacturers agreeing to hold back so that it's interoperable once it does hit the market-- Yeah.

I mean, there have been huge changes.

Quite a lot the stuff-- and if you're looking at easy ways to offer feedback, a lot of these new specs have just loads of issues in line that are just, "What should we call this?" Or, "This is a bad name.

Can anyone think of a better one?" And so, like, just loads things like naming changes as the spec's developing, and so this is what happened in Flexbox as well.

But if it's happening when people are using it in production, it's a bigger problem.

And if that happens now, you know, it's really just me updating my examples when things change with Grid at the moment.

So that's fine.

You know, so I think that once it's-- it kind of gets essentially sort of finished and no one's going to change any of the naming, it'll be smaller tweaks to the spec.

I think the browser manufacturers are going to be much happier to start shipping it.

And it's not just bike shedding, is it? I know that a friend of ours, Mark Bolton, who's a designer, has been talking to the working group because it's a very designer friendly module-- I'm talking about the Grid module here.

So he's been trying hard to make sure that the names that are chosen are aligned to the nomenclature that actual designers use so that it's even more friendly.

Yeah.

I think it is really difficult, and because there is this sort of idea that things should behave in a similar way.

That Grid and Flexbox, you know, should actually behave quite similarly, which is happening and wasn't happening initially.

So I think-- because all that stuff is going to make it a lot easier to use.

But it's an interesting process.

I'd recommend anyone kind of get involved early stages with something they like the look of.

It is interesting to follow these things and you learn a lot about just how browsers work.

By interesting you mean soul destroying in a masochistic way.

Oh, you know, I'm a massive nerd, so-- Ah, OK.

OK.

Somebody else asked-- and this is a bit of an ambush question as well, but it seemed-- it seemed to the person asking, and I didn't bring my iPad up with me, that the fr unit in Grid was pretty much indistinguishable from just the single number that you'd use in flex grow or flex stretch, so why the different units? Why not homogenize it? Yeah, I don't know what they-- I'll have to look up and see if I can focus that.

That fr unit has certainly been around since I've-- I'm pretty sure it was in the original IE stuff, yeah.

So I don't know where that came from.

A bit interesting.

I can have a dive into the specs if I can find out where it originated from, but it doesn't exist in anything else as far as I know.

It's a brand new four grid thing.

But, yeah, I can certainly see if I can find out-- The question's on Twitter anyway-- Yeah-- ---so whoever asked, I apologize for not remembering your name.

I will have-- I will have a look through Twitter and answer any I can.

There's-- there's the question about accessibility, which you've touched on as well.

It seems to me that it's not really a problem if you're being sensible, you know.

If you're rearranging big, discreet lumps like, I don't know, your nav is on the left on desktop but is underneath the content on mobile, you won't have a problem.

If you're rearranging the order of individual words, that's an accessibility problem but also it's stupid, so-- Yeah.

Yeah.

I think the biggest issue, really, is in terms of authoring tools because you could imagine anything that's trying to create a way of doing layout visually, the temptation would be just to flatten out all the markup because no one's going to see the markup.

You know, it's like we're just dragging things around, and here's a website and it works, which it will.

And I think that's probably-- and that's something that it's good to have that stuff in the specs saying that an authoring tool is not conforming if they're doing that sort of thing.

Yeah, I know when I was-- my endless redesign of my own blog to make it properly responsive, the accessibility issue I had was that I started doing it in mobile first and then rearranging the content with Flexbox for desktop.

But the trouble with that is that if I was tabbing through-- and I have like a nice focus ring-- the tab order moves around because it follows the source order rather than the visual older, which is why I went back and actually designed it desktop first so that on desktop if were tabbing it would follow a logical order, and then rearranged it for narrow screens because of course you don't tab through stuff in mobile.

Yeah.

I think that-- I mean, I'm not an accessibility expert.

I'd love to actually speak to people who are about this stuff because I think there's an awful lot we're going to have to work out because we've got a very, very different way of doing layout with these tools.

And I think, you know, as a community, we need to figure out how we do that because I don't think the answers are always straightforward.

Yeah, you know, things like tab order.

It's not necessarily obvious that that's what's going to happen unless you-- unless you've checked, and not everyone checks.

So I think, yeah, we need to definitely have discussions about how that's going to work in the future.

There was talk, I remember, in the spec-- there was talk of adding to the spec some kind of CSS property to say the visual tab order, almost like a visual tab index, but I don't recall it going any further than a mailing list conversation.

Yeah.

I think there have been various conversations about it.

I think it's definitely an area that I think we'll need to be thinking about and talking about and I'd like to be adding the sort of decisions made by the accessibility community into talks like this to make sure people know what they should actually be doing, you know, in the future.

And the last question, which is a long one.

I remember when we were at the working group meeting in Paris, I remember you, like, throwing bottles and beating people up in the lift about something called subGrid, and you were saying that the lack of subGrid would actually harm accessibility and harm semantics and everybody in this room should also hurl a bottle at a working group representative.

So could you expound and get everybody fired up over this? Yeah.

So I briefly mentioned the subGrid issue.

Essentially it's this ability-- because with Grid and with Flexbox the only things that become able to be used in that context are direct children of the item that has Grid or Flex declared on it.

That's fine for Flexbox because we're just dealing with things in one dimension.

With Grid, really what you're going to want is not only to direct children to be able to go to the lines of the grid you've defined but also their children, so nested things.

And there is something in the spec to allow you to do that, but because no one has implemented it and no one looks like they're thinking about implementing it, like, it's-- on the browser vendor front, it's completely silent.

And if things don't get implemented, then there's a possibility that they'll get removed from the spec just so that the spec can kind of be declared a thing that's done, implemented, and people can say we've got an implementation.

I think if we lose subGrid then we have more accessibility problems.

I've got-- the article I showed in the presentation links to more stuff about that.

But it's definitely something I would like people to look at and think about and maybe mention to their friendly browser vendor while they're doing that.

Yeah, please do look at it because I was unaware of the issue.

I'd read the blog article but I hadn't realized the magnitude of it and then Rachel talked to me in Paris and made me realize that it is a clear and present danger.

Anyway, ladies and gentleman, Rachel Andrew.

Thank you.