[popup] Bikeshed: popup=popup is unusual

[mfreed7]

This issue was reported by @domenic here, and is being moved to the OpenUI repo.

---

The x=x pattern in HTML is generally used as a way to allow XML serializations (i.e. "XHTML") to do boolean attributes. I.e. instead of the simple <div checked>, you'd do <div checked="checked">, because XML does not allow value-less attributes.

We should probably avoid using this pattern for a non-boolean attribute, as it will confuse people.

Ideas:

• Rename the attribute. (E.g. toplayerbehavior=popup or toplayer=popup.)
• Rename the value. (E.g. popup=default, popup=onlyone.)
• Have no value, and just a state. (So you'd do <div popup> with no value to get this behavior.)

I imagine there's going to be a general bikeshedding fest on popup/hint/async, but I just wanted to note this as a relatively high-priority consideration in that bikeshed.

[mfreed7]

One more thing I've run into, related to this issue, as I've been implementing the Chromium prototype:

<script>
function popup() {
  ...do something...
}
</script>
<button onclick="popup()">Click me</button>

I've seen this example in several of our web tests now, and I'm wondering if it portends Web compat issues in the future. The issue is that within the onclick handler, this is the <button>, so popup() tries to call button.popup(), which is now the DOMString-valued IDL attribute on Element, so this throws. Renaming popup to something a bit more obscure would clearly help this potential issue.

[domenic]

I think you could fix that by adding [Unscopable] to the popup IDL attribute.

[css-meeting-bot]

The Open UI Community Group just discussed popup=popup.

The full IRC log of that discussion

<gregwhitworth> Topic: popup=popup
<gregwhitworth> github: https://github.com//issues/491
<andrico1234> masonf: there are 3 bikeshedding issues, that we can't resolve, but it's worth talking about them
<andrico1234> masonf: the easy one is renaming open, another doesn't have an issue, trigger popup attribute.
<andrico1234> masonf: the important one is, which changes the syntax is the popup attribute itself, a number of reason dominic bought up for considering why wemight want to change.
<bkardell_> q+
<andrico1234> masonf: he's in favour of changing the attribute or value it to something else, another issue i've run into is that popup is a common name
<andrico1234> masonf: in chromium, i've run into collisions when things are named popup, so i' in favour of renaming the attribute from popup to something else
<gregwhitworth> ack bkardell_
<andrico1234> bkardell_: I think popup as an attribute name seemed convenient at first, but might cause trouble. i support an alternative
<tantek> +1 bkardell_
<dandclark> q+
<una> q+
<gregwhitworth> ack dandclark
<andrico1234> dandclark: i agree, i like renaming it to toplayer as a name for the attribute, like bringing an element to the top layer.
<scotto_> +1 to toplayer
<gregwhitworth> ack una
<gregwhitworth> q+
<masonf> q+
<gregwhitworth> ack gregwhitworth
<andrico1234> una: i think toplayer is a little more explicit if popup is always toplayer, which i think it is. you could have popup inline, or in the top layer, so this could make it more clear if we want to distinguish them. i don't mind popup, but i don't mind toplayer, and it makes sense
<gregwhitworth> ack masonf
<masonf> Proposed resolution: we should rename the `popup` attribute to something else. Naming TBD.
<JonathanNeal> +1 for bikeshedding the name, desiring something more “oem”, namely to avoid patterns like `popup="popup"` which are uncommon (probably for the XML rationale).
<gregwhitworth> +1 to what everyone said
<andrico1234> masonf: i propose that we a resolution that we change the name, and the TBD is the name it should be. i like toplayer but we don't use dashes in attribute names so it looks like "to player". are there objections to naming it?
<tantek> +1 to renaming it
<dandclark> +1 to renaming
<JonathanNeal> +1 to renaming
<scotto_> +1 rename
<davatron5000> toupee-layer
<andrico1234> una: for me, it depends if there's a better option, if toplayer is a bad idea, then what's a name better than popup?
<andrico1234> masonf: we should propose to have a discussion about options for name
<masonf> Proposed resolution: we should rename the `popup` attribute to something else, if we can find a better name.
<JonathanNeal> +1 to it being 'bikeshedding' or 'consider an alternative name' :)
<tantek> +1
<andrico1234> gregwhitworth: please add what your names are so we can keep the bikeshedding discussion short next week
<andrico1234> gregwhitworth: can someone cover for me next week, because there's plenty to cover
<JonathanNeal> `pop="↑"` :P
<gregwhitworth> Resolved: we should rename the `popup` attribute to something else, if we can find a better name.
<gregwhitworth> Zakim, end meeting
<Zakim> As of this point the attendees have been JonathanNeal, flackr, andrico, davatron, dbaron, futekov, scotto_, kylegach, gregwhitworth, dandclark, miriam, masonf, bkardell_, battaglr,
<Zakim> ... una, tantek
<Zakim> RRSAgent, please draft minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2022/03/31-openui-minutes.html Zakim

[mfreed7]

I think you could fix that by adding [Unscopable] to the popup IDL attribute.

Ohh nice. Thanks for that - TIL about [Unscopable]. That might alleviate the pressure at least from a compat perspective. I will add that to the prototype right now.

Per the meeting just now, there's a desire to rename the attribute, if a better name can be found. We'd like folks to please suggest alternate names, and hopefully we can find something better. A leading contender is something like toplayer but the issue with that is that it looks like "To Player". Suggestions welcome.

[dandclark]

Maybe toplevel?

[una]

Not a direct opinion, just some considerations:

1. toplayer also describes other components (ie. dialog with showModal()). What's the difference between showModal() and showPopup()?
2. Why not popup=initial or popup=default instead of popup=popup

I don't mind renaming if there is something better, and toplayer is more clear RE: what this attribute is affecting.

That being said, I don't mind popup since we have bikeshed this before and landed on it being the best descriptor for a variety of components with shared behavior.

[mfreed7]

While you're in a bikeshedding mood, please don't forget to also look at the other two popup-related issues:

• [popup] Consider renaming initiallyopen #500
• [popup] Consider renaming triggerpopup #508

[css-meeting-bot]

The Open UI Community Group just discussed [popup] Carryover: popup=popup is unusual #491 (timebox to 10 mins), and agreed to the following:

• RESOLVED: keep the attribute as 'popup' and bikeshed a replacement for the 'popup' *value*.

The full IRC log of that discussion

<hdv> Topic: [popup] Carryover: popup=popup is unusual #491 (timebox to 10 mins)
<Travis> https://github.com//issues/491
<hdv> github: https://github.com//issues/491
<hdv> masonf: we discussed this last time, there are two issues we're bikeshedding, most important is the name of the attr itself
<hdv> masonf: suggestions include toplayer, toplevel, topmost
<hdv> masonf: we also should discuss attribute values. Currently a value is `popup`, that's the genesis of this isusues as it seems odd to have a value that is the same as the name of the attribute
<JonathanNeal> How do we request to ask a question again?
<hdv> masonf: another value is `hint`, behaves like tooltip, or @@@
<bkardell_> q followed by +
<hdv> JonathanNeal: my question about popup=popup, was the concern this conforming to a pattern in HTML attributes where they don't tend to mimic the value of the attr name? is that a concern?
<hdv> masonf: that's why this issue was raised by Domenic, generally because generally not used in HTML, doesn't seem to be a hard rule, but ideally something to avoid, is how I interpreted that
<Travis> q?
<JonathanNeal> q+
<flackr> +1 I like the name, and would prefer to see popup value change
<hdv> masonf: personally I like the word popup, it concisely and accurately describes the behavior, so perhaps the best is to find a better value for the default 'normal' popup
<hdv> s/the word/the attribute name
<hdv> q?
<flackr> q+
<hdv> ack Jon
<hdv> JonathanNeal: was the issue with the role and aria-modal=false still an issue?
<hdv> masonf: basically we sidestepped the role discussion because we moved away from choosing a specific element and towards using an attribute
<hdv> JonathanNeal: is the conflict resolved for hint, if aria-modal=false?
<hdv> masonf: could you be more specific about what the issue was?
<hdv> JonathanNeal: I learned the different values for popup were related to specific roles for popup, and I saw in an issue somewhere that that would not be allowed for a popup? this issue is linked from 491
<hdv> JonathanNeal: if I know what it reflects, I might be better at bikeshedding names
<JonathanNeal> it was in #410
<hdv> masonf: sounds like that is an older, popup element discussion
<hdv> s/491/410
<hdv> scotto: I think it has been misread, we should probably review again
<dandclark> q+
<hdv> masonf: I'll close the issue where we decided not to go for a popup element
<hdv> q?
<hdv> ack flackr
<JonathanNeal> I am sorry if my questions did not make sense, but I am glad it helped close an issue.
<hdv> flackr: I like the name popup for the attribute, so I agree we probably need to find a new name for the popup value
<hdv> dandclark: I would support a resolution that keeps the popup attribute name
<hdv> dandclark: I also like una's suggestion of popup=default
<masonf> or maybe 'standard'
<hdv> dandclark: I like framing the popup behavior as the default thing, seems reasonable
<masonf> q?
<hdv> ack dan
<una> I also like `popup=default` :)
<hdv> dbaron: just trying to think of uses for popup, or the default popup or whatever we want ot call it… I haven't been following this for long… a default kind of popup is something that is attached to some control… the others seem more loosely attached?
<una> q+
<hdv> dbaron: a tooltip doesn't feel like it is attached to any specific place? maybe this is useful in terms of naming?
<JonathanNeal> Wild Idea — but since I am unclear on the story where these are serialized values shipped with initial HTML, I am in favor of popup being a property or a css property.
<hdv> ack dbaron
<masonf> Proposed resolution: keep the attribute as 'popup' and bikeshed a replacement for the 'popup' *value*.
<Travis> aria-haspopup=true
<masonf> travis, that goes on the element that triggers the popup.
<hdv> una: there are so many use cases for popup… like you might want a standalone dialog experience, or a menu that is dismissable, some may be attached during positioning some might not … I like the popup attribute
<hdv> una: I could also imagine popup=true or just having popup would trigger the default behavior
<masonf> RESOLVED: keep the attribute as 'popup' and bikeshed a replacement for the 'popup' *value*.
<Travis> https://github.com//issues/500

[flackr]

I think it would be helpful to look back to the behavioral differences

Roughly:

• popup implies uniqueness, dismisses only on an explicit action.
• hint implies uniqueness, dismisses on action or timeout.
• async is not unique, and only timeout dismissal.

There is also the subtle difference that opening a popup dismisses popups and hints where opening a hint only dismisses hints, however it's a bit unclear to me in what use case you would be opening a hint that wasn't nested in the current popup when any interaction with this element would cause dismissal of the popup.

With this in mind, I think I would propose the main popup value be sync (the opposite of async). I'd also consider modal since while it doesn't force you to interact with the popup (due to light dismiss), you're still not able to interact with any content outside of the popup without first implicitly dismissing the popup.

[scottaohara]

FWIW, I like the sync suggestion.

I'd be very wary of modal, and to Una's question:

What's the difference between showModal() and showPopup()

I would not consider these to be the same. A popup doesn't / shouldn't have to be modal by default. E.g., the example i mention in this issue, and others I can think of but don't want to bog this issue down (but would be happy to discuss if interested). Rather, I'd expect that if someone needed a modal popup, they should use other features to do so (e.g., inert or maybe they're really just invoking a modal dialog at that point).

[zcorpan]

Related: #514

[mfreed7]

I'll leave the bikeshedding going for values, thanks for all of the suggestions! But I wanted to talk quickly about this part:

There is also the subtle difference that opening a popup dismisses popups and hints where opening a hint only dismisses hints, however it's a bit unclear to me in what use case you would be opening a hint that wasn't nested in the current popup when any interaction with this element would cause dismissal of the popup.

The use case that this behavior has in mind is a popup (for example a select menu) that is open on one part of the page, and the user moves the mouse over another element on the page (separate from the select menu) and hovers it. That hover triggers a tooltip which is unrelated to the select menu, so it should not close the select's listbox. But it should also show up, so they can read the tooltip.

Rather, I'd expect that if someone needed a modal popup, they should use other features to do so (e.g., inert or maybe they're really just invoking a modal dialog at that point).

Also a very quick +1 to this comment. I think "modal popup" should be an oxymoron. If you want something truly "modal", you should use the <dialog> element and its .showModal() invoker. Popups are by definition transient, and transient things can't be modal.

Related: #514

Thanks for the reference - for context, this issue raises the possibility of allowing just <div popup> (without an explicit value) to signify the "normal" case. I.e. equivalent to the current proposal's <div popup=popup>. I like this idea for two reasons: 1) It makes the common case easier to type, and 2) it avoids what appear to be some awkward naming choices for this default behavior's value.

[css-meeting-bot]

The Open UI Community Group just discussed [popup] Bikeshed: popup=popup is unusual #491.

The full IRC log of that discussion

<hdv> Topic: [popup] Bikeshed: popup=popup is unusual #491
<hdv> github: https://github.com//issues/491
<hdv> masonf: This one is bikeshedding on the popup attribute… the attribute name is popup and will stay popup, but the question is, what should the values be named?
<JonathanNeal> q+
<hdv> masonf: one is popup=popup, it's like popup with 'normal rules', see explainer, and then popup=hint and popup=async (like a toast; no light dismiss)
<hdv> masonf: those ar the three we've currently proposed
<hdv> s/ar/are
<hdv> masonf: naming of all three is in question, but let's start with the one for the normal behavior
<JonathanNeal> q?
<hdv> masonf: maybe it could be leaving the popup attribute without value
<bkardell_> <div popup="" vs <div popup ?which one masonf ?
<hdv> JonathanNeal: had it been considered to have the empty and popup value mean the same thing? So that way the boolean continued to work and the XML variant continued to work?
<hdv> masonf: I don't now if it has been explicitly proposed, not sure if anyone disagrees with allowing that
<JonathanNeal> q?
<flackr> q+
<JonathanNeal> ack JonathanNeal
<hdv> [ +1 sounds good to me to have that variant as well ]
<JonathanNeal> ack flackr
<dandclark> q+
<bkardell_> popup="plain | extra-cheese | peperoni"
<hdv> flackr: I would disagree with allowing both… the popup attribute has the general attribute of producing a popup… it would be weird if the popup attribute would have a value that doesnt meant the same as the popup
<JonathanNeal> q?
<hdv> masonf: are you disagreeing with allowing both?
<hdv> flackr: just with requiring it
<JonathanNeal> q?
<bkardell_> q+
<hdv> dandclark: I agree with flackr on this… it's difficult to talk about, I prefer to just have the boolean attribute, not a fan of allowing both the boolean and popup=popup. Multiple ways to do the same is confusing and popup=popup seems confusing
<JonathanNeal> ack dandclark
<JonathanNeal> ack bkardell_
<hdv> bkardell_: to be sure I'm understanding correctly… popup with no `=` is what we're saying, right?
<hdv> bkardell_: what if you did empty string? `popup=""`
<JonathanNeal> q?
<hdv> masonf: that's how we would technically have to implement as `popup` and `popup=""` are technically equivalent
<hdv> bkardell_: how would you remove the popupness?
<hdv> masonf: remove the attribute?
<hdv> s/?//
<hdv> bkardell_: what if you add anything in the value?
<hdv> s/bkardell_/JonathanNeal
<bkardell_> so that means that "" is explcitly an allowed value?
<hdv> JonathanNeal: was thinking when I was passing a value to something in a template, it is possible for me to pass an empty string in…
<hdv> flackr: we could consider explicitly supporting popup=false or popup=none
<hdv> JonathanNeal: am more thinking about the default value…
<JonathanNeal> q?
<hdv> scotto: if I add required="lol" if I add it into an input it would still be required… 
<hdv> masonf: but that's a boolean attribute
<hdv> scotto: right, but the same goes for the hidden attribute
<hdv> masonf: that was done for backwards compat, which we're not constrained by here… but if it's a pattern… 
<flackr> q+
<davatron5000> reminds me of checked=checked
<hdv> bkardell_: I think the boolean nature is somewhat confusing on this stuff
<hdv> bkardell_: I would almost consider giving it a name, like popup=simple or something
<JonathanNeal> Is `popup=""` synonymous for `popup="default"` an option? Sorry if this is too similar to my earlier question.
<hdv> bkardell_: because there are parallels with like hidden that was a boolean before but no longer
<hdv> bkardell_: if we just give it a name all these problems go away
<hdv> masonf: good point…
<JonathanNeal> ack flackr
<hdv> flackr: the advantage of treating any invalid value as the default popup behavior is that even if we decided the name would be popup, or others, it would just resolve to popup behavior, you could then even do popup=popup in your XML if you needed to
<JonathanNeal> q?
<hdv> JonathanNeal: do we have a resolution on this?
<hdv> masonf: I didn't hear consensus on anything specifically… but maybe if we allow anything that's not hint or async it would be the default and then most of the things we talked about would work (like popup=popup)
<hdv> flackr: on the issue there was 'sync', because it was kind of the opposite of 'async'
<bkardell_> scotto: you htink that popup="blah" should be work like current 'popup=popup', right?
<bkardell_> q+
<hdv> una: I thought the original issue was popup=popup was a problem… so popup=default instead of popup=popup could be a solution
<JonathanNeal> +1 to the popup="" / popup="default" option
<hdv> una: and then we don't need to worry about figuring out what a no value would mean… so default could be default
<JonathanNeal> q?
<hdv> scotto: I like default
<dandclark> I like popup="default".
<masonf> Proposed resolution: the new value for "standard popup" should be "default", and invalid values should resolve to a "standard popup".
<hdv> bkardell_: I also like default… but backtracking a little… the convo we had before about what happens with another value, is pertinent to this
<hdv> una: I agree that needs to be sorted out
<dandclark> q+ to mention compatibility concern
<hdv> bkardell_: so you could use popup=whatever and it would be the same (even popup=false, unfortunately but pretty normal)
<JonathanNeal> q?
<masonf> q+
<JonathanNeal> ack bkardell_
<JonathanNeal> ack dandclark
<Zakim> dandclark, you wanted to mention compatibility concern
<Alexander_Futekov> q+
<hdv> dandclark: for the second part of that resolution… what if we're introducing a new popup type later, might that lead to web compat issues?
<hdv> dandclark: that might be a potential downside?
<JonathanNeal> q?
<JonathanNeal> ack masonf
<hdv> masonf: I was on the queue for the same… I would be a bit concerned about that… there is another issue defining the behaviors of the other types, I am not completely convinced that they're the only types we'll ever define
<JonathanNeal> +1 to the popup="" / popup="default" option
<hdv> scotto: there is a way as long as there is a default value… if it is expected that you have to use one of these values to use it, I don't have the concern for an invalid value to default to something
<hdv> scotto: I was concerned because with other attrs that work like defaulting to something there's an issue, was more of an author education point
<hdv> Alexander_Futekov: I am not convinced that we should have a default option because not sure how this will scale… if we have a popup that is async and one that is a hint, and another one that is popup, then what is popup? why not use popup=modal?
<JonathanNeal> q?
<hdv> masonf: because it is technically not a modal
<hdv> Alexander_Futekov: I think we have to find a term that says more
<hdv> masonf: what about default?
<JonathanNeal> if `popup="default"` is a default popup, then is `popup="hint"` a hint popup?
<JonathanNeal> q?
<JonathanNeal> ack Alexander_Futekov
<hdv> Alexander_Futekov: it's the most common pattern now, but might not be in the future?
<hdv> JonathanNeal: is popup=default describable as a 'default popup', or like popup=hint can be described as a 'hint popup'?
<bkardell_> popup="2022"
<hdv> masonf: the hint popup makes sense, but as Alexander_Futekov raised what is that?
<hdv> una: if we use another term we still need to define it
<hdv> scotto: I agree with that, there is a common expectation of what the default is and that can be defined
<hdv> scotto: if other popups come to be, we define those as well
<hdv> scotto: there has to be a default
<JonathanNeal> q?
<masonf> Proposed resolution: we should pick a new value for "standard popup" which isn't the word "popup", and invalid values should behave as if the `popup` attribute is not present.
<hdv> JonathanNeal: so does that mean your proposed resolution would stay the same?
<scotto> +1 to what mason just said
<Alexander_Futekov> +1
<dandclark> +1
<hdv> +1
<JonathanNeal> +1
<hdv> bkardell_: if we had no fallback, let's say chromium implement, say, spicy popup, but firefox only implemented bland regular popup, the end user experience would do nothing?
<hdv> una: I don't know if we can resolve this today
<hdv> JonathanNeal: as someone who likes to write polyfill things… getting the raw value and feature detecting, that's helpful… not opposed in that sense
<bkardell_> computedPopup :)
<hdv> masonf: so as long as you could feature detect you would be happy?
<bkardell_> that is the opposite of what most features in html do, no?
<hdv> JonathanNeal: it is harder when the browser throws it away and I have no access to it, than when the browser says this is what I thought I got… 
<hdv> masonf: great feedback thanks
<hdv> JonathanNeal: looks like we won't achieve a resolution on that today
<hdv> JonathanNeal: thanks everyone for attending today!
<bkardell_> hdv: thanks for scribing!
<hdv> RRSAgent, end meeting please
<RRSAgent> I'm logging. I don't understand 'end meeting', hdv. Try /msg RRSAgent help
<JonathanNeal> hdv: thank you!!!
<hdv> RRSAgent, make minutes please
<RRSAgent> I have made the request to generate https://www.w3.org/2022/04/28-openui-minutes.html hdv
<hdv> Zakim, end meeting
<Zakim> As of this point the attendees have been masonf, flackr, JonathanNeal, davatron, miriam, andrico, una, scotto, bkardell_, dbaron
<Zakim> RRSAgent, please draft minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2022/04/28-openui-minutes.html Zakim
<Zakim> I am happy to have been of service, hdv; please remember to excuse RRSAgent. Goodbye

[mfreed7]

Just to highlight and summarize what I heard in the discussion:

1. There was fairly good consensus that we should rename the "standard popup" value from popup to something else, to avoid popup=popup.
2. There was significant discussion about the behavior for "invalid" values. While it might be desirable to allow invalid values to default to "standard popup" behavior, that would come with fairly significant forward-compatibility issues, if we ever want to add or change values for this attribute. So I think we reached rough agreement that invalid values should behave as if there is no popup attribute present, potentially with a console warning.
3. We discussed, at length, the option to give the popup attribute a "boolean-like" value, where <div popup> would confer "standard popup" behavior. However, that came with additional complications, such as behavior in frameworks (where a value like true might be assigned), whether empty values (<div popup="">) would behave the same way, and whether there should also be a string name for this behavior. In the end, I think we reached rough agreement that we should not pursue a "boolean-like" behavior.
4. I feel that we were close to agreement that we should simply pick a better name for "standard popup" behavior, perhaps one that better describes what "standard popup" behavior actually is. Some suggestions that were proposed include: default, standard, and sync. Other suggestions welcome.
5. There wasn't a lot of discussion about hint and async values at all.

The above is just what I heard - please feel free to chime in if I missed something or if you disagree with anything. Otherwise, suggestions for a value that means "standard popup" with these behaviors would be appreciated.

[mfreed7]

I added agenda+ to try to resolve on the bolded phrases in the comment above. Please chime in here if you disagree with those points.

Assuming general agreement, we need to pick a name for the "standard popup" value. Please either vote with emojis, or propose an alternative (in which case I'll edit this comment to add your suggestion):

• popup=default 🚀
• popup=standard 😄
• popup=sync 👍
• popup=auto 🎉

[Edit: based on this comment, I've added another alternative, popup=auto. Feel free to change your vote, if you want!]

[domenic]

Strong -1 for popup=standard. All popup="" values will be standard, hopefully.

[css-meeting-bot]

The Open UI Community Group just discussed [popup] Bikeshed: popup=popup is unusual, and agreed to the following:

• RESOLVED: rename the "standard popup" value to something else (to be chosen), and make invalid values, including empty/boolean-like values, behave as if there is no popup attribute present. Also, the IDL reflection of the `popup` value should reflect what was used, to allow feature detection.

The full IRC log of that discussion

<gregwhitworth> Topic: [popup] Bikeshed: popup=popup is unusual
<gregwhitworth> github: https://github.com//issues/491
<gregwhitworth> q?
<bkardell_> masonf: We discussed this last week and we got close but didn't reach a resolution
<bkardell_> masonf: we're trying to find a value for popup="the normal thing"
<bkardell_> masonf: we discussed boolean, we talked about what happens for invalid values - both ran into troubles.
<gregwhitworth> q?
<flackr> q+
<bkardell_> masonf: the rough concensus I thought I heard is we should rename with an explicit name, and make it so invalid values act as if there is no value at all and don't allow an empty boolean value
<gregwhitworth> ack flackr
<bkardell_> flackr: I generally like the proposal. Can developers test whether it resolved correctly
<bkardell_> masonf: yeah, we discussed that - to make the idl reflection only reflect the used value
<bkardell_> flackr: that sounds great
<masonf> Proposed resolution: rename the "standard popup" value to something else (to be chosen), and make invalid values, including empty/boolean-like values, behave as if there is no popup attribute present.
<gregwhitworth> bkardell_: is there an attribute that works like that today?
<bkardell_> JonathanNeal: if you create an input with a type"willywonka" the .type is "text"
<bkardell_> bkardell_: cool
<bkardell_> flackr: it is consistent with what we decided
<bkardell_> bkardell_: yay!
<masonf> Proposed resolution: rename the "standard popup" value to something else (to be chosen), and make invalid values, including empty/boolean-like values, behave as if there is no popup attribute present. Also, the IDL reflection of the `popup` value should reflect what was used, to allow feature detection.
<bkardell_> +1 to the resolution
<flackr> +1
<dandclark> +1
<bkardell_> resolved
<masonf> RESOLVED: rename the "standard popup" value to something else (to be chosen), and make invalid values, including empty/boolean-like values, behave as if there is no popup attribute present. Also, the IDL reflection of the `popup` value should reflect what was used, to allow feature detection.

[mfreed7]

Ok, per the resolution, we just need to pick a name. Please vote! I'd like to bring this back up next week and resolve on the name that gets the most votes here.

[AmeliaBR]

I've just read the description of what the values should do. From that, I understand that the value you want to name is an exclusive popup. It closes all other pop-ups/dialogs (except its ancestors) when it is opened; and it is automatically closed by any other pop-up or dialog opening.

I would not have guessed this based on a name like popup, default, standard. Maybe auto makes sense in that it triggers an auto-closing behavior, but that isn't clear; auto could just as easily refer to an auto-opening behavior which might be added in the future!

Of the choices in the poll, I would therefore vote for sync because it contrasts against async for the non-exclusive option. But, I don't really think that sync and async are the correct words for either. This isn't just about time-ordering, it's about whether it interrupts other actions.

I would therefore vote for changing both these values to something that more clearly defines the difference between them:

• popup=exclusive vs non-exclusive
• popup=unique vs multiple
• popup=only vs many

[mfreed7]

Thanks for all of the great new suggestions for names here! From the original poll, popup=auto got the most votes, with 7, followed closely by popup=default with 5 votes. Since there have been some new additions, I'm inclined to try to re-organize them here for a runoff poll, where I've included only auto and default from the original:

• popup=auto 🎉
• popup=default 🚀
• popup=basic 👍
• popup=simple 😄
• popup=native 😕
• popup=exclusive ❤️
• popup=unique 👀
• popup=only 👎 (sorry, last available emoji)

Please vote early and often.

[zcorpan]

I'll note that in #500 the initiallyopen attribute was renamed to defaultopen. So when used together the options here would look like:

• <div popup=auto defaultopen>...</div>
• <div popup=default defaultopen>...</div>
• <div popup=basic defaultopen>...</div>
• <div popup=simple defaultopen>...</div>
• <div popup=native defaultopen>...</div>
• <div popup=exclusive defaultopen>...</div>
• <div popup=unique defaultopen>...</div>
• <div popup=only defaultopen>...</div>

[mfreed7]

Reminder: I'm looking for a final resolution on a name here at the meeting tomorrow.

Please vote!

[mfreed7]

Also note that #533 reopens a part of our last resolution on this issue. But it contains some potentially-new context, and is worth a read.

[mfreed7]

The Open UI Community Group just discussed [popup] Bikeshed: popup=popup is unusual, and agreed to the following:

• RESOLVED: Rename `popup=popup` to `popup=auto`.

The full IRC log of that discussion

[11:36]  masonf: another bikeshedding issue… we talked about it many times. For the value we used to call popup=popup, we want to replace the popup value with something else.
[11:36]  masonf: this one got a bit more voting… it got down to two: popup=auto and popup=default… currently 'auto' is winning by 1
[11:37]  q+
[11:37] * Zakim sees gregwhitworth on the speaker queue
[11:37]  masonf: multiple people voted for multiple options
[11:37]  masonf: resolution would be to go for 'auto'… 
[11:37]  ack gregwhitworth
[11:37] * Zakim sees no one on the speaker queue
[11:37]  q+
[11:37] * Zakim sees masonf on the speaker queue
[11:37]  I feel the opposite for the same reasons :)
[11:37]  gregwhitworth: I like auto it feels it describes well what it tries to do
[11:38]  ack masonf
[11:38] * Zakim sees no one on the speaker queue
[11:38]  +1 to `auto` if we wanted to resolved.
[11:38]  masonf: there is a separate discussion too about what to do with 'no value'  situation
[11:38]  q+
[11:38] * Zakim sees JonathanNeal on the speaker queue
[11:39]  ack JonathanNeal
[11:39] * Zakim sees no one on the speaker queue
[11:39]  JonathanNeal: I like all of this… my question is since top voted things were `auto` and `default`… we have been discuss `default` as a different meaning for things in a reflection sense… do we think that should influence our decision here? Sometimes in attribute name default takes on a different meaning, which is why I preferred auto
[11:40]  JonathanNeal: what do others think?
[11:40]  q+
[11:40] * Zakim sees masonf on the speaker queue
[11:40]  JonathanNeal: I wanted to avoid defualt as it started to take on meaning on the web that would not be useful here
[11:40]  ack masonf
[11:40] * Zakim sees no one on the speaker queue
[11:40]  masonf: I like that point, default does have some other meaning… but auto also has a different meaning in CSS, auto is the default
[11:40]  +1 to mason maybe +1’ing me :)
[11:40]  gregwhitworth: was my point too, 'do the thing you're supposed to do'
[11:41]  Proposed resolution: Rename `popup=popup` to `popup=auto`.
[11:41]  +1
[11:41]  +1
[11:41]  [ fantasai did a fantastic talk on `auto` in CSS https://vimeo.com/134597090 ]
[11:41]  [ matches what gregwhitworth and others say about it ]
[11:42]  RESOLVED: Rename `popup=popup` to `popup=auto`.
[11:42]  up next: rename space to tabs
[11:42]  noooo

[mfreed7]

(Above manually posted from these minutes.)

I'm going to close this issue! Thanks everyone for the great contributions and discussion around this overall topic.

[css-meeting-bot]

The Open UI Community Group just discussed [popup] Bikeshed: popup=popup is unusual #491, and agreed to the following:

• RESOLVED: Rename `popup=popup` to `popup=auto`.

The full IRC log of that discussion

<hdv> Topic: [popup] Bikeshed: popup=popup is unusual #491
<gregwhitworth> github: https://github.com//issues/491
<hdv> masonf: another bikeshedding issue… we talked about it many times. For the value we used to call popup=popup, we want to replace the popup value with something else.
<hdv> masonf: this one got a bit more voting… it got down to two: popup=auto and popup=default… currently 'auto' is winning by 1
<gregwhitworth> q+
<hdv> masonf: multiple people voted for multiple options
<hdv> masonf: resolution would be to go for 'auto'… 
<gregwhitworth> ack gregwhitworth
<masonf> q+
<bkardell_> I feel the opposite for the same reasons :)
<hdv> gregwhitworth: I like auto it feels it describes well what it tries to do
<gregwhitworth> ack masonf
<JonathanNeal> +1 to `auto` if we wanted to resolved.
<hdv> masonf: there is a separate discussion too about what to do with 'no value' situation
<JonathanNeal> q+
<gregwhitworth> ack JonathanNeal
<hdv> JonathanNeal: I like all of this… my question is since top voted things were `auto` and `default`… we have been discuss `default` as a different meaning for things in a reflection sense… do we think that should influence our decision here? Sometimes in attribute name default takes on a different meaning, which is why I preferred auto
<hdv> JonathanNeal: what do others think?
<masonf> q+
<hdv> JonathanNeal: I wanted to avoid defualt as it started to take on meaning on the web that would not be useful here
<gregwhitworth> ack masonf
<hdv> masonf: I like that point, default does have some other meaning… but auto also has a different meaning in CSS, auto is the default
<JonathanNeal> +1 to mason maybe +1’ing me :)
<hdv> gregwhitworth: was my point too, 'do the thing you're supposed to do'
<masonf> Proposed resolution: Rename `popup=popup` to `popup=auto`.
<JonathanNeal> +1
<flackr> +1
<hdv> [ fantasai did a fantastic talk on `auto` in CSS https://vimeo.com/134597090 ]
<hdv> [ matches what gregwhitworth and others say about it ]
<masonf> RESOLVED: Rename `popup=popup` to `popup=auto`.
<JonathanNeal> up next: rename space to tabs
<hdv> noooo
<gregwhitworth> Zakim, end meeting
<Zakim> As of this point the attendees have been hdv, gregwhitworth, miriam, JonathanNeal, tantek, scotto, bkardell_, emilio, flackr, masonf, dbaron
<Zakim> RRSAgent, please draft minutes
<RRSAgent> I have made the request to generate https://www.w3.org/2022/05/19-openui-minutes.html Zakim
<Zakim> I am happy to have been of service, gregwhitworth; please remember to excuse RRSAgent. Goodbye
<masonf> nice job minuting as always hdv
<JonathanNeal> Yes! thank you so much, hdv.
<masonf> It doesn't appear to have copied the minutes or the resolution to #491. I'll copy/paste them...