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.

[LeaVerou]

We discussed this again in today's breakout. We all agree that we don't want any of these two extremes:

• All HTML attributes only set initial state, any dynamic state needs to be set with JS and styled with CSS pseudo-classes
• All state is reflected via HTML attributes, including things like hover, focus etc.

It seems that the optimum choices for the Web Platform are somewhere in the middle, but we are having some trouble to zero in on the exact distinction. @plinss came up with a thought experiment, inspired by my point about SSR: If browsers were read-write, what state would you expect to be copied if you copied a part of a webpage? It seems there are aspects of state that are part of the document (i.e. makes more sense to expose) and aspects of state that are external (e.g. hover, focus, :target etc).

Link to minutes

[LeaVerou]

Resolved in today's breakout: @LeaVerou to write a draft principle based on the first comment so we can have something concrete to debate.