We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Under the Hood of Modern CSS Frameworks

00:00

Formal Metadata

Title
Under the Hood of Modern CSS Frameworks
Title of Series
Part Number
50
Number of Parts
52
Author
License
CC Attribution - ShareAlike 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this
Identifiers
Publisher
Release Date
Language

Content Metadata

Subject Area
Genre
Abstract
Together we’ll look at the code behind Bootstrap, Foundation, Semantic UI, and other CSS frameworks. We’ll identify common patterns and architectural decisions that make these systems so easy to use. Some of the things we’ll discover: What it takes to set up a good type system. How style and structure are separated to make theming easier. Best practices for stubbing out grid systems. How configuration works. How to make everything feel cohesive. What it takes to test a framework so you can potentially test your own. So much more! If you’re looking to improve your skills with one of these frameworks or potentially roll your own mini-Bootstrap, this talk is for you.
13
Thumbnail
42:32
Right angleSystem programmingSpacetimeVisualization (computer graphics)Primitive (album)InformationSemiconductor memoryMereologySource codeValidity (statistics)Mathematical analysisTraffic reportingTerm (mathematics)Web pageSoftware frameworkContext awarenessSystem callWeightComplex (psychology)Software testingModel theoryMassIncidence algebraNumberMultiplication signFunctional (mathematics)FrequencyLibrary (computing)Canadian Mathematical SocietyPoint (geometry)Service (economics)Component-based software engineeringProjective planeBoiling pointContent (media)Content management systemData managementQuicksortDifferent (Kate Ryan album)BitBootstrap aggregatingContrast (vision)Product (business)Type theoryCore dumpElectronic mailing listWeb browserBuildingSet (mathematics)Scaling (geometry)Client (computing)Web applicationHeegaard splittingGraph coloringUMLComputer animation
Different (Kate Ryan album)QuicksortFocus (optics)MathematicsCore dumpLogical constantElectronic mailing listWeb browserConfiguration spaceNormal (geometry)Similarity (geometry)Right angleElement (mathematics)Software frameworkType theory1 (number)Point (geometry)Slide ruleSystem programmingMultiplicationMultiplication signFunction (mathematics)Set (mathematics)Functional (mathematics)Web pageKeyboard shortcutWordAdditionCircleMathematical analysisRevision controlVotingState of matterObservational studyDuality (mathematics)Basis <Mathematik>SoftwareEqualiser (mathematics)Insertion lossGradientMusical ensembleSemiconductor memoryCategory of beingTouchscreenVector spaceValidity (statistics)Order (biology)Maxima and minimaBitPattern language
Electronic mailing listContent (media)Computer fileProjective planeHeegaard splittingComponent-based software engineeringTable (information)Right angleBit rateSoftware frameworkSelf-organizationWordBootstrap aggregatingComputer animation
Software frameworkBootstrap aggregatingComputer fileMassMultiplication signRight angleIterationComputer animation
Element (mathematics)Web pageComputer fontComputer fileType theoryBitSpacetimeCollisionEmailSoftware frameworkSystem programmingHypermediaVertex (graph theory)QuicksortQuery languageDifferent (Kate Ryan album)Goodness of fitCodeRight angleComponent-based software engineeringTerm (mathematics)Graph coloringLibrary (computing)Line (geometry)LogicBuildingTouchscreenBootstrap aggregating2 (number)Disk read-and-write headDependent and independent variablesLevel (video gaming)Configuration spaceMappingBlock (periodic table)Graphics tabletDoubling the cubeSocial classProjective planeRouting1 (number)Basis <Mathematik>Error messageImage resolutionProduct (business)Variable (mathematics)GradientSoftware design patternMaxima and minimaComputer virusPixelHarmonic analysisExecution unitWordProcess (computing)Negative numberComputer wormMereologyResultantTable (information)Validity (statistics)Natural numberBounded variationSystem callTheoryLecture/ConferenceComputer animation
Type theoryMultiplication signElement (mathematics)Model theorySpacetimeWeb pageLine (geometry)Workstation <Musikinstrument>PixelScaling (geometry)CuboidVertex (graph theory)Computer animation
Marginal distributionSpacetimePixelHypermediaQuicksortCuboidConsistencyVertex (graph theory)Multiplication signPopulation densitySocial classSoftware frameworkType theoryComponent-based software engineeringWebsiteProjective planeHeegaard splittingMathematicsBootstrap aggregatingDivision (mathematics)Right angleMetreVideo gameDifferent (Kate Ryan album)CodeLogical constantWrapper (data mining)Square numberPhysical constantSystem programmingBitBoilerplate (text)Content (media)Functional (mathematics)Line (geometry)Pattern languageCalculusConfiguration spacePoint (geometry)Single-precision floating-point formatResultantBasis <Mathematik>Universe (mathematics)Real numberSpeciesBounded variationMereologyMaxima and minimaNumberSet (mathematics)Query languageGraph (mathematics)Image resolutionCategory of beingGradientRenormalization groupElement (mathematics)Portable communications deviceValidity (statistics)Degree (graph theory)Arithmetic meanException handlingInformationProduct (business)Computer fileAngleWeb pageSoftware design patternState of matterFile formatWeightAssociative propertyComputer animation
System programmingWeb browser1 (number)Line (geometry)Element (mathematics)Group actionComputer animation
CuboidNumberQuicksortPixelSystem programmingDifferent (Kate Ryan album)Graphics tabletMultiplication signMathematicsText editorSpacetimeMobile appType theoryTerm (mathematics)Execution unitWeb browserCalculationSocial classRow (database)Branch (computer science)Category of beingValidity (statistics)Line (geometry)Level (video gaming)ResultantPosition operatorContent (media)Basis <Mathematik>Right angleComputer animation
Computer configurationRevision controlAndroid (robot)CalculusLibrary (computing)DivisorIntegrated development environmentValuation (algebra)Social classMultiplication signRange (statistics)Different (Kate Ryan album)Asynchronous Transfer ModeExecution unitNumberRight angleMereologySatelliteSubdifferentialTheorySeries (mathematics)Component-based software engineeringMachine visionGraph coloringFerry CorstenComputer fontHomologieProcess (computing)Video gamePopulation densityTask (computing)Bit rateAreaFigurate numberCycle (graph theory)Water vaporBranch (computer science)BitCategory of beingProjective planeResidual (numerical analysis)Software frameworkQuicksortTrailOperator (mathematics)VelocityFood energyFreewareDecision theoryReading (process)Functional (mathematics)Order (biology)Product (business)VotingStandard deviationCollisionWebsiteSoftware developerSystem programmingCodeMagnetic stripe cardGradientMathematicsDisk read-and-write headStress (mechanics)Canadian Mathematical SocietyPerturbation theoryFunction (mathematics)1 (number)Real numberLine (geometry)Sheaf (mathematics)Contrast (vision)BootingExistential quantificationCombinational logicConfiguration spaceText editorVariable (mathematics)Semantics (computer science)Parameter (computer programming)Bootstrap aggregatingTerm (mathematics)Mixed realitySinc functionComputer animation
MathematicsFunctional (mathematics)Different (Kate Ryan album)Service (economics)Overlay-NetzWebsiteUtility softwareProduct (business)Web pageVertex (graph theory)1 (number)Directed graphReal numberLine (geometry)BuildingBitPoint (geometry)Standard deviationConfiguration spaceExterior algebraEntire functionVisualization (computer graphics)Sinc functionSoftware testingEnterprise architectureDebuggerMarginal distributionWeb browserSoftware frameworkMultiplication signSoftware bugGoodness of fitSystem programmingData conversionHand fanVirtual machineInferenceType theoryLevel (video gaming)Library (computing)MereologyMassMaxima and minimaMedical imagingWordGame controllerProteinGodBounded variationTerm (mathematics)Right angleMonster groupMathematical analysisOntologyGame theoryVideo gameAnalytic setSystem callReliefInteractive televisionCASE <Informatik>Set (mathematics)ResultantLecture/Conference
Computer animationXML
Transcript: English(auto-generated)
All right, so CSS framework for 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 had been doing this for so many years. When I started in 1996 as a kid, it doesn't matter. No one, 20 years, 10 years, none of that matters. But when I started as a kid, we really just had HTML,
right, and I had a big old HTML 4 book. And then over the years, you start to accumulate all these little tips and tricks, and the next thing you know, you're building these complex things. And you don't really quite realize you've maybe either built a framework or set of tools or whatever. When I started thinking about this topic, I had just rolled off of a medium-sized content management system based on, what's in Django CMS?
What's the other cool one, Wagtail? And LinkingLoot does quite a bit of these. We sort of split between web applications and traditional, I need to get something done, put some stuff in, get something out, and large scale content management system. So I was on a 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 did all the baggy trick 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'd done years before. 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 of that project is that 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 a 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 at these things, they're not that scary. There really isn't a whole lot of magic like there used to be. And a lot of that is because CSS is sort of caught up, and we're getting better at documenting. We're getting better at clarifying things. I don't know, the best practices that people are using
just aren't quite as odd as it used to be. I think a lot of that kind of boils down to thinking browsers aren't so bad anymore. But in any case, what I tried 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 get things done. And I have a lot of things I could pull from.
Essentially, that's what I'm trying to say. And that got me really thinking about what's in these modern frameworks. 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 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 going to find just about anywhere or in any good system. I would say most places 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, could be bolted on. You don't necessarily need CSS to do form validation that you could use in your libraries and get away with it. Components are always going to be based on opinion. Bootstrap has a hero. Some of them don't have heroes.
Some of them have resets for different types of lists. Some of them don't. Behaviors of animation, how things are going to work when you click them, interact with them. That's going to be very opinionated. So 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. I'll mention that towards the end here, but more so after the talk. So my talk's 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 attracting 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 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. 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 overwrite focus elements. And the most popular one out there seems to still be normalize.css. I'm sure, who's using normalize on a project?
I'm sure most of you folks have, right. It's sort of become an industry of learning. Most people don't really question it, it's phenomenal. If you start googling around and trying to find alternatives, you're not gonna find anything that's all that great, or is really all that different. I think there might be one called reset. Eric Meyer, if you're not familiar,
one of the founding people of modern CSS has one that doesn't really get used, but it still pops up in the 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, 7K.
It works with a lot of browsers that you might not care about. There's stuff for IE7 in some places, and I don't know, some folks, I'm sure, are still using it, but a lot of people are starting to move away from some of the older ones. It has a lot of things that are just corrupt. For example, it does things with the KBD tag, it'll do things with, I don't know,
I don't know who really cares about keyboard output on your screen, but it'll reset those styles for you too. It's always seemed a little weird for me. 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 always drives me nuts,
when I'm going to inspect something, open up Chrome, you have that gigantic list of styles that are impacting 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 frameworks that I looked at is doing things a little bit differently. Foundation, for example, sort of includes, normalize right into, I think it's one of their, it's some sort of setup function. But instead of versioning it out, it's just baked in. Which is a little weird, right? Because you can't,
we discover new quirks all the time to browse. Things are gonna change constantly. And having something that is essentially the foundation of your foundation, is just a little odd. You can't swap it out if something comes along. It's gonna 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 long in the tooth with their selectors. Resetting either too many things, or doing similar properties, 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, sorry, you'll know that they have a ton of configuration.
This can be a little all over the place. So let's take a look at it. One thing to remember is that, since these frameworks are a bunch of different systems, essentially sort of working together very well, there's gotta be some stuff that you can turn on and off, right? Not every system is gonna 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 a page.
You have to have 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. You're probably all very familiar with what this is.
Anytime you open up any of these frameworks, you're gonna 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. There's just two seem to be the heavy-weighted ones.
You can see there's some organization. Stuff's going in 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 components, and then there's a components file,
and the components file includes all this. 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. These are global font styles. Okay? In a 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? 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 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 full messy and buried down.
And the reason why I say this bleeds 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. Why not put them in a global space? One of the things that I've learned
with a lot of trial and error is names basing the important stuff. If you are sort of going your own route or you're shoehorning 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 from 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, I don't know, heights or padding or whatever else. So one of the things that I've started to do is use maps and you'll notice this is SAS code.
But just names basing 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 don't think many people are gonna overwrite that. I've been on projects where we've had project name or like initials, dash, something. But names basing kind of goes a long way,
especially if you're throwing a lot of things together. And it'll also let 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. 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, a baseline height, some presets.
You'll see these, typically you have your reset and then you're building on top of this, but even foundations topography file, bootstrap topography file, just have a lot of safe defaults, right? They'll set the block wood size, one through six in the heading sizes,
paragraph probably gonna end up being your base size. But then they also start to solve, you know, the topography system starts to solve things about, starts to solve spacing between elements in different components. 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 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,
it'll 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 headers, they actually go a little step further
and make the font sizes configurable. You go back to my other example, you 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 sizes. My opinion, that's a little complicated. 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 really quick about is, I always thought this was weird, and I've seen some frameworks do this.
If I am working in the right side, side bar of my page, I guess it's not all that strange to say this heading, even if it's an H3, I want it 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. I don't know, a little different, but I think this is kind of a slippery slope. It kind of gets you into class itis, where you could end up having a lot of elements that just have H6 and then blue and then active or whatever else.
I tend to like to abstract that stuff away. But in any case, that's the pretty simple example of setting up some configuration. 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 and responsive. We've got to deal with people who want to adjust their font size on their screen.
And the relationship of sizing is called vertical rhythm. It's essentially the harmonious spacing between everything in a document. The best way for me to do this is to show you guys what this looks like. This is a really simple example
of what's called a modular scale. 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 this little dotted line. There's spacing between these two elements.
And 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, you'll see that the page just looks right. Right, it's not, you don't have 10 pixels here and five pixels here.
That's hard. So a lot of the frameworks these days are cheating and keeping it simple. They use REMS. Anybody here familiar with REMS? Great, okay. You guys should go up here. I always have trouble explaining what REMS are.
My wife yells at me constantly. Anyway, it's essentially a typographic constant. It's a global size based on the type. The way this is set up is by setting the base size on the HTML.
So you can say my basic size here is 20 pixels. And anytime I reference a REM, it's gonna be 20 pixels. The font size, 20 pixels. Margin bottom, 40 pixels. If I had to 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. If I increase my font size, it goes up, it goes down, depending on what I wanna do. And 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 the part of that you have. What a lot of folks do, and it's a little out of scope for this example,
is they'll use, this is a pretty simple example where I just have two boxes. Nothing crazy, blue borders, whatever. Kind of based on the same thing. But what they'll do is they'll use REMs for spacing between elements. They'll use M's on the inside of the box
so that all of the relationships between things inside of a container are relative to each other. So if I had a heading, use your imagination here, but if I had a little 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 size to one of these boxes and have it ripple down via M's. But the spacing between each one of these is gonna be consistent on my main font size, I said. Foundation does this. 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 of harmonious spacing and sizing and everything between all your different points,
it makes it a lot more solid. And with that, I think you can avoid a lot of, I wanna 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 files, but it doesn't really have to be that complicated.
And the other thing that I've seen is that, 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 too many tools and putting too many things too many places, you don't have situations where you put two components side by side and they don't feel right. This is a page from foundations, 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 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 marbling. And it seems to work just with their universal constant.
15 minutes. Layout. Grid systems used to be a lot harder. They're not anymore. Typical grid system has some sort of container or box. We're starting a grid, just throw grids in the middle of text and whatever.
We can, but you don't, because it looks bad. Usually get some helpers for columns, laying things out. There's some gutter definition, so I want this much space between each thing, this much space on the sides. 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
and 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 if I have a component and it does have a wrapper, it gets a name that's partially generic, but also tied to the component.
So if it's a text component, it might be text wrapper or something like that. In my opinion, it can make code a little bit more portable outside. Everybody's containers are a little bit different. Flexbox, 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. 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 I stole it from, but it's essentially you're not going up and down. You're just going left and right. 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 justify content space between,
and we have a max width. That's configurable. That's just a little cool. Most important thing is justify 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, this would be a big old white spot.
What I'm doing is I'm saying each box is 33.33%. And there's probably some preconfigured margin here in my example. But the idea is that 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 where you call them. 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. It 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 gonna take up as much space as it can take. And then it'll just have a margin 20 pixels on the right.
So 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 need a lot with Flexbox. It has pretty good support. I think 97, if I read that correctly, roughly.
All the browsers are gonna give you some trouble, of course. But if you're not going back too far with IE, you're probably okay. IE 11 and some of the other ones just need to be prefixed properly. 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 heavy-handed grid. It's just, I mean this thing here and this thing here, Flexbox, three lines of code, there you go. Using CALP is another really great tool. CALP doesn't have the browser support. I'll show you guys that in a minute. But CALP's really neat because it'll
perform a calculation with different types of units. So 100% times one third minus 20 pixels will give me a box that is 33.33% wide minus 20 pixels. Works really great with justify-content-space-between. And there's all different types of scenarios and values
you can put in justify-content to get different things. Really quick example of a really rough grid system that I've stubbed out recently and worked with is right here, where on the row that I have, I'm saying all of the children are using this.
Sorry folks, my app should be row here. Just me messing with namings last minute. But doing the same thing here. I'm saying that, give me a magic number to give me my percentage. And 100% times the percentage is just a little easier to read, right? It's slightly easier math.
Minus the spacing. It's the same thing I just showed you folks with this. But what I can do is just say this row, everything is gonna be three columns. Or two columns, or one column, or whatever. Whatever number you wanna pass in there will work. Again, the built-in tired grid system's based on that.
Bushard Foundation are doing something very similar. They're just taking numbers that you pass in with their functions, with their class names, they're running it through a function, and then they're just spitting out some really basic math, and there you go. You have percentages, and some gutters, and some padding. This is the simplest one I could think of.
There's an example of that. Same thing, 20 pixels padding between each one. So remember, 33.3%, 33.33%, minus 20, think like that.
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, it's just weird. 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 Flexbox, but if you can't use Flexbox, or you're just doing some sizing of the inline block, something else, you have some options there. I 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. There's just a lot of weird quirks to it, and 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.
Not to mention my wife again, but she did the cheat sheet, which seems to be pretty popular. Use this fruit, 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 pen this with gray most dark, gray darker darkest. The darkest grayest you've ever seen, as a bird woman. This has always been straining me.
I know eventually it becomes black, right? It's not gray at a certain point, or it's just white. But I've always liked the idea of putting these in variables. I'm gonna have an example of this later on. So what 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 do a lot of this. Here's an example that I was just referring to. The answers to anti-pattern is using sensible names. These have been great. We've used this on a bunch of projects now.
And it's easy to think in terms of orchid, or poppy, or iron, or mercury, as opposed to a gray dark or a 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. But this is a 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. Semantic UI. Here's my contrast function. 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. This is really great because you can go ahead
and you can take a lot of different combinations and span new layouts up. So when we do a CMS, and this is what we're currently doing, we've given editors the ability to just select a theme. I want blue, 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 can make things a bit more flexible if you make your color system configurable. It's probably not a need everybody has, but if you're working in a CMS environment
or if you're handing off code to another development team, they're gonna 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 theme. You just override a few variables, you plug in some code, and it sort of works.
But I've always liked the idea of making it a bit more programmatic as well. So if you can generate palettes or pretty much anything you wanna do. Here's an example if you were to apply the theme. Just really quick.
All right, hot color tips to impress your friends. Avoid modifying colors via darken and lighten. If you're gonna do something, if 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, you 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 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 off, it's the opacity. No one mentions that. So just be careful when you're modifying colors. If you're using hex, use hex everywhere.
Some people I know are using HSL. None of the frameworks have picked this up. 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 color system, don't mix them up. And use your color lingo.
I had mentioned using friendly names. It does go a long way. It's a lot easier to say I am using orchid and bright, rich purple. Saves time, and you can build a more friendly palette. My final points, since I'm almost out of time.
It's better to keep things really simple and then build a base on it. I know it 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 were a bootstrap site, and that's all you did. And your site looked the same to everyone else's, and you went and got a bootstrap theme. That's wonderful, but 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 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 on here. Use your standard CSS APIs. You won't have a lot of weird stuff you have to work around and use or extend. Use boot configuration, over-configure. Can't stress that enough. If you've worked with bootstrap,
or foundations, foundations are 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 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.
Use sensible constants, parameters and base colors, and some helpers to go for each system. That's it.
All right, we do have time for some questions. Thank you so much, Michael. You mentioned testing. Yeah. One question that we haven't yet to solve is, you can test code. How do you test visual works?
Right, so Micah Godbolt has a book called Front End Architecture. Micah Godbolt is somebody who works, is a front end 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 it's one of those things that got complex that I had to cut, is onion skinning. So if you've ever used cross browser testing,
I think maybe browser shots. We're a big fan of cross browser testing. We'll build a kitchen sink page. We'll put everything on a page, and we'll build a layout, a couple different layouts. I'm actually having to do this this week. We want onion skinning. We'll take a screenshot of everything. And all these services do this now. And they overlay them, and they'll all say,
okay, what's your base one? My base one's probably the latest chrome or something. And they'll show me all the deviations. So you can spot check that way. There's a way to automate that. I usually punt that to somebody else who likes to deal with 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 Micah's, if you are interested in Micah's book, does cover that. In painful detail. All right, we have time for one more question. So I was always averse to using CSS frameworks too,
because when I worked, there were big glasses on everything, right? So last year I used Susie by Oddbird. Have you ever used that? Yeah, I mentioned Smithsonian earlier. We did the entire bird system in Susie. Cool. And it was really slick.
The problem, I've since moved away from it, since Flexbox has picked up, because it's just made some of the math. That was my question basically. I've actually met the author of that. I'm friends with him and his brother, and had the same question. His whole thing was, grids 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 actually the math's not terribly difficult,
layout stuff's kind of solved with Flexbox, or 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 of sites that are using it in production. Would you recommend doing something like that where you're using a utility library,
just math functions based on gutter and line height and everything, rather than use a framework? Because it seems like you might have to end up building a lot of things in the framework anyway that aren't related to the grid. Yeah, yeah.
There, you can definitely go, and I probably should have driven this point home a little bit more now that you mention it. 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's been really good at doing the math and helping you come up with,
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. I think it probably does with margins. But yeah, if like that piece is in the tail, and you don't feel like doing the math or rolling your own, or the 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. Awesome. Well, Michael, I'm sure there are other questions in the room, so if people wanna keep the conversation going, you'll be here all week? Yeah, yeah, I'll be here. Okay, cool. Thanks so much.