font-feature-settings value demonstrated in one single page.
Thursday, August 30th, 2018
Tuesday, August 21st, 2018
In defence of the cascade (especially now that we’ve got CSS custom properties).
I think embracing CSS’s cascade can be a great way to encourage consistency and simplicity in UIs. Rather than every new component being a free for all, it trains both designers and developers to think in terms of aligning with and re-using what they already have.
Remember, every time you set a property in CSS you are in fact overriding something (even if it’s just the default user agent styles). In other words, CSS code is mostly expressing exceptions to a default design.
Friday, August 3rd, 2018
This is an interesting tool: mess around with styles on any site inside Chrome’s dev tools, and then hit a button to have the updated styles saved to a URL (a Gist on Github).
Tuesday, July 31st, 2018
A great collection of styled and accessible form elements:
Form controls are necessary in many interfaces, but are often considered annoying, if not downright difficult, to style. Many of the markup patterns presented here can serve as a baseline for building more attractive form controls without having to exclude users who may rely on assistive technology to get things done.
Tuesday, June 12th, 2018
This is really good breakdown of what’s different about CSS (compared to other languages).
These differences may feel foreign, but it’s these differences that make CSS so powerful. And it’s my suspicion that developers who embrace these things, and have fully internalized them, tend to be far more proficient in CSS.
Friday, June 8th, 2018
A nice intro to variable fonts.
Thursday, May 3rd, 2018
I’m not great at estimation, but I still try to do it on any project I’m working, even if it’s just for my own benefit. I break down different bits of the work, and ask myself two questions:
- How important is this?
- How long will it take?
If I were smart, I’d plot the answers on a graph. I start doing the important stuff, beginning with whatever won’t take too long. Then I’ve got a choice: either do the stuff that’s not all that important, but won’t take long—or do the stuff that will take quite a while, but is quite important. Finally, there’s stuff that’s not important and will take quite a while to do. I leave that to the end. If it never ends up getting done, it’s not the end of the world.
I guess it’s not really about estimation; it’s more about prioritisation.
Anyway, I’m working on a fun little project right now—the website for one of Clearleft’s many excellent events. There was one particular part of the design that I had estimated would take quite a while to do, so I didn’t get around to it until today. It was a layout that I figured would take maybe half a day of wrangling CSS.
I used CSS grid and I was done in five minutes. That’s not an exaggeration. It was literally five minutes.
I thought to myself, “Well, I want these elements to be arranged in two rows of three columns, but I want that particular one to always be in the last column of the top row.”
Normally my next step would be to figure out how to translate those wishes into floats and clears, or maybe flexbox. But this time, there was almost no translation. I could more or less write the CSS like I would write English.
I want these elements to be arranged in rows of three columns.
display: grid; grid-template-columns: 1fr 1fr fr
I want that particular one to always be in the last column of the top row.
grid-row: 1; grid-column: 3;
That was it. I was done.
I think I may need to recalibrate the estimation part of my brain to account for just how powerful CSS grid is.
Wednesday, May 2nd, 2018
Good advice on print styles from Rachel. The browser support situation is frustrating; I suspect it’s because the people working on browsers would rather get stuck in on shinier stuff.
Tuesday, May 1st, 2018
Chris takes us on a whirlwind tour of radial gradients in CSS.
Friday, April 20th, 2018
Patrick is thinking through a way to implement
:focus-visible that’s forwards and backwards compatible.
Monday, April 2nd, 2018
Graduating to Grid by Rachel Andrew
When Rachel spoke at An Event Apart last year, grid layout was still on the horizon. Then in March 2017, Chrome, Safari, and Firefox all shipped within weeks of one another. Then at An Event Apart Seattle last year, Edge announced that they were shipping too. So within a very short time, CSS grid got really good browser support.
What’s it like being in the middle of a launch of a big new CSS feature? Very quickly, we had 90% browser support. Suddenly it wasn’t just Jen and Rachel talking about grid—everyone was talking about grid. It involved a lot of email. Alas, Rachel couldn’t answer all those questions (she has a job, after all) but she did start collecting those questions. She found that people were excited, confused, and scared. So much to learn!
Rachel put out a survey and asked “How do you feel when a new CSS feature is announced?” Responses included “Oh, no!” and “Tired.” Some of us in the audience can, no doubt, identify with that.
People started emailing Rachel asking for her blessing. Were they doing the right thing? But Rachel can’t tell you what to do. She’s not in your situation. But she can help you develop the skills to make those decisions yourself. She can offer you confidence. She wants everyone to be the amazing CSS layout person on their team. That’s what this talk is for.
First of all, you need to understand CSS. There’s no shortcut here. But that doesn’t mean you need to learn every single property and value by heart. That’s not what CSS is about. That’s like learning phrases in a foreign language—knowing the words for “coffee” or “beer” doesn’t help you grok the language. It’s the same for CSS. There are some core ideas that help CSS layout make sense. You probably have an understanding of them already, but maybe you don’t have the right words for them.
At the heart of this is the first word in the language we’re talking about: cascading. You need to understand the (much-maligned) cascade. And you can’t talk about the cascade without encountering specificity. The MDN page on the cascade and specificity is a good explanation.
Then there’s dimensions. In any language with a horizontal writing mode, the inline dimension runs left to right or right to left, and the block dimension runs down the page from top to bottom. In vertical writing mode, it’s different.
In grid, we talk about the inline axis as rows, and the block axis as columns.
Sizing matters. It has become obvious that no one understands how big anything is. We’re living in a world where you don’t control the size of things.
In older float-based systems, everything is given a percentage. As long as our percentages don’t exceed 100%, everything’s okay. And we’ve got wrappers to keep things within rows. We end up with something that looks like a grid. It involves us doing a lot of calculating. You can do this with flexbox too, but it’s much the same—figuring out percentages. These past layout methods create the appearance of a grid by lining things up.
With the new layout, we don’t have to do the calculations. We need to understand CSS intrinsic sizing and extrinsic sizing (say that ten times fast).
With a regular
div, you’ve got a block-level element. The box will stretch as far as it will go, to the viewport width by default. You can specify an intrinsic size by saying, say,
width: 500px. That makes 500 pixels wide in the inline direction.
However the content of the box has a size. The maximum size of a string of text is how much space it would take up if it never wrapped. The minimum size is the space it would take up if everything wrapped. Now in CSS we can say
width: min-content or
Let’s say our
div was in a container that had a width of 20em. The
max-content of the contents of the
div (which is more than 20 ems) is wider than the width of the
div and so the content overflows.
In flexbox, let’s say we’ve got a flex container with four items and we’ve declared that each one should take up
max-content. Each item takes up as much space as it needs. Each one uses
max-content as its starting point, and then width is removed to make all four items fit in the container.
flex: 1 1 auto will distribute space according to the content.
flex: 1 1 0 will distribute the space equally (you’re effectively saying that the
max-content is zero).
It’s similar with grid layout but with slight differences. Flexbox is starting from
max-content and taking space away. Grid is starting from
min-content and adding space.
Those content keywords aren’t well supported outside grid layout. They’re safe to use for track sizing.
grid-template-columns: repeat(4, min-content);
That will make everything squished down.
grid-template-columns: repeat(4, max-content);
That one will probably cause an overflow.
grid-template-columns: repeat(4, fit-content(15ch));
That one will make 15 characters an upper limit!
You can make a grid layout using
fr units and
grid-gap. No need for figuring out percentages. You can use percentages if you like though. You can use percentages for gaps, for example.
Remember, you don’t have to stick with a twelve column grid. Slack started with that because it was what they were used to. Then they realised they didn’t have to.
Imagine a media object pattern, where you don’t want the image to ever be bigger than 300 pixels.
grid-template-columns: fit-content(300px) 1fr
As Rachel creates more layouts with grid, she finds she’s using less and less CSS, which is great. The browser is doing the work. That matches the reality of the situation where you don’t know the size of your content in advance—long titles, and so on.
This is not exciting. But it will let you do exciting things. Learning about sizing is the CSS equivalent of eating your vegetables or getting enough sleep.
“Why is all of this so complicated?”, is something Rachel hears a lot. It’s like all software. People want all the features, and they also want it to be easy to use.
More capability and flexibility means more to learn. But it’s worth remembering that you don’t have to learn everything at once. Once you switch your mindset to the grid way of thinking (where you define things on the layout) it gets easier. It’s all just lines.
If you name your grid lines, e.g. “content-start” and “content-end”, you automatically get a named area called “content.”
It works the other way around too. If you create an area called “content”, you automatically get lines named “content-start” and “content-end”.
You don’t have to use any of that. You have real choice for the first time.
A lot of the assumptions we’ve had in the past about what isn’t possible don’t hold up any more. You can now ask, “what’s the best way to do this?” instead of asking “which patterns does our framework give us?”
Well, that’s fine, you might be thinking, for shiny new things. But what if you’re building things that have an old codebase? Rachel asked “How old is the oldest CSS in your project?” in her survey. People have code that’s over ten years old. But old CSS in your codebase doesn’t mean you can’t use new CSS. You can design components or a section of a page using a new technique. This is where understanding CSS comes in really useful—the cascade, especially.
Rachel shows an example of a page made with Bootstrap. She drops a grid component into that layout. It works fine. Nothing explodes. They coexist side by side.
You can create systems with new layout. You’ve got a lot of choice. You can start to make decisions about which layout method works best for different situation. Other layout methods still exist. Don’t try to recreate floats within grid—just use floats. It’s like when we moved from tables for layout, some people went too far and stopped using tables for tabular data. If you need content to flow around an element, float that element. Likewise, if you’re doing layout in just one dimension, you don’t have to use grid; use flexbox.
Off-the-shelf frameworks are designed to solve generic problems. We end up solving problems we don’t have. Do you want your project to inherit the CSS problems of the rest of the world? Solving your specific problems only will result in lighter, easier to understand code.
You don’t need to lean on somebody else’s framework to get reusable code for your project and your team.
What about working with less capable browsers? (these may not always be old browsers). Let’s go back to 2006 and Yahoo’s graded browser support matrix. It was updated quarterly. It was useful. A lot of discussion around browser support was happening with a lack of understanding on one side (bosses, clients) meeting a lack of confidence on the other (developers). Yahoo’s browser support matrix gave us ammunition. If it was okay for Yahoo to say that it was okay for certain browsers to not receive certain features, then that argument was easier to make.
A lot of the discussion now is about older Internet Explorer—IE11 comes up a lot. If IE10 and 11 are your oldest supported versions, you can use the
ms- prefixed grid layout.
Some people are using devices that aren’t updating to new browsers. UC browser for Android is used a lot. It’s very popular in India (35% usage). Many browsers without grid support are mobile browsers, popular in areas where data is expensive.
You can use feature queries to ask if a browser supports a feature before using it. The great thing about doing this is that you are future-proofing: as browsers get support for features, your code works automatically.
You can create complex layouts for browsers that support them with a few lines of CSS. Being able to do new cool stuff is great. Saving developer time is great. But making the web available to everyone …that’s exciting!
To wrap up, Rachel recounts some of the other responses to her survey. People said they were “Excited!”
Wednesday, March 7th, 2018
Everything old is new again—sometimes the age-old technique of using a 1x1 pixel image to log requests is still the only way to get certain metrics.
While tracking pixels are far from a new idea, there are creative ways in which we can use them to collect data useful to developers. Once the data is gathered, we can begin to make much more informed decisions about how we work.
Thursday, December 7th, 2017
These experiments with transitioning variable font styles on hover might be silly, but I can see the potential for some beautiful interaction design.
Monday, July 31st, 2017
A starter kit of CSS that gives you some basic styles that you can tweak with custom properties.
For when you don’t need the whole boot.
I approve this message!
Thursday, June 22nd, 2017
Oh No! Our Stylesheet Only Grows and Grows and Grows! (The Append-Only Stylesheet Problem) | CSS-Tricks
I think Chris is on to something here when he identifies one of the biggest issues with CSS growing out of control:
The developers are afraid of the CSS.
Thursday, May 18th, 2017
Tuesday, May 2nd, 2017
A smart approach to creating patterns as symbols in Sketch. Sounds like diligence and vigilance is required to make it work, but then, that’s true of any pattern library.
Styling the Patterns Day site
Once I had a design direction for the Patterns Day site, I started combining my marked-up content with some CSS. Ironically for an event that’s all about maintainability and reusability, I wrote the styles for this one-page site with no mind for future use. I treated the page as a one-shot document. I even used ID selectors—gasp! (the IDs were in the HTML anyway as fragment identifiers).
The truth is I didn’t have much of a plan. I just started hacking away in a
style element in the
head of the document, playing around with colour, typography, and layout.
I started with the small-screen styles. That wasn’t a conscious decision so much as just the way I do things automatically now. When it came time to add some layout for wider viewports, I used a sprinkling of old-fashioned
display: inline-block so that things looked so-so. I knew I wanted to play around with Grid layout so the
inline-block styles were there as fallback for non-supporting browsers. Once things looked good enough, the fun really started.
I was building the site while I was in Seattle for An Event Apart. CSS Grid layout was definitely a hot topic there. Best of all, I was surrounded by experts: Jen, Rachel, and Eric. It was the perfect environment for me to dip my toes into the waters of grid.
Jen was very patient in talking me through the concepts, syntax, and tools for using CSS grids. Top tip: open Firefox’s inspector, select the element with the
display:grid declaration, and click the “waffle” icon—instant grid overlay!
For the header of the Patterns Day site, I started by using named areas. That’s the ASCII-art approach. I got my head around it and it worked okay, but it didn’t give me quite the precision I wanted. I switched over to using explicit
It’s definitely a new way of thinking about layout: first you define the grid, then you place the items on it (rather than previous CSS layout systems where each element interacted with the elements before and after). It was fun to move things around and not have to worry about the source order of the elements …as long as they were direct children of the element with
Without any support for sub-grids, I ended up having to nest two separate grids within one another. The logo is a grid parent, which is inside the header, also a grid parent. I managed to get things to line up okay, but I think this might be a good use case for sub-grids.
The logo grid threw up some interesting challenges. I wanted each letter of the words “Patterns Day” to be styleable, but CSS doesn’t give us any way to target individual letters other than
:first-letter. I wrapped each letter in a
b element, made sure that they were all wrapped in an element with an
aria-hidden attribute (so that the letters wouldn’t be spelled out), and then wrapped that in an element with an
aria-label of “Patterns Day.” Now I could target those
For a while, I also had a
br element (between “Patterns” and “Day”). That created some interesting side effects. If a
br element becomes a grid item, it starts to behave very oddly: you can apply certain styles but not others. Jen and Eric then started to test other interesting elements, like
hr. There was much funkiness and gnashing of specs.
It was a total nerdfest, and I loved every minute of it. This is definitely the most excitement I’ve felt around CSS for a while. It feels like a renaissance of zen gardens and layout reservoirs (kids, ask your parents).
After a couple of days playing around with grid, I had the Patterns Day site looking decent enough to launch. I dabbled with some other fun CSS stuff in there too, like gratuitous clip paths and filters when hovering over the speaker images, and applying
shape-outside with an image mask.
Go ahead and view source on the Patterns Day page if you want—I ended up keeping all the CSS in the
head of the document. That turned out to be pretty good for performance …for first-time visits anyway. But after launching the site, I couldn’t resist applying some more performance tweaks.
Thursday, April 20th, 2017
A great piece from Danielle on the different mental models needed for different languages. When someone describes a language—like CSS—as “broken”, it may well be that there’s a mismatch in mental models.
CSS isn’t a programming language. It’s a stylesheet language. We shouldn’t expect it to behave like a programming language. It has its own unique landscape and structures, ones that people with programming language mental maps might not expect.
I believe that this mismatch of expectation is what has led to the current explosion of CSS-in-JS solutions. Confronted with a language that seems arbitrary and illogical, and having spent little or no time exposed to the landscape, developers dismiss CSS as ‘broken’ and use systems that either sweep it under the rug, or attempt to force it into alignment with the landscape of a programming language — often sacrificing some of the most powerful features of CSS.
Tuesday, April 4th, 2017