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

[mfreed7]

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.

Yep, good point. But as you said - I don't think that part applies to a popup element. I'm not sure if that adds confusion or doesn't change things at all. Is your vote for defaultopen?

[domenic]

I think I'm agnostic. I like initiallyopen a bit more from a semantics point of view. But I recognize it's a bit long of a thing to type, and maybe authors won't appreciate the careful distinction we're making between "initially" and "default" and will just say "lol HTML continues to use lots of unnecessary synonyms".

[jonathantneal]

I apologize if I am conflating things, but it seem like there could be a lot of these initial/default values, at least between details, dialog, popup, and a tabs effort that I’m working on. From my point of view, it seems like it would be very confusing to remember and manage these (semi?) global attributes across a document without a central, consistent pattern.

Would there be interest in “punting” on these individual attributes in exchange for a singular, consistent pattern that could assign multiple kinds of initial/default values going forward? Without explicitly recommending an implementation, could we have a universal default attribute (similar to style) that handles the serialized initial states of things, like whether a popup is initially open?

[bkardell]

While initiallyopen "reads nicely" that seems to me that it has something to do with the particular word that comes after, and likely to not always work.

Imagine we introduced a new version of iframe which used that concept - it has to be provided an default value, and you can't change it. I'm not sure why we'd do that, and I'm not suggesting we should - I just needed an attribute to show what I mean: initiallysrc feels less good to me. I'm not even sure that is the best example - but, if we just thought through imagining applying something similar to existing attributes as a kind of similar thought experiment, does initiallySomething seem as good? I'm not sure. defaultSomething seems better in many cases to me.

[mfreed7]

Would there be interest in “punting” on these individual attributes in exchange for a singular, consistent pattern that could assign multiple kinds of initial/default values going forward? Without explicitly recommending an implementation, could we have a universal default attribute (similar to style) that handles the serialized initial states of things, like whether a popup is initially open?

This seems tough, since the meaning of the thing being "defaulted" differs between things, and the syntax will be interesting. I'm not against trying to make this better, but I'd really like to avoid tying the Popup API to this effort. Would it be ok to work on this separately, and then apply it to Popup along with the rest of the things?

Imagine we introduced a new version of iframe which used that concept - it has to be provided an default value, and you can't change it. I'm not sure why we'd do that, and I'm not suggesting we should - I just needed an attribute to show what I mean: initiallysrc feels less good to me. I'm not even sure that is the best example - but, if we just thought through imagining applying something similar to existing attributes as a kind of similar thought experiment, does initiallySomething seem as good? I'm not sure. defaultSomething seems better in many cases to me.

This was a really convincing argument for me. I agree that defaultSomething feels more future proof. That, combined with the already-existing defaultOtherThings, makes me lean much more heavily towards voting for defaultopen/defaultOpen.

[zcorpan]

There are various HTML attributes with "initially" semantics but without any prefix (e.g. <input value>, <input checked>, <iframe src>, <video muted>), so I'm not convinced that all future such attributes need a prefix. But picking a prefix that works in more cases seems good.

[mfreed7]

There are various HTML attributes with "initially" semantics but without any prefix (e.g. <input value>, <input checked>, <iframe src>, <video muted>), so I'm not convinced that all future such attributes need a prefix. But picking a prefix that works in more cases seems good.

Fair point. But I don't know how the community sees those other attributes with "default" semantics but without a prefix - are those good? I personally find them confusing, especially <input value>. If that was <input defaultvalue> I think the behavior would be crystal clear.

That's really beside the point I guess, since those are shipped. Do you think default* is a good prefix that works in more/most cases, going forward?

[zcorpan]

That's really beside the point I guess, since those are shipped.

If we plan to replace input with a set of new elements, we have the opportunity to switch to defaultvalue and defaultchecked attributes for the new elements, and declare input as legacy. Do we have a way to find out which is better (polls, interviews, a usability study)?

Do you think default* is a good prefix that works in more/most cases, going forward?

Yes.

[mfreed7]

declare input as legacy

Wow - bold plan. I like it. But it might take decades. 😄

Do we have a way to find out which is better (polls, interviews, a usability study)?

Which question exactly are you interested in polling about? default vs initially? Or defaultvalue vs. just value for <input>? I don't have enough twitter followers to do effective polling, but I'm sure others on this thread do.

Do you think default* is a good prefix that works in more/most cases, going forward?

Yes.

Thanks!

[zcorpan]

defaultvalue vs value and defaultchecked vs checked for new elements (e.g. https://open-ui.org/components/checkbox) intended to replace <input type=x>.

[css-meeting-bot]

The Open UI Community Group just discussed [popup] Consider renaming initiallyopen #500, and agreed to the following:

• RESOLVED: Rename `initiallyopen` to `defaultopen`.

The full IRC log of that discussion

<hdv> Topic: [popup] Consider renaming initiallyopen #500
<hdv> github: https://github.com//issues/500
<JonathanNeal> q?
<hdv> masonf: this issue is bikeshedding renaming the initiallyopen attribute
<hdv> masonf: looks from my reading that there is consensus for changing to defaultopen
<jh3y> `defaultopen` +1
<scotto> +1
<bkardell_> +1
<masonf> Proposed resolution: Rename `initiallyopen` to `defaultopen`.
<JonathanNeal> q?
<hdv> masonf: so proposed resolution would be to rename initiallyopen to defaultopen
<jh3y> Matches framework usage too +1
<flackr> +1
<hdv> scotto: in HTML-AAM we are defining some stuff to default to align with existing stuff, that's my reason to +1 as it would be easir
<hdv> s/easir/easier
<JonathanNeal> q?
<masonf> RESOLVED: Rename `initiallyopen` to `defaultopen`.

[scottaohara]

as mentioned in the call today, HTML AAM is purposefully using the term 'default' in some updates we're doing now / will be doing in the future rather than using the term 'initial' or 'initially'

see w3c/html-aam#396

[mfreed7]

Per the resolution, I'm closing this issue.