You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thinking about element overloading (#370) in our meeting today I realized something: 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).
The text was updated successfully, but these errors were encountered:
Thinking about element overloading (#370) in our meeting today I realized something: 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).
The text was updated successfully, but these errors were encountered: