Hiding The Complexity of Element Selection Chris Coyier

blog

CSS is the champ1 of selecting elements. There is nothing on a web page that a selector of some sort can’t get it’s hands on.

But not everyone, nay, very few people, are skilled at hand-crafting CSS selectors, yet need their functionality to do things. So sometimes applications need to help people select things on a page, then retain that selector information so it can do the thing that that app needs to do. I’m thinking about this in relation to some apps I use and app features I’ve seen released lately:

1) Appcues Flow Steps

We use Appcues at CodePen. It allows you to build “flows” which are like popups that are anchored to certain DOM elements.

You have the option of using stuff like a “tooltip” step, which positions and attaches itself to an existing DOM node. This is like 90% of our usage at CodePen, because we largely use it educationally to show people things about the app.

Notice that whole “Target element” area in the screenshot below which concerns itself with how to find the DOM element.

That’s complicated stuff. Appcues is smart in that you don’t need to care that much about this, because it’ll find some selector that works. You click on something, it picks what selector it thinks is best. It hides the complexity of element selection.

But you do need to be careful here! Notice the selector it has chosen for me here: .Sidebar_link-onAgY. I’m sure you can smell that as a build-process-generated class name. Who knows when that will change? When it does, BAM, this flow is broken.

Also notice it has some other choices you can pick from. It offers a tag selector (that seems like a horrible idea), an attribute selector based on the href of the element (better, but still feels dangerous), and then a very super specific CSS selector:

[role] div:nth-of-type(2) .Sidebar_link-onAgY:nth-of-type(2)Code language: CSS (css)

That one increases the chances of breakage even more, but also reduces the chances that it selects the wrong element.

In my experience, these things really do break quite often, and require manual maintenance from us to keep working again because there isn’t a great system yet for alerting users for broken steps in flows.

In order to avoid breakage, for the most part, at CodePen, we try to connect the tooltip steps to elements where we use a [data-appcues="x"] selector, so it won’t change and selects exactly what we mean it to.

2) Tango Guidance

Tango, which I’ve mentioned before, has a new release called Guidance.

Their Guides product (prior to Guidance) is pretty cool. You flip on a browser extension, do some stuff on a website, and a guide is produced showing exactly what you did. It’s useful for making a step-by-step guide on how a website works.

But Guidance is a step further, in that rather than reading a guide full of screenshots, it walks you through the steps on the actual website. So now they really need to care about selecting elements, because they need to find the exact same elements on websites that the creator of the guide did.

So now Tango is in the business of hiding the complexity of selecting DOM elements.

Check out this guide Make a Vue 3 SFC on CodePen, which took me like 20 seconds to make.

That’s usable and readable all on it’s own, but now there is a “Guide Me” button in the header. Click it, and it takes you to the actual CodePen website and walks you through it. Check out how clear it is:

So hopefully Tango can actually find that DOM element again later. If they can’t, then the Guidance feature of this Guide is hosed (fortunately the saved screenshots are a nice fallback).

Unlike Appcues, Tango doesn’t expose the selectors to you, so they entirely hide that complexity. In a brief conversation with them, they say they save multiple ways to find that element again (so presumably if one fails they will try the next). And they are even considering some kind of ML-powered “healing” of broken selectors. Wild!

3) Arc Boosts

The browser Arc has long had a “boosts” feature, which is like User Stylesheets and User JavaScript that you can apply to one-or-all websites. It used to offer a code editor right in the browser and then package it up as a browser extension. Super clever.

Their latest iteration of Boosts is even easier. Upon selecting the New Boost menu option, you get a panel where you can do common website-editing things like change colors, fonts, and remove things. It’s dead simple to use.

But how do they know what elements to select to do that? One website might set the overall background on the <html>, another the <body>, and another a site-covering <div>. And not only that, fiddling with the colors doesn’t just change the background but all sorts of colors all over the site. Just dragging a little into the greens changes CodePen to all sorts of wild green-ness!!

If I change the fonts, it needs to inject styles that match text elements to change their fonts. They better pick selection tools that are up for the job!

And the hardest yet: “Zapping”. That allows you to remove elements from the page. They’ll need to figure out selectors to use to reliably and repeatable do that, otherwise, the Boost won’t quite do what it says it does. A lot of hidden element selection complexity there!

It looks like the latest iteration of Zapping exposes the CSS selector that will be used to find that element:

Tricky tricky tricky.

ncG1vNJzZmibmKe2tK%2FOsqCeql6jsrV7kWlpbGdga3xxhI6hoJ2hnpx6tbTEZpqopaChsrm107JkqJ5dmrmmucSnq2arlaGypMDIqKVo