Establish a rule about element overloading #502
Conversation
I'm sure that we could say more, but I think that this is enough. Closes #370.
| but attributes should not fundamentally alter that purpose. | ||
|
|
||
| Rather than defining elements that can operate in different modes, | ||
| having a separate element for each mode is preferable. |
There was a problem hiding this comment.
Counterexample: <legend>, <caption>, and <figcaption> probably should have all been the same element (but can't be for compat reasons).
| The now-deprecated <{acronym}> element is duplicative of the <{abbr}> element | ||
| and therefore overspecialization. | ||
| The <{source}> element can have distinct purposes depending on context. | ||
| A <{source}> element is not standalone; it's semantics are determined by its parent. |
There was a problem hiding this comment.
| A <{source}> element is not standalone; it's semantics are determined by its parent. | |
| A <{source}> element is not standalone; its semantics are determined by its parent. |
|
It would be nice for a non-native English speaker to take an editorial pass on this. |
| This simplifies usage for authors. | ||
|
|
||
| <div class=example> | ||
| The <{input}> element uses a <{input/type}> attribute to switch between |
There was a problem hiding this comment.
<link> is another good example to include here.
|
|
||
| <div class=example> | ||
| The <{textarea}> element and an <{input}> element with a <{input/type}> of `"text"` | ||
| could have used the same element as the differences between these is not material. |
There was a problem hiding this comment.
| could have used the same element as the differences between these is not material. | |
| could have used the same element as the differences between these are not material. |
| </div> | ||
|
|
||
| Potential counterexamples include overspecialization and elements that rely on context to establish their semantics. | ||
| The now-deprecated <{acronym}> element is duplicative of the <{abbr}> element |
There was a problem hiding this comment.
This should be in a <div class=example>
| Potential counterexamples include overspecialization and elements that rely on context to establish their semantics. | ||
| The now-deprecated <{acronym}> element is duplicative of the <{abbr}> element | ||
| and therefore overspecialization. | ||
| The <{source}> element can have distinct purposes depending on context. |
There was a problem hiding this comment.
This should also be in a (different) <div class=example>.
I disagree that this is an antipattern. The purpose of <source> is clear, the details change based on its context which is fine — having distinct elements would have been an antipattern just like <caption>/<figcaption>/<legend> that @hober mentioned.
There was a problem hiding this comment.
I think Martin agrees with you. This suggests this needs to be reworded so that people don't misread him.
| through the use of attributes could be used to select | ||
| between different behavior. | ||
| This only makes sense where the purpose remains the same | ||
| for any value of the attributes. |
There was a problem hiding this comment.
This reads a little awkward. Maybe something like
| through the use of attributes could be used to select | |
| between different behavior. | |
| This only makes sense where the purpose remains the same | |
| for any value of the attributes. | |
| through the use of attributes is valid when used to differentiate | |
| behavior within the same purpose. |
?
There was a problem hiding this comment.
See comments.
I wonder if it might make sense to mention distinct elements sharing the same interface as a halfway solution, with the positive example of <video> and <audio> as instances of HTMLMediaElement. <h1> to <h6> could also be a counterexample of insufficient overloading.
🙋🏽♀️ |
| The semantics of these modes could have been more clearly expressed | ||
| through the use of distinct element names. |
There was a problem hiding this comment.
While this is true, I wouldn't want people to walk away with the idea that we should completely abandon input. Making minor changes to input seems clearly preferable to creating a whole new element.
I'm sure that we could say more, but I think that this is enough.
Closes #370.
Preview | Diff