[popup] Consider renaming initiallyopen

[annevk]

As expressed by @zcorpan at #311 (comment) I think this should have an easier name, e.g., defaultopen.

It seems @domenic did not care strongly and apart from @mfreed7 I could not find anyone else who chimed in on the name, but maybe I missed something?

[css-meeting-bot]

The Open UI Community Group just discussed [popup] Consider renaming initiallyopen#500.

The full IRC log of that discussion

<hdv> Topic: [popup] Consider renaming initiallyopen#500
<hdv> github: https://github.com//issues/500
<JonathanNeal> q+
<una> q+
<hdv> masonf: we could talk about 500 or 508 actually
<JonathanNeal> my question is whether these attributes can be considered strictly initial values or living values?
<scotto> +1 to mason's suggestion
<hdv> Travis: does anyone have a suggestion or strong feeling on issue 500?
<hdv> q?
<flackr> q+
<hdv> ack una
<flackr> q-
<flackr> q+ to question why not open instead of initiallyopen
<hdv> JonathanNeal: are the values the initial states like in inputs? are they attributes that change when you change them in DOM they also change? are they strictly serialised or do they change?
<hdv> flackr: I don't know why we decided it couldn't be open, we have existing behavior for checked and others
<hdv> bkardell_: isn't it because open in another place in the DOM means the opposite
<hdv> masonf: yes that's why, it is confusing in two ways, one reason being that 'open' only has affect first time, like initially, not after that… the other discussion is whether that attribute would be live
<JonathanNeal> I think knowing whether these are initial or live by default is key to bike-shedding, for me.
<masonf> q?
<hdv> q?
<Travis> q?
<hdv> ack JonathanNeal
<hdv> ack flackr
<Zakim> flackr, you wanted to question why not open instead of initiallyopen
<hdv> masonf: for initiallyOpen things would be a lot easier
<hdv> bkardell_: I wanted to ask because we have dbaron and Travis here… I know we have relationships through TAG / former TAG… I remember there being guidance around such things, so I would be curious about your thoughts
<JonathanNeal> q+
<hdv> dbaron: TAG guidance on naming has some general things, but I can't think of anything that is specifically applicable here… one thing is that it discusses values like true and false, can't think of anything that would apply to initiallyOpen or triggerPopup
<hdv> bkardell_: is it worth inventing a policy for new attributes?
<hdv> bkardell_: like when is something a live, reflective value?
<JonathanNeal> With the exception of new elements like <details>, are live reflected values generally not a thing?
<hdv> Travis: if there's not already an issue that may be worth raising… what are cases?
<hdv> masonf: <dialog> has a live open attribute
<JonathanNeal> I can only think of maybe <details> or <dialog> and I am wondering if those are examples we should follow or avoid following.
<JonathanNeal> I would be in favor of not following those two elements.
<hdv> scotto: and <details> element also has it. but it pushes its state down to <summary>
<hdv> masonf: we've moved in the direction of CSS pseudo state for stating whether it is open or not, it would remove a lot of problems
<hdv> Travis: in that case I kind of trend towards the default state
<JonathanNeal> With that resolution about the CSS pseudo-state, I would be even more strongly in favor of the attribute reflecting the initial state.
<JonathanNeal> e.g. `open` boolean
<masonf> q?
<hdv> s/the default state/how masonf presented it earlier
<Travis> q?
<bkardell_> https://github.com/w3ctag/design-principles/issues/289 is one of the related issues in tag

[bkardell]

I would like to throw a vote in here for being explicit in the naming and working through discussion on this TAG issue and #311 to determine something that at least the rest of the OpenUI proposals that have a similar case can follow - in other words defaultSomething or initiallySomething or, as @zcorpan had suggested a shorter initSomething. This would also avoid violating the general agreement in 279 that if we do wind up with an IDL property they don't wind up having the same name.

Personally, I kind of lean toward @annevk and @domenic's comments that thread defaultSomething makes sense for those - so defaultOpen here

[zcorpan]

I think a potentially confusing thing with defaultSomething is that HTML has some content attributes something that are reflected as IDL attributes defaultSomething. In particular <input checked> <-> defaultChecked.

[mfreed7]

I'm agnostic between initiallyOpen and defaultOpen, as both easily convey the behavior. The issue with something that reflects to defaultSomething is that the something content attribute is still there, but setAttribute('something') just doesn't do anything. I find that confusing, and perhaps (?) a pattern that we shouldn't repeat just because it already exists. In other words, there is confusion both ways, but it seems less confusing on the defaultSomething side.

[zcorpan]

I'm not saying the defaultChecked pattern should be followed. Indeed new features in HTML haven't followed it because it is confusing.

What I am saying is that because defaultChecked exists and has weird behavior, adding new attributes to HTML with the same naming scheme but different behavior could be a source of confusion. So a different prefix could avoid this.

However, it's possible that most developers never use defaultChecked and therefore aren't confused by it, and it's ok to use default as a prefix for new features.

[jonathantneal]

In my own experience, developers using React are very familiar with the defaultX pattern that @zcorpan mentions.

In the React rendering lifecycle, the value attribute on form elements will override the value in the DOM. With an uncontrolled component, you often want React to specify the initial value, but leave subsequent updates uncontrolled. To handle this case, you can specify a defaultValue attribute instead of value.

render() {
  return (
    <form onSubmit={this.handleSubmit}>
      <label>
        Name:
        <input
          defaultValue="Bob"
          type="text"
          ref={this.input} />
      </label>
      <input type="submit" value="Submit" />
    </form>
  );
}

Likewise, <input type="checkbox"> and <input type="radio"> support defaultChecked, and <select> and <textarea> supports defaultValue.

— React Docs: Uncontrolled Components

For compatibility reasons, I am uncertain which path breaks less expectations. I am not outright opposed to a defaultOpen/defaultopen HTML attribute; just wary of it.

EDIT: Upon further consideration, I am generally in favor of defaultOpen/defaultopen. This is after review of the linked resources, and just plain reflection.

Also, thank you for the helpful resources, @bkardell. I have been considering this thought experiment:

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).
— @LeaVerou, crediting @plinss, w3ctag/design-principles#289

My issue with that thought experiment is context. If I copy a form, then I may or may not want the input fields to include their content. The same for whether a popup is open. I might expect something completely different depending on whether I’m copying the content for printing or copying the content for another content editor.

I tend to prefer reflecting state in DOM and CSS properties, and not in HTML attributes / forced mutations.

[mfreed7]

What I am saying is that because defaultChecked exists and has weird behavior, adding new attributes to HTML with the same naming scheme but different behavior could be a source of confusion. So a different prefix could avoid this.

Ahh, I see your point. Ok, sounds like something to consider.

Thanks for pointing out w3ctag/design-principles#279 and w3ctag/design-principles#289 - some interesting reading there. The only hard conclusions seem to be that the IDL and content attributes should have the same name, and should stay in sync. As that relates to this issue (about initiallyopen or defaultopen), it sounds like we're "ok" with either. The behavior matches the description: this property isn't "live". So the question just comes down to which name is less confusing or more informative.

initiallyopen - to me this better conveys "when" it takes effect - initially on page load. It also is different from existing patterns, which is a negative.
defaultopen - this matches other things on the platform. But to me, "default" means "value to use when there isn't an explicit setting", which doesn't immediately connote "on page load only". But perhaps given the history of other "default*" properties on the Web, this is clear.

Again, I'm relatively agnostic. I'm hearing more votes for defaultopen on this thread. Any strong voices against just changing to defaultopen (content attribute) and .defaultOpen (IDL)?

[domenic]

Note that "default" in the context of form controls also denotes that it's the value that resetting the form will reset the control to. I.e. it's not just on the page load.

I'm not sure if that has any bearing on non-form-control cases, but just something to consider.