Guidance about reflecting state in HTML attributes #501
Conversation
| @@ -1032,6 +1032,25 @@ The alternative user experience is a flash of unstyled content, which is undesir | |||
|
|
|||
| See also [[#worker-only]]. | |||
|
|
|||
| <h3 id="html-attribute-property-reflection">Expose content attributes for writable IDL attributes</h3> | |||
|
|
|||
| When designing a new *writable* IDL attribute to specify element state, | |||
There was a problem hiding this comment.
The emphasis on "writable" doesn't seem to serve a purpose. (I, for one, find it distracting.)
There was a problem hiding this comment.
I disagree, I think "writable" is essential to the principle and should be emphasized.
There was a problem hiding this comment.
I would suggest a rephrase then.
When designing a new IDL attribute that reflects the state of an element,
expose a corresponding content attribute,
unless the attribute is immutable or
there are other strong reasons not to.
| - It takes advantage of HTML reactivity, and alleviates the need to apply changes at a specific moment in time. | ||
| - It integrates with existing DOM methods, improving learnability, whereas an API specific to the feature needs to be learned separately. | ||
| - Behaviors can be expressed reactively in libraries supporting HTML-based syntax and be handled by any library handling HTML generically. | ||
| - UI states can be addressed in CSS via simple attribute selectors rather than new pseudo-classes. |
There was a problem hiding this comment.
I wonder if this is a good thing in all cases. For instance, [lang=foo] v. [lang|=foo] v. :lang(foo).
There was a problem hiding this comment.
This seems orthogonal. In that case the pseudo-class serves a distinct purpose by targeting the actual computed language (which may be specified on an ancestor). I’d argue there may even be value in a generic attribute selector for these inherited attributes.
There was a problem hiding this comment.
I'd favor Lea's point on this one. :lang() is justified because it is not as much about element state directly and more about the state of the DOM tree, as viewed from that node.
That said, the other point is also good: [lang=foo] is possible, but inadvisable.
| <{input}>'s {{HTMLInputElement/indeterminate}} IDL property | ||
| which was never exposed as a content attribute making it impossible to fully update checkbox state | ||
| by modifying HTML. | ||
| </div> |
There was a problem hiding this comment.
On the other hand, indeterminate is a terrible feature that should never have been added to the platform in the first place. Maybe we should try to find a more positive example?
There was a problem hiding this comment.
Could you elaborate? Is it the UI of an indeterminate checkbox that you think is a mistake or the way it was added to HTML?
There was a problem hiding this comment.
The indeterminate IDL attribute is a bad example as it's like the checked or value IDL attributes which also do not have corresponding content attributes.
You could argue that we should have had a defaultIndeterminate IDL attribute for a corresponding indeterminate content attribute, but that's a separate matter. whatwg/html#6578 goes into this a bit.
(And of course people always like to point out that the IDL attributes not matching the names of the content attributes is confusing, but that's also a separate matter and anyway not something that can actually be solved.)
There was a problem hiding this comment.
There’s a separate, existing, principle about this: Keep attributes in sync. It’s right below this one actually 😁
indeterminate in addition to that, also has no content attribute counterpart so there is no HTML way to specify it at all (current OR initial status).
There was a problem hiding this comment.
@hober Interesting. Could you elaborate on the UI part?
There was a problem hiding this comment.
That principle is about content attributes needing to be reflected right? But indeterminate is not a content attribute. Edit: ah right, it even says so in the note:
This does not hold the other way around. A new IDL attribute does not always warrant a content attribute counterpart.
Co-authored-by: Theresa O'Connor <[email protected]>
| <{input}>'s {{HTMLInputElement/indeterminate}} IDL property | ||
| which was never exposed as a content attribute making it impossible to fully update checkbox state | ||
| by modifying HTML. | ||
| </div> |
| - It takes advantage of HTML reactivity, and alleviates the need to apply changes at a specific moment in time. | ||
| - It integrates with existing DOM methods, improving learnability, whereas an API specific to the feature needs to be learned separately. | ||
| - Behaviors can be expressed reactively in libraries supporting HTML-based syntax and be handled by any library handling HTML generically. | ||
| - UI states can be addressed in CSS via simple attribute selectors rather than new pseudo-classes. |
There was a problem hiding this comment.
I'd favor Lea's point on this one. :lang() is justified because it is not as much about element state directly and more about the state of the DOM tree, as viewed from that node.
That said, the other point is also good: [lang=foo] is possible, but inadvisable.
martinthomson
changed the title
Preview | Diff