New principle: Discourage overloading (in HTML)

[LeaVerou]

This was brought up by @hober in a breakout today.

We should have a principle about avoiding things like <input type> in the future.

[LeaVerou]

Consensus from today's breakout:

• If we were to design <input> today, text fields would still be grouped under the same element (<text> or <textfield> or the like), but radios, checkboxes, color inputs, file inputs would have likely been separate elements.
• <object> is a total mess: can cause plugin execution, or subresource loading & rendering, or some other behavior.
• <link rel>: some things should have been grouped together, others should have been separate elements, because some rel values cause subresource loads and others don't
• <button> is a positive example of overloading where type differentiates different purposes, but they are all similar enough and have the same API.
• <textarea> possible it should have been overloaded together with single line text fields, as some kind of <text multiline>. we've seen cases where people have wanted to grow <textarea> to have features like pattern="", which suggests it should have been the same element as single-line text input.

[hober]

see also #270 (comment)

[martinthomson]

Checkboxes and toggle/switch are a good case where the new UX treatment of the toggle gains some benefit from a fallback.

We have also given advice in the past that <input type="somenewthing"> degrades cleanly to a text field. Overloading might have been a good thing. On the other hand, with some JS, you can polyfill just about anything and maybe the transitionary costs are not what should dominate.

[LeaVerou]

Thinking about this some more in today's meeting, the crux of it is avoiding mode errors: <input> and <link> are antipatterns because they have attributes that only apply when other attributes are set, or properties that make sense only when other properties have certain values. When this is not an issue, it's fine to reuse elements, e.g. reusing checkboxes for switches is fine.

So perhaps what we really need is a principle around mode errors, since that applies to other cases too, e.g. in CSS when we introduce properties that only have meaning when other properties are set it always ends up being a source of author pain (though sometimes unavoidable — but principles are rules of thumb, not laws).

Edit: I ended up filing a new issue: #532