When I wrote about my time in Amsterdam last week, I mentioned the task that the students were given:
They’re given a PDF inheritance-tax form and told to convert it for the web.
Rich had a question about that:
I’m curious to know if they had the opportunity to optimise the user experience of the form for an online environment, eg. splitting it up into a sequence of questions, using progressive disclosure, branching based on inputs, etc?
The answer is yes, very much so. Progressive disclosure was a very clear opportunity for enhancement.
You know the kind of paper form where it says “If you answered no to this, then skip ahead to that”? On the web, we can do the skipping automatically. Or to put it another way, we can display a section of the form only when the user has ticked the appropriate box.
This is a classic example of progressive disclosure:
information is revealed when it becomes relevant to the current task.
But what should the mechanism be?
This is an interaction design pattern so JavaScript seems the best choice. JavaScript is for behaviour.
On the other hand, you can do this in CSS using the :checked pseudo-class. And the principle of least power suggests using the least powerful language suitable for a given task.
I’m torn on this. I’m not sure if there’s a correct answer. I’d probably lean towards JavaScript just because it’s then possible to dynamically update ARIA attributes like aria-expanded—very handy in combination with aria-controls. But using CSS also seems perfectly reasonable to me.
It was interesting to see which students went down the JavaScript route and which ones used CSS.
It used to be that using the :checked pseudo-class involved an adjacent sibling selector, like this:
input.disclosure-switch:checked ~ .disclosure-content {
display: block;
}
That meant your markup had to follow a specific pattern where the elements needed to be siblings:
<div class="disclosure-container">
<input type="checkbox" class="disclosure-switch">
<div class="disclosure-content">
...
</div>
</div>
But none of the students were doing that. They were all using :has(). That meant that their selector could be much more robust. Even if the nesting of their markup changes, the CSS will still work. Something like this:
.disclosure-container:has(.disclosure-switch:checked) .disclosure-content
That will target the .disclosure-content element anywhere inside the same .disclosure-container that has the .disclosure-switch. Much better! (Ignore these class names by the way—I’m just making them up to illustrate the idea.)
But just about every student ended up with something like this in their style sheets:
.disclosure-content {
display: none;
}
.disclosure-container:has(.disclosure-switch:checked) .disclosure-content {
display: block;
}
That gets my spidey-senses tingling. It doesn’t smell right to me. Here’s why…
The simpler selector is doing the more destructive action: hiding content. There’s a reliance on the more complex selector to display content.
If a browser understands the first ruleset but not the second, that content will be hidden by default.
I know that :has() is very well supported now, but this still makes me nervous. I feel that the more risky action (hiding content) should belong to the more complex selector.
Thanks to the :not() selector, you can reverse the logic of the progressive disclosure:
.disclosure-content {
display: block;
}
.disclosure-container:not(:has(.disclosure-switch:checked)) .disclosure-content {
display: none;
}
Now if a browser understands the first ruleset, but not the second, it’s not so bad. The content remains visible.
When I was explaining this way of thinking to the students, I used an analogy.
Suppose you’re building a physical product that uses electricity. What should happen if there’s a power cut? Like, if you’ve got a building with electric doors, what should happen when the power is cut off? Should the doors be locked by default? Or is it safer to default to unlocked doors?
It’s a bit of a tortured analogy, but it’s one I’ve used in the past when talking about JavaScript on the web. I like to think about JavaScript as being like electricity…
Take an existing product, like say, a toothbrush. Now imagine what you can do when you turbo-charge it with electricity: an electric toothbrush!
But also consider what happens when the electricity fails. Instead of the product becoming useless you want it to revert back to being a regular old toothbrush.
That’s the same mindset I’m encouraging for the progressive disclosure pattern. Make sure that the default state is safe. Then enhance.