Under the Hood of Modern CSS Frameworks by Michael Trythall

Speaker 1: Come on, no.

Speaker 2: Alright, so hi, I'm Mike. Um I build CSS frameworks with people A little bit of background. This was a weird talk for me. This is a huge topic if you really start to get into it, which I did not know when I did my abstract. But I I had been doing this for so many years. When I started nineteen ninety-six, as a kid, it doesn't matter, no one, you know 20 years, 10 years, none of that matters. But um when I started as a kid, we really just had HTML, right? And I had a big old HTML4 book. And then over the years you start to sort of accumulate all these little tips and tricks and the next thing you know you're building these complex things you don't really quite realize you've maybe even built a framework or a set of tools or whatever When I started thinking about this this topic, I had just rolled off of a medium-sized content management system

Speaker 2: based on Uh what's in Django CMS? What's the other cool one? Wagtail. And and LinkedIn does quite a bit of these. We sort of split between web applications and you know like traditional I need to get something done, put some stuff in, get something out, and and large scale content management systems. So I was on a medium, medium scale CMS. We did everything completely custom using my big old bag of tricks. and did the design completely ourselves. And it was the one project that I had done a long time that I was really happy with because I had done all the badger prick work for years and years and years. There was definitely things that I learned that were hard kind of doing something in 2000, late 2015, early 2016, a little different than what I've done years before.

Speaker 2: But it came together well. And then I immediately jumped over to an extremely large content management system for a large national nonprofit That project was ongoing. The contrast with that project is that they wanted a large they wanted a well-known CSS framework. So I had just come off something making a whole bunch of mistakes. And going into something where all the mistakes were made for me already. We ended up going with CERB Foundation and it's been going very, very well, but it's huge difference. When I did start with this talk, I was planning on going extremely deep with everything and getting in stuff being very, very technical. But the problem is that when you really look under the hood of these things, they're not that scary. There really isn't a whole lot of magic like there used to be.

Speaker 2: And a lot of that is because CSS is sort of caught up. Um and we're getting better at documenting, we're getting better at clarifying things and I don't know, the best practices that people are using just aren't quite as odd as they used to be. I think a lot of that kind of boils down to think the browsers aren't so bad anymore. But in any case, what I try to do here is go through a whole bunch of frameworks and of course five years of my good and bad code, most of it very bad. Don't tell those folks Those products are great. It's the three and four that I have. So I went through a whole bunch of frameworks and I actually do this fairly regularly when clients come in the door and we're trying to figure out how to sort of get things done. And

Speaker 2: I had a lot of a lot of things I could pull from, essentially is what I'm trying to say. And that kind of got me really thinking about What's in sort of these modern frameworks, right? They're all a little bit different. And stuff that I was doing was quite a bit differently. It does sort of all boil down to what I don't know if you've heard folks have ever seen this term, but design systems, the fancy designer term for just modules, components. We're always trying to make things complicated. But the stuff on the left is sort of the core things that you're gonna find just about anywhere. Uh or in any good system. I would say most places or or most systems don't necessarily call all these things out as being important, but they are. And the things on the right are sort of the stuff that can, I want to say

Speaker 2: could be bolted on. You don't necessarily need CSS to do form validation though you could use the new libraries and get away with it. Components are always going to be uh based on opinion. Bootstrap has a hero. Um some of them don't have heroes, some of them have you know, resets for different types of lists, some of them don't. Um behaviors of animation, how things are going to work when you click them, uh, interact with them, that's gonna be very opinionated. So those the stuff on the right We're not really going to get into simply because you can swap it out as needed. And testing is one of those things that everybody kind of does very wrong everywhere. I do have some thoughts on that. I'll mention that towards the end here, but more so after the talk.

Speaker 2: So my talk is primarily going to focus on reset configuration, color management, topography, and rhythm and layout. And what I'm going to try to show you is that there's no mystery here. Under the hood, these things aren't really all that complicated. They're just using some stuff that's new that you might not have heard of. And using those few new things, you can get really far. Not like the old days when everything really was all magic and hacks and it's gross and it's a lot simpler than it used to be. It's the bundling that kind of makes these things nice. So let's start with resets. CSS reset is essentially a way of abstracting away all of the bad browser stuff. So it's not necessarily defining the style. In fact, it really shouldn't. It shouldn't be going in and and and giving you a base set of styles. That's what your framework is for. What it's trying to do is equalize all the different browsers, work around the quirks.

Speaker 2: A lot of browsers Have a tendency to either have incorrect sizing and spacing or they will just not handle things from an accessibility standpoint that well. You won't get outlines or sizing won't work or And the most popular one out there seems to still be normalized. css. I'm sure Who hasn't or who's usually normalizing a project? I'm sure most of you folks have right. It's sort of become an industry. Most people don't really question it. It's phenomenal. If you start Googling around and trying to find alternatives, you're not going to find anything that's all that great or is really all that different. I think there might be one called reset. Eric Meyer, who, if you're not familiar, one of the founding people of modern CSS

Speaker 2: , has one that doesn't really get used, but it still pops up in those search results. Normalize is sort of the standard I would say nowadays. But it's got a few issues with it, like all resets do. First off, it can be a little heavy. It's 7K. It works with a lot of browsers that you might not care about. They're stuff for like IE7 in some places, and I don't know, I mean Some folks I'm I'm sure are still using it, but a lot of a lot of people are starting to move away from some of the older ones. Um it has a lot of things that are just cruft. Um for example, it uh it does things with the KBD tag, it'll do things with I don't know. I don't know who really cares about the keyboard output on your screen, but it'll reset those styles for you too. It's always seemed a little weird for me.

Speaker 2: It's got a lot of stuff that I think most people aren't probably using. That said, I don't really know how you can get away from it these days. And then one last point here. They can add another layer. This this always drives me nuts when I'm going to inspect inspect something opening up Chrome and you have that gigantic list of styles that are impacting your uh your computed styles it's just another layer Where I'm trying to go with this is that when you add these things to your project, take a look at what's actually going in there. Maybe you don't need a heavy-handed reset. Every single one of the major uh frameworks that I looked at is also is doing things a little bit differently. Uh foundation, for example, sort of includes normalize right into, I think it's one of their um it's some sort of setup function.

Speaker 2: But instead of versioning it out, it's just baked in, which is a little weird, right? Because you can't we just we discover new quirks all the time in the browsers. Things are gonna change constantly. And having something that is essentially the foundation of your foundation is um it's just a little odd. You can't swap it out, something comes along It's going to be directly tied in with everything that you have. I don't know, just type coupling. That's what I'm trying to say. Type coupling, fat, right? If you're looking for a reset or if you're sort of rolling your own, and this could just depend on the setup that you have, try to look for something that either has very efficient selectors. Some of the other resets that I did find, some of the older ones especially, or some of the things that I've seen other folks do if they're building their own reset, is they can get a little

Speaker 2: long in the tooth with their selectors. Resetting either too many things or doing similar properties or or similar styles in multiple places. The whole point of this thing is that it's supposed to be lean And well documented too. I threw that in there because as a knock to normalize, it does have a lot of comments, but I think most people are probably ripping those out. at some point in time. Configuration. If you have worked with Bootstrap Foundation or any of these other ones, you'll know that they have um Sorry, you'll know that they have a ton of configuration. Uh this can be a little all over the place. Um let's take a look at it. Um one thing to remember is that Since these frameworks are a bunch of different systems

Speaker 2: essentially sort of working together very well , there's got to be some stuff that you can turn on and off, right? Not every system is going to be required, just like in most frameworks. I think one of the great things about Django is that it's got a lot of batteries included. You can ignore some of those batteries, some of those batteries you can't. Same thing with CSS frameworks The slide I had earlier when I had the two columns, the stuff on the left, the topography system, the reset, those are things you need to have a base. Really to lay things out on page. You have to have some some core systems there Things you can probably turn off, forms, components, validation, those sort of things. Most frameworks make everything pretty easy to configure, except when it comes to that core configuration.

Speaker 2: You're probably all very familiar with this what this is. Anytime you open up any of these frameworks, you're going to get a long, lengthy list of imports. I don't know if this is gross or not, because this is all I know. But it's always felt a little gross. I think on the left is strictly bootstrapping on the right is foundation. Those just two seem to be the heavyweighted ones But you can see there's some organization. Stuff's going into components, type, form, whatever. So that there is some logical split there. If you're going your own route, definitely keep this Again, I can't think of anything different other than maybe you're including uh components and then there's a components file and the components file includes all this.

Speaker 2: But I've always liked this as a table of contents. You can go in and see very quickly what's been included in the project. You can turn off whatever you need right then and there. There's no guessing. Most frameworks keep their variables global-ish. This is a weird one, and I'm calling this out for a very specific reason. This is foundation. Um these are global font styles. Okay? In the topography file. Right. So topography I would say is probably one of those core things you have to have. But if I'm just trying to go through and just make some quick changes, I have to drill down and find this. This isn't all in one massive file, right?

Speaker 2: Which is Kind of good and bad. I mean if you're coming from the Django space, I think we do a lot of global configuration, but um this impacts everything and I have to dig for it Bootstrap's a lot better about it. Tends to put everything in one long file. Again, I think that's the way to go. Oh, I'm sorry. I got a little confused there. This is the font file. This would be the global file. So there's my example. This is the stuff that would be that's full of messing and buried down And the reason why I say this is this believed everywhere is that when it comes to color, type, your grid, those are things that are gonna impact every single component, every single element on the page. They're important.

Speaker 2: Why not put them in a global space? One of the things that I've learned with a lot of trial and error is namespacing the important stuff. If you are sort of going your own route or if you're shoeharding something into an existing framework, it's just a good practice to sort of make sure there's no collisions. Header sizes are a really good example of this. Colors are another one. I have some stuff on colors I'll show you folks in a little bit. But it's not uncommon to go grab some just random code or another library somewhere and somebody resets whatever gray is or blue or something like that. They start messing with your your I don't know heights or padding or whatever else. So one of the things that I've I've started to do is use maps and

Speaker 2: you'll notice this is SAS code. But Just namespacing everything, keeping all of my important logic inside of a map, giving a good name. I mean no one's gonna you might have header sizes. I I don't think many people are gonna overwrite that. Um I've seen I've been on projects where we've had you know a project name or like initials dash something. But namespacing kind of goes a long way, especially if you're throwing a lot of things together. And it also lets you do some cool things that I'll show later on. Breakpoints is another example. You'll see this a lot in all the frameworks. They also have a media query map of some sort. I think it makes a lot of the logic for handling media queries a little easier. Moving along, topography.

Speaker 2: I keep mentioning over and over again topography is important, and I'll show you folks why A basic topography system is gonna have a basic font size, uh a base line height, um some presets. You'll see these Typically you have your your reset and then your building on top of this, but um even foundation's topography file, bootstrap stypocry file just have a lot of safe defaults, right? They um They'll set the block code size, uh one through six and the heading sizes, uh paragraphs probably gonna end up being your base size. Um but then they also start to solve, you know, the the department system starts to solve things about um

Speaker 2: And this is really important because it sets the whole rhythm for the whole site. Which we'll get to in a second. This is a really quick example. I'm sure you folks are, you know, if you've seen this anywhere, you've seen just some basic variables, basic line height. Line height is unitless. This is one thing I'm starting to see more of here where instead of having like, I don't know, 24 pixels. Let's just say it's two, three, double what it was. I need double spacing, so it's just two, three, or whatever you want Another example here, Bootstrap, what they're doing with their

Speaker 2: heads, they actually go a little step further and make the font sizes configurable If you go back to my other example, I go a few steps back, you'll see that from foundation, foundation does that, but it actually ties it to the media query. So in the small media query These are all the sizes. You can have a medium, large, whatever you wanted, and then their whole responsive system sort of knows where they're at and shows the right the right sizes. My opinion that's a little complicated. It can be a little hard to follow and debug, but it does. It works great. It's nice and robust. One of the things I wanted to chime in real quick about is I always thought this was weird and I've seen some some frameworks do this. If I am working in the right side

Speaker 2: sidebar of my page, I guess it's not all that strange to say this heading, even if it's an H3, I want the size of an H6. I guess it's good to think in terms of those predefined headings, I've always preferred just thinking in terms of sizes. So this one is this element would be double the size of the base font. Um I don't know, a little different. But I think this is uh kind of a slippery slope. It kind of gets you into um classitis where you could end up having a lot of elements that just have H6 and then blue and then I don't know, active or whatever else. Um I tend to like to abstract that stuff away. Um but in any case, that's the Pretty simple example of setting up some some configuration.

Speaker 2: Good topography is hard. My wife is actually giving a talk tomorrow on the basis of topography. A few years ago we kind of got obsessed with it in the design community. You'll hear the term vertical rhythm a lot. And this is where topography becomes so crucial to a project. Not everything can be pixel based nowadays. Everything needs to be kind of stretchy, responsive. We gotta deal with people who want to adjust their font size on their screen. And the relationship The relationship of sizing is called vertical rhythm. It's essentially the harmonious the harmonious spacing between everything and a document. The best way for me to do this is to show you guys what this looks like.

Speaker 2: This is a really simple example of um what's called a modular scale. Uh it's a type of Vertical rhythm. And what you'll see here is that this first line doesn't spill out of this little bounding box. Every single line is on its little dotted line. There's spacing between these two elements. This is just text, but there's spacing between these two elements. And if you were to go further down this page in this example Um you'll see that the page just looks right. Right? It's not you you don't have ten pixels here and five pixels here. That's hard. So a lot of the frameworks these days are cheating and keeping it simple.

Speaker 2: They use RAM. Anybody here familiar with REMs? Great, okay. You guys should be up here. Um I always have trouble explaining what REMs are and my YPLs at me constantly. Anyway, it's uh essentially a typographic um constant. It's a it's a global size based on the type. Right now the way this is set up is by setting a base size on the HTML. So you can say my my my basic size here is 20 pixels And then anytime I reference a rem, it's gonna be 20 pixels. So font size, 20 pixels.

Speaker 2: Margin bottom, 40 pixels. If I didn't do math correctly, I think. That's huge. That's huge. Because what we can do is we can say all of the spacing between everything is going to be one rem or two rem or three rem. Uh if I increase my font size, it goes up, goes down, depending on what I want to do. I don't have to worry about pixel density. You could come in with some crazy Steve jobs, made it from the grave device. And it could have a million pixels per square centimeter or something nuts, and it's just gonna be based on topography that you have. Um what a lot of folks do, and it's a little a little out of um

Speaker 2: Is they'll use this is a pretty simple example if I just have two boxes. Nothing crazy. Blue borders, whatever. Um, kind of based on the same thing. But what they'll do is they'll use REMS for spacing between elements. We'll use M's on the inside the box so that all of the relationships between things inside of a container are relative to each other. So if I have a heading, use imagination here, but if I had a a little set um a subtitle here and it needed to be very small But related in size to that main heading, that might be M-based. And then I can just apply a size to one of these boxes and have it ripple down via M's.

Speaker 2: But the spacing between each one of these is going to be consistent on my my main font size that I said. Um foundation does this. Uh I think Bootstrap does it as well. Foundation actually has a rem calc function that you can throw at pixels or whatever else and it'll convert it over to REMs. But the idea is that it gives you sort of this consistency through everything, which makes that vertical rhythm, which is a harmonious spacing and sizing and everything between all your different components, it makes it a lot more solid. And with that, I think you can avoid a lot of I want to say boilerplate stuff that you'll find out in the wild A lot of folks for a few years were trying to solve this by add-ons and huge CSS

Speaker 2: files, but it doesn't really have to be that complicated And the other thing that I've seen is that um well I'll show you in this example. One of the issues that I've seen with vertical rhythm and just spacing and sizing is that it doesn't really ever hold up. There's always an exception. There's always something a little weird. So I think over-defining it, and this is what the frameworks don't do. They don't over-define it by giving you, you know, too many tools and putting too many things too many places. Um you don't Have situations where you put two components side by side and they don't feel right. This is a page from Foundation's I don't know, site template, whatever. And you can see that it doesn't really seem odd, right? I know it's kind of small, but

Speaker 2: there isn't anything that's totally broken or feels like there's too much white space or just messed up. And there's just some regular REM-based sizing between everything, just marginal. And it seems to work just with their universal constant. Fifteen minutes. Layout. Um grid systems used to be a lot harder. They're not anymore. Typical grid system has some sort of container or box for starting a grid. You don't just store grids in the middle of text and whatever. You can, but you don't, because it looks bad. Usually get some helpers for columns laying things out. There's some gutter definitions, so I want this much space between each thing, this much space on the sides.

Speaker 2: And then typically, I think when people think of media queries, they probably first and foremost think about moving boxes around. You don't really think resizing a lot of other elements, but working with your grid is probably the first place to start Every single one of the frameworks has some sort of grid helper. This is just a very basic example of what a container I think I have this on every single project. Foundation Bootstrap all have the same thing. The benefit of splitting it out as a mix-in , not just having a container class, is so that you can avoid div class container everywhere All the time. It's not shown here, but one of the things that I've tried to do is uh if I have a component and it does have a wrapper, um, it gets a name that's

Speaker 2: Partially generic, so um, but also tied to the component. So if it's a text component, it might be text wrapper or something like that. Um In my opinion, it can make code a little bit more portable outside. Everybody's containers are a little bit different. Fluxbox. Just jump right into it. All of the major frameworks that I've seen are starting to use this API called Flexbox. Who here is familiar with Flexbox? Okay, so I love Flexbox. I've been using it for a few years now. Um it makes my life a lot easier. It's very good at one-dimensional layout This is a weird definition that I've seen. I stole this, I don't know where it's still from. But it's essentially you're not going up and down, you're just going left and right.

Speaker 2: It's really good at putting things in a line. Here's a really basic example. We have our container again, but this time we're doing display flex. We have justified content space between and we have a max width. That's configurable. That's just a little cool. Most important thing is justified content space between. Anything we put into our container. Flexbox is gonna try to put as much space as it can between those things. If I only had one box here, it would be a big old white spot. What I'm doing is I'm saying each box is 33. 33%. Um and there's probably some pre-configured margin here in my example. But the idea is

Speaker 2: that every each one of these boxes is going to be 33% wide Which if you've seen that pattern going back to this, you've probably seen that a million times on websites. Just pretty calm. Here's another example of just a two-column layout. The first box has the flex property, flex one. This is shorthand , essentially just saying the box can grow as much as it needs to. And has a margin right of 20 pixels. So this box is going to sort of get pushed out and take up whatever space it's allowed to take. This box is going to take

Speaker 2: as much space as it can take, and then it'll just have a march of 20 pixels on the right. So I I cited those two examples because I build those all the time. I build entire websites out of those two patterns And that's really you don't you don't need a lot with Flexbox. It has pretty good support, I think 97 if I read that correctly, roughly. Older browsers are gonna give you some trouble. Of course. But if you're not going back too far with IE, you're you're probably okay. IE 11 and some of the other ones just need to be prefixed properly and there's a few dragons here and there. But I've been using this for a few years. And it's actually allowed me personally to replace some of my grid systems entirely. I don't have to have a handy-hand

Speaker 2: heavy-handed grid. It's just I need this thing here and this thing here. Flexbox, three lines of code, there you go. Using calc is another really great tool. Calc doesn't have the browser support. I'll show you guys that in a minute. But calc is really neat because it'll it'll perform a calculation with different types of units So 100% times 1 third minus 20 pixels will give me a box that is 33. 33 pixel percent wide minus 20 pixels. Works really great with justified content space between. And there's all different types of scenarios and values you can put in justified content to get different things. A really quick example of a really rough grid system that I've I've stubbed out recently and

Speaker 2: worked with is right here where On the row that I I I have, I'm saying all of the children are using this. Sorry folks, my X should be row here. Just me messing with namings last last minute, but doing the same thing here. I'm saying that um give me a magic number to give me my um my percentage and one hundred percent times the percentage is just a little easier to read, right? It's slightly easier math. Um minus the spacing. So same thing I just I just showed you folks with this But what I can do is just say this row, everything is going to be three columns. Or it's two columns or one column or whatever.

Speaker 2: Whatever number you want to pass in there will work. Again, the built-in tire group substance based on that. Bruce Shot and Foundation are doing something very similar. They're just taking numbers that you pass in with their functions, with their class names that are running it through a function, and then they're just spitting out some really basic math and There you go, we have percentages and some gutters and some padding. This is the simplest one I could think of. So there's an example of that Same thing, 20 pixels patty between each one. So remember, 33. 3%, 33. 33% minus 20, chink, think like that.

Speaker 2: Um you can Go kind of far with how accessible that is. I tend to find if you're not using your grid system, assume devs only I've had editors try to get in and sort of work with some stuff and it's great, but the math is it's just weird. If you're not if you're thinking in terms of content and you're forced to sort of think about the grid, it's a little weird. Calc has not as good a support as FletchBox, but if you don't can't use Fletchbox or you're just doing some sizing to be inline block, something else, you have some options there. I've definitely hit issues with old IE. And oddly enough, old versions of Android. Here's some different resources on Flexbox. Calc's pretty easy to look up, but Flexbox is a bit easier or a bit harder to grasp

Speaker 2: There's just a lot of weird quirks to it. Once you wrap your head around it, it's fine. Lincoln did a whole series called Flexbox Friday where we took real-world examples and built them. We did a masonry layout. We did all kinds of cool stuff. Um not to mention my wife again, but she did the cheat sheet, which seems to be pretty popular. Use of spruit, it's cute, check it out. And then of course Chris Porter and some other folks that did some wonderful things as well Last section here, color. Most frameworks don't do much here, which has always been odd to me because color is so important. They'll make color configurable. They'll do it like this. Or they'll have gray dark, gray, gray lighter, gray lightest. I've had to append this with gray most dark, gray, darker, darkest. Um

Speaker 2: the darkest and greyest you've ever seen is a bravery. This has always been strange to me. I know eventually it becomes black. Right, it's not gray after a certain point, or it's just white. Um but I've always liked the idea of um put it in variables. I'm gonna add an example of this later on. So what do we need from a color system? Because I don't think this kind of comes up that often. And I definitely had to roll my own a lot. Make it easy to access colors. Make it easy to apply colors And some helpers. Helpers are do a lot of those. Here's an example that I was just referring to. The answer stayed anti -pattern is Using sensible names. These have been great. We've used this on a bunch of projects now,

Speaker 2: and it's easy to think in terms of ORCID or Poppy or Iron or Mercury as opposed to gray dark or gray light. Comparing different colors is a little strange in that way. Again, I'm namespacing my colors so I don't have any collisions. And I'll show you why this is awesome. You can easily pump out themes. This is my theme code's huge, um, but this is the very simple version of it where I am looping through all of my different colors in my palette and I'm just setting my background color and my foreground color which is using my neat little helper called contrast color Again, I don't know why frameworks do this. They've been huge for me on every single project. Some of the ones that do theme, I think semantic has some stuff for color. uh semantic UI.

Speaker 2: This is my contrast function. I'm just checking the lightness of color. And if it's light give me a black foreground. If it's dark give me a white foreground. Um this this is really great because you can you can go ahead and you can take a lot of different um combinations and stand new layups uh layouts up. So when we do a CMS and this is what we're currently doing, we have we've given editors the ability to just select a theme. I want blue. It's just blue Or red. And then with stuff like this, we can go through and make really intelligent decisions when they put, I don't know. blue on red or they do something weird. You know what I mean? We can make things a bit more flexible if uh you make your color system configurable.

Speaker 2: Um it's probably not a need everybody has. But if you're working in CMS environment or if you're handing off code to another development team, they're going to get weird requests too. So making your color system flexible like you've made everything else flexible, I think, helps quite a bit. I'm assuming that most of the frameworks don't really do this because they have theming, right? Like you just overwrite a few variables, you plug in some code, and it sort of works. But I've always liked the idea of um making it a bit more chromatic as well programmatic as well since you can generate pallets or pretty much anything you want to do Here's an example if you were to apply the theme just really quick

Speaker 2: Alright, hot color tips to impress your friends. Avoid modifying colors, be a darkened and lighten. If you're gonna do something If you're if you're you're introducing a brand new color or something totally drastic, unless it's something like zebra stripes or you're alternating something, you need a subtle gradient or something. could make it configurable. It's a little weird having to go through code and find out why something's been modified. Same thing with the best example I can I can give you is that I've designed or I've been given a lot of components with the colors just slightly off And the colors on all fits the opacity. And no one mentions that. So just be careful when you're modifying colors. If you're using um If you're using hex, use hex everywhere. Some people I know are using HSL. None of the frameworks have picked this up.

Speaker 2: It seems a little bit easier to follow if you're coming from a design background, but it's probably hard to follow if you're not. Probably a bit more flexible though. But use one one color system, don't mix them up. And use your your your color lingo. I had mentioned using uh friendly memes. Um it does go a long way. Um It's a lot easier to say I am using ORCID and bright rich purple. Saves time, and you can build a more friendly palette. My final points, since I'm almost out of time, is It's better to keep things really simple and then build a base on it. I know that sounds kind of dull, but hear me out. Your framework doesn't really have to be everything. And I think for a while some of these frameworks were you you were a bootstrap site and that's all you did.

Speaker 2: And like your site looked the same as everyone else's and you went and got a bootstrap team. That's wonderful, but um I don't know that having a site that looks like everyone else is always the best thing, even though it maybe makes things a bit more predictable. Your frameworks just sort of get out of the way to some extent. And keeping things pretty simple using Flexbox, using CSS, or using Calc, as I mentioned down here. Use your standard CSS APIs. You won't have a lot of weird stuff you have to work around and be easier to extend. Use good configuration, overconfigure. Can't stress that enough if you've worked with Bootstrap.

Speaker 2: Or foundation. Foundation's really bad about it. There's definitely some things you just can't change without overriding. And it's stuff that you think you should logically be able to change. Colors, line height. Font size and borders I I know I have all seen in that framework where I have to override. But everything else is configurable. Everything else in the form is configurable except for this one property I need. Okay, um sensible constants , parameter base colors , and some helpers to go for each system. That's it.

Speaker 3: All right, we do have time for some questions. Thank you so much, Michael.

Speaker 4: You mentioned testing.

Speaker 2: Yeah.

Speaker 4: One question that we haven't yet to solve is you can test code. How do you test visual looks?

Speaker 2: Right, so um Mike Godbold has a book called Front End Architecture. Uh Michael Godbolt is somebody who works on, he is a front architect who did a bunch of work for Red Hat where he explored this problem A lot of ways to do it. The easiest way that I've seen to do it, and I've this is one of those things that got complex that I had to cut, is onion skinning. So if you've ever used cross-bowser testing, I think maybe browser shots, we're a big fan of cross uh cross-bowser testing. We'll build a kitchen sink page. We'll put everything on the page or we'll build a layout a couple different layouts. I'm actually having to do this this week. We will on screen, we'll take a screenshot with everything and all these services do this now. And they overlay them and then all say, okay, what's your base one? My base one's probably the latest Chrome or something. And then it'll show me all the deviations.

Speaker 2: So you can spot check that way. There's a way to automate that. I'm I usually punt that to somebody else who's likes to deal with the configuration. But that's the quickest way that I've done it is a good old kitchen sink page and building out some real world scenarios. Automating it, yeah, I mean that stuff's a little rough, but Mike's uh if you are interested, Micah's book does cover that in painful detail. So

Speaker 3: all right, we have one time for one more question.

Speaker 5: So I I was always uh averse to using uh CSS frameworks too because when I worked there were like you know big classes on everything, right? So last year I used um uh Susie by Oddbird. Have you have you ever used that?

Speaker 2: Yeah, uh I mentioned Smithsonian earlier. We did uh the entire grid system um in SUSE for that and uh it was really slick Um I the problem I've since moved away from it since what 's box is picked up because it's just made some of the math. I mean

Speaker 5: that was my question basically.

Speaker 2: I've actually met the author of that. I'm I'm friends with him and his brother and uh had the same question like His whole thing was bridge really aren't that hard. It's just a little bit of math. And if the math and the bugs and quirks and stuff have been sort of worked out, and I actually like the math's not terribly difficult. Um layout stuff's kind of solved with flexbox or um the upcoming grid layout system that we should be getting in the next year or so. But yeah Susie's phenomenal, especially if you're doing float-based layouts, I would absolutely use it. We have a couple sites that are using in production. Do

Speaker 5: do you would you recommend uh doing something like that where you're you're using like a utility library of you know just math functions based on gutter and line height and everything? Yeah. Rather than use a framework? Because uh Um it seems like uh uh you you might have to end up like building a lot of things in the framework anyway that aren't related to the grid.

Speaker 2: Yeah, yeah. Um There, you can definitely go, uh and I probably should have driven this point home a little bit more now that Nature mentioned it. Um you can definitely go and grab a grid system off the shelf and plug it in and keep it kind of basic. Where you might get some issues is with like the vertical rhythm stuff that I mentioned. But if you're just thinking of your site as a bunch of containers And you're controlling what's inside of it, not really a big issue, right? Like you've just got two columns or three columns, whatever. There's a ton of those Nowadays, especially ones that are using Flexbox that do have some APIs that make it a little easier. If you're looking for something like Suzy, and I don't know what a good alternative to Suzy would be nowadays, but Suzy is really good at really good at doing the math and helping you come up with

Speaker 2: It's gonna have some helpers for like how to push stuff around, which could be really helpful. I don't know if that correlates that well to flexbox as much. Maybe I think it probably does with margins But yeah, if if like that piece is a thing in the tail and you don't feel like doing the math or rolling your own or if a framework's too heavy, yeah, there's a ton of those. And I would definitely go grab that and plug that in. The other ones are a little bit harder to swap out, but there's tons of grids.

Speaker 3: Awesome. Well Michael, I'm sure there are other questions in the room, so if people want to uh keep the conversation going, you'll be here all week.

Speaker 2: Yeah, yeah, I'll be here.

Speaker 3: Okay, cool. Thanks so much.