Snippets

Developers, designers, and strategists, here’s something you can do for the health of the web: 

Test all your sites in Firefox.

Yes, we should all design to web standards to the best of our ability. Yes, we should all test our work in *every* browser and device we can. Yes, yes, of course yes. 

But the health of Firefox is critical now that Chromium will be the web’s de facto rendering engine. 

Even if you love Chrome, adore Gmail, and live in Google Docs or Analytics, no single company, let alone a user-tracking advertising giant, should control the internet.

[…]

When one rendering engine rules them all, well, many of us remember when progress halted for close to ten years because developers only tested in IE6, and more than a few of us recall a similar period when Netscape was the only browser that mattered.

[…]

When one company decides which ideas are worth supporting and which aren’t, which access problems matter and which don’t, it stifles innovation, crushes competition, and opens the door to excluding people from digital experiences.

I found this quite useful in learning the basics of XPath:

CSS custom properties are commonly known as CSS variables, and judging by the main web development blogs and resources, most people likely use the terms “custom property” and “variable” interchangeably[.]

[…]

The reason for this could be that the CSS spec itself uses both terms. ”Custom properties” and “variables” both appear in the spec’s text dozens of times and even in the spec’s own title (“CSS Custom Properties for Cascading Variables”).

However, the spec distinguishes the two terms: A custom property is not a variable, but it defines a variable. Any property can use variables with the var() function whose values are defined by their associated custom properties.

[…]

This distinction is useful because it allows us to talk about “variables with fallback values” (a custom property like any other property cannot have a fallback value) and “properties using variables” (a property cannot use a custom property) […] as well as “declaring a custom property on an element” (a variable isn’t declared but assigned to a property) and “the computed value of a custom property” (a variable doesn’t have a computed value but draws from the computed value of its associated custom property).

This is a fascinating deep dive by the people at Discord on their development of a focus ring component and all the problems they had to overcome:

Browsers implement default focus rings that apply to all elements, but the ability to style these is (currently) very limited. These rings, while they have recently improved greatly in Chrome and Edge, are also not very pleasant when integrated with the rest of Discord’s design, and other browsers like Firefox are almost entirely invisible in most cases due to the thinness and low contrast of their styles.

As such, we want to implement a custom focus ring style. At a glance, this seems relatively simple, but when dealing with the variety of use cases Discord has for these rings, the list of requirements quickly grows, and the options for implementations shrink.

Ideally, we want to match the browser’s focus ring behavior exactly. Within Discord, this means that a comprehensive focus ring implementation needs to:

• Perfectly map to the element that has focus (with exceptions listed below).
• Follow elements as they move when containers scroll.
• Follow elements as they animate and transition within the document.
• Not be clipped off when the focused element is bounded by overflow: hidden or other bounding techniques.
• Respect occlusion of overlapping elements, but not be occluded by an element’s own z-index.

Additionally, to be able to implement pleasant and overall better focus styles for various elements in the app, we have additional requirements to be able to:

• Apply the focus ring on a different element than the actual focused element
• Provide positional offsets to adjust ring placement around the element.
• Adjust ring styles to match the look and feel of the surrounding context (could include changing border radius, color, shape, and more)
• Specify a style for when focus is within an element, for example to indicate the bounds of a widget.

See the source link for the rest.

Little #a11y tip for you: If you are using a status message bar, you’ll want it to be a live region. But it should [also] be discoverable in case the messages are missed when they’re announced. Good case for an <aside>:

<aside aria-live="polite" aria-label="Status">
  ...
</aside>

I sometimes forget that transparent colours can solve certain contrast and design issues like the following:

The panel is using a subtle gray (#ddd) to draw a border between its contents and the surrounding page. But when the page background gets closer to #ddd, the design doesn’t work as well.

Using transparency, we can keep the same effect on white backgrounds while ensuring increased contrast on other backgrounds. Here I use a black color set to 0.135 opacity instead: rgba(0, 0, 0, 0.135). This matches #ddd on white backgrounds but automatically appears darker on other backgrounds:

This technique also works well on lightly colored backgrounds. The panel will pick up the underlying colors and display them through the transparent black: