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 https://github.com/w3ctag/design-principles/issues/270#issuecomment-933786019

[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.