# data[].attributes.title
The web is ready for great graphic design

# data[].attributes.blurb.html
Some of the world's greatest print design was made on known canvases, with known content using known color options. On the web, we have more flexible tools. Media queries, flexible units, Grid Layout and Flexbox let us do great graphic design. With flexibility.

In this talk, I will show some of the CSS that puts great graphic design into practice on the web. Get inspired by some of the icons from the history of graphic design, while learning new properties that you can use in projects today.

# data[].attributes.slidedeck.data[].slides[].desc.html
Hello and good morning! I am excited to be here today, I'm local so I've been to all of the previous CSS Days, it is a great honour to now be on this stage.

# data[].attributes.slidedeck.data[].slides[].desc.html
I've already been introduced, but for those curious how that name is spelled, it's Hidde. I am a contract slash freelance front-end developer working for all sorts of organisations and companies, trying to make their front-end code a little better.

# data[].attributes.slidedeck.data[].slides[].desc.html
Currently I am contracting at Mozilla where I work in the Open Innovation team on something completely unrelated to CSS: Identity and Access Management. Any queries, in the break please, as I'll be talking to you about something else.

# data[].attributes.slidedeck.data[].slides[].desc.html
Graphic design and the web!

# data[].attributes.slidedeck.data[].slides[].desc.html
My main reason for looking into this is probably that Grid Layout was going to get built into browsers…

And a workshop; in 2016, Fantasai, one of the creators of Grid Layout and too many other specs to count, tweeted about her idea for a workshop. It involved getting together, reading a spec, understanding it and making it more understandable for others. So not a ‘we will teach you how to use this’ kind of workshop, but one to read the actual spec.

# data[].attributes.slidedeck.data[].slides[].desc.html
It was a sunny day like today and we sat in a warm office with that long spec. In the train back, I kept feeling “shit I'll need to know more than just CSS -I'll need to read more about graphic design history now”

# data[].attributes.slidedeck.data[].slides[].desc.html
I had always been interested in that stuff, so I had a few books, but I started to buy more.

I also started reading some older blog posts about layout on the web, and took out the books that taught me how to build websites. It was fascinating to have a look through. These books describe things like how you can build navigation bars with CSS, do tabbed layouts with rounded corners and shadows… I remember how inspiring they were at the time, but also realised that a lot of the things in there are currently possible with JUST CSS.

# data[].attributes.slidedeck.data[].slides[].desc.html
It's clearly a new era for design and lay-out on the web. We have stuff built in to browsers now that did not exist before.

# data[].attributes.slidedeck.data[].slides[].desc.html
So what's great graphic design, I hear you think? This is quite a subjective term I guess, but what I mean by it is the kind of design from years ago that people still look back to. I want to look at some historic graphic design.

# data[].attributes.slidedeck.data[].slides[].desc.html
I'll be focusing specifically on modernist graphic design. One because modernism is pretty rule-based, like the web, and two because it is a movement that responded to industrialisation. We got more and more machines around us and modernism tried to come up with a matching aesthetic.

# data[].attributes.slidedeck.data[].slides[].desc.html
One of the great modernist graphic designs is Jan Tschichold, who wrote Die Neue Typography. I read it as The New Typography, the English edition which comes with a good introduction as well as some context.

# data[].attributes.slidedeck.data[].slides[].desc.html
In 1928, Tschichold noticed that people had more and more ‘printed matter’ in their hands, as he liked to call it. Newspapers and books, he was talking about presumably. It was time to focus on readability, he said, and to put function before form.

# data[].attributes.slidedeck.data[].slides[].desc.html
One of the ways he suggested we should do that, is by introducing assymetric alignment: rather than having columns of text that are exactly the same width, he suggested we should get more contrast, also in font sizing for example. This is an example of good readability, according to Tschichold, because there is plenty of contrast.

# data[].attributes.slidedeck.data[].slides[].desc.html
It's all about leading the people's eyes from one word to another. TLastly, Tschichold emphasised we should be intentional about our work. This may be at odds with how flexible the web is, we can have good intentions, but our solutions won't look the same in every browser.his poster has contrasts between red and black colors, and large and small font sizes. And the text column isn't exactly half of the page.

# data[].attributes.slidedeck.data[].slides[].desc.html
Lastly, Tschichold emphasised we should be intentional about our work. Not solving every problem with the same solution, is what I read there between the lines.

# data[].attributes.slidedeck.data[].slides[].desc.html
The clarity that Tschichold was after, Müller-Brockmann continued thinking about to make it better. Designing with grids was a large part of that.

# data[].attributes.slidedeck.data[].slides[].desc.html
Müller-Brockmann explains why we'd want grids in the first place.

He explains that if you have a bunch of content that needs to go into a lay-out, a grid can give solutions that are functional, logical, and just look better.

# data[].attributes.slidedeck.data[].slides[].desc.html
When a grid is applied to it, a surface an more easily be organised in a way that is rational.

# data[].attributes.slidedeck.data[].slides[].desc.html
I can't really explain here how to make grids according to Müller-Brockmann, that would be a whole talk on its own, but Müller-Brockmann talks a lot about dividing the page into what he calls ‘grid fields’, we would these ‘grid cells’ in CSS Grid Layout terminology. He divides the paper into fields.

# data[].attributes.slidedeck.data[].slides[].desc.html
Müller-Brockmann, like Tschichold, talked about how important it is to be intentional about designing something for your requirements. I don't think he meant every page should have a different design, he was after a systematic approach. This matches our style guide world well.

# data[].attributes.slidedeck.data[].slides[].desc.html
Müller-Brockmann really believed in the benefits of mathematical proportions in grids. Not only as a way to make a more interesting or pretty design, but also to aid focus and create order and hierarchy.

Here's on example.

# data[].attributes.slidedeck.data[].slides[].desc.html
And here is another.

# data[].attributes.slidedeck.data[].slides[].desc.html
In the early sixties, modernism got very popular in the Netherlands, for a large part because of this man: Wim Crouwel, graphic designer and known for his grid-heavy design work and his agency Total Design.

# data[].attributes.slidedeck.data[].slides[].desc.html
He is well-known for this creation of his: The New Alphabet. In a response to how screens work, with rasters, so everything is squares. That made rendering serif fonts like Garamond impossible, so he came up with an aesthetic that took the constraint into account. This typeface only uses horizontal and vertical lines. Consequently, it is super hard to read especially the a and the w. So the title says 'new alphabet'.

# data[].attributes.slidedeck.data[].slides[].desc.html
His designs were typography heavy, and had creative use of whitespace.

# data[].attributes.slidedeck.data[].slides[].desc.html
Sometimes with graphical elements, and with rotations. The poster on the right is one of his most famous, he created the typeface for this poster specifically.

# data[].attributes.slidedeck.data[].slides[].desc.html
In this year's redesign, the Dutch magazine Vrij Nederland used the 'Shima' typeface for some of its headings. This is special, they even credit the type designer along with the author and photographer.

# data[].attributes.slidedeck.data[].slides[].desc.html
We've seen some examples of posters for museums and events, but really, a lot of modernism in graphic design took off when corporations started getting ‘house styles’. It became quite a thing in the early sixties.

Companies realised that their visual style was all over the place and they desired on system to make themselves more recognisable and get more trust from their customers or the general public.

# data[].attributes.slidedeck.data[].slides[].desc.html
You could say it was during this time that we had something like design systems 1.0. With different materials, of course, but perhaps similar goals.

# data[].attributes.slidedeck.data[].slides[].desc.html
The first company in the Netherlands that introduced their own ‘house style’ is KLM, the airline.

They used to have this as a logo. As you look at it, you might see some recognisability problems right away. The crown is pretty ok, although it is quite eloborate. The letters ‘KLM’ are downright hard to recognise. But they're there.

# data[].attributes.slidedeck.data[].slides[].desc.html
Their internal design team worked with an American design company that helped them develop an identity that they could use on planes, newspaper ads, napkins, you name it. It had colourful stripes and a much simplified version of the logo.

# data[].attributes.slidedeck.data[].slides[].desc.html
But it was still a bit complex in shape, they found in further research. The designer David Ogilvy drew these lines on top of the logo, as part of his research, and found it was still quite a lot of lines.

# data[].attributes.slidedeck.data[].slides[].desc.html
With only a few changes that hardly changed the feel of the logo, they were able to have a much simpler shape, and, perhaps, more recognisable.

With the KLM redesign, Dutch agencies started to realise that they could take on large house style projects, and they did. Total Design, which Wim Crowed co-founded, is one of those pioneering agencies.

# data[].attributes.slidedeck.data[].slides[].desc.html
They completely restyled the PAM, but also worked on phonebooks, stamps and many other visual identities.

Their competitor Tel Design did a new house style for the national railways.

# data[].attributes.slidedeck.data[].slides[].desc.html
Designed in 1968, it looked like this and it is still around. This redesign project went massively over budget, but it was very effective and, indeed, timeless.

# data[].attributes.slidedeck.data[].slides[].desc.html
Modernist graphic design wasn't just about visuals: it was also during this time that things like paper sizes and colours started to get standardised.

With huge advantages, including financial advantages: it made large corporations much more efficient and it aided the idea of having one visual style everywhere.

# data[].attributes.slidedeck.data[].slides[].desc.html
Grids were super popular, and even used to make print easier work with computer involvement. Because if the phone number in a form is always placed in the same place, that is easier to process and paves the way for automated processing with computers.

# data[].attributes.slidedeck.data[].slides[].desc.html
In the sixties and seventies of the last centuries, many, many large companies in The Netherlands got some sort of house style, almost all of them in an orderly, modernist way. With grids, neutral typefaces, simple shapes, mathematical proportions, et cetera.

# data[].attributes.slidedeck.data[].slides[].desc.html
Not everybody liked this modernist revolution

# data[].attributes.slidedeck.data[].slides[].desc.html
The designer Piet Schreuders, the Dutch amongst us may know him for his work for VPRO and de Poezenkrant, a newspaper about cats, eclectically designed, wrote an essay in which he openly criticised the work by his modernist colleagues.

This is him on the left, graphic designer Wim Crouwel on the right, he is presenting his book. During the presentation he teared apart one of Crouwel's posters. Quite the statement.

# data[].attributes.slidedeck.data[].slides[].desc.html
Schreuders spent several pages ridiculing Crouwel's work, for example he says it is too mundane: apparently so simple the designs can be delivered by phone.

Lay In, Lay Out is still sold, much recommended reading, it is very funny and puts all that modernism nicely into perspective.

# data[].attributes.slidedeck.data[].slides[].desc.html
Other graphic designers like Piet Zwart also commented on the downsides of modernism: all the life has gone out of it.

# data[].attributes.slidedeck.data[].slides[].desc.html
If we're being too objective about things, that might make for a boring layout. We've seen this on the web, if too many of us use the same design framework, I won't name names, it could make the web more boring.

# data[].attributes.slidedeck.data[].slides[].desc.html
So not all of modernism is great, it is good to keep a critical view on things. But let's see if we can use some of the good things of modernism in CSS: intentional whitespace for example, proportions, maybe, too!

# data[].attributes.slidedeck.data[].slides[].desc.html
I like to see CSS as a language to set rules for what websites look like.

# data[].attributes.slidedeck.data[].slides[].desc.html
And that's a large part of my job as a front-end developer writing CSS. I take designs and turn them into repeatable rules. Trying hard not to take the life out of them.

# data[].attributes.slidedeck.data[].slides[].desc.html
So how can we do it, how can we do great graphic design on the web?

# data[].attributes.slidedeck.data[].slides[].desc.html
A lot has been written about doing great graphic design in CSS. In 2012, Mark Boulton already reapplied Tschichold's New Typography to the web in an article called The New Canon. A lot has changed since then, and a lot of the maths that he had to work out at the time, we can now leave to the browser.

# data[].attributes.slidedeck.data[].slides[].desc.html
There have been many improvements in CSS recently, that make graphic design on the web easier. I won't talk about any of these today, unfortunately.

# data[].attributes.slidedeck.data[].slides[].desc.html
I'll focus on layout. Because it seems that is where before we could not do a lot of things that make graphic design great. And now we can. Flexbox and grid are new and well-supported.

If you take away one thing from this presentations: these are the first non-hacky methods for doing lay-out on the web and they are built in right into the browser. Into all recent versions of all browsers. They'll let us define what we want, and make the browser deal with the mathematical fiddly bits.

# data[].attributes.slidedeck.data[].slides[].desc.html
So equal heights is one thing that has traditionally been difficult to deal with. I've had this often, where I was building a design that had three perfectly lined up columns, each with the same content.

# data[].attributes.slidedeck.data[].slides[].desc.html
Something like this. Fits perfectly. The reason is that they have exactly the same content.

# data[].attributes.slidedeck.data[].slides[].desc.html
Being the naughty front-end developer that I sometimes am, I would add some different content to them, and then they would no longer be the same height. Designer in shock, and I would try to explain ‘this is how the web works’. Super difficult argument to make.

This is fixed in our two new layout modes. Both grid cells and flex items have a default size of ‘stretch’, which makes them fill all available space.

# data[].attributes.slidedeck.data[].slides[].desc.html
Let's look at this in practice. So because grid and flexbox allow left over space to exist and be reassigned, we can choose where we want it. So here we have three items aligned to the start of the container.

# data[].attributes.slidedeck.data[].slides[].desc.html
With stretch, these items will take all available space. The 'stretch' value is actually the default, so by default these things get the same height. (And the size of the container depends on the tallest item)

# data[].attributes.slidedeck.data[].slides[].desc.html
A large part of what makes great graphic design, I think, is composition. It's about where you put things and which places you leave empty, intentionally.

# data[].attributes.slidedeck.data[].slides[].desc.html
The best article I saw recently about designing with Grid Layout, is written by Hui Jing Chen, she explains that when building grid layouts, it helps her a lot to sketch them out on paper.

# data[].attributes.slidedeck.data[].slides[].desc.html
Here's the example she shows in her article: the design on the left and the sketch on the right. She explains it is great for figuring out which parts of your grid will be flexible and which parts are fixed. As we'll see in a minute, CSS Grid Layout lets you do anything you like, so it is super useful to sit down and decide what you want.

I think it will also be a great approach if you're trying to have whitespace in your design, if you need to decide where it needs to go.

# data[].attributes.slidedeck.data[].slides[].desc.html
So here's a bit of content in its default mode. With no further CSS applied to it, it just takes up all the available space in the viewport.

# data[].attributes.slidedeck.data[].slides[].desc.html
Maybe we want to organise this layout into four columns. Tschichold and Müller-Brockmann would probably both kill me if they saw this. Anyway.

# data[].attributes.slidedeck.data[].slides[].desc.html
This is the page as I showed it before, it has four paragraphs of text. So: four columns, four paragraphs.

# data[].attributes.slidedeck.data[].slides[].desc.html
With CSS, we can turn the container into a grid container. That's what happens as soon as 'display: grid' gets applied to the container, it then becomes a grid container. With the second property, we set it up so that there are 4 columns that each take equal space. So we have four columns, four paragraphs.

# data[].attributes.slidedeck.data[].slides[].desc.html
Auto placement will put each of these paragraphs into the first available column. So the first paragraph goes into the first column, the second goes into the second column.

# data[].attributes.slidedeck.data[].slides[].desc.html
Each paragraph goes into a column. This is because they are direct children of the grid container, and direct children become grid items.

What if we wanted to group them and put them all into one column? We can do that by wrapping the paragraphs into one element.

# data[].attributes.slidedeck.data[].slides[].desc.html
Now that one element is the only grid item and it goes into the first available container.

# data[].attributes.slidedeck.data[].slides[].desc.html
Grid Layout also lets us intentionally place content in specific grid columns. For example, we can put content into the second and third column. Note that with this syntax, we're putting content between numbered grid lines.

# data[].attributes.slidedeck.data[].slides[].desc.html
Or in the two last columns.

# data[].attributes.slidedeck.data[].slides[].desc.html
Or three columns, that also works.

# data[].attributes.slidedeck.data[].slides[].desc.html
The point is, in Grid Layout it is as easy to fill parts of the grid with content as to leave them empty and have whitespace. The whitespace will stay, we don't need to add content to them for them to remain visible.

# data[].attributes.slidedeck.data[].slides[].desc.html
Old graphic design heroes talked about making deliberate choices about whitespace and where to put things, how to organise things. CSS Grid Layout is the first thing in CSS that brings that kind of intentional choices to the web.

# data[].attributes.slidedeck.data[].slides[].desc.html
It's still the web, so intentional placement is harder than in print. It's all about composition, and that is arguably harder on the web. This is due to scrollbars, you never see the whole thing. Vasilis van Gemert wrote a great short post on this.

# data[].attributes.slidedeck.data[].slides[].desc.html
A second thing that we see the great graphic designers do a lot, is to use mathematical proportions to lay things out. Both flexbox and Grid Layout let us do this.

Neither is better than the other. Flexbox let us do this from items, Grid Layout from the container.

# data[].attributes.slidedeck.data[].slides[].desc.html
So flexbox lets us do proportions from the item.

When we set display:flex to the container, its direct children become flex items, which means we can give them flex properties. With flex, we can say something about their size in relation to the other items in the same flex container.

# data[].attributes.slidedeck.data[].slides[].desc.html
With Grid Layout, we work from the container, we define the layout on the container. In this example, I am creating a grid with some columns, so each value in that grid-template-columns property is one column. They are set with the fr unit, which means fraction. Basically, we're saying that the second column can be 3 times as wide as the first, the third twice as big.

# data[].attributes.slidedeck.data[].slides[].desc.html
With the newly proposed ar unit, you could have the space between be a ratio between row and column gaps!

# data[].attributes.slidedeck.data[].slides[].desc.html
Another thing that kept last century's designers busy is standardised paper sizes. They based some of their grids on standard paper sizes. Can we do something similar?

# data[].attributes.slidedeck.data[].slides[].desc.html
Paper sizes, for example.

# data[].attributes.slidedeck.data[].slides[].desc.html
Here's our standard, right? Phones, laptops desktops. Boom. Easy. Or is it? Wouldn't it be great?

# data[].attributes.slidedeck.data[].slides[].desc.html
I still see this happen it at my clients, designers design stuff for specific viewports, e.g. one iPhone design, one iPad design and one MacBook design.

It is not the worst thing ever, it can even work well, as long as we keep in mind there's hundreds of possibilities in between.

# data[].attributes.slidedeck.data[].slides[].desc.html
We're working for any viewport when designing for the web.

# data[].attributes.slidedeck.data[].slides[].desc.html
Viewport width is a number between 1 and 100 and basically a percentage of the viewport. Vh is the same for height.

# data[].attributes.slidedeck.data[].slides[].desc.html
We can base our layouts on viewport units and create some ‘grid fields’, or as we call them in CSS, ‘grid cells’.

# data[].attributes.slidedeck.data[].slides[].desc.html
So if we add a div called tomato onto it, we can tell it which cells to occupy.

# data[].attributes.slidedeck.data[].slides[].desc.html
And let's add another div, called gold.

# data[].attributes.slidedeck.data[].slides[].desc.html
We can put this into the browser.

# data[].attributes.slidedeck.data[].slides[].desc.html
And this is what it looks like with the Grid overlayed, using Firefox' Grid inspector. It keeps its proportions while resizing.

# data[].attributes.slidedeck.data[].slides[].desc.html
Something else we can do in Grid Layout is to have designs with overlap.

# data[].attributes.slidedeck.data[].slides[].desc.html
The thing with CSS Grids is that you can put multiple things into the same cell. They will then occupy the same cells, as instructed. That means overlap will happen, and sometimes you actually want this.

# data[].attributes.slidedeck.data[].slides[].desc.html
So here's some content.

# data[].attributes.slidedeck.data[].slides[].desc.html
And here I've added some overlap.

# data[].attributes.slidedeck.data[].slides[].desc.html
By default this follows source order. With z-index we can control which thing goes on top.

# data[].attributes.slidedeck.data[].slides[].desc.html
There is many other things that are new in lay-out too, these are some that I am particularly excited about.

# data[].attributes.slidedeck.data[].slides[].desc.html
So, can we say we're ready for great graphic design? Well, for one reason we can't. There's one question people have kept asking me when I talked about this in workshops.

# data[].attributes.slidedeck.data[].slides[].desc.html
Will everything look the same in every browser? If you've been to any web conferences in the last 10 years, it must really sound like a broken record, but I'll repeat it once more: it doesn't need to. Website's don't need to look the same in every browser.

But I'll try and be realistic, I know we don't all live in happy land, some of us work for huge corporate clients, where process demands things to be the same. When I talked to some friends that work on big sites, one of them said they will wait a couple of years, until IE11 is no longer used, before they start using Grid Layout. That's the real world some people are in.

With that in mind, let me try to show you Grid is ok to use NOW.

# data[].attributes.slidedeck.data[].slides[].desc.html
I've drawn a quick diagram to show what can happen between browsers that support grid and those that don't.

# data[].attributes.slidedeck.data[].slides[].desc.html
Supporting browsers will have beautiful grid layout, and non supporting ones terrible layout. Maybe?

# data[].attributes.slidedeck.data[].slides[].desc.html
Some will try to get exactly the same layout in browsers that don't support Grid Layout, or look for frameworks or tools that help do this. But this might take so much time that you might as well just use technologies that work in more browsers. If it was possible it would be doing math that the browser was doing directly in JavaScript which then executes in the browser. In browsers that are older to begin with! Oh and you can't do much CSS custom layout stuff via JavaScript, not until Houdini, which is only in new browsers!

# data[].attributes.slidedeck.data[].slides[].desc.html
It really doesn't have to be like that, we can have a simple fallback that effectively makes the content look pretty ok.

That fallback will then work in browsers that don't support grid lay-out, so that nobody needs to suffer from a terrible layout.

I really recommend keeping this simple, for everyone's sanity: people building it now, people maintaining it later.

# data[].attributes.slidedeck.data[].slides[].desc.html
These are some ways to do that. But the technology is probably not even the most important thing, if you keep it simple you don't need to go overboard with complex stuff.

# data[].attributes.slidedeck.data[].slides[].desc.html
To show you quickly how it works: you wrap something in a supports query, and at that point the lines between that query will only apply when a browser supports the property, in this case display: grid.

# data[].attributes.slidedeck.data[].slides[].desc.html
Most likely you would do a fallback that requires widths for sizing and some margins for whitespace in between items. That's likely all you'll need.

# data[].attributes.slidedeck.data[].slides[].desc.html
But maybe I'll need to undo floats, I hear you think? The spec has got you covered here, because it is specced that floats have no effect on grid items. Browsers that don't understand grids, don't make elements grid items, so floats will still work there.

# data[].attributes.slidedeck.data[].slides[].desc.html
So we have technology to do fallbacks. But the technology is probably not even the most important thing, if you keep it simple you don't need to go overboard with complex stuff. The more important problem is probably this:

# data[].attributes.slidedeck.data[].slides[].desc.html
Experiment together! For designers that could mean playing with this, like I said, and for developers it could mean showing what's possible, make some Codepens. Maaike de Laat, who used to be a front-end dev, now UX designer urged front-enders to take responsibility for this at Fronteers conference a couple of years ago: it's the front-enders responsibility to keep designers up to date with what's possible.

# data[].attributes.slidedeck.data[].slides[].desc.html
Stephen Hay tweeted this the other day about designers that are afraid to prototype. Don't be, play with this stuff if it interests you, I guess just don't force the team to ship prototypes to PROD.

# data[].attributes.slidedeck.data[].slides[].desc.html
And I think it's important to make sure people know what our reality is like, if we can't technically make everything the same everywhere, that was never possible, but I know there are people who believe it to be possible, we need to show that to whoever believes it and introduce the team to SIMPLE ways to deal with it, for everyone's sanity, keep fallbacks simple.

# data[].attributes.slidedeck.data[].slides[].desc.html
If you have to choose between the problem of having too complex code and the problem of talking more to colleagues, talking will help you more in the long term (and complex code will give you more maintainability headaches later on).

# data[].attributes.slidedeck.data[].slides[].desc.html
Oliver Reichenstein said it too about designing for the web… find compromises!

# data[].attributes.slidedeck.data[].slides[].desc.html
So with that, yep, I think the web is ready for great graphic design.

# data[].attributes.slidedeck.data[].slides[].desc.html
Because things that were once difficult to achieve are now built-in to browsers.

# data[].attributes.slidedeck.data[].slides[].desc.html
But one thing is not satisfactory… it's great that we like modernism and that we can now do modernist things, awesome that graphic design inspires web design. But as Vasilis asked me when I showed him these slides, can't we turn it around, how can we make it so that print designers would get excited to come and work on the web!? And how can we do a better job on the web than we could ever in print?

# data[].attributes.slidedeck.data[].slides[].desc.html
Basically, the question is: how can we make the most out of this new era?

# data[].attributes.slidedeck.data[].slides[].desc.html
I think for that we should look at the web's defaults. The web is flexbile, accessible, interactive and standards-based by default. We can use all of these four things to our advantage, to make things that people can enjoy to the maximum.

# data[].attributes.slidedeck.data[].slides[].desc.html
First, the web is flexible by default.

# data[].attributes.slidedeck.data[].slides[].desc.html
Making print work is more easy in the sense that canvases are fixed, you can decide what you're working with and that will stay the same; the content is known and there are standards for colours that you can rely on somewhat.

# data[].attributes.slidedeck.data[].slides[].desc.html
Not on the web… our canvases are flexible, content changes all the time, colours are different in different

# data[].attributes.slidedeck.data[].slides[].desc.html
We can't really do that much about the reality we work in, so we should probably embrace flexibility and let it go.

A great article about this is by John Alssopp, if you're not familiar with it, it sparked that whole responsive design revolution. He explains we should let it go.

# data[].attributes.slidedeck.data[].slides[].desc.html
Embracing flexibility is going to help us worry less about the things that don't really matter…

# data[].attributes.slidedeck.data[].slides[].desc.html
One way of letting go is leaving more things to the browser.

# data[].attributes.slidedeck.data[].slides[].desc.html
Some famous graphic designers have established rules for how many characters per line give good readability. We can actually do this in CSS.

ch is the width of a zero, it is roughly .5em-1em depending on writing mode and axis, and we can use it in grid definitions. Here's a grid with a 1fr column left and right and one of 50ch in the middle.

# data[].attributes.slidedeck.data[].slides[].desc.html
We can also be between two values and that lets the browser decide based on how much space there is in the viewport.

# data[].attributes.slidedeck.data[].slides[].desc.html
The web is also accessible by default! Accessibility is one of the basic principles the web was built on.

# data[].attributes.slidedeck.data[].slides[].desc.html
One reason is that is mostly text, and text has this magic ability of being super transformable.

# data[].attributes.slidedeck.data[].slides[].desc.html
We can put it into Google Translate, make it larger, copy paste it or select it… you name it!

# data[].attributes.slidedeck.data[].slides[].desc.html
Text lets us have a lot of accessibility for free, I mean, we don't need to do anything special to make these things work.

# data[].attributes.slidedeck.data[].slides[].desc.html
Here's the website of a cinema I wanted to visit in Taiwan. In the menu at the top I was looking for a link about ticket sales. I thought I'd just copy paste the contents of the menu items, but that didn't work.

# data[].attributes.slidedeck.data[].slides[].desc.html
The layout of these buttons was so advanced that they decided to use images instead of text plus CSS. They didn't have alt text either, so no copy pasting for me. Text would have helped here.

# data[].attributes.slidedeck.data[].slides[].desc.html
Using text can really be helpful. The other day I built this poster with HTML and CSS.

# data[].attributes.slidedeck.data[].slides[].desc.html
This is the HTML I used for it. It has some structure to it, with the name of the exhibition as the main heading in the page, and the other info, location, dates and opening times, in paragraphs.

# data[].attributes.slidedeck.data[].slides[].desc.html
By doing this in the browser, we have usable text under the hood.

The structure works well without CSS, too. And sometimes people don't see your CSS; the obvious example is people who cannot see it and use screen reader software, but also people like me who use content blockers to access the web.

# data[].attributes.slidedeck.data[].slides[].desc.html
Added benefit of text: I could easily get some translated posters in the same layout.

# data[].attributes.slidedeck.data[].slides[].desc.html
Anyway, for accessibility, make sure you use mostly text, it lets you have more adaptability, translatability, et cetera (or alternatives if you have to use images).

# data[].attributes.slidedeck.data[].slides[].desc.html
The web is also interactive by default!

# data[].attributes.slidedeck.data[].slides[].desc.html
@hdv Focus indicators:   can I see where I am without using a mouse? @hdv

# data[].attributes.slidedeck.data[].slides[].desc.html
@hdv Hide and show: display on demand for less UI clutter @hdv

# data[].attributes.slidedeck.data[].slides[].desc.html
@hdv Do transitions make design more pleasurable? @hdv

# data[].attributes.slidedeck.data[].slides[].desc.html
@hdv @hdv https://swissincss.com

# data[].attributes.slidedeck.data[].slides[].desc.html
@hdv The web is built on web standards @hdv

# data[].attributes.slidedeck.data[].slides[].desc.html
@hdv Understanding the standards themselves pays off @hdv

# data[].attributes.slidedeck.data[].slides[].desc.html
@hdv @hdv web   standards frameworks that abstract them

# data[].attributes.slidedeck.data[].slides[].desc.html
@hdv @hdv web   standards frameworks that abstract them �F�K�U�R�N�C�[���H�N�G�Z� �"�K�P�E�N�W�F�G��H�N�G�Z� �E�N�C�U�U���E�Q�N��U�O����O�F���� �5�W�\�[

# data[].attributes.slidedeck.data[].slides[].desc.html
@hdv Grid systems are overkill. I haven't used Suzy in 5 years and I recommend that you stop [using it, too].

— Miriam Suzanne, creator of Suzy   In Don't use my grid system , presented at Beyond Tellerand (8 May 2018). “ @hdv https://vimeo.com/268576559

# data[].attributes.slidedeck.data[].slides[].desc.html
@hdv Bootstrap's default grid has 204 classnames to do the maths for your layout @hdv Based on unique classnames in Bootstrap 3.1.0 starting with col- and many other layouts

# data[].attributes.slidedeck.data[].slides[].desc.html
@hdv @hdv Choose vanilla!

# data[].attributes.slidedeck.data[].slides[].desc.html
@hdv @hdv web   standards frameworks that abstract them �D�G��J�G�T�G�

# data[].attributes.slidedeck.data[].slides[].desc.html
@hdv @hdv http://jensimmons.com/post/aug-15-2017/heres-super-quick-way-try-out-css-grid

# data[].attributes.slidedeck.data[].slides[].desc.html
@hdv @hdv https://gridbyexample.com / https://thecssworkshop.com

# data[].attributes.slidedeck.data[].slides[].desc.html
@hdv @hdv http://flexboxfroggy.com / http://cssgridgarden.com

# data[].attributes.slidedeck.data[].slides[].desc.html
@hdv @hdv equal heights intentional whitespace mathematical proportions proportionate to viewports compositions with overlapping content ���9�G��E�C�P��P�Q�Y��F�Q����

# data[].attributes.slidedeck.data[].slides[].desc.html
@hdv flexible accessible interactive standards-based @hdv ���&�G�U�K�I�P��H�Q�T��Y�G�D��V�J�T�K�X�G�U���D�G�E�C�W�U�G��K�V��K�U����

# data[].attributes.slidedeck.data[].slides[].desc.html
@hdv It's a great time to   do graphic design   on the web!

# data[].attributes.slidedeck.data[].slides[].desc.html
@hdv Thanks! @hdv hidde@hiddedevries.nl https://hiddedevries.nl/en /blog   https://noti.st/hdv Many thanks to Vasilis van Gemert, Krijn Hoetmer, Jenny Shen and Peter van Grieken.

# data[].attributes.resources.data[].desc.html
Fantasai's idea for a Grid Layout workshop.

# data[].attributes.resources.data[].desc.html
Interview with Wim Crouwel.

# data[].attributes.resources.data[].desc.html
Examples from the Total Design portfolio

# data[].attributes.resources.data[].desc.html
Mark Boulton applying Tschichold's principles to the web.

# data[].attributes.resources.data[].title
Hui Jing Chen - How I design with CSS Grid

# data[].attributes.resources.data[].desc.html
One of the best blog posts about designing with grids, one of the tools Hui Jing shows is to sketch a grid with pencil and paper.

# data[].attributes.resources.data[].desc.html
There's a proposal for having ratios between rows and column spacing using the ar unit.

# data[].attributes.resources.data[].title
Using CSS Grid: Supporting Browsers Without Grid

# data[].attributes.resources.data[].desc.html
Rachel Andrew on supporting browsers without Grid.

# data[].attributes.resources.data[].desc.html
Maaike de Laat on working together and how developers should show designers more of what's possible.

# data[].attributes.resources.data[].title
Stephen Hay's tweet about designers that prototype

# data[].attributes.resources.data[].title
Oliver Reichenstein, Responsive typography, the basics

# data[].attributes.resources.data[].desc.html
“Web design is about finding the right compromise”

# data[].attributes.resources.data[].desc.html
“It is the nature of the web to be flexible, and it should be our role as designers and developers to embrace this flexibility (…)”

# data[].attributes.resources.data[].desc.html
In which Swiss design posters have been recreated on the web with beautiful transitions.

# data[].attributes.resources.data[].desc.html
The inventor of Suzy explains she doesn't use Suzy anymore either (great talk with fantastic Grid Layout examples)

# data[].attributes.resources.data[].title
Jen Simmons: here's a super quick way to try out CSS Grid

# data[].attributes.resources.data[].desc.html
Some examples to get started with Grid Layout.

# data[].attributes.resources.data[].desc.html
Great examples of many possible lay-outs using Grid.

# data[].attributes.resources.data[].desc.html
Rachel Andrew has an in-depth CSS Layout workshop

# data[].attributes.resources.data[].desc.html
A game to learn flexbox properties

# data[].attributes.resources.data[].desc.html
A game to learn CSS Grid Layout properties

# data[].attributes.codeblocks.data[].desc.html
Designing a grid and using parts of it