Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Guidance about reflecting state in HTML attributes #501

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
+19 −0
Open

Guidance about reflecting state in HTML attributes #501

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
de81d1d
First stab at #289
LeaVerou Jul 15, 2024
c599e4b
Update index.bs
LeaVerou Jul 15, 2024
039c7ef
Update index.bs
LeaVerou Jul 17, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
19 changes: 19 additions & 0 deletions index.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The emphasis on "writable" doesn't seem to serve a purpose. (I, for one, find it distracting.)

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I disagree, I think "writable" is essential to the principle and should be emphasized.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

expose a corresponding content attribute unless you have a compelling reason not to.

Providing declarative ways to manipulate state has several benefits for authors:
- It takes advantage of HTML’s [reactivity](https://en.wikipedia.org/wiki/Reactive_programming), 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if this is a good thing in all cases. For instance, [lang=foo] v. [lang|=foo] v. :lang(foo).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

- State can be inspected and manipulated via the browser's developer tools with no need for implementing a new UI.

<div class="example">
A counterpattern to this guidance can be found in
<{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>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

All of the above, IIRC.

Copy link
Member

@annevk annevk Jul 17, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

@LeaVerou LeaVerou Jul 17, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hober Interesting. Could you elaborate on the UI part?

Copy link
Member

@annevk annevk Aug 21, 2024 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.


<h3 id="html-idl-must-by-synced">Keep attributes in sync</h3>

New content attributes
Expand Down