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