Attribute Superpowers Taken All The Way

I mentioned one of my votes for Interop 2024 (there aren’t really votes, just like, my favorites) is for attr() extended capabilities.

The point is snagging the value of an HTML attribute in CSS, along with the type, so it can actually be used.

If you could do that (reliably), you could do something like this if you wanted:

<div font-size="16px" color="green" font-weight="bold">Code language: HTML, XML (xml)

Then write CSS to go with it:

[font-size] {
  font-size: attr(font-size);
}
[color] {
  color: attr(color);
}
[font-weight] {
  font-weight: attr(font-weight);
}Code language: CSS (css)

(You’d probably want to do like data-font-size so you aren’t trampling HTML attribute space.)

That’s not terribly different than a utility class method, right?

<div class="text-base text-green-300 font-bold">Code language: JavaScript (javascript)

And would similarly make for some extremely lightweight final CSS.

But… there would be no guard rails. Any value would go! Maybe that’s a strength. But I might argue it’s a weakness. With no pre-determined values (or abstraction), then you really are just writing inline styles. And utility class advocates have always said: this is different than writing inline styles. The pre-determined values form a sort of design system that yield consistent results.

How might you reign it in then and only allow certain values? Maybe you write a linter. The linter can then run:

• As a code editor plugin, so you get red squiggles for “invalid” values
• As a pre-commit hook, so people aren’t checking in “invalid” values
• In CI, so you can’t merge code with “invalid” values

I don’t think this is like a good idea — it’s just interesting.