CSS Can Do That Too

Hello, everyone. This is the first time I'm participating in JS Nation and I hope you've all had a great time so far. I believe it's the third day, so plenty of amazing talks already. Now, hang in there. Almost done.

Now, JS Nation is the biggest JavaScript conference in the cloud, so naturally I'm going to be talking about CSS! Specifically, things that we used to need JavaScript for, but can now be simplified using CSS alone. So a quick introduction. My name is Hui Jing. I'm fairly simple enough that these emojis right here paint a pretty comprehensive picture of who I am as a human being. I happen to be Chinese, and if you're unfamiliar with Chinese names, our family names come first and the first name comes after, so Hui Jing is me. I'm currently a front-end developer at Shopify. Day job, important. Have to pay the bills. So this is going to be a rather short 20-minute talk, so I don't expect people to instantly pick up everything that I'm trying to cover here. Think of this as more of a, ooh, that's nice, I've learned new information today kind of thing. And if you ever come meet a use-case where these solutions work for you, then you can take your time to go and understand them at a deeper level at your own time.

So let's start off with responsive topography. Now when I say this, some of you might think I have a weird mindset, but to me, the web is fun because you cannot control the environment in which your audience views your creations. So it's kind of like you built something, but you're not sure how other people are going to see it. That's what makes it exciting. But for textual content on the web, there is still a key concern, regardless of what type of design or whatever you're doing, is the legibility and readability of your textual content. So web typography has always been a focus for many people. And there have been a number of techniques that have been developed over the years, and as newer CSS properties become available, a lot of these techniques have been continually refined.

So let's do this in the browser, demo time. The first option we have is just straight up media queries, and even though it seems fairly basic, you can also look at it as this is the most flexible option, even today, because you have really granular control over the size of which you want your text to change at whatever viewport that you specify. So in this example here, I've arbitrarily put in 42 and 54 as the breakpoints, but it's really very customizable. So let's do this DevTools thing. So as the viewport changes, you can see you can get your text to change alongside it, and just having a very basic series of media queries, you can be very granular. I can see how people feel that this might get a bit tedious if there are many different viewports you want to take care of. So the second option that I'm showing here, which is CALC.

A combination of CALC and viewport units. This technique was created by Mike Rithmuller, I believe, back in 2015. It has a couple of names, I think. Some people call it CSS locks, you might have seen it covered in other articles. Basically, this technique allows your font sizes to grow and shrink with the viewport width. This is the viewport units here. And if I'll show you, you can see that it's kind of a gradual grow and shrink. But then, it doesn't... at this point, it stops shrinking, somewhere along this point, it stops growing. So that's why, again, it's a combination of media queries CALC and viewport units, because there's a cap on the maximum and minimum sizes. But anything between that, the font size will scale smoothly. I guess that's why they call CSS locks, because you're locking the minimum and the maximum size.

So for a really in-depth explanation of this exact formula, it eventually... if you look at it, you're like, wait a minute, wait a minute. 48 minus 24, I could do that mathematically. But this formula kind of matches up with your minimum and maximum view font sizes. So there is a very in-depth explanation. I'm not going to go into it here because there's not enough time. So I highly suggest you read Mike's article, which I've linked at the end of the presentation.

So what we have most recently is we've had a slew of math functions that have been supported in the major browsers already. And among them, we have the clamp function, which allows us to pick a value within a range that's between a defined minimum and maximum value. So this kind of sounds familiar, right? It's almost what I described for Mike's CSS locks option. So this is how the function looks like. It takes in three parameters. There's the first one, which is the minimum value. And the last one is the maximum value. So what you have right in between here is what we refer to as the preferred value. And this function is useful if the preferred value is dependent on something you don't control directly. For example, viewport units. So if you want your font to grow and shrink, but not get too tiny or not get too large, that's exactly what the clamp function is doing. So it's similar to option two, albeit a much more simplified syntax.

Now one thing to take note of when using viewport units or limiting text sizes with math functions is that it may, not 100% but it may result in users being unable to scale text to 200% of its original size and that's a WCAG failure. So it's definitely essential to test with Zoom. When I say Zoom, I mean like this. Zoom. Just to make sure you're not failing any. Accessibility test. So for browser support for the math functions, looks really good. Statistically, it's about like, I don't know, 91% of broad support. So give it a try if you had this particular use case. Okay, let's move on. Talking about scroll snapping.

The CSS for scroll snapping has been around for a while. But the specification had gone through a number of modifications and the properties have kind of changed somewhat from the first iteration. Now today, the main properties are scroll snap type for the container and scroll snap align for the child element.

So let's take a look at this again, live demo. So for scroll snap type, which is applied onto the container, you can set a value of mandatory or proximity. And this determines how strictly the browser will snap to a snap point. So here I snapped it to mandatory. So the browser will always snap to a snap point, which in the sense, I'm not sure if the mic is catching the sound, but I'm only clicking once and it's flying to the next item. It works for a keyboard too. So my keyboard might be a bit louder, so you might be able to hear this better. And you can do the scroll snapping on the x-axis or also the y-axis. So if you want to do a y-axis, I'll just modify this a little bit. And there we go, you can do it vertically as well. So this is mandatory, but if I change it to proximity, you can see that it's much looser snapping. So if you can't hear, I'm just going to tap, tap, tap, tap, tap, snap. Tap, tap, tap, tap, tap, snap. Tap, tap, tap, tap, snap. So it's kind of up to the browser I believe, the exact point where the snapping occurs. But it seems that it kind of kicks in when we stop scrolling within a couple hundred pixels of the snap point. So you have this kind of a more flexible option for scroll snapping.

But if this is the type of interaction that you want to design, you don't really have to use a JavaScript library anymore because I know there are a number of scroll snapping libraries out there. So as for support, it's even better than the math functions, coming in almost 94%. And even IE is kind of supported, albeit with the old syntax. So maybe your mileage might vary. But if you need something like this, instead of reaching for a JavaScript-based solution, maybe give this native CSS solution a chance.

Next up, we have sticky elements. Now this is a pattern that I encounter very often these days. And I do still remember the days, I'm not dating myself, but I remember the days before position sticky was widely supported. And we needed to use JavaScript, because we needed to calculate the position of the element, we needed to figure out where it needed to be, and then we needed to fix it there. But then there are all sorts of problems, because you know, things overlapped.

It was all very expensive and tiring, to be honest. Right now today, we have, oh, very, very good support. If we just were going to ignore that IE column right there, support for position sticky, you know, all over the place already. The main issue with position sticky these days I see when people try to use it is kind of like why doesn't it work? Why is it not sticking? And I figured out that most of the time, it's due to some gaps in the understanding of how precision sticky works. So let me try to explain this.

A sticky position box is like a hybrid between a relatively position box and a fixed position box. So a relatively position box goes with the flow, you know, you can scroll, scroll, scroll, it goes along. Fixed position box just stays there like tick. So for position sticky to work, it's not, okay, so here I have a styled sticky box, this green box right here is my sticky candidate. It's not enough to just put position sticky on it and call it a day, no, no, no. You gotta have a offset value, offset value being either top, bottom, left, right, because this sticky element will be treated as relatively positioned until it crosses a threshold for the container within it's, for the container within it, this is so hard. Within the container it's scrolling in. So there has to be this point where it sticks too. So if you don't define this offset value, it's just not going to stick, you know? So then the, as I scroll, so right now I set it to top 1m, just to make it obvious, like I could change it to zero for people who are like, argh, there's a gap. So change it to zero so it will stick nicely. So it'll be stuck at that threshold point until it hits the opposite edge of it's containing block. So, we can also change this to bottom, and then it'll stick to the bottom, scroll, scroll, scroll, stick. Also works in left, right. And let's not make it flexible. Change this to left, right. Oh hey, it's not really working. Interesting. Right, okay. So I just showed you a very common bug, why didn't it work for left, right? It's easier for me to show using the vertical example because of, it's just because of the size. So let's do this. Height, and gonna make it like 800. And then so, just so that you can see the height. Let's give it a border. Righto 2 maybe. Okay, so there's like this black border, right? And I made it 800 because like, this wrapper is the parent of my boxes right here.

And so I clearly have more content than 800. So now if I wanna do like the top... It doesn't look like it's sticking at all, right? Let's try 1000. The reason why it's not sticking, it's not that it's not sticking, per se. Let's see if I can explain this correctly. If your sticky element has already reached the edge of the containing block, it might not appear to be sticky at all. It's just that it's the containing block that's being scrolled away. So I'm just gonna switch this back to 800 where it appears there's no sticking involved. It's kinda, there's nothing for it to really stick to because before it can reach the edge, the containing block has already gone away. So it becomes more obvious when the container is larger that, oh yeah, there is some sticking going on. So, this is one of the tricky things I think people encounter when they're using sticky for the very first time. My suggestion is you take the time to really understand and figure out how it works. It's great if you can just try out these values on your own in dev tools maybe. I also wrote about positioning in my blog before and I've linked to several articles by different authors that explain sticking in their own way. This is because I think everyone grogs this and understands this slightly differently. So if what I said today doesn't make sense to you, try a different explanation until you find the one that sticks. That's just my advice.

Okay, okay, running out of time. Last thing I wanna talk about masonry layout. Now this was originally a JavaScript layout created by David DiSandro back in 2009. It was all the rage back then, Tumblr uses it, Pinterest uses it, some people call this the Pinterest layout, so good job, Pinterest, I guess. But given its popularity among web designers and developers, this layout method was discussed quite a bit within DCS's working group meetings. And so we have an editor's draft of Grid Level 3 that specifies how masonry can be done natively in the browser with just CSS.

Demo time. So, but like, before CSS masonry, because it's really not very widely supported right now, let's see, yeah, it's only implemented in Firefox behind the flag, so you gotta switch that flag on to be able to see it or even play with my demo right now. So let's say you don't have CSS masonry, we can do something pretty close with the multi-column layout it's just that multi-column has a couple of limitations. Its implementation is also a bit inconsistent across browsers at the moment, in fact.

So I would say that multi-column is more suited for inline content, like lines of text as opposed to like discrete boxes that I'm doing here. I'd say there's inconsistencies because like my break inside is not working here, but if I open this in say, Chrome. Nevermind. So multi-col, when we use it, it's a, how should we put this, it flows, you know, in the block direction and then multi-columns spins back up. So your content is actually flowing top to bottom and then left to right. So if order matters to you, I've numbered these boxes so you can see. Maybe the first couple of things in your grid are important, but you don't want them at the bottom. You can't really control this with multi-column. And what else, you could, if you want to like span your item across columns, you kind of can do that with multi-col, but like as I said, the implementation for multi-column isn't very complete in browsers. So right now all you have is like all, and it kind of looks like this. The breaking, it looks weirdish, a bit buggy, so let's just say multi-col is a third of the way there for Masonry, right? So with CSS Masonry, you can do both directions, the x-axis and the y-axis, because CSS Masonry builds on top of the browser's grid capabilities, and its syntax is pretty similar to how we would use SubGrid, which is part of Grid Level 2. The value of Masonry is applied either to the gridTemplateRows property or the gridTemplateColumns property, depending on the direction that you want to go. For this horizontal direction here, my row heights are defined with template rows here. I put this repeat thing because I'm lazy. And then you can leave the columns free to be masoned. So, essentially, the columns are not lined up as per a normal grid, but they're masonry, whatever the verb is. So, you can definitely do span much better. So because this is horizontal, I'm using gridRow for this. Span two, span three looks kind of nice. Things flow together.

If you want to do the opposite direction, you see columns and rows are flipped, so now my rows are the ones that are being masoned. And one of the great things about grid and flexbox is the alignment properties. So naturally, CSS Masonry also has masonry-related alignment properties, and they use the same value as the other box alignment properties, so nothing especially new to figure out.

So for this vertical masonry layout that I have here, let's do something like this. Let's say my container, really, really long. Let's go for 150 viewport heights. So, you know, long container. You can use the tracks alignment property. So we have alignTracks and justifyTracks. Again, depending on the direction you want to go, alignTracks is for the block direction. I can, kind of push them down, push them up, push them in the center. So these alignment properties also work if you want to use masonry layout. And of course, you can also do the spanning thing, except that this time you would use column because the direction changed, it's grid plus plus, right?

So currently the working group is looking for feedback on the implementation, it's very, very early days. I'm sure there are bugs in this Firefox implementation as well, so lots of aspects to consider before it's production ready. So if you're using Firefox, this feature is behind a flag so you can try it out for yourself. Go back to my slides, this is the end of it, man. As a self-proclaimed CSS lover, I must say that the thing that draws me to CSS is that there's no one right way to do things. It's flexible enough to adapt to a variety of situations. Can't touch the markup, don't worry. Probably a combination of CSS properties that can fix the problem. So there are really a lot of exciting developments in CSS, which gives us more tools with which to style the web. So I'm just hoping that the next time any one of these use cases come up for you instead of going for a JavaScript-based solution, you could try the CSS one instead. So these are the resources. I'll share these slides with everyone. There's a link at the footer. Thank you.