Designing better target sizes
This is a wonderfully in-depth interactive explainer on touch target sizes, with plenty of examples.
This is a wonderfully in-depth interactive explainer on touch target sizes, with plenty of examples.
Huh! I did not know this. Good to know!
Remember when I wrote about sizes="auto"
? Well, it’s coming to Chrome! Hallelujah!
As well as her personal site, wordridden.com, Jessica also has a professional site, lostintranslation.com.
Both have been online for a very long time. Jessica’s professional site pre-dates the Sofia Coppola film of the same name, which explains how she was able to get that domain name.
Thanks to the internet archive, you can see what lostintranslation.com looked like more than twenty years ago. The current iteration of the site still shares some of that original design DNA.
The most recent addition to the site is a collection of images on the front page: the covers of books that Jessica has translated during her illustrious career. It’s quite an impressive spread!
I used a combination of CSS grid and responsive images to keep the site extremely performant. That meant using a combination of the picture
element, source
elements, srcset
attributes, and the sizes
attribute.
That last part always feels weird. I have to tell the browser what sizes the images will displayed at, which can change depending on the viewport width. But I’ve already given that information in the CSS! It feels weird to have to repeat that information in the HTML.
It’s not just about the theoretical niceties of DRY: Don’t Repeat Yourself. There’s the very practical knock-on effects of having to update the same information in two places. If I update the CSS, I need to remember to update the HTML too. Those concerns no longer feel all that separate.
But I get it. Browsers use a look-ahead parser to start downloading images as soon as possible, so I understand why I need to explicitly state what size the images will be displayed at. Still, it feels like something that a computer should be calculating, not something for a human to list out by hand.
But wait! Most of the images on that page also have a loading
attribute with a value of “lazy”. That tells browsers they don’t have to download the images immediately. That sort of negates the look-ahead parser.
That’s why the HTML spec now includes a value for the sizes
attribute of “auto”. It’s only supposed to be used in conjunction with loading="lazy"
(otherwise it means 100vw
).
Browser makers are on board with this. You can track the implementation progress for Chromium, WebKit, and Firefox.
I would very much like to see this become a reality!
Some lovely scroll-driven animations illustrate this great little microsite.
There’s something very pleasy about the chunky design that harkens back to the Zeldmanesque early web.
This is a terrific walkthrough from Andy showing how smart fundamentals in your CSS can give you a beautiful readable document without much work.
Container queries can’t be used in the sizes
attribute for responsive images. Here, Jason breaks down why that is (spoiler: it’s the lookahead pre-parser) and segues into a truly long term solution: a “magical” image format.
If you’ve ever thought it felt weird to put media conditions inside the HTML for responsive images, this will resonate.
Gerry talks about “top tasks” a lot. He literally wrote the book on it:
Top tasks are what matter most to your customers.
Seems pretty obvious, right? But it’s actually pretty rare to see top tasks presented any differently than other options.
Look at the global navigation on most websites. Typically all the options are given equal prominence. Even the semantics under the hood often reflect this egalitarian ideal, with each list in an unordered list. All the navigation options are equal, but I bet that the reality for most websites is that some navigation options are more equal than others.
I’ve been guilty of this on The Session. The site-wide navigation shows a number of options: tunes, events, discussions, etc. Each one is given equal prominence, but I can tell you without even looking at my server logs that 90% of the traffic goes to the tunes section—that’s the beating heart of The Session. That’s why the home page has a search form that defaults to searching for tunes.
I wanted the navigation to reflect the reality of what people are coming to the site for. I decided to make the link to the tunes section more prominent by bumping up the font size a bit.
I was worried about how weird this might look; we’re so used to seeing all navigation items presented equally. But I think it worked out okay (though it might take a bit of getting used to if you’re accustomed to the previous styling). It helps that “tunes” is a nice short word, so bumping up the font size on that word doesn’t jostle everything else around.
I think this adjustment is working well for this situation where there’s one very clear tippy-top task. I wouldn’t want to apply it across the board, making every item in the navigation proportionally bigger or smaller depending on how often it’s used. That would end up looking like a ransom note.
But giving one single item prominence like this tweaks the visual hierarchy just enough to favour the option that’s most likely to be what a visitor wants.
That last bit is crucial. The visual adjustment reflects what visitors want, not what I want. You could adjust the size of a navigation option that you want to drive traffic to, but in the long run, all you’re going to do is train people to trust your design less.
You don’t get to decide what your top task is. The visitors to your website do. Trying to foist an arbitrary option on them would be the tail wagging the dog.
Anway, I’m feeling a lot better about the site-wide navigation on The Session now that it reflects reality a little bit more. Heck, I may even bump that font size up a little more.
Reminder:
em
andrem
work with the user’s font size;px
completely overrides it.
Prompted by Utopia, Piper shares her methodology for fluid type in Sass.
Removing
media
support from HTML video was a mistake.
Damn right! It was basically Hixie throwing a strop, trying to sabotage responsive images. Considering how hard it is usually to remove a shipped feature from browsers, it’s bizarre that a good working feature was pulled out of production.
Find out how much smaller your JavaScript could be.
There’s no browser support yet but that doesn’t mean we can’t start adding prefers-reduced-data
to our media queries today. I like the idea of switching between web fonts and system fonts.
Did you know there’s an imagesrcset
attribute you can put on link rel="preload" as="image"
(along with an imagesizes
attribute)?
I didn’t. (Until Amber pointed this out.)
Playing The Chicago Reel on mandolin:
Chris has put together one of his indispensable deep dives, this time into responsive images. I can see myself referring back to this when I need to be reminded of the syntax of srcset
and sizes
.
A nice succint explanation of using the srcset
and sizes
attributes on the img
element—remember, you probably don’t need picture
and source
elements if your use case is swapping out different sized versions of the same image.
One caveat thought: you do need to know the dimensions of the images. If you’re dealing with unknown or user-generated photos, that can be an issue.
How and when did I get to the point where I would consider a page weight of 4 MB on a large page and 500 KB on a small page normal?
This isn’t just a well-earned rant from Manuel. I mean, it *is that, but it’s also packed with practical performance advice.
Celestial objects ordered by size, covering a scale from one astronaut to the observable universe.
Here’s a nice little test for the file size of your web pages—could they fit on a floppy disk?
The Session fits comfortably and adactio.com just about scrapes by.