Tags: styling

66

sparkline

Sunday, June 16th, 2019

This page is a truly naked, brutalist html quine.

What you see really is what you get. I like this style!

Thursday, April 18th, 2019

Fading out siblings on hover in CSS | Trys Mudford

Well, the clever CSS techniques just keep on comin’ from Trys—I’m learning so much from him!

Sunday, April 7th, 2019

Drag’n’drop revisited

I got a message from a screen-reader user of The Session recently, letting me know of a problem they were having. I love getting any kind of feedback around accessibility, so this was like gold dust to me.

They pointed out that the drag’n’drop interface for rearranging the order of tunes in a set was inaccessible.

Drag and drop

Of course! I slapped my forehead. How could I have missed this?

It had been a while since I had implemented that functionality, so before even looking at the existing code, I started to think about how I could improve the situation. Maybe I could capture keystroke events from the arrow keys and announce changes via ARIA values? That sounded a bit heavy-handed though: mess with people’s native keyboard functionality at your peril.

Then I looked at the code. That was when I realised that the fix was going to be much, much easier than I thought.

I documented my process of adding the drag’n’drop functionality back in 2016. Past me had his progressive enhancement hat on:

One of the interfaces needed for this feature was a form to re-order items in a list. So I thought to myself, “what’s the simplest technology to enable this functionality?” I came up with a series of select elements within a form.

Reordering

The problem was in my feature detection:

There’s a little bit of mustard-cutting going on: does the dragula object exist, and does the browser understand querySelector? If so, the select elements are hidden and the drag’n’drop is enabled.

The logic was fine, but the execution was flawed. I was being lazy and hiding the select elements with display: none. That hides them visually, but it also hides them from screen readers. I swapped out that style declaration for one that visually hides the elements, but keeps them accessible and focusable.

It was a very quick fix. I had the odd sensation of wanting to thank Past Me for making things easy for Present Me. But I don’t want to talk about time travel because if we start talking about it then we’re going to be here all day talking about it, making diagrams with straws.

I pushed the fix, told the screen-reader user who originally contacted me, and got a reply back saying that everything was working great now. Success!

Friday, March 15th, 2019

BEM: 4 Hang-Ups & How It Will Help Your CSS Organization

A few common gotchas when using BEM, and how to deal with them.

Saturday, March 9th, 2019

Homework I Gave Web Designers - Cloud Four

This is such a great excercise for teaching the separation of structure and presentation—I could imagine using something like this at Codebar.

Thursday, March 7th, 2019

How to become a “Designer who Codes” – Medium

This is such excellent advice for anyone starting out in front-end development:

  1. Get comfortable with the naked internet (sorry, not THAT naked internet)
  2. Build yourself some nice little one-column websites
  3. Learn about layout
  4. Make it work on phones
  5. Make it dynamic

(I would just love it if Meagan were posting this on her own incredibly beautiful website rather than on Ev’s blog.)

Tuesday, March 5th, 2019

Designing Intrinsic Layouts by Jen Simmons

Alright, it’s time for the final talk of day one of An Event Apart in Seattle. The trifecta of CSS talks is going to finish with Jen Simmons talking about Designing Intrinsic Layouts. Here’s the description:

Twenty-five years after the web began, we finally have a real toolkit for creating layouts. Combining CSS Grid, Flexbox, Multicolumn, Flow layout and Writing Modes gives us the technical ability to build layouts today without the horrible hacks and compromises of the past. But what does this mean for our design medium? How might we better leverage the art of graphic design? How will we create something practical, useable, and realistically doable?

In a talk full of specific examples, Jen will walk you through the thinking process of creating accessible & reusable page and component layouts. For the last four years, Jen’s been getting audiences excited about what, when, and why. Now it’s time for how.

I’m not sure if live-blogging is going to work given the visual nature of this talk, but I’ll give it a try…

How many of us have written CSS using display: grid? Quite a few. How many people feel they have a good grip on it? Not so many.

Jen has spent the last few years encouraging people to really push the boundaries of graphic design on the web now that we have the tools to do so in CSS. But Jen is not here today to talk about amazing new things. Instead she’s going to show the “how?” The code is on labs.jensimmons.com.

Let’s look at laying out a header. You might have a header element with a logo image, the site name in an h1, and a nav element with the navigation. The logo, the site name, and the navigation are direct children of the parent header. By default we get everything stacked vertically.

<header role="banner">
    <img class="logo" src="..." alt="...">
    <h1>Site title</h1>
    <nav>
        <ul>
            <li><a href="...">Home</a></li>
            <li><a href="...">Episodes</a></li>
            <li><a href="...">Guests</a></li>
            <li><a href="...">Subscribe</a></li>
            <li><a href="...">About</a></li>
        </ul>
    </nav>
</header>

Why should we care about starting with semantic HTML? It matters for reusability and accessibility, but also for reader modes in browsers. These tools remove the cruft. If you mark up your content well, it will play nicely with reader modes. Interestingly, there are no metrics around how many people are using reader modes (by design). Mozilla has a product called Pocket that’s a “read later” app. It can also turn saved articles into a podcast for you. Well marked up content matters for audio playback.

Now let’s start applying some CSS. Fonts, colours, stuff like that. Everything is still stacking vertically though. It’s flow content. This can be our fallback layout. Now let’s apply our own layout. We could use float: left on the logo. Now we need some margins. We can try applying widths and floats to the h1 and the nav. Now we need a clearfix to get the parent to stretch to the full height of the content. It’s hacky. floats suck. But it’s all we had until we got flexbox. But even using flexbox for this kind of layout is a hack too. What we really need is CSS grid.

Apply display: grid to the header. Use Firefox’s dev tools to inspect the grid. Seeing the grid helps in understanding what’s going on. We’ve got three grid items in three separate rows. Notice that we don’t have margin collapsing any more. We can get rid of margins and use grid-gap instead. But we want is three columns, not three rows. We’ll try:

grid-template-columns: 1fr 1fr 1fr;

Looks okay. Not exactly the spacing we want though. We want the logo and the navigation to take up less space than the site name. We could translate our old percentage values into fr equivalents. 8% becomes 8fr. 75% becomes 75fr. 17% becomes 17fr. But the logo and the nav never shrink below their actual size. Layout isn’t working like we’re used to. The content will never get smaller than the minimum content size. So the amount of space assigned to each column is no longer linear.

Let’s change those fr units to percentages. Now we need to get rid of our gaps. But now when the layout gets small, everything squishes up. This is what we need breakpoints for. But now we can do something else. Let’s make the logo max-content. That column will now be the size of the logo. The other columns can remain `fr:

header {
    grid-template columns: max-content 3fr 1fr;
}

Let’s also define the last one—the navigation—as max-content. We can toss auto in for the middle content (the site name):

header {
    grid-template columns: max-content auto max-content;    }

Let’s layout the navigation horizontally. The best tool for this is flexbox. The li elements are the flex items. So the ul needs to be the flex container.

ul {
    display: flex;
}

Looking good. Let’s allow items to wrap onto another line:

ul {
    display: flex;
    flex-wrap: wrap;
}

Let’s change that navigation from max-content to auto so that it doesn’t get too long:

header {
    grid-template columns: max-content auto auto;   }

(How you want the navigation items to wrap determines whether you use flexbox or grid. Both are perfectly valid choices. There’s nothing wrong with using grid for the small stuff.)

Just look at how little code we need for this layout!

Let’s try a different layout. We’ll put the navigation on a new row.

header {
    grid-template-columns: min-content auto;
    grid-template-rows: auto auto
}

Let’s get the logo to span across both rows:

.logo {
    row-span: 2;
}

Need to finesse the alignment of the navigation? No problem. Play with align-self property on the nav element.

Again, look at how little code this is!

But these layouts are safe. We need to break out of our habits. What about disjointed text? Let’s take the h1. Apply some typography and colour. Also apply overflow-wrap: anywhere. Now the text can break within words.

We can take this further. But to do that, we have to wrap all of my letters in separate spans. Yuck!

Apply display: grid to the h1 that contains all those span children. Say grid-template-columns: repeat(8, 1fr) to make an eight-column repeating grid.

Let’s make it more interesting. We can target each individual letter with grid-column and grid-row. There are many ways to tell the browser where to place grid items. We can tell them the start lines. By default it will take up one cell.

Let’s add some images. Let’s rotate items. Place items wherever we want them. Mess around with the units to see what happens. Play with opacity when elements overlap. See the possibilities!

But, people cry, what about Internet Explorer? Use @supports

/* code for every browser */

@supports (display: grid) {
    /* code for modern browsers */
}

Set up a fallback outside the @supports block. Toggle grid on and enough in dev tools to see how the fallback will look. If this kind of thinking is new to you, please watch youtube.com/layoutland where Jen talks about resilient CSS.

Let’s try something else. Jen got an email announcement for an event. It had an interesting bit of layout with some text overlapping an image.

Mark up the content: some headings and images. By default the images are displayed inline. The headings are displayed as blocks.

Think about where your grid lines will need to go. How many lines will you need? How about setting your columns with 1fr 3fr 3fr 1fr? Now how many rows do you need? You define and the grid on the container and tell the items where to go. Again, it’s not much code. Tweak it. How about setting the columns to be 1fr minmax(100px, 400px) min-content? You have to mess around to see what’s possible. You can use all sorts of units for columns: fixed lengths (pixels, ems, rems), min-content, max-content, percentages, fr units, minmax(), and auto. Play around with the combinations.

Jen shows a whole bunch of her demos. Check them out. Use web inspector to play around with them.

And with that, the first day of An Event Apart Seattle is done!

Making Things Better: Redefining the Technical Possibilities of CSS by Rachel Andrew

The CSStastic afternoon of day one of An Event Apart in Seattle continues with Rachel Andrew. Her talk is Making Things Better: Redefining the Technical Possibilities of CSS. The description reads:

For years we’ve explained that the web is not like print; that a particular idea is not how things work on the web; that certain things are simply not possible. Over the last few years, rapid browser implementation of advances in CSS have given us the ability to do many of these previously impossible things. We can use our new powers to build the same designs faster, or we can start to ask ourselves what we might do if we were solving these problems afresh.

In this talk, Rachel will look at the things coming into browsers right now which change the way we see web design. CSS subgrids allowing nested grids to use the track definition of their parent; logical properties and values moving the web away from the physical dimensions of a computer screen; screen experiences which behave more like an app, or even paged media, due to scroll snapping and multidimensional control. By understanding the new medium of web design we can start to imagine the future, and even help to shape it.

I’m not sure if it even makes sense to try to live-blog a code talk, but I’ll give it my best shot…

Rachel has been talking about CSS at An Event Apart for over three years now. Our understanding of the possibilities of CSS has changed a lot in that time. Our use of floats for layout is being consigned to history. It’s no less monumental than the change from tables to CSS. Tableless web design often meant simplifying our designs. We were used to designing in a graphic design tool and then slicing it up into table cells. CSS couldn’t give us the same fine-grained control so we simplified our designs. It got us to start thinking of the web as its own medium. That idea really progressed with responsive web design.

But perhaps us CSS advocates downplayed some of the issues. We weren’t trying to create new CSS, we were just trying to get people to use CSS.

What we term “good web design” is based in the technical limitations of CSS. We say “the web is not print” when we see a design that’s quite print-like. People expect to have to hack at CSS to get it to do what we want. But times have changed. We have solved many of those problems (but that doesn’t mean we got all of them!).

Rachel spends a lot of time telling designers: you never know how tall anything is on the web. It used to be a real challenge to get the top and bottom of boxes to line up. We’d have to fix the height of the boxes. And if too much content goes in, the content overflows. Then we end up limiting the amount of content at the CMS side. We hacked around the problem. A technical limitation influenced our design, and even our content management. Then we got flexbox. Not only did the problem disappear, but the default behaviour is exactly what we struggled with for years: equal height columns.

How big is this box? You’ve seen the “CSS is awesome mug”, right?

Our previous layout systems relied on percentage lengths for widths. Those values had to add up to 100%, and no more. People tried to do the same thing with flexbox. People made “grid systems” with flexbox that gave widths to everything. “Flexbox is weird!”, people said. But the real problem is that flexbox is not the layout method you think it is. It’s for taking a bunch of oddly-sized things and returning the most reasonable layout for those things. It assigns space in a smart way. That solves the problem of needing to give everthing a width. It figures it out for you. If you decide to put widths on everything, you’re kind of working against flexbox.

We’re so used to having to hack everything in CSS, we had to take a step back with flexbox and realise that hacks aren’t necessary.

CSS tries to avoid data loss. That’s why the “CSS is awesome” text overflows the box. You don’t want the text to vanish. Visible overflow is messy, but it’s better than making some content disappear.

In the box alignment specification, there’s the concept of safe and unsafe alignment. Safe:

.container {
    display: flex;
    flex-direction: column;
    align-items: safe center;
}

You give the browser permission to align items to the start if necessary. But you can override that with unsafe:

.container {
    display: flex;
    flex-direction: column;
    align-items: unsafe center;
}

Overflow is going to happen. Now it’s up to you what happens when it does.

The “content honking out of the box” problem described in the “CSS is awesome” meme is now controlled with min-content:

width: min-content;

The box expands to encompass the widest content.

You have many choices. But what if the text isn’t running left to right? It might not be a problem we run into for English text. For years, CSS had that English-centric assumption baked in. Now CSS has been updated to not make that assumption. The web is not left to right. Flexbox and grid take an agnostic approach to the writing mode of the document. There’s no “top”, “bottom”, “left” or “right”. There’s “start”, “end”, “inline” and “block”. Now we have a new spec for logical properties and values. It maps old physical values (top, bottom, etc.) to the newer agnostic values.

So even if you use writing-mode to flip direction, width is still a width. Use inline-size instead of width and everything keeps working: the width maps to height when you apply a different writing-mode value. Eventually we’ll use those flow-relative values more than the old values. Solutions need to include different writing modes.

There is no fold. We’ve said that for years, right? But we know where the fold is. We’ve got viewport units that represent the width and height of the browser viewport. We can start to make designs that make use of the viewport. You can size a screen full of images exactly to fit the visible space. Combine it with scroll-snap to get the page views to snap as the user scrolls. You get paged layout. That’s interesting for Rachel because she’s used to designing for paged layout in print versus continuous layout on the web.

What’s next for CSS grid? Grid layout has been the biggest problem-solver of recent years. But that doesn’t mean it has solved all the layout problems. New problems appear as we start to work with CSS grid. We often end up nesting grids. But the nested grids don’t have any knowledge of one another. We’re back to: you never know how tall things are on the web. We need a way to have a relationship. Some kind of, I don’t know, subgrid.

You could use display: contents. It removes a box from the visual display allowing grandchildren to act like children. The browser support is good, but there’s a stonking accessibility bug so don’t use it in production. Also you can’t apply visual styles to anything that’s got display: contents on it. But grid-template-rows: subgrid will solve this problem. The spec is in a good shape. We’re waiting for the first browser implementations.

You will hit problems. Find new technical limitations. It’s just that we can’t do that stuff yet. We get the new stuff when we create it. Write up the problems you come across.

We’re finding the edges. Rachel is going to share her problems.

Rachel wants to put some text into her image grid. No problem. But then if there’s too much text, it might not fit in a height-restricted row. We can adjust the row to not be height-restricted, but then we lose the nice viewport-fitting layout.

In continuous media—which is what the web is—content inside multicol gets longer and longer. You can fix the height of the container but then the columns get created horizontally. What if you could say, I want my multicol container to be, say 100vh high, but if the content overlows, create a new 100vh high container below. Overflow in the block dimension. Maybe that’ll be in the next version of the multicol spec.

Multicol doesn’t solve Rachel’s image grid situation. What she needs is a way for the text to fill up a box and then flow into another box. The content needs to be semantically marked up—not broken into separate chunks for layout—and we want the browser to figure out where to break that content and fill up available space.

It comes as a surprise to people that a lot of paged media—books, magazines—are laid out with CSS. It’s in the paged media module. Prince is a good example of a user agent that supports paged media. There’s the concept of a page box: a physical page into which content can go. You get to define the boxes with physical dimensions like inches or centimeters. You create a bunch of margin boxes with generated content. Enough pages are created to hold all the content. You create your page model and flow the content through it.

Maybe apps and websites with defined screens are not that different from paged contexts. There have been attempts to create CSS specs that would allow this kind of content-flowing behaviour. CSS regions was one attempt. There was -ms-flow-into and -ms-flow-from in the IE and Edge implementations. You had to apply -ms-flow-into to an iframe element.

Regions needs ready-prepared boxes for the content to flow into. But how can you know how many boxes to prepare in advance? You don’t know how big things will be on the web. Rachel has been told that there’s nothing wrong with the CSS regions spec because you can define a final bucket for all leftover content. That doesn’t seem like a viable solution.

CSS regions predated CSS grid and didn’t take off. Now that we’ve got grid, something like regions makes a lot of sense.

Web design has been involved in a constant battle with overflow. Whether it’s overflowing boxes, or there (not) being a fold, or multicol layout. Rachel thinks we can figure out a way to get regions to work. Perhaps regions paved the way for something better. Maybe it was just ahead of its time. There are a lot of things hidden away in CSS specs that never made it out: things that didn’t make sense until more advanced CSS came along.

Regions—like multicol—relies on fragmentation. Ever tried to stop a heading behind the last thing on a page in a print stylesheet? We need good support for break-inside, break-before, and break-after.

We create new things to solve problems. Maybe you don’t see the value of something like regions, but I bet there’s been something where you thought “I wish CSS could do this!”.

Rob wrote up a problem that he had with trying to have a floated element maintain its floatiness inside a grid. He saw it as a grid problem. Rachel saw it as an exclusions problem. Rob’s write-up was really valuable to demonstrate the need for exclusions. Writing things up is hugely valuable for pushing things forward. Write up your ideas—they’ll show us the use case.

Ask “why can’t I do that?” Let’s not fall into the temptation of making things grid-like just because we have CSS grid now. Keep pushing at the boundaries.

Many of things Rachel has shown—grid, exclusions, regions—were implemented by Microsoft. With Edge moving to a Chromium rendering engine, we must make sure that we maintain diversity of thought in the standards process. Voices other than those of rendering engines need to contribute to the discussion.

At a W3C meeting or standards discussion, the room should not be 60-70% Googlers.

More than ever, the web needs diversity of thought. Rachel isn’t having a dig at Google. This isn’t a fight between good and evil. It’s a fight against any monoculture. So please contribute. Get involved. Together we can work for the future of the web platform.

Monday, March 4th, 2019

Generation Style by Eric Meyer

It’s time for the afternoon talks at An Event Apart in Seattle. We’re going to have back-to-back CSS, kicking off with Eric Meyer. His talk is called Generation Style. The blurb says:

Consider, if you will, CSS generated content. We can, and sometimes even do, use it to insert icons before or after pieces of text. Occasionally we even use it add a bit of extra information. And once upon a time, we pressed it into service as a hack to get containers to wrap around their floated children. That’s all fine—but what good is generated content, really? What can we do with it? What are its limitations? And how far can we push content generation in a new landscape full of flexible boxes, grids, and more? Join Eric as he turns a spotlight on generated content and shows how it can be a generator of creativity as well as a powerful, practical tool for everyday use.

Wish me luck, ‘cause I’m going to try to capture the sense of this presentation…

So we had a morning of personas and user journeys. This afternoon: code, baby! Eric is going to dive into a very specific corner of CSS—generated content. For an hour. Let’s do it!

He shows the CSS Generated Content Module Level 3. Eric wants to focus on one bit: the pseudo-elements ::before and ::after. What does pseudo-element mean?

You might have used one of these pseudo-elements for blockquotes. Perhaps you’ve put a great big quotation mark in front of them.

blockquote:: after {
    content: "“";
    font-size: 4em;
    opacity: 0.67;
/* placement styles here */
}

Why is Eric using ::after? Because you can. You can put the ::after content wherever you want. But if your placement styles fail, this isn’t a good place for the generated content. So don’t do this. Use ::before.

Another example of using generated content is putting icons beside certain links:

a[href$=".pdf"]::after {
    content: url(i/icon.png);
    height: 1em;
    margin-right: 0.5em;
    vertical-align: top;
}

But these icons look yucky. But if you use larger images, they will be shown full size. You only have so much control over what happens in there. I mean, that’s true of all CSS: think of CSS as a series of strong suggestions. But here, we have even less control than we’re used to. Why isn’t the image 1em tall like I’ve specified in the CSS? Well, the generated content box is 1em tall but the image is breaking out of this box. How about this:

a[href]::after * {
    max-width: 100%;
    max-height: 100%
}

This doesn’t work. The image isn’t an element so it can’t be selected for.

The way around it is to use background images instead:

a[href$=".pdf"]::after {
    content: '';
    height: 1em; width: 1em;
    margin-right: 0.5em;
    vertical-align: top;
    background: center/contain;
    background-image: url(i/icon.png);
}

Notice there’s a right margin there. That stretches out the width of the whole link. That’s exactly the same as if there were an actual span in there:

a[href$=".pdf"] span {
    height: 1em; width: 1em;
    margin-right: 0.5em;
    vertical-align: top;
    background: center/contain;
    background-image: url(i/icon.png);
}

So why use generated content instead of a span? So that you don’t have to put extra spans in your markup.

Generated content is great for things that work great when they’re there, but still work fine if they’re not. It’s progressive enhancement.

You’ve almost certainly used generated content for the clearfix hack.

.clearfix::after {
    content: '';
    display: table;
    clear: both;
}

Ask your parents. It’s when we wanted to make the containing element for a group of floating elements to encompass the height of those elements. Ancient history, right? Well, Eric is showing an example of a certain large media company today. There are a lot of clearfixes in there.

Eric makes the clearfix visible:

.clearfix::after {
    content: '';
    display: table;
    clear: both;
    border: 10px solid purple;
}

It looks like a span: a 10 pixel wide box. Now change the display property:

.clearfix::after {
    content: '';
    display: block;
    clear: both;
    border: 10px solid purple;
}

Now it behaves more like a div than a span.

The big question here is: who cares?

Let’s say we’re making a site about corduroy pillows (I hear they’re really making headlines).

<header>
<h1>Corduroy pillows</h1>
<p>Lorum ipsum...</p>
</header>

We can add a box under the header:

header::after {
    content: " ";
    display: block;
    height: 1em;
}

You can do stuff with that extra content, like using a linear gradient:

header::after {
    content: " ";
    display: block;
    height: 1em;
    background: linear-gradient(to right, #DDD, #000, #DDD) center / 100% 1px no-repeat;
}

The colour stops are #DDD, #000, and #DDD. You get this nice gradiated line under the header. You can chain a bunch of of radial gradients together to get some nice effects. You could mix in some background images too. Now you’ve got some on-brand separators. You could use generated content to add some “under construction” separators.

By the way, ever struggled to keep track of the order of backgrounds? Think about how you would order layers in Photoshop.

How about if we could use generated content to make design tools?

div[id]::before {
    content: attr(id);
}

Now the generated content is taken from the id attribute. You can make it look like Firebug:

div[id]::before {
    content: '#' attr(id);
    font: 0.75rem monospace;
    position: absolute;
    top: 0;
    left: 0;
    border: 1px dashed red;
    padding: 0 0.25em;
    background: #FFD;
}

You can even make the content cover the whole box with bottom and right values too:

div[id]::before {
    content: '#' attr(id);
    font: 0.75rem monospace;
    position: absolute;
    top: 0;
    left: 0;
    bottom: 0;
    right: 0;
    border: 1px dashed red;
    padding: 0 0.25em;
    background: #FFD8;
}

(And yes, that is a hex value with opacity.)

Let’s make it less code-y:

div[id]::before {
    content: attr(id);
    font: bold 1.5rem Georgia serif;
    position: absolute;
    top: 0;
    left: 0;
    bottom: 0;
    right: 0;
    border: 1px dashed red;
    padding: 0 0.25em;  
    background: #FFD8;
}

Throw in some text-shadow. Maybe some radial gradients. We’re at the wireframe stage. Let’s drop in some SVG images to show lines across the boxes.

How about automating design touches?

pre {
    padding: 0.75em 1.5em;
    background: #EEE;
    font: medium Consolas, monospace;
    position: relative;
}

Let’s say that applies to:

<pre class="css">
...
</pre>

You can generate labels with that class attribute:

pre::before {
    content: attr(class);
    display: block;
    padding: 0.25em 0 0.15em;
    font: bold 1em Noah, sans-serif;
    text-align: center;
    text-transform: uppercase;
}

Let’s align it to the top of it’s parent with negative margins:

pre::before {
    content: attr(class);
    display: block;
    padding: 0.25em 0 0.15em;
    margin: -0.75em -1.5em 1em;
    font: bold 1em Noah, sans-serif;
    text-align: center;
    text-transform: uppercase;
}

Or you can use absolute positioning:

pre::before {
    content: attr(class);
    display: block;
    padding: 0.25em 0 0.15em;
    position: absolute;
    top: 0;
    right: 0;
    left: 0;
    font: bold 1em Noah, sans-serif;
    text-align: center;
    text-transform: uppercase;
}

Now let’s change the writing mode:

pre::before {
    content: attr(class);
    display: block;
    padding: 0.25em 0 0.15em;
    position: absolute;
    top: 0;
    right: 0;
    bottom: 0;
    writing-mode: vertical-rl;
    font: bold 1em Noah, sans-serif;
    text-align: center;
    text-transform: uppercase;
}

Now the text is running down the side, but it’s turned on its side. You can transform it:

pre::before {
    content: attr(class);
    display: block;
    padding: 0.25em 0 0.15em;
    position: absolute;
    top: 0;
    right: 0;
    bottom: 0;
    writing-mode: vertical-rl;
    transform: rotate(180deg);
    font: bold 1em Noah, sans-serif;
    text-align: center;
    text-transform: uppercase;
}

But if you this, be careful. Your left margin is no longer on the left. Everything’s flipped around.

You could also update the generated content according to the value of the class attribute:

pre.css:: before {
    content: '{ CSS }';
}

pre.html::before {
    content: '< HTML >';
}

pre.js::before,
pre.javascript::before {
    content: '({ JS })();';
}

It’s presentational, so CSS feels like the right place to do this. But you can’t generate markup—just text. Angle brackets will be displayed in their raw form.

But positioning is so old-school. Let’s use CSS grid:

pre {
    display: grid;
    grid-template-columns: min-content 1fr;
    grid-gap: 0.75em;
}

pre::before {
    content: attr(class);
    margin: -1em 0;
    padding: 0.25em 0.1em 0.25em 0;
    writing-mode: vertical-rl;
    transform: rotate(180deg);
    font: bold 1em Noah, sans-serif;
    text-align: center;
    text-transform: uppercase;
}

Heck, you could get rid of the negative margins by putting the code content inside a code element and giving that a margin of 1em.

You can see generated content in action on the website of An Event Apart:

li.news::before {
    content: attr(data-cat);
    background-color: orange;
    color: white;
}

The data-cat attribute (which contains a category value) is displayed in the generated content.

Cool. That’s all stuff we can do now. What about next?

Well, suppose you had to put some legalese on your website. You could generate the numbers of nested sections:

h1 { counter-reset: section; }
h2 { counter-reset: subsection; }

Increment the numbers each time:

h2 { counter-increment: section; }
h3 { counter-increment: subsection; }

And display those values:

h2::before {
    content: counter(section) ".";
}
h2::before {
    content: counter(section) counter ":" (subsection, upper-roman);
}

Soon you’ll be able to cycle through a list of counter styles of your own creation with a @counter-style block.

But remember, if you really need that content to be visible for everyone, don’t rely on generated content: put it in your markup. It’s for styles.

So, generated content. It’s pretty cool. You can do some surprising things with it. Maybe ::before this talk, you didn’t think about generated content much, but ::after this talk ,you will.

Saturday, February 9th, 2019

Proper UI hierarchy · accssible

Bringing gradients back, baby!

This is going to be a handy reference to keep on hand whenever you want a button to actually look like a button.

CSS Remedy

This is a really interesting approach that isn’t quite a CSS reset or a normalisation. Instead, it’s an experiment to reimagine what a default browser stylesheet would be like if it were created today, without concerns about backwards compatibility:

Applies basic styling to form elements and controls, getting you started with custom styling. We want to find the balance between providing a base for implementing a custom design, and allowing OS-level control over how form inputs work (like how a number pad works on iOS).

Provides a very lightweight starter file, with generic visual styling that you will want to replace. This isn’t as robust or opinionated as a starter-theme or framework. We’ve leaned toward specifying less, so you have less to override. (We haven’t defined any font families, for example.)

You can contribute by adding issues.

Wednesday, January 16th, 2019

Use the :lang pseudo-class over the lang attribute selector for language-specific styles

This is a great explanation of the difference between the [lang] and :lang CSS selectors. I wouldn’t even have thought’ve the differences so this is really valuable to me.

Monday, January 14th, 2019

Sunday, January 13th, 2019

The Flexbox Holy Albatross | HeydonWorks

Er …I think Heydon might’ve cracked it. And by “it”, I mean container queries.

This is some seriously clever thinking involving CSS custom properties, calc, and flexbox. The end result is a component that can respond to its container …and nary a media query in sight!

Wednesday, January 9th, 2019

CSS doesn’t suck - Andy Bell

It’s getting exhausting spending so much of my time defending one of the three pillars of the web: CSS. It should sit equal with HTML and JavaScript to produce accessible, progressively enhanced websites and web apps that help everyone achieve what they need to achieve.

Saturday, December 29th, 2018

Making single color SVG icons work in dark mode

Another good reason to use the currentColor value in SVGs.

Friday, November 23rd, 2018

When to use CSS vs. JavaScript | Go Make Things

Chris Ferdinandi has a good rule of thumb:

If something I want to do with JavaScript can be done with CSS instead, use CSS.

Makes sense, given their differing error-handling models:

A JavaScript error can bring all of the JS on a page to screeching halt. Mistype a CSS property or miss a semicolon? The browser just skips the property and moves on. Use an unsupported feature? Same thing.

But he also cautions against going too far with CSS. Anything to do with state should be done with JavaScript:

If the item requires interaction from the user, use JavaScript (things like hovering, focusing, clicking, etc.).

‘Sfunny; I remember when we got pseudo-classes, I wrote a somewhat tongue-in-cheek post called :hover Considered Harmful:

Presentation and behaviour… the twain have met, the waters are muddied, the issues are confused.

Saturday, November 10th, 2018

CSS Frameworks Or CSS Grid: What Should I Use For My Project? — Smashing Magazine

Rachel does some research to find out why people use CSS frameworks like Bootstrap—it can’t just be about grids, right?

It turns out there are plenty of reasons that people give for using frameworks—whether it’s CSS or JavaScript—but Rachel shares some of my misgivings on this:

In our race to get our site built quickly, our desire to make things as good as possible for ourselves as the designers and developers of the site, do we forget who we are doing this for? Do the decisions made by the framework developer match up with the needs of the users of the site you are building?

Not for the first time, I’m reminded of Rachel’s excellent post from a few years ago: Stop solving problems you don’t yet have.

Friday, November 2nd, 2018

The CSS Working Group At TPAC: What’s New In CSS? — Smashing Magazine

Rachel gives us the run-down on what’s coming soon to Cascading Style Sheets near you, including an aspect-ratio unit and a matches selector (as originally proposed by Lea).

Saturday, October 6th, 2018

An nth-letter selector in CSS

Variable fonts are a very exciting and powerful new addition to the toolbox of web design. They was very much at the centre of discussion at this year’s Ampersand conference.

A lot of the demonstrations of the power of variable fonts are showing how it can be used to make letter-by-letter adjustments. The Ampersand website itself does this with the logo. See also: the brilliant demos by Mandy. It’s getting to the point where logotypes can be sculpted and adjusted just-so using CSS and raw text—no images required.

I find this to be thrilling, but there’s a fly in the ointment. In order to style something in CSS, you need a selector to target it. If you’re going to style individual letters, you need to wrap each one in an HTML element so that you can then select it in CSS.

For the Ampersand logo, we had to wrap each letter in a span (and then, becuase that might cause each letter to be read out individually instead of all of them as a single word, we applied some ARIA shenanigans to the containing element). There’s even a JavaScript library—Splitting.js—that will do this for you.

But if the whole point of using HTML is that the content is accessible, copyable, and pastable, isn’t a bit of a shame that we then compromise the markup—and the accessibility—by wrapping individual letters in presentational tags?

What if there were an ::nth-letter selector in CSS?

There’s some prior art here. We’ve already got ::first-letter (and now the initial-letter property or whatever it ends up being called). If we can target the first letter in a piece of text, why not the second, or third, or nth?

It raises some questions. What constitutes a letter? Would it be better if we talked about ::first-character, ::initial-character, ::nth-character, and so on?

Even then, there are some tricksy things to figure out. What’s the third character in this piece of markup?

<p>AB<span>CD</span>EF</p>

Is it “C”, becuase that’s the third character regardless of nesting? Or is it “E”, becuase techically that’s the third character token that’s a direct child of the parent element?

I imagine that implementing ::nth-letter (or ::nth-character) would be quite complex so there would probably be very little appetite for it from browser makers. But it doesn’t seem as problematic as some selectors we’ve already got.

Take ::first-line, for example. That violates one of the biggest issues in adding new CSS selectors: it’s a selector that depends on layout.

Think about it. The browser has to first calculate how many characters are in the first line of an element (like, say, a paragraph). Having figured that out, the browser can then apply the styles declared in the ::first-line selector. But those styles may involve font sizing updates that changes the number of characters in the first line. Paradox!

(Technically, only a subset of CSS of properties can be applied to ::first-line, but that subset includes font-size so the paradox remains.)

I checked to see if ::first-line was included in one of my favourite documents: Incomplete List of Mistakes in the Design of CSS. It isn’t.

So compared to the logic-bending paradoxes of ::first-line, an ::nth-letter selector would be relatively straightforward. But that in itself isn’t a good enough reason for it to exist. As the CSS Working Group FAQs say:

The fact that we’ve made one mistake isn’t an argument for repeating the mistake.

A new selector needs to solve specific use cases. I would argue that all the letter-by-letter uses of variable fonts that we’re seeing demonstrate the use cases, and the number of these examples is only going to increase. The very fact that JavaScript libraries exist to solve this problem shows that there’s a need here (and we’ve seen the pattern of common JavaScript use-cases ending up in CSS before—rollovers, animation, etc.).

Now, I know that browser makers would like us to figure out how proposed CSS features should work by polyfilling a solution with Houdini. But would that work for a selector? I don’t know much about Houdini so I asked Una. She pointed me to a proposal by Greg and Tab for a full-on parser in Houdini. But that’s a loooong way off. Until then, we must petition our case to the browser gods.

This is not a new suggestion.

Anne Van Kesteren proposed ::nth-letter way back in 2003:

While I’m talking about CSS, I would also like to have ::nth-line(n), ::nth-letter(n) and ::nth-word(n), any thoughts?

Trent called for ::nth-letter in January 2011:

I think this would be the ideal solution from a web designer’s perspective. No javascript would be required, and 100% of the styling would be handled right where it should be—in the CSS.

Chris repeated the call in October of 2011:

Of all of these “new” selectors, ::nth-letter is likely the most useful.

In 2012, Bram linked to a blog post (now unavailable) from Adobe indicating that they were working on ::nth-letter for Webkit. That was the last anyone’s seen of this elusive pseudo-element.

In 2013, Chris (again) included ::nth-letter in his wishlist for CSS. So say we all.