– DRAFT –
Open UI Telecon

https://github.com/WICG/open-ui/issues/296

melanierichards: First topic is naming of the new popup element

melanierichards: we proposed a popup element, as discussed before, we have taken it to become an official OpenUI item. Some folks have said it doesn't make sense to them

melanierichards: it may imply directionality that is not always the case

melanierichards: so I wanted to do some bikeshedding, to think about what should we name this element

melanierichards: it should be generic enough so that it can cover all use cases, but also specific enough so that it doesn't get confused with other use cases or other parts of the web platform

melanierichards: my preferences among what's not popup would be 'popover', that's my personal preference.

masonf: is the issue with popup that it implies a direction?

masonf: like, up?

melanierichards: yes

melanierichards: it also didn't always make sense to people who didn't have English as their first language

davatron5000: is it called popup for any reason, like that ARIA has aria-haspopup?

melanierichards: it seemed most logical to the proposers

melanierichards: interesting that you bring that up, it could be a reason to keep popup

bkardell_: I'd say that is a strong argument for keeping popup, if, and only if, popup is like aria-haspopup

<Francis_Storr> https://adrianroselli.com/2020/03/stop-using-drop-down.html

Francis_Storr: Adrian Roselli wrote a blog post that went through 'popup' andwhy some things shouldn't be called popup if they aren't popups

<bkardell_> https://www.irccloud.com/pastebin/azncHB2Z/

masonf: we're trying not to invent new things… popups on web pages are pretty common as well

melanierichards: sounds like there are a few folks that would like to preserve the name as is… are there others who feel there are other reasons why we shoudl or should not use popup?

silverdust: the thing with popup is that the word is used for many other things

silverdust: so I think popover is better

<tantek> also pop-under windows are a known nasty anti-pattern of advertising windows

Francis_Storr: I like popover, it works better for me because it does go over other things

<tantek> since we're brainstorming pop-* terms

melanierichards: just to say, yes, it would go over everthing else

<davatron5000> here's one... <hovercraft>

bkardell_: I said earlier about 'if it is like the ARIA thing', but I looked it up and it does not seem to be the case, popup does not match the aria-haspopup

bkardell_: how inherently tied to 2021 is this? over time, different form factors and devices and experiments may change the assumptions we have now

bkardell_: it is top layer… but what is the thing you build with it? that would be the bigger question. Maybe on some other device it is not what we think now, the concept of top layer may be completely different

melanierichards: so basically it may not look like a popup, but still be top layer?

bkardell_: like with dialog, on some devices it would be the whole top layer

melanierichards: would using the term <popover> run into the same problem?

bkardell_: I think popup has this problem, and I feel it's not a great choice for that reason… I don't think popover has it

masonf: you mentioned this is not the same as aria-haspopup… can you explain?

bkardell_: in Adrian Roselli's piece, he lists a number of things that 'pop up' but are not referred to as popups

melanierichards: there are also things like listbox, that still may have aria-haspopup relationships

melanierichards: there may be an action for this group to go over this a bit more

<Zakim> tantek, you wanted to note the select vs popup, semantic vs presentational challenge

tantek: one of the challenges around popup… there is conflation of the semantics and the presentation… for instance, as soon as you went to mobile, popups didn't behave like popups… it's this notion of 'choose one control' vs 'choose multiple control'… 

<melanierichards> https://open-ui.org/components/popup.research.explainer/

tantek: are we standardising one specific presentation of a popup… or are we standardising semantics with multiple potential presentations?

<bkardell_> tbh "transient user interface (UI)" is a good explanation in the explainer

melanierichards: in the explainer, we say, the popup component is a foundational component that other components can build on top of

<tantek> got it

melanierichards: it doesn't lock you into a specific presentation

<silverdust> I have a demo of how a browser may implement the popover for mobile https://lqcoj.csb.app/

melanierichards: for instance, in some cases of it you may want multiple, like multiple listboxes, some you may not. Best to think of this component in terms of the behaviors we have defined, like light dismiss, rather than one specific use case

tantek: the big semantic distinction in listboxes is 'choose one' vs 'choose multiple' , there are many ways you could display this

tantek: so that's the kind of abstractions we've historically tried to explore

tantek: maybe people think popup, but they actually think 'choose one', they may not know about different ways to show it

tantek: do we want to be specific about possible presentations? looks like there are two dials: first is choose one / choose multiple semantic, the second the presentation of it

masonf: it sounds like the comments are more about the select proposal… I agree with the comments

masonf: popup would be more general purpose, so it is transient and pops up to the user, and it can be used to build choose one / choose many type of controls

bkardell_: it still applies I think… tantek is making a similar point to the point I made

bkardell_: a lot of existing systems will be popup-like, but it may not be like that on all possible systems

tantek: I got confused by the examples I saw first

masonf: illustrates the need to pick a good name

tantek: also good to think about what this means in contexts like audio

<tantek> and mobile, where there's a slide right to a "nested" state that needs to be resolved before going back to the previous state

melanierichards: we can explore this a bit more. There is a popup research PR that thinks about different use cases

melanierichards: maybe we need to resolve on the use cases, then get back to the element naming

melanierichards: we didn't want to flood the platform and create elements for all the possible use cases

<bkardell_> popup *might*be totally fine, even in the case I described

melanierichards: let's wrap here and go to the next. Action for us is to go back to the research

<tantek> popover does nicely distinguish it from the overloaded "popup" term

Action: melanierichards bring back up the research PR

https://github.com/WICG/open-ui/issues/311

<bkardell_> ugh, I *meant* to say popover might be totally fine :-p

melanierichards: masonf is working through building a prototype of popup in Chromium and wondered if the 'open' attribute is truly a blocker for this element

melanierichards: the 'open' attribute effectively can allow a developer to mark a popup as open, without requiring some invoking element, like an element that you want open on page load

melanierichards: we got some feedback early on… that it is important that it is declarative, i.e. does not require JavaScript

melanierichards: so the open attribute is part of that

melanierichards: I wanted to discuss today: is this element relevant for developers?

masonf: what Melanie said

masonf: I wonder what the use cases are… I understand 'open on page load', but it would be only a one line of JavaScript to do it… is it worth the complexity required to make it work declaratively?

masonf: I've also heard about the open attribute in dialog, it does not always seem to work well

flackr: there may be other components that have a more obvious use case for the 'open' attribute

<flackr> https://jsbin.com/leyosok/edit?html,js,output

flackr: I was just putting together a demo with radio buttons

flackr: I wonder if the attribute could set an initial state, but it is not live… 

masonf: it would simplify all of the complexity

<bkardell_> defaultOpen

flackr: my argument is that this is already the case with some input elements

masonf: right, but they have been around for a long time

silverdust: I think 'open' may clash with dismissal… when I open the webpage, some code may run before I encounter the element with the 'open' attribute

silverdust: when dismissable set to false, the popup would not have light dismiss behavior, so it may be easier to use open attribute on popups that don't have the light dismiss behavior

masonf: one of the key differences between dialog and popup is light dismiss, so it may be a better fit for your use case

masonf: I almost want 'transient' to be in the name of the popup element… that is really the key difference

<bkardell_> ttui

melanierichards: <transient-top-layer-ui>

bkardell_: dialog was not shipped to three major engines… way more common is <summary>/<details>, which also has an open attribute

bkardell_: there is some frustration that it is locked in to a specific representation that is bound to its specific concept. It does progressive disclosure, but not all use cases are the use case that matches its presentation

bkardell_: my other comment is… I like the idea that flackr said, as long as we change the name. (Because we can't have an attribute that is one multiple elements, but doesn't do the same thing.)

bkardell_: I would be in favour of an attribute that lets you declaritively set an initial state, not reflectively and not called 'open'

davatron5000: I like 'open', in the same way that I like 'hidden', I like the binary flip of it, from a developer perspective

<bkardell_> you can do that on the DOM API tho dave

<bkardell_> the DOM API IDL can can an open boolean, it just doesn't reflect to a live attrbute called open

davatron5000: what's nice about hidden that I can transition it

<bkardell_> +1 tantek

<bkardell_> :)

davatron5000: I like to be able to use the DOM IDL, things like element.open = !open

melanierichards: one thing I didn't mention, another use case for it to be an attribute is that it can be used as a style hook

bkardell_: the implementation of hidden is a UA style rule… so you can make its behavior be something else than hidden. But you can't do that with a summary/details

masonf: that's the same with popup, if it is closed, it is not there, you won't be able to do anything with it, so styling popup[open] would be the same as popup

<Francis_Storr> https://www.w3.org/TR/wai-aria-1.2/#dialog

Francis_Storr: ARIA has had the concept of a non-modal dialog, but it's never really gotten further than that word 'non-modal dialog'. It is a descendant window of a primary window

<tantek> good pointer Francis

dandclark: another use case for an IDL property… a compound control that uses a popup, like a custom select elements… when it is open I may want to check that in script, or do something based on timing.

<Francis_Storr> thanks @tantek :)

dandclark: the proposal has a 'hide' event, maybe we would also need a 'show' event, but if not done right I worry I would get out of sync

dandclark: having an IDL attribute I could look at would help with that

masonf: I should have made it clearer, I was not suggesting in my issues we're not thinking of removing the IDL attribute, it was just about the content attribute

<bkardell_> also for some components, just linking to content inside

tantek: we had some challenges with hidden states. There are pages that use summary/details or constructs similar to that, like GitHub… you want to do things like find all such elements in a page and then open them all. It is hard to tell up front whether a use of summary/details is one where that behavior would be useful or not

<silverdust> masonf: so I gave the point I raised some extra thought and I think by saying having to not have light dismiss I meant the light dismissal from visiting a different tab, resizing the browser, not clicking outside the popover

tantek: it would be useful for that to have some way for a developer to declare whether their element is 'findable'

<silverdust> Wish I could've articulated that better

<bkardell_> notes that linking to content inside as a solution could be declarative and work for melanie's use case

tantek: sometimes elements may need to be hidden but also findable

melanierichards: thanks everyone!

<tantek> there may be a WHATWG HTML issue open re: summary/details and findable, and hidden=findable, though I'd have to do some digging to find them (so to speak)

<melanierichards> thank you hdv for scribing!