New principle: The value of HTML boolean attributes doesn't matter

[LeaVerou]

This was brought up in openui/open-ui#800

We should formalize it as a design principle that in HTML, boolean attributes are true by presence and false by absence — the exact value does not matter. ARIA is an outlier here, and we should not repeat this.

FWIW I don't think it's actually a good pattern, and introduces a lot of warts, but this ship has sailed long ago, and inconsistency with the existing precedent would be more costly.

[alice]

The ARIA "true/false" issue is a tricky one; see w3c/aria#1110 (comment) for example. Obviously, as you say, it's too late to change it now anyway.

As far as the principle is concerned, does it need to be a design principle, or does the Reflecting content attributes in IDL attributes guidance for boolean attributes suffice?

[LeaVerou]

As far as the principle is concerned, does it need to be a design principle, or does the Reflecting content attributes in IDL attributes guidance for boolean attributes suffice?

The design principle would be about the HTML syntax.

[annevk]

This feels too detailed to be a design principle. HTML already codifies what a boolean attribute looks like (and contradicts itself with various boolean-like attributes that are defined as enumerated attributes, which is what we should migrate ARIA towards).

A design principle to me would be something more akin to "follow established precedent (unless you have a very good reason not to)".

[LeaVerou]

This feels too detailed to be a design principle. HTML already codifies what a boolean attribute looks like (and contradicts itself with various boolean-like attributes that are defined as enumerated attributes, which is what we should migrate ARIA towards).

A design principle to me would be something more akin to "follow established precedent (unless you have a very good reason not to)".

We currently have both types of principles in the Principles document. E.g. 3.2. Use space-separated attributes for short lists of values, separate elements for longer lists or 6.4. Accept optional and/or primitive arguments through dictionaries are in the same level of abstraction, and there's several low-level principles around naming as well. I'd say our principles are 70% low-level and 30% higher level, abstract stuff (mainly chapters 1 and 2).
And for good reason: general, abstract principles are nice, but without concrete, specific principles, they are open to interpretation, so it's hard to achieve any level of consistency in the platform.

[hober]

As far as the principle is concerned, does it need to be a design principle, or does the Reflecting content attributes in IDL attributes guidance for boolean attributes suffice?

The design principle would be about the HTML syntax.

Why just HTML syntax? Would we want boolean attributes to work differently in SVG and MathML? I hope not.

[plinss]

We should also document the CSS principle to not use booleans, and perhaps write guidance about when enum values would be more appropriate (extensibility).