Guidance about which state properties should be reflected as HTML attributes

[LeaVerou]

This came up while reviewing <popup> in w3ctag/design-reviews#599 (comment), and more specifically about whether it should have an open attribute like <dialog> and <details>.

There is another issue about keeping IDL attributes and HTML attributes in sync when both exist, but we don't have anything about which IDL attributes should also exist as attributes.

My personal opinion is to err on the side of including attributes for main properties. Providing declarative HTML-based ways to interact with UI controls has several benefits. Off the top of my head:

• It is easier for authors: No need to worry about running code at the appropriate moments (e.g. after the element is created, but not too late to avoid getting a flash of unintended UI), intent is declared and automatically applied when appropriate
• It facilitates experimentation and iteration (e.g. much quicker to type open when iterating than to write script)
• It makes it more learnable: there is a baseline uniform API (DOM) that novices can use to interact with the element via script, even before learning the more specialized API that might come with each element
• It means behaviors can be expressed reactively in libraries supporting such syntax (e.g. open={{expression}}) and be handled by any library handling HTML generically.
• It means UI states can be addressed via established and widely understood attribute selectors, instead of new pseudo-classes
• It makes state inspectable via dev tools which facilitates debugging

On the other hand, there have been some arguments against this, I believe primarily centered around performance. In the case of <dialog open>, things got messy I believe due to some inconsistency with the open and close events, I'm not sure if there's anything more general to learn from that.

Anyhow, I think this is something we should discuss, resolve on so that we're all on the same page, and provide guidance about in the form of a design principle.

[annevk]

I think there is an unresolved issue around dialog elements when the events fire. I think if they fire using custom-element-reaction time™ and only in documents with a browsing context it ought to be fine, but that's not the case right now.

The dialog element is also somewhat precedent breaking in that for other form controls, user input never modified the tree. And it's also not clear how to do certain features with that model. E.g., for <textarea> its contents represent the default value. How would you serialize user input?

[LeaVerou]

The dialog element is also somewhat precedent breaking in that for other form controls, user input never modified the tree. And it's also not clear how to do certain features with that model. E.g., for <textarea> its contents represent the default value. How would you serialize user input?

I think that's more a comment for #279, though is is certainly related with this. User input already has a defined serialization for textarea.value. I don't see how this is different, but maybe I'm missing something? There is also precedent for text editing that modifies the tree, with contentEditable. Furthermore, just like the other form elements, the fact that textarea.textContent doesn't actually represent the current value but the default value is incredibly confusing to developers, and I have seen many of them stumble over it badly. So, if <textarea> were to be designed today, I would strongly argue against this pattern.