What you see really is what you get. I like this style!
Sunday, June 16th, 2019
Saturday, March 9th, 2019
This is such a great excercise for teaching the separation of structure and presentation—I could imagine using something like this at Codebar.
Thursday, January 31st, 2019
This article by Cassie is so, so good!
First off, there’s the actual practical content on how to change the hover styles of SVGs that aren’t embedded. Then there’s the really clear walkthrough she give, making some quite complex topics very understandable. Finally, there’s the fact that she made tool to illustrate the point!
Best of all, I get to work with the super-smart developer who did all this.
Sunday, January 13th, 2019
You know what I like? Print stylesheets!
I mean, I’m not a huge fan of trying to get the damn things to work consistently—thanks, browsers—but I love the fact that they exist (athough I’ve come across a worrying number of web developers who weren’t aware of their existence). Print stylesheets are one more example of the assumption-puncturing nature of the web: don’t assume that everyone will be reading your content on a screen. News articles, blog posts, recipes, lyrics …there are many situations where a well-considered print stylesheet can make all the difference to the overall experience.
You know what I don’t like? QR codes!
It’s not because they’re ugly, or because they’ve been over-used by the advertising industry in completely inapropriate ways. No, I don’t like QR codes because they aren’t an open standard. Still, I must grudgingly admit that they’re a convenient way of providing a shortcut to a URL (albeit a completely opaque one—you never know if it’s actually going to take you to the URL it promises or to a Rick Astley video). And now that the parsing of QR codes is built into iOS without the need for any additional application, the barrier to usage is lower than ever.
So much as I might grit my teeth, QR codes and print stylesheets make for good bedfellows.
I picked up a handy tip from a Smashing Magazine article about print stylesheets a few years back. You can the combination of a
@media print and generated content to provide a QR code for the URL of the page being printed out. Google’s Chart API provides a really handy shortcut for generating QR codes:
For now, I’ve got the QR code generation happening on The Session for individual discussions, events, recordings, sessions, and tunes. For the tunes, there’s also a separate URL for each setting of a tune, specifically for printing out. I’ve added a QR code there too.
I’ve been thinking about another potential use for QR codes. I’m preparing a new talk for An Event Apart Seattle. The talk is going to be quite practical—for a change—and I’m going to be encouraging people to visit some URLs. It might be fun to include the biggest possible QR code on a slide.
I’d better generate the images before Google shuts down that API.
Monday, December 3rd, 2018
Absolutely spot on! And it cuts both ways:
Saturday, November 10th, 2018
Harry takes a look at the performance implications of loading CSS. To be clear, this is not about the performance of CSS selectors or ordering (which really doesn’t make any difference at this point), but rather it’s about the different ways of getting rid of as much render-blocking CSS as possible.
…a good rule of thumb to remember is that your page will only render as quickly as your slowest stylesheet.
Thursday, August 30th, 2018
font-feature-settings value demonstrated in one single page.
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!