For some reason this week I’ve been returning to the very basics of HTML and CSS, going over a lot of blog posts that remind me that there’s still some gaps I have in my knowledge when it comes to the foundations of web design. For example, back in May, Florens Verschelde wrote this great piece about styling buttons the right way and how to avoid all the common mistakes. Resetting the styles to make buttons look like links, and then adding hover, focus, and active states to make things look a bit snazzier.

On that note, Chris wrote a while back about the importance of :focus states:

Always worth repeating: all interactive elements should have a focus style. That way, a keyboard user can tell when they have moved focus to that element.

I feel like a lot of designers and developers hate :focus states. I’ve worked with folks who hate them and then whenever I need to use a keyboard to tab through an interface on the web I find it difficult to see the highlight. But :focus states should be gigantic and eye-catching, that’s really what’s best for usability.

The problem with CSS was that whenever you used :focus like this:

a:focus { background-color: blue; }

…it meant that when you clicked that link with a mouse or with your finger on a touch screen you’d see the focus state. And a lot of folks hated that. But now it’s possible to only make these styles apply to keyboard-focused elements with the :focus-visible pseudo. So you can write something like this:

/* Focusing the button with a keyboard will show a dashed black line. */ button:focus { outline: 4px dashed black; } /* Focusing the button with a mouse, touch, or stylus will show a subtle drop shadow. */ button:focus:not(:focus-visible) { outline: none; box-shadow: 1px 1px 5px rgba(1, 1, 0, .7); }

That :focus:not(:focus-visible) bit is a really smart hack for only applying these styles to mouse or touch clicks. And it’s a hack that has pretty okay-ish browser support, too.

[Chris]: All this focus stuff is a mind trip for me. I had to create a test page to wrap my mind around it all. It really is a clever trick to combine :focus and :focus:not(:focus-visible)so you can style keyboard focus and mouse focus differently, while not losing those keyboard focus styles in non-supporting browsers. In the future, if :focus-visible becomes perfectly supported and you’re in a position where you want keyboard-focus-only styles, you could only use :focus-visible, but that’s a lot of maybes.

[Chris]: Another thing worth mentioning. If you’re on a Mac and you are testing keyboard focus stuff, but aren’t a huge keyboard focus use yourself, you might have an OS setting you need to change. Go to System Preferences > Keyboard > Shortcuts and at the bottom there is a checkbox for “Use keyboard navigation to move focus between controls”. Browsers are starting to honor that, meaning keyboard tabbing might not work how you think it should if this setting isn’t on.

[Robin]: Earlier this week I stumbled upon a problem where the only solution I could think of was a hypothetical one: an :nth-letter selector in CSS. It would work something like this:

.element:nth-letter(2) { color: red; }

Similar to :nth-child, the CSS above would make the second letter in that word red. Yet, today no such thing exists, unfortunately. A while back Jeremy Keith wrote why he believes :nth-letter would be so darn useful and you’ve likely experienced this limitation, too. One common example is when you want to edit big display titles on a website, let’s say something like this:

Imagine we want to change the color of each of these letters in this word. Perhaps the best solution would be to make it an SVG or to wrap each letter in a span like this:

<h1> <span>r</span> <span>a</span> <span>i</span> <span>n</span> <span>b</span> <span>o</span> <span>w</span> <span>!</span> </h1>

Pretty gross, right? It’s a shame that we have to mess up the markup simply to make a relatively simple aesthetic change.

Since we’ve been so very lucky with properties in CSS, I feel like this is now at the top of my CSS wishlist. It’s one of the few remaining challenges that have stuck around in web development since before I started and fixing it would help us make micro-typographic changes to the characters in a word or in a paragraph whilst encouraging folks to think about text in a different way on the web.

[Chris]: Ten years ago (2011), I wrote A Call for ::nth-everything. Not just letters, but words and lines too. Maybe even sentences. Wondering about use cases? Well, anything that uses Splitting.js for one (here’s a collection of demos).

Last I heard, I think the danger/pushback on all this is other languages. Like, there are some languages where one character also represents a word or phrase, so how do you design a feature like this that isn’t too biased toward English, and similarly-featured languages?

I believe the danger of the <span>s that Robin posted above is that screen readers (some, anyway?) read each of those characters with pauses in between, rather than just speaking “rainbow.” So, if you really want to do that to get the style, maybe try:

<h1> <span class="visually-hidden">rainbow</span> <span aria-hidden="true"> <span>r</span> <span>a</span> <span>i</span> <span>n</span> <span>b</span> <span>o</span> <span>w</span> <span>!</span> </span> </h1>

[Robin]: Stefánia Péter made a neat website called CSS Hell. It tells us what to avoid when writing CSS and I like this note about specificity:

Developers often write overly specific selectors just to be 10000% sure their rules will rule.

Stefánia then gives this example:

div#my-popup div span.my-radiocheckbox-label-text { color: #666; }

This is the sort of CSS that will lead to nightmares, but how do we fix it? Okay, sure, we can replace it with a single CSS class most likely:

.radio-label { color: #666; }

That’s a good first step but what happens when we find color: #666; a hundred times in our codebase? I’d say that specificity isn’t the problem in this case, but instead it’s the sign of a bigger problem with our system of styles. Is #666 some random color we want our label to be or all our labels?

We can simplify that further:

.label { color: #666; }

Or is #666 the secondary color we use throughout our website? In that case, we should have a variable that we can change to make sweeping changes within our codebase:

:root { --c-secondary: #666; } .label { color: var(--c-secondary); } .another-component { color: var(--c-secondary); }

Now, instead of fixing this one CSS problem (which can be annoying), we’re now solving system-level problems throughout our app.

It’s important to remember that specificity is always the sign of a bigger disagreement within a codebase and fixing those disagreements is the way to really make CSS scale across hundreds of components. It’s hard and annoying but it’s how you make sure the developers on your team and working as efficiently as possible and aren’t secretly arguing in your codebase.

Anyway, ranting aside, CSS Hell is riffing of Manuel Matuzović’s excellent HTML Hell that similarly walks through common mistakes and pitfalls when writing HTML.

Here’s Manuel on the problems with close buttons for instance:

In modals, ads, and other overlays you often find a button with a close symbol that allows users, or at least some of them, to close the overlay. This functionality is often limited to mouse users, because most implementations of close buttons suck.

Then Manuel gives us fifty different options for building a better close button for something like a modal and then talks about all those potential problems, too. Reading through all the different methods for this one particular thing reminds me that there’s never one way to build a website. There’s no easy guide for anything because all of these things are so very complex and nuanced.

Front-end development is hard! Who knew.

[Robin]: First up this week, Una Kravets wrote about how marvelous the future will be with container queries:

Container queries will be the single biggest change in web styling since CSS3, altering our perspective of what “responsive design” means.

Why is that? Well, when it comes to CSS, the very small is disconnected from the very big. So it would be easy to make relatively large layout changes with grid and media queries, but smaller components are disconnected from that logic. Adding container queries makes smaller bits of UI more intelligent in a way that they now understand the context that they exist in. Or, as Una says much more eloquently:

One of the best features of container queries is the ability to separate micro layouts from macro layouts. You can style individual elements with container queries, creating nuanced micro layouts, and style entire page layouts with media queries, the macro layout. This creates a new level of control that enables even more responsive interfaces.

And with that, Una shows this pretty nifty example. Watch how the dates at the top of the calendar change their size in response to the width of their parent:

In this demo, Una showcases what makes container queries so very useful: improving small typographic details like font-size, line-height, and other properties. Perhaps that’s my own bias showing here as a font nerd, but websites will be able to be so much more typographically beautiful once container queries lands in browsers. Our toolbox gets so much bigger.

On that note, Max Böck wrote about how container queries can be applied to web components and argued that they’re so very helpful when combined together because they set up a clear separation of concerns:

That’s why Container Queries pair so well with CSS Grid. Grid defines a flexible layout from the outside, while container queries adapt whatever content sits inside it to the optimal size for the available space.

His demo for container queries is equally impressive here:

[Robin]: This week I’ve been thinking about this post from the team at gov.uk where they write about how they made a button to show and hide the password of an input. They do that by toggling between the input type of password and text with some JavaScript. There’s a host of lessons they jotted down in this post about the craft (and frustrations) of making forms.

It’s fascinating reading about how the team tackled this problem but it also makes me a tiny bit frustrated because a show/hide password button feels like something that should be built into forms by default. Here’s some of the lessons they learnt along the way that suggests this should be a problem that browsers solve for us:

• show or hide the password by toggling input type between ‘password’ and ‘text’
• use a button with type ‘button’ to avoid accidental form submission
• autocomplete=”off” doesn’t work in all browsers
• don’t allow users to submit text inputs containing passwords

I know there’s that consortium to make browsers more consistent, but now that we have all sorts of fabulous layout tools on the web, I think it’s time for us as a community to return to the basics: let’s make forms on the web real good.

I know this is an extremely punk rock statement to make, but I’m scared to make a form on the web. Just look at what it took for this team to add a simple button to show the password! All this work and effort is required for something that results in extremely low pay-off in the end. I think browsers really need to meet us halfway here because making a form should be as enjoyable and as easy as creating a grid with CSS. Forms shouldn’t be scary.

I guess this is the lesson I came away from this post: whenever you feel like you’re fighting the browser to get it to do what you want, then those are the problems that should be the priority of browser manufacturers.

Okay, enough moaning about forms…