Transcription
(Music)
(Applause)
Thank you very much.
Thank you, Marc.
(Applause)
I hope you had a wonderful day yesterday. It was just amazing to see all those brilliant talks. I mean, it was in the audience like so many times before, watching people showing their creative work all over the place. I was just blown away and now I’m suddenly here up on this stage.
My name is Matthias.(...) Matthias. I’m a user experience designer, a web design engineer. I teach interface prototyping and also run workshops on modern web design, prototyping, web design engineering. I am Matthias Ott on Mastodon social. You can follow me there or also connect on basically all other networks and my personal website is MatthiasOtt.com.(...) I actually am quite passionate about personal sites and this is why I created a newsletter about it. It’s called Own Your Web and every now and then I send out a new issue covering various topics about owning your little corner on the open web. So if you’re interested, feel free to sign up.
But now let’s talk about painting.
Can anyone guess the artist of this piece?
Gerhard Richter. I planned with a short silence and stuff but now it’s a correct answer. So he’s certainly one of the most important living artists from Germany. I took this photograph in Dresden in the Albertinum Gallery where this is in an exhibition. Have you ever seen Gerhard Richter painting though? So like how he creates one of those pieces? Because it’s really phenomenal to watch. There’s also a documentary of the same name called Gerhard Richter Painting.
He usually starts his paintings by carefully applying oil paint to the canvas first with a thick brush and then he starts to drag and scrape and smear the paint around with this huge homemade squeegee.
And after each move, he takes a step back and pauses and looks at the result. He looks at what did just happen to the canvas, to the composition, what looks interesting, what is maybe the next move. And there is a lot of intention and carefulness in this process. But also he lets go of control and follows his intuition to let things happen that are really unexpected and exciting.
And in a way you could say that this is the ultimate creative process. It’s a constant conversation. And we saw this yesterday all over the place. This conversation is really at the heart of the creative process because no work of art arrives fully formed in the mind of its creator.
It always emerges through constant reflection, through experimentation and revision. And it’s really what makes deep creative work also so fulfilling and meaningful and rewarding. And it’s also how we as humans, actually in any discipline, evolve and ultimately master our craft.
And a lot of Richter’s creative process actually reminds me of working on the web,
at least a little bit. The unpredictability, quirks of the medium, and there are also bugs and happy accidents. And if we are really honest, many of us designers, we like to think of ourselves a little bit like this. Like we are creatives in control of the process and painting with the web. But actually, in fact, we aren’t really, because there are huge differences between how Richter approaches painting and painting on the web. And the first difference is the canvas.
Richter starts every office paintings with a blank canvas with fixed dimensions and clear boundaries. On the web, however, our canvas is radically different.(...) It’s not fixed. It scrolls. It zooms. It spans an unpredictable landscape of screens and contexts.
And this is a photo that Brad Frost took at a conference in 2012. But here’s the thing that’s several years old now. So how about today?
This is a graphic I created in 2018, inspired by an earlier one from a talk by Frank Camaro. And what you’re looking at is a snapshot of all the screen sizes I could find back then.
And even then, the fragmentation was really impossible to ignore. But then I recently took the data that Andy Bell and his colleagues at Set Studio collected for their brilliant site Viewports.fy and updated my own graphic with their dataset of 2,300 viewport sizes, and this is the result.
This is our canvas on the web. Our canvas is unpredictable and ageless and fluid. And the question is, how does the right way to paint on this canvas look like? And now I want you to be really honest with yourself, especially for our designer,(...) does it look like this?
Really?
I mean, hands up, who knows this view and who still designs, or gets designs handed off in this?
In fixed desktop and mobile sizes? Sorry.
It’s really how the industry works. And I also hear this question again and again in my workshops, like, what is the right size for mobile and which one do you currently use for desktop?
It’s been 12 years since Josh Brewer got up on this stage.
And he sang about Photoshop, the damn liar that did...
Whoever you was here back then? Yeah, quite a few. Toby, a lot of material on this day for you, I guess. Yes, nice. He reminded us that all the beautiful pictures of websites we are creating are actually not the real thing. And what did we do? We ditched Photoshop, but we replaced it with Figma and Adobe XD or whatever, but we are still painting pixel-perfect, pretty pictures of websites. We are painting static pictures of websites.(...) I mean, we have improved a little bit. We are very often painting static pictures of components because we started to break down our interfaces into those tiny modules that we can use to be more effective and efficient. But it doesn’t really necessarily make our designs less static. And so we are still tackling a fluid medium with the static tools and linear waterfall process of the past. We are creating abstractions of the final medium. And this brings me to the second large difference between Richter’s process and how we design on the web today, and that’s the material itself. Because as we have seen, painting is a constant dialogue between the artist and the material. And this feedback is immediate and unfiltered and honest and materially honest, really. On the web, however, it almost seems like we have a broken relationship with this material. When we design for the web with our tools, we create at a distance because they simulate the web in a way, but they aren’t really the web. They give us fixed artboards, pixel-perfect illusions of control with fixed font sizes, and the real web, on the other hand, is fluid and dynamic. And you could also say that we are not touching really our material on a daily basis. And so we are breaking effectively the feedback loop of the creative process because also by separating design and development, we are limiting our ability to have that creative dialogue with the web and its materials. And we limit our potential for exploration, for creating surprising and novel solutions, and also ultimately it prevents us from making decisions, well-informed decisions throughout the design process.(...) Because how can you make the right decision in the end if you’re basing it on assumptions instead of insights coming from the real material itself?
And this is becoming a real issue now, I think, because the web platform is evolving at an unprecedented speed. And I’m not talking about generative AI.
I’m talking also about CSS, for example.
We can do things with CSS now that were unthinkable a few years ago. We don’t have to work around the limitations of CSS anymore. Instead, the tools are very often the limiting factor when we are working on the web. You could even say that CSS is the most powerful design tool for the web. And so this is also a real problem because, like, never before the gap between what designers design and what would actually be possible to create with the web platform has been wider. So on one hand, we could be creating much more resilient and beautiful websites, and on the other hand, it also means that we create subpar experiences for all the people out there who rightfully expect the website to be successful and stress-free and an accessible, enjoyable experience.
And so the question really still is what would happen if we changed that and we stopped treating the web like a blank canvas to paint on and instead started treating it like a material to build with. This is from Frank Camaro’s fantastic talk, "The Web Screen."
I highly encourage you to watch it if you haven’t yet.
So how can this look like? The web as a design material. To properly design for any medium, you have to have a good understanding of it. So we have to get a good understanding of the qualities of the material we are working with and what the constraints are that we are working with, right? A large part of this understanding will come from working with the material directly, but on the other hand, we also have to get a good understanding of the core principles underpinning the web as a technology.
And this is also, I think, what’s sometimes missing also in design teams. We have to see why the web and its technologies were built the way they are. And for this, we have to go back to the early 90s, to the early 90s, and this young fella. This is, of course, Tim Berners-Lee, who was working at CERN at the time in Geneva, its research facility where they are smashing particles together to increase our understanding of the universe.(...) This is also where the Large Hadron Collider is located, the world’s largest and most powerful particle accelerator. It’s the world’s largest machine. It consists of a 27 kilometer ring of superconducting magnets with a number of accelerating structures to boost the energy of particles along the way. Where else could the World Wide Web have been invented, if not here?
Actually, it was invented here.
At this next machine here at the center, Tim Berners-Lee worked on his hypertext projects in the early years. It’s an ordinary office room somewhere at CERN. First, he thought of naming it the information mine, or short, Tim.
But it turned out to be maybe a bit too egocentric, and so eventually he modestly called it the World Wide Web. He developed the hypertext transfer protocol HTTP, and he invented URLs, which you all know. At the core of the project was his new structured document format, HTML. HTML really was a very simple format. It was all about adding markup tags around text to give those pieces of text meaning, like headings, paragraphs, links, and so on.
The elements in early HTML were really structural, logical, and semantic, rather than presentational. So it wasn’t about presentation at all. This was intentional.(...) In the very first proposal for the World Wide Web project, he wrote, "We should work toward a universal linked information system in which generality and portability are more important than fancy graphics techniques and complex extra facilities."
So he knew that the web would only become a success if the information on the web was truly portable, able to flow anywhere to any device. Therefore, it was a core principle that HTML should convey the structure of a hypertext document, but not the details of its presentation.(...) And it was the only way to show information reliably in already growing number of devices. And this was completely opposite to how print worked at the time, because unlike print, where designers control everything, the web was built to be flexible, and it also turned out to be the web superpower in the end. It’s what makes it resilient and robust to this day. The idea really was, regardless of the end device, the web is for everyone, if only it was. But it turned out that a lot of people wanted to adjust the presentation of web documents as well, in particular fonts and colors. And so HTML slowly started to become cluttered with purely presentational tags, like font, small, big, or even does anyone remember blink,
marquee? So HTML was really on a downwards move away from a semantic and reusable markup language towards a presentation-oriented language. And this threatened device independence and accessibility and the reuse of content, and so something had to be done. Thanks to Zach Leatherman for this tailwind screenshot.
And in 1994, Sir Tim was joined, therefore, by a young programmer from Norway, Hocken Wium-Lee, who published in 1994, three days before Netscape announced their new browser, the first proposal for what would later become CSS, Cascading HTML Style Sheets. At the time, a style sheet, actually, I don’t know if you know this, was a short document that a designer would hand over to a printer, for example. This sheet contained the most important information about how to set the text of a book, for example, so things like the typeface, line height, how headings or quotes should look.
And Hocken Wium-Lee took this idea of style sheets and applied it to the World Wide Web. So the browser would get an ordered list of style sheets that included rules that defined how the document should be rendered in the end. But once again, there was an important difference to how print style sheets worked, because the idea was that the user could supply their own style sheet.
And this could take over full control over the document, but more likely could also hand most of the influence over to the styles coming from the website itself.
In his PhD thesis, which he wrote about CSS, of course, Hocken Wium-Lee wrote, "Negotiating between the needs and wishes of readers and authors was one of the main ambitions of CSS. If successful, authors would get their fair share of influence over the presentation and would not feel compelled to use presentation or HTML and other tricks.(...) Readers, on the other hand, would be served documents in a form in which they could choose between accepting the author’s suggested presentation or specify their own." Two really interesting words in this quite long quote, sorry,
"influence" and "suggested." And this idea of influence actually was central to this first proposal, because in this line, where font size is set for an H1 heading, it doesn’t look like CSS yet,(...) but at the end of this line, there is this 100%, and that’s actually the influence that this line should have. It’s an important statement, basically.(...) And there was even this graphic in this proposal, which looks like range sliders. So, for example, in the case of a font, the author would have 64% influence, and the user gets the rest.
And I have no idea how that would look like, let’s say, the author defined "comic sense" as the typeface, but the user actually loves the lobster font so much.
Nobody would want to see this, right?
Right?
I sincerely apologize to all the typographers in the room. Jason, Oliver, everyone.
I think there are very, very, very obvious reasons why some parts of this proposal didn’t make it into the final version of CSS,(...) but you get the idea. Other than in print, on the web, the influence over the presentation is shared.
Author control becomes shared.(...) Author user influence and personalized experiences become possible this way. This is why we can have assistive technology, screen readers, and so on. And once again, the reason for this was that the web should keep its flexibility, this idea of universal access. CSS needed to work. For multiple output devices, it needed to keep working, and resources failed to load, like when the CSS file doesn’t load.
By the way, I had to keep it in,
because I couldn’t stop thinking about this line in this very first proposal.
Have you heard about this discussion whether or not CSS is a programming language?
Yeah?
Here he uses a ternary operator. For all the non-programmers in the room, a ternary operator is basically how the cool kids are writing if-else statements. And so...
My son told me that there are also really nice use cases for this. But if the document is older than three days, the background color should be pale yellow, else the background color should be white.(...) Like, this is an aging document turning yellow in the sun. Quite a nice idea.(...) But this didn’t make it into CSS in the end, this idea.
Also the idea of a percentage-based influence. But the basic idea that the presentation can be influenced from various sources did.(...) And so on the web, the browser provides a default style sheet, and users can adjust the presentation to their liking, for example, by overriding colors and font sizes. And 3%, I read recently, of users set a base font size, or change the base font size in their browser. And we as web authors get to suggest a bit as well.
And this process of bringing all those origins together is known as cascading, then. That’s the C in CSS.
So if you use style sheets properly to suggest the appearance of a page and not to control the appearance of a page, and you don’t rely on your style sheet to convey information, then your pages will work fine in any browser, past or future.(...) This is actually a quote from the past.(...) John also wrote this 25 years ago,(...) in his seminal article, "A Dao of Web Design," which is really required reading for anyone working on the web. In his article, John argues that we should not treat the web as print, but instead embrace the inherent qualities of this medium, because other than print, the web is flexible and uncontrollable, unpredictable, but rather than thinking of this as a weakness of the medium, as so many people still do to this day, we should embrace it as a strength. We should see it as a unique opportunity because it makes the web the most accessible and robust of all mediums. Only on the web content can adapt to different screens and devices, and only on the web users can adjust the presentation of content. This all changes the role of us as designers, as people creating things on the web, because we are not controlling the experience, we are suggesting it. Jeremy Keith, who’s not here today, likes to call this the declarative approach to designing for the web, meaning that you don’t try to precisely control or dictate how something should look or work. You are declaring your intent, like a suggestion. Providing the boundary conditions, you suggest parameters that shape your design and its behaviour, but then you let the browser figure out in the end how the design works in a certain context, and you always keep in mind that your design stays flexible in case something breaks, right? Or users overwrite your design with their preferences. And this is the materially honest approach to painting with the web.(...) Just like Gerhard Richter, you are giving up control, but you’re gaining a lot more.(...) And so building and painting with the web as a material really fundamentally means that we start with the most robust layer first by painting a semantic structure in HTML with native HTML elements, and those elements also provide a lot of features out of the box for free, by the way, like form validation, keyboard focus management, other accessibility features, and then we are building on top of that with declarative CSS.
And following Keith’s law,
we are using JavaScript only for the things that only JavaScript can do, because it is the most powerful but also the most fragile of the languages on the web.
And on top, we then use, for example, ARIA rules and attributes to make our sites more accessible, but please, only where they are really necessary. We’ve seen that yesterday that you might not need them on a button element, for example, so only use them when they are really needed. And this is a huge problem also that developers are always very often slapping ARIA attributes and roles on elements without really a need for that. So we are progressively enhancing the experience, but let’s look at a few examples now of how we can really do this, right? How we can use the power of the platform to paint with the web as a material.
And I have a few areas which I want to highlight, and the first one is one that is very dear to my heart also,
although I showed this weird lobster comic-sounds mix,
and that’s typography. And when it comes to typography on the web, this lack of control is still a real issue for designers, for stakeholders, right? In print design, we have this control over every typographic detail, but on the web, we don’t. We have to accept the dance with uncertainty, and this is even visible in the very first line, more or less, that when it comes to typography in many CSS files, this is the font-family decoration. This is where you set your font-family,
and instead of just dictating one typeface, CSS allows us to suggest a list of typefaces. It’s really basic, I know that, but in case thousands by Christoph Kühberling is not yet available or the web font fails to load, then please try Helvetica, or if that doesn’t work and fails, try ARRIEL, and if that doesn’t work, then use any sensor font that is available on the system. So instead of assuming control,(...) you can offer a set of suggestions to make it work in different contexts, the same idea can be applied to font sizes, and this is where Fluid Web Typography comes in.
That’s a nice pink. Yeah.
It allows us to scale type based on the size of the viewport so that it works well on any screen without any breakpoints. Who has used Fluid Type before in the room?(...) Yeah, quite a few people, but not everyone.(...) This is how it looks in action.
So instead of adding more and more and more breakpoints to change the font sizes, we instead create a system in which elements scale proportionally and fluidly. This idea is not that new. I think it’s several years older as well, and it can not only be used for font sizes, but actually also works very well for the spacing of your sites. And this is how it is done with modern CSS. You are using the clamp function to calculate a font size that adds a fraction of the viewport to a base font size, but we also make sure that it never gets smaller than our minimum and never larger than our max value. And the relative font size units then also make sure that it stays accessible because users can still scale up the typeface up and down the font size.
And this idea of fluidly scaling our type is then combined with another idea that is really centuries old. That’s the idea of a typographic scale. In the 16th century already, European typographers developed such a series of typeface sizes that allowed them to work with harmonious relationships.
And the underlying idea is really that numbers that are related by a certain ratio will feel harmonious naturally, just like in music, for example. So if you have a so-called modular scale, you use a multiplier to create a set of numbers. With a multiplier of two, for example, you get what’s known as an octave. You use a multiplier of 1.5. You get a perfect fifth, and so on. Those are also music terms.
And now we can combine those two ideas. We are scaling our headings fluidly with clamp, and we are using a modular scale to create a system of harmonious font sizes. And the final trick is that we are using different scales for our min and max viewports. So we are using 1.2 as the multiplier for the smallest viewport, 1.33 for the largest one, and you can see how the contrast really goes up the larger the viewport is. And this way we can make sure that the larger the viewport, we make use of the larger screen real estate, but on small screens there is more pressure on the layout and less contrast between the sizes. And as a designer, I have given up control. I’m already, again, I created a framework. I’m suggesting, but I don’t know exactly how large my typeface is on a 960-pixel widescreen or whatever.
There are a few calculators you can use to get CSS that works already, so you don’t have to come up with everything yourself. Utopia by CleoLeft created by James Gilead and Tris Mudford is a nice calculator, probably one of the best well-known,(...) and you enter all your values for min and max and font sizes and then Utopia generates the CSS for you.
But you can even do something like this with CSS. Instead of scaling our type up linearly,(...) right,(...) we can also use a curve.
And this will allow the type to scale up more quickly on smaller viewports, so we make use of the larger screen real estate faster. And on larger viewports, it then grows more slowly.
We do this actually, the trick here is to use a trigonometric function like the sine function. And we take actually this part of the sine function, which is also used in easing calculations very often. I don’t know if any designers are working with easing functions.
A SID is definitely working with easing functions, I guess. And in our case, we can use the min and max viewport width as the starting and end points and use the sine curve then to interpolate between the values.
Those trigonometric functions are available in CSS(...) since the year before last year, 2023, and you can use them in your projects, maybe even in production. So always be testing and careful. And this is how the CSS looks like.
Maybe, yeah, I won’t explain it in detail. It looks a bit intimidating, I agree. But don’t worry, if you’re interested in how it works exactly, you can either watch my CSS talk from last year or you can also take a look at this code pen and I will also share the slides in the end.
So there isn’t a huge difference between this version and the one I showed at the beginning, but it’s supposed to show you what you can do with native platform features using CSS, for example. And you have this immediate feedback with the platform. You’re trying and changing your values and just like Brandon showed yesterday. And if that’s not programming, in a way, I don’t know what it is, but it’s also design in the browser.
And we can take this idea even further, just as an experiment. Always be experimenting. So why do we always base our type calculations on the width of the viewport? We could also look at the overall available space. Like in this example, although all we are doing is rotating the device, the screen size hasn’t changed, the typography appears radically different in size.
We could do, for example, something like this. We multiply the viewport width with the viewport height and take the square root of it, which you can do with CSS, and then we use this value to calculate our font size. We could call it our space index.
This is a space gem reference for the very old people like me.
And if we base our fluid type calculation, then on this space index we get this.
Please also see this as a prototype as well, right? I would be careful of using it in production without testing it further.
But again, you can do stuff like this. Also, always be testing for accessibility support so that the typeface can scale up properly to 200%,(...) which is an requirement.
Yeah, but stuff like this can only be built and evaluated directly in the browser. And we’re not even talking about variable fonts yet. I mean, we could combine this with variable fonts.
So there are so many typography-related features like TextRab, like the LineHide unit,(...) like a text box trim, so many new things coming out these days that you can explore and try out and get creative with, but only in the browser working with the real material. And this also goes for color.
On the web, at the moment, we are, most of us, are writing our colors probably in one of those ways, like named colors, hex colors, RGB, HSL, whatever it is.(...) Also, our tools that choose those colors, pick those colors. Figma, for example, even lets you enter a color in CSS syntax, which is nice, but all those ways to write colors share one limitation, and that’s the sRGB color space.
Yeah, and if that’s the range of human perception, so colors we, on average, can see, then this is sRGB.
And this is really what the s in sRGB stands for. It’s the smallest common denominator when it comes to color spaces on digital devices. But all of this has changed in recent years. Many of us carry devices in our pockets with wide gamut displays, and we also have them on our desks.
So those devices support the display P3 color space, which is much larger. So it can produce much more vibrant colors.
Kevin.(...) Pinker pinks.
Even pinker pinks.
Our design tools, however, aren’t quite there yet. You can switch, Figma, and also Sketch, I think, to P3, but it says this isn’t recommended for web design.
I don’t know why. Because you can use, for example, the OKLCH color space in CSS to use those vibrant colors.(...) It’s an interesting color space because it is so-called perceptually uniform color space. And this means it’s really good at producing different colors which have a similar perceived lightness. So the lightness doesn’t change when you change the color. So the L in OKLCH stands for lightness. The C stands for chroma. So the saturation of the color,(...) the pinkiness of the pink.
And the H stands for the U angle. So where on the color wheel are we, really? And it is an OK color space because it is actually more OK than the regular LCH in how perceptual uniform it is. That’s no joke. That’s the reason.
And this is how you write OKLCH colors. You have three values. The first one is ranging from 0 to 100 percent, the decimal value between 0 and 1, that is the lightness. The chroma value ranges from 0 to infinity, theoretically, but in practice it stops around 0.5 or 0.3 depending on the color. And the U value goes from 0 to 360.
And you can also use it with transparency. And you can use it in production today. Like you could, for example, check for support with add supports and then adjust a variable, a custom property.(...) And you can use it to create much more beautiful gradients.
This is an OKLCH projector.
So the gradient at the bottom clearly has more vibrant colors on my screen here. But it is this way because OKLCH also doesn’t use the shortest path from one color to the next, but it goes actually around the color wheel. And so all the colors stay vibrant.
Just try it out in the browser. You can also try to do it in Figma, but I have no idea what Figma does. You can just paste in a P3 color and it somehow gets transformed into something that is more vibrant, but it’s not reproducible easily. And the same then goes for choosing and picking your color. So you can’t really reliably pick a color or adjust it in Figma at the moment. Luckily, there are a few online tools you can use if you want to define them and also fallbacks like this color picker here made by evil Martians, OKLCH.com. Also, you can use the Chrome DevTools actually to see also the current color contrast ratio for accessibility, which is also nice. And this is actually one of the major advantages of using OKLCH. When you are creating a color palette, like with this free tool, you can create accessible color palettes because you have much more control over the lightness of the color and the contrast.(...) And another tool that is really good is Atmos.style. This is a paid one, but you can check your color contrast against WakeHic 2 or WakeHic 3 requirements and create your palette.
But here’s the thing, you can also create color palettes in CSS with the browser. Paint,
painting a color palette in CSS. There are a few ways to do that. You could use the color mix function, the new one, which lets you mix two colors into each other. But another option is the relative color syntax or just relative colors. And they are really powerful because you can easily create complements of an existing color, like lighter or darker or more saturated colors.(...) And it is super convenient for color palette creation, therefore.(...) If you want to create such a variation,
you define a new color using a basic color function, like OKLCH. So we have our OKLCH function and then we are using the From keyword. And you tell the browser that you would like to create this color from your origin color, like here, this blue indigo, and then you provide an output value for each individual channel, the LC and H. Like in this case, we are not changing anything in the first line, and we also can use it with transparency. But you can also change the values for each individual channel, like here. We are using lightness values from 10 to 100 percent. And what we are getting is a color palette that has the same chroma and U values, so it is the same blue, but basically the lightness has changed.(...) And this is how it looks like if we are applying this to a whole range of colors. And you can see how the colors in each column have a very similar perceived lightness. In this case, I also reduced the saturation at the edges a little bit.
Again, this stuff is only possible to explore and test directly in the browser, painting with the web as a material. If you want to know more about color on the web, watch my friend Manuel Matuzovic’s talk from last year’s Beanteler on Berlin. He also talked about color fonts.
And also make sure to read this amazing blog post by Eric Portis, OK Color Spaces. He includes a lot of interactive three-dimensional demos, but he also brilliantly explains color gamut and color spaces in a simple plain language, especially if you are a designer.(...) Color spaces are 3D, actually.
Nice. So those were two areas where we can work with the medium directly with the material. But there is another area where CSS is really outperforming our design tools at the moment, and this is layout. And I need to talk about layout because I guess there are many designers in the room.
Yes? Yeah, quite a few. All right.(...) And this is really for you also because you can use native layout tools on the web to really be creative with CSS. We now have an amazing mix of native layout tools at our disposal, but for this to happen, designers really, again, must know what is possible. And this is why I want to quickly talk about CSS Grid, because CSS Grid lets us do things that are so powerful but impossible to do in most modern design tools.(...) And from my experiences, from my experience in workshops, for example, designers still very often don’t know what’s possible with CSS Grid. Some haven’t even heard of CSS Grid and what it is exactly.(...) You can do stuff like this with CSS Grid. You can create a fully responsive layout that dynamically wraps and changes the number of columns with one line of CSS.
This is how it is done, and many of the CSS people in the room know this.
You use the repeat function with the auto fill or auto fit keywords and a min max function that defines how small or large your columns can become fluidly. We can also do stuff like this. We can create columns that grow and shrink at different rates.
Some of them can disappear completely.
We can create columns that are fixed, some are fluid, some...(...) Yeah, we define min and max values for the dimensions of our columns and so on, so we can be really flexible. This example is from a website called the Experimental Layout Lab of Jen Simmons,
who also created a wide range of examples, useful demos. If you are a designer, go to this website, labs.jensimmons.com, and have a look because it’s just amazing and shows you what is possible. There’s also a responsive Mondrian and whatever.
And then we can even do things like this with Grid. We can make things overlap. We can name the areas in our grid and rearrange our elements depending on the context.
We can do stuff like this. Responsive layouts aren’t your usual boxy grid. This is a code pen by Andy Barefoot.
Or we have a main column. When the viewport gets large,
our layout can... Or our image, in this case, can break out of this main column,
like Tyler Sticker showed here.(...) There’s so much you can do.(...) Two years ago, the adoption of CSS Grid was really low still. It seems to have caught up a bit recently. But in the last state of CSS survey, 7% of the people who answered said that CSS Grid is their favorite new CSS feature.
CSS Grid has been in major browsers since 2017. So for eight years now, and you can work with it. So you can use it. And once designers know what’s possible, I guess usage will grow even more. And the same then goes for subgrid. Has anyone heard of subgrid? It finally somehow completes CSS Grid. And we can do stuff like this. We can use our grid not only for the direct children of a container, but actually use it further down in the tree. So, like, in this layout, the cards can inherit the grid rows from the parent grid and have images and type that nicely aligns. What’s not to love about nicely aligned stuff in Germany? And we can even use different gaps within our subgrids.(...) And then there are container queries. We waited forever to get this feature. And now that we have it,(...) not so many people are using it. We can adjust the element and element based on the size and very soon also the style of the container it is in, like here. This is the mother of all container query demos.
Depending on how large the container is, in this case, the width of this grid columns. We are changing the color or where the heading sits or the layout of our component.(...) And by using container queries, we can use our card in different areas or, yeah, of our layout without needing to know specifically where it will be placed. It’s really important. We can be really flexible then again.(...) Container queries are also a baseline feature since 2023, available in all major browsers. So, you can use them in production probably also if you use them as a progressive enhancement. And there are so many more areas that can really benefit from working directly in the browser with the web as a material.
With direct and honest feedback, so to say.
And our static design tools can really compete with many of those areas. So, from using semantic HTML for key belt navigation, screen reader support, color contrast, focus management, things like this when it comes to accessibility, or creating forms, testing forms. Native inputs for form validation.
Interactivity of components, hover and click states. The responsiveness of components and whole layouts.(...) Animation. Sid will talk about animation.
One topic I love as well a lot. And so, there’s also so much possible with scroll driven animations. View transitions also in JavaScript.(...) You are. Yeah. Still, it’s still okay to use JavaScript, of course. Actually,(...) a lot of people are using JavaScript at the moment.(...) But GZAP, for example, is a nice library. It’s available for free since last week. I don’t know if you have heard that one.(...) And performance is also an area where you can create tests and building with the web as a material has a huge impact on performance.
And all of this will enhance the overall experience that the people will have while visiting your sites and your interfaces.
So, does all this mean that we ditch Figma completely now? I don’t think it’s realistic, right?
But, I mean, it’s, for example,(...) the tools will improve, definitely. So, they are trying to catch up, although it’s quite hard for them. Tools like Pentot are also adding interesting grid features. They are replicating what CSS Grid is doing in a UI.
But is that the real thing? I don’t know.
And, yeah, we still need those tools, definitely, to explore design directions, typeface combinations, to push things around visually, and, of course, to get approval for visual designs from clients. But beyond that, we really need to think about what our tool set is for designing and building on the web.(...) What do we want to use?
And one thing is definitely clear. I think we need to use HTML and CSS and also JavaScript much earlier again in the process. So that we are able to make those design decisions early in the process, and not when we have already painted all the static canvases and filled them with unrealistic designs. And for this, I think prototyping is one of the most powerful tools that we have at our disposal. It’s been something that industrial designers have used for decades to explore materials, to evaluate and iterate solutions.
Prototyping is really where ideas can come to life, and you can test and refine and quickly work towards a solution, and where you can make sure you are building the right thing.
But most importantly, you can very quickly build little prototypes, for example, in CodePen with the real material, and then use the insights you gain to influence your decisions, and you can work with the web platform without having to build the final thing.
And all of the things I showed you were basically prototypes.
And anything can be a prototype. You can build typography prototypes, colour prototypes, layout prototypes, animation prototypes, test accessibility features and so on. You can build them with low or high fidelity, with a narrow or wide scope, and then you decide in the browser what works and what doesn’t. So you don’t have to necessarily design everything in the browser, but decide in the browser, not in a static design tool.
And there is actually a name for this way of working at the intersection of design and development, and that’s design engineering.
Also, web design engineering is a term I like. Practicing web design engineering can mean that we hire people, design engineers, who know how to prototype and build web components with the web as a material, and who help build bridges between design and development, also really important. But it also means that we all can and have to become better at design engineering collectively, as teams, as people with different skill sets working together, collaborating.
And it also means that we let the devs design.
I mean, why not, right?
Come on.
Yeah, so they need to...
They need to develop a better understanding of the basics of design, so that they can make their own decisions as well, and we need more creative developers. It also means, you know what’s coming,
that we let the designers code.
It’s a very new idea, I know. But I’m not talking about production code necessarily, right? I’m talking about...
Some designers can write production code as well. I’m talking about not being put into boxes when you’re working together, right? That you can look beyond the teller-and.
And... Yeah, sorry.(...) And that you understand the concepts behind things like fluid typography and color spaces, modern CSS layout, accessibility, animation, and so on. Because ultimately, telling designers they don’t need to worry about code is like telling architects they don’t need to worry about steel, wood, or physics. I’m with Brad Frost here. Or telling Gerhard Richter, he doesn’t need to worry about oil paint, right? The web is our material, and we need to know how it behaves. We need to acquire first-hand knowledge of what it means to design and paint with the web. And now is really, I think, the best time to get started with learning design and coding for the web, because there has never been more information out there.
Just do quick research on any topic, and you will find an enormous amount of stuff to learn. Free and paid articles, tutorials, videos, workshops, courses, right? You name it. And as we heard from Gavin yesterday, there really is no barrier to learning more.
So there is also probably no better way to get your hands dirty than a real project.
And a real project with real content, where you can build a structure in HTML and learn and explore CSS and JavaScript yourself.(...) And the thing is, we all already have or can have such a project. It’s right there in front of us, and that’s a personal website.
Your personal site is the perfect place to explore and play, and it’s where you can do whatever you want, where you can try out what you are curious about, where you can do the things you don’t know how to do yet. It’s your playground to tinker with all this stuff, fluid type, colors,(...) animations, accessibility. You can improve the performance of your site or the structure of your HTML a little bit. It’s your place to sometimes also take risks, create opportunities, and create something that is funny, silly, and wonderful. And there has never been a better time to get started with a personal website, also because we need you and many more on the open web. We need you to keep the web open and independent and diverse. And you can start small with just a plain HTML file and a few lines of CSS, or you can look into static site generators like 11T or CMS like Kirby.
So I look forward to seeing what you all will be painting on the web on all your personal sites. And if you do, don’t forget to send me the URL.(...) Thank you very much.
(Applause)
