Snippets

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 aslo 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:

In May 2019 I attended a talk by Mike Taylor who works on webcompat at Mozilla. Mike told the sordid story of window.event, a non-standard IE invention that was replicated in Konqueror, which showed up in Webkit, which stuck around in Blink, and was now Mike’s problem in Firefox. It was a good story fraught with ups and downs and literal “Breaking the Web” level changes for a tiny feature rollout.

At the end of the talk Mike threw out a pretty prescient question (Edge had just released its Chromium beta) and I’ve been mulling over it ever since:

What is the value of browser diversity? If Firefox switched to Chromium tomorrow, what would we lose?

– Mike Taylor, a traitor (apparently)

Mike made it clear that the question was purely theoretical and no serious talk about this was happening at Mozilla at the time. Nonetheless, it was a challenging thought. Throwing away all sunk costs, what is the value of the colossal expense required to employ engineering teams to chase Chrome’s tail?

I’ve thought about these questions for over a year and narrowed my feelings of browser diversity down to two major value propositions:

1. Browser diversity keeps the Web deliberately slow
2. Browser diversity fosters consensus and cooperation over corporate rule

They are similar, but slightly different concepts for me.

Slow, like brisket.

I think the Web platform’s most frustrating aspect is also its greatest asset: it’s slow. It’s not just slow, it’s “it took 10 years to ship the <main> element which is just a spicy <div>” kind of slow. It’s glacial.

This can be agonizing while you wait for a much needed feature to roll out in all browsers, only to find out five years in the process one browser refuses the entire premise of the feature (RIP HTML Imports). The big tradeoff is that web platform features have to run the gauntlet and more thinking is applied over time: robustness, naming, internationalization, accessibility, security, etc. all have proper time for consideration and aren’t rushed through like it’s a product sprint.

[…]

Cooperation, not corporation.

Browser diversity means browser vendors are hindered from shipping features that only benefit themselves (e.g. ActiveX in IE, -webkit-box-reflect, etc). Good ideas have to be open and meet a pseudo-requirement of ubiquitous utility. To make good platform features requires consensus, not competition, and the web’s potential is born out of cooperation, not a single corporation.

It’s hard to quantify this, but if all aspects of the Web (development, browsing, searching, hosting) are ceded to a single corporation, all it takes is one heavy-handed manager or executive hellbent on hitting some OKRs to push their thumb on the scale of the Web. If the Web is governed by a single corporation, it will start looking like that corporation’s vision of the Web, ultimately limiting its own potential. Trading short term gain on new shiny features for long term vision.

This is a delightfully nerdy exploration of how IntersectionObserver works, its quirks and caveats, and how it can be used to create a JavaScript position: sticky event as a bonus.