Making Things Better

We hacked around the problem

Designs were created that hid the issue, a gradient that faded away and hid the fact that the boxes were uneven heights, avoiding background colors altogether, the faux columns technique of the past. A technical limitation influencing design, and even sometimes our content.

Enter flexbox and then Grid and the fact that align-items has an initial value of stretch and the problem not only disappeared, but the default behaviour of these layout methods was the thing we struggled with for so long.

How big is that box?

But it isn’t just about how tall the thing is, but in general how big it is. We’ve gained new abilities to size things based on how big they are. My talk in 2018 at An Event Apart is online as a video, and in that talk I unpacked some of the complexity of sizing in new layout.

Overflow happens, if you fix the size of things. By default CSS tries not to cause some of your information to vanish. If you want something else to happen then you need to declare that. And you have an increasing number of options.

Better ways to stop content just “honking out of the box”

The author of the meme wondered why the box didn’t grow to fit the content. However if you give something a fixed size in CSS, it will respect that size. What the author really wanted was to make the box min-content sized. With a box that has a width of min-content the box will grow as big as it needs to be to contain the content, with all soft-wrapping opportunities taken, but no bigger.

If instead, you want to make the box not wrap at all, then give it a width of max-content. The text will then display all as one line and take no soft-wrapping opportunities.

Perhaps you need to have the box that fixed width, but don’t mind if it grows taller. In that case use overflow-wrap: break-word.

Take a look at the next CodePen for all your awesome possibilities.

Being awesome vertically

A problem which perhaps many of us English speakers haven’t run into, is the fact that CSS had for any years a baked in assumption that we were all using a left to right top to bottom language. Essentially that we were all English speakers.

However CSS has also updated to match the reality that worldwide many languages are not horizontal, and running left to right, but perhaps are horizontal and running right to left, or written vertically, or maybe even a mixture of the two. The Writing Modes specification details the different writing modes and allows us to switch between them, we can do so for creative reasons or, because we are typesetting a language which uses those writing modes.

Flexbox and CSS Grid brought with them an agnostic approach to the writing mode of the document

For the first time we had to think about start and end, rather then left and right, top and bottom. This agnostic approach is apparent in alignment, and also in line-based and auto placement in grid. In fact, in my early Grid talk, which you would have seen if you came to An Event Apart sometime in late 2015 or 2016, I mentioned that if you set all four lines using the grid-area property the order of the lines wasn’t the familiar top right bottom left of setting a margin shorthand, but instead – when in a horizontal writing – mode top left bottom right. The reverse of that order.

What that shorthand is doing is setting the block and inline start then the block and inline end, for as soon as your grid is not in horizontal-tb thinking about top, right, bottom, and left doesn’t make a lot of sense.

Logical Properties and Values

The problem then is that we have a situation where our main layout methods talk about start and end and inline and block, and everything else in CSS – floats, positioning, margins, padding and borders, all describe themselves in terms of physical dimensions.

All this specification contains is a set of mappings, and additional shorthands that give us a way of defining things in a flow relative, logical way as opposed to the physical way we are used to. If I have a grid layout with a width but then use Writing Modes to switch to a vertical writing mode, the grid layout will all work in that writing mode. However the width remains tied to the horizontal measure, meaning that the shape of the grid changes.

Instead of width I could use the new mapped property inline-size, representing the size in the inline direction. Which for a vertical writing mode is vertical not horizontal. This would mean that once in a vertical writing mode, the inline-size would control the height of the component and the entire grid would retain its dimensions.

Therefore if we give our awesome meme an inline-size of min-content, when we are being awesome horizontally, the inline-size runs horizontally. To be awesome vertically the inline-size runs vertically.

There are mapping like these for pretty much all properties in CSS, and some values too. I’ve recently documented these over at MDN, MDN also has lots of live examples so you can play around with the different properties.

Browser support is improving with the mapped properties, and I mention this here, partly because I think ultimately these logical, flow relative properties will become our defaults but also in the context of problem solving. In creating CSS.

An additional complexity for anything that we create in CSS is it needs to consider these writing modes. We’re not in the business of creating a better web just for horizontal language users. In fact, as I’ve looked into vertical writing more as a spec editor, I’ve realised what a wealth of interesting patterns emerge from people who use the written word in a different way to me.

Grid and Subgrid

Before thinking more about paged media, I wanted to think a little bit about a problem that is currently being solved. I think most people would agree that CSS Grid Layout has been the biggest problem solver of the last few years, giving us a real layout system for the web for the first time. Moving us away from hacking around floated layouts to build grid-based designs.

A new problem appears however when we begin to really work with grid, we discover that one grid is not enough. I’ve got a different presentation of my gallery here, which uses grid layout and I have this time added some captions to the images. The overall layout here is a fairly straightforward grid, each individual image and caption is also a grid, by making the grid item a grid container and defining two row tracks. This enables me to stretch the image over two tracks, and place the caption in the second track.

The problem we have however is if we add additional text to the caption. It becomes taller than the other items and the effect of nice lined up boxes is diminished. We can’t line the captions up because those nested grids don’t know about each other and how big each caption is. Sound familiar?

That’s right. We never know how tall anything is on the web.

What we need is a way to ask the nested grid to use tracks defined on the parent. That way the captions could be in the same row. A change to the size of one caption would then change the height of the entire row, taking the other captions with it. This is exactly what the subgrid value of grid-template-columns and grid-template-rows gives us. You can see this is action in the CodePen below, as long as you use Firefox. Firefox is currently the only browser to support subgrid. If you would like to see it in Chrome, it wouldn’t hurt to go star this bug to show your support.

The point it, that as you start to design with and for these new layout methods you will hit other problems. And do you know, that’s a good thing.

Don’t fall into the trap, of becoming excited about all the new things, and when someone points out something you can’t do, perhaps scoffing, oh you think grid is so great but look, it can’t do this, feeling you need to defend it, perhaps explaining that this isn’t a limitation, the web doesn’t work like this, the web is not print, or perhaps the web is not native, or whatever ….

We just can’t do that yet

We get to do it, by finding the use cases, explaining them, writing them up. Pointing to other media and asking whether we can do that thing on the web in an elegant and performant manner. We get this stuff because we create this stuff.

Not just me, or the CSS Working Group, or the browsers, or the folk from print user agents or EPUB. All of us.

So here are my edges, the things I want to be able to do. Things I think we’re sort of close to, and where more use cases and more thinking might just help to push them over the line.

If we can back to my example of three pages of gallery images. What would happen if I wanted to put text into one of those boxes? It’s a grid layout, so the area can accept text rather than an image. However, if we end up with more content than the fixed size row will accept we get overflow. The only way to fix that is to make my track expand to auto size, and I then lose my nice paged effect because I can’t be sure that my rows will add up to 100vh. We are right back to our same problem, we don’t know how tall things are on the web. It’s like groundhog day here.

Overflow and Multicol

How might we solve this problem? We can start by taking a look at overflow in multicol. CSS Columns behave differently in a few ways depending on whether we are in Paged Media, such as a book or a printed webpage, or in Continuous Media which is what we are on the web. These things really refer to what happens with overflowing content. When you end up with more content than will fit on a page in Paged Media, a new page is created. When you end up with more content than will fit on a screen in Continuous Media you get a scrollbar and can scroll down to view more content.

In multicol on the web, if you have more content than fits on the screen the columns just get longer and longer. Eventually you have to scroll up and down to read the content, which is a terrible reading experience, and the reason people tend not to use multicol on the web.

If you fix the height of the container, to prevent the up and down scrolling thing, the overflow columns are created in the inline direction. You will end up with a horizontal scrollbar. Again, there might be some use cases for this but I don’t want to do a horizontal scrolling thing very often.

So let’s assume I’m not a maverick and want to stick with scrolling in the block dimension. What if you could say I want my multicol container to be so high – perhaps 100 viewport height high AND if there is more columns, create another 100 vh box in the block dimension and fill it with columns. Keep on doing that until you run out of columns.

The image on Can I Use above was taken before Edge moved to Chromium. Edge had an implementation of Regions and so I was able to record the following video, demonstrating how Regions worked with my grid layout.

The text is one continuous thread. It fills the boxes in turn. First filling box 1, then box 2 and moving onto fill box 3.

The problem with Regions can be understood via this example. The content flows nicely between the boxes. I get a multicol like effect between the first two boxes. The remaining content then flows into the third box.

But what happens if there is more content then these three boxes can hold, or the user has increased their font size? That’s right – we get overflow because you never know how big things are on the web. Regions needs somewhere for the content to go. You have to create a stack of redundant elements to hold content which may or may not be forthcoming, second guessing the content to have enough layout and not too much. In all likelihood using JavaScript to work that out and create enough elements.

There was no ability to do anything like the things we can do in Paged Media, no way to declare that my pages or components look like this, please create as many as you need and put the content into these boxes.

It has been suggested to me that the spec is fine because you can dump everything leftover into a final div for sad content without a home. I don’t think that is a solution anyone really wants. That’s a hack, a workaround, it feels like something not fully thought through.

Regions faltered. The code was removed from Blink. Whenever it comes up people get very tetchy. However this all really predated grid layout.

I think that now, in a world where we have Grid and where Regions makes a lot of sense, we can circle back and look at something which is like Regions again.

As with block dimension overflow for multicol, I think this is also all about overflow. Web design has always been a battle against overflow, against the fact that we never now how tall (or how big in the block dimension) anything is on the web.

The minute we decide that we have a finite page, we aren’t just scrolling forever, we have decided how big this is in the block dimension, we risk overflow and we have given ourselves the job of managing it.

Web design is mostly a batle against overflow.

Did Regions pave the way for something better?

What if, as with multicol overflow, we can say – this is my container – it’s 100vh. It looks like this, at this breakpoint, it looks like this at another breakpoint. Here is my content, I want it to flow through these boxes. If I fill all the boxes, create me another box with the same layout and continue to add content.

As with the original regions idea my content thread is a semantically marked up thing, it makes sense outside of that layout. We gain that separation of structured content and the layout. I think it would be incredibly exciting and useful. There are however things that need to be put into place before anything Regions-like can happen. CSS Regions, like multicol relies on Fragmentation, and fragmentation is not in great shape across browsers right now. And, while it is annoying enough to end up with a heading at the bottom of one column with the content in the next. It would be a dealbreaker to have the heading in a box completely disconnected from the rest of the content.

Making things better

Whether you like the idea of Regions or not, I talk about these things because this is how we get new things. This is how we solve problems.How we figure out the next big layout challenge and start to fix it. Here is another example.

At An Event Apart I ended up chatting to Rob about a problem he had with Grid. He wanted to be able to float items but still have them use the grid layout.

Because a floated item, when it becomes a grid item, loses the float behaviour he couldn’t do that. So had come up with a hacky solution to the problem and he wrote it up.

Now Rob saw this as a grid problem. He wrote it up as a grid problem.

However when I looked at it, because I’ve been digging around these specs for years, I recognised that we already had something in CSS that could solve this. The Exclusions spec – also only useable in Edge right now – solves this problem perfectly.

I was able to write up the solution with some demos.

More importantly it gave me a great use case to take back to the CSS Working group, to show them of a real-world problem that Exclusions solved, to see if we could start talking about it and solving the problems in that spec so more browsers might implement it.

This is the sort of thing that anyone can do. Write up the things you can’t do – even guess at a solution – don’t worry if it isn’t the best solution. Figuring that out takes more than one mind most of the time – that’s why we have the CSS Working Group. But do show us. Don’t assume that because CSS doesn’t work like that now it can never work like that.

We have come so far in the last few years. The last thing I want, is for it to stop now.

Perhaps these first few years of grid, when we look back will look very grid like, as we all got excited about being able to neatly line up our boxes. That’s great, lining up boxes is a useful thing to be able to do, but let’s not allow that to define our new technical limitations, and instead keep poking at the edges and asking what next, why can’t I do that? And we’ll keep pushing at the edges, and continue to break out of the technical limitations, making things better, faster, or yes just less weird.

And this was very nearly the end of this talk. But, when I was about to present this in San Francisco for the first time something happened that I think backs up the importance I place on more people having input into the web platform.

I woke up, to the rumors that were later confirmed that Microsoft were dropping their rendering engine EdgeHTML in favour of using Chromium. And I feared that we were heading right back to the days where one browser had over 95% market share. Where one browser could quite literally dictate the direction of the web.

Many of the things I have talked about, Exclusions and Regions for example, were implemented by the Microsoft team. No, not in a perfect finished way, but enough for us to be able to experiment. Enough for us to try them out. Grid Layout was first implemented by the Microsoft Team in IE10. No, it wasnt perfect, essentially a prototype for what was to come, but it enabled people to experiment. I probably wouldn’t be known as the CSS Grid person if it hadn’t been for that implementation allowing me to start to work with the spec.

Fewer browsers mean fewer experiments. Mean fewer places where things can start to evolve. When I first gave this talk, I said I was absolutely sure that the excellent people on the Microsoft browser team, people who I would call my friends, good people, good engineers, true standards advocates would do great work on Chromium. That has already played out to be true. But ultimately, it’s a single rendering engine and is driven by the needs of Google.

And, if we are not to have diversity in rendering engines then we need to double down on making sure that there is diversity of thought involved in the standards process.