Skip to main content

Journal

We use too many damn modals (modalz modalz modalz dot com)

At our fortnightly Accessibility Forum at work, we just had a great discussion about modal dialogues. We started by discussing whether focus should be completely trapped within the modal or if the user should at least have access to the browser toolbar (we decided on the former). We then moved onto a general discussion on the pros and cons of modals, which led me to share MODALZ MODALZ MODALZ with the team.

· 3:37 PM · Glasgow

Putting a full stop on truncation

At work we’ve recently been shown a couple of design proposals where truncation was presented as a solution to the perceived problem of long and unwieldy content, for example a long description in a table cell. However following good discussions, as a wider team we’re now leaning towards avoiding truncation as an approach. Truncation can present accessibility issues and as Karen McGrane says truncation is not a good content strategy. I reckon we should just let long content wrap, and design for that to look OK.

:has(): the family selector (Chrome developers blog)

The :has() CSS pseudo-class represents an element if any of the selectors passed as parameters match at least one element.

But, it's more than a "parent" selector. That's a nice way to market it. The not so appealing way might be the "conditional environment" selector. But that doesn't have quite the same ring to it. How about the "family" selector?

Custom multi-checkbox and multi-radio controls

Our Design System team has recently received “new component requests” for some custom filtering controls. These look like custom-styled <select>s however their “options” appear more like checkboxes and radio buttons. I think the inspiration was Carbon Design System’s Dropdown component and the idea is to bring consistency to filtering controls in forms. Although it’s not yet time to fully explore this and make a yay/nay decision on the request, I’ve been doing some initial thinking.

Perceived affordances and the functionality mismatch (by Léonie Watson)

Léonie tackles the prickly subject of “element re-purposing” in web development. This post follows a fantastic Twitter exchange started by Lea Verou regarding whether the common visual design request for “adjacent but mututally exclusive buttons” should be built as radio buttons or using <button> elements.

Using one element or set of elements (usually because of their functionality) and styling them to look like something else is a common pattern […but…] it creates a mismatch between the actions people expect they can take and the ones they actually can.

My new syntax for modern, responsive blog images

I’ve started trialling different HTML and technologies for the “simple” responsive images (i.e. not art-directed per breakpoint) used in blog articles on this site. I’m continuing to lean on Cloudinary as my free image host, CDN and format-conversion service. But at the HTML level I’ve moved from a complicated <img srcset> based approach which included many resized versions of the same image. I now use a simpler <picture> and <source> based pattern that keeps the number of images and breakpoints low, leaning instead into the performance gains offered by the newer image formats avif and webp.

External Link Bookmark Note Entry Search