18:02:50 <RRSAgent> RRSAgent has joined #openui
18:02:50 <RRSAgent> logging to https://www.w3.org/2021/04/08-openui-irc
18:03:00 <melanierichards> Zakim, start meeting
18:03:00 <Zakim> RRSAgent, make logs Public
18:03:01 <Zakim> please title this meeting ("meeting: ..."), melanierichards
18:03:25 <melanierichards> meeting: Open UI Telecon
18:03:29 <masonf> masonf has joined #openui
18:03:32 <masonf> present+
18:03:36 <melanierichards> present+
18:03:40 <hdv> present+
18:03:56 <melanierichards> scribenick: hdv
18:03:57 <dandclark> present+
18:04:00 <Francis_Storr> present+
18:04:04 <silverdust> present+
18:04:23 <flackr> present+
18:04:25 <hdv> RRSAgent, draft minutes
18:04:25 <RRSAgent> I have made the request to generate https://www.w3.org/2021/04/08-openui-minutes.html hdv
18:04:29 <bkardell_> bkardell_ has joined #openui
18:04:29 <miriam> present+
18:04:39 <melanierichards> present+
18:04:40 <bkardell_> present+
18:05:13 <melanierichards> topic: https://github.com/WICG/open-ui/issues/296
18:05:26 <hdv> melanierichards: First topic is naming of the new popup element
18:05:55 <hdv> 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
18:06:04 <hdv> melanierichards: it may imply directionality that is not always the case
18:06:15 <hdv> melanierichards: so I wanted to do some bikeshedding, to think about what should we name this element
18:06:38 <hdv> 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
18:06:50 <davatron5000> davatron5000 has joined #openui
18:06:58 <hdv> melanierichards: my preferences among what's not popup would be 'popover', that's my personal preference.
18:07:16 <melanierichards> q?
18:07:18 <masonf> q+
18:07:34 <hdv> masonf: is the issue with popup that it implies a direction?
18:07:44 <hdv> masonf: like, up?
18:07:46 <hdv> melanierichards: yes
18:07:53 <davatron5000> q+ Is it called popup because of aria-haspopup?
18:07:59 <davatron5000> q+
18:08:06 <hdv> melanierichards: it also didn't always make sense to people who didn't have English as their first language
18:08:07 <melanierichards> q?
18:08:21 <hdv> davatron5000: is it called popup for any reason, like that ARIA has aria-haspopup?
18:08:28 <hdv> melanierichards: it seemed most logical to the proposers
18:08:48 <hdv> melanierichards: interesting that you bring that up, it could be a reason to keep popup
18:08:51 <melanierichards> q- masonf
18:08:56 <melanierichards> q- davatron
18:09:00 <masonf> q+
18:09:14 <hdv> bkardell_: I'd say that is a strong argument for keeping popup, if, and only if, popup is like aria-haspopup
18:09:30 <Francis_Storr> https://adrianroselli.com/2020/03/stop-using-drop-down.html
18:09:54 <hdv> 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
18:10:16 <bkardell_> https://www.irccloud.com/pastebin/azncHB2Z/
18:10:37 <hdv> masonf: we're trying not to invent new things… popups on web pages are pretty common as well
18:10:40 <tantek> tantek has joined #openui
18:10:59 <silverdust> q+
18:11:10 <hdv> 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?
18:11:17 <melanierichards> q- masonf
18:11:40 <hdv> joseph: the thing with popup is that the word is used for many other things
18:11:56 <tantek> present+
18:11:57 <hdv> s/joseph/silverdust
18:12:12 <bkardell_> q+
18:12:12 <hdv> silverdust: so I think popover is better
18:13:05 <tantek> also pop-under windows are a known nasty anti-pattern of advertising windows
18:13:11 <hdv> Francis_Storr: I like popover, it works better for me because it does go over other things
18:13:14 <tantek> since we're brainstorming pop-* terms
18:13:18 <melanierichards> q?
18:13:19 <masonf> q?
18:13:24 <hdv> melanierichards: just to say, yes, it would go over everthing else
18:13:26 <melanierichards> q- silverdust
18:13:31 <hdv> ack bkardell_
18:13:53 <davatron5000> here's one... <hovercraft>
18:14:06 <hdv> 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
18:14:41 <hdv> bkardell_: how inherently tied to 2021 is this? over time, different form factors and devices and experiments may change the assumptions we hav now
18:14:51 <hdv> s/hav/have
18:15:21 <hdv> 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
18:15:40 <hdv> melanierichards: so basically it may not look like a popup, but still be top layer?
18:15:57 <hdv> bkardell_: like with dialog, on some devices it would be the whole top layer
18:16:12 <hdv> melanierichards: would using the term <popover> run into the same problem?
18:16:46 <hdv> 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
18:16:52 <melanierichards> q?
18:16:55 <tantek> q+ to note the select vs popup, semantic vs presentational challenge
18:17:08 <hdv> masonf: you mentioned this is not the same as aria-haspopup… can you explain?
18:17:33 <hdv> bkardell_: in Adrian Roselli's piece, he lists a number of things that 'pop up' but are not referred to as popups
18:18:00 <hdv> melanierichards: there are also things like listbox, that still may have aria-haspopup relationships
18:18:17 <hdv> melanierichards: there may be an action for this group to go over this a bit more
18:18:18 <melanierichards> q?
18:18:44 <hdv> ack tantek
18:18:44 <Zakim> tantek, you wanted to note the select vs popup, semantic vs presentational challenge
18:19:45 <hdv> 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'… 
18:20:26 <melanierichards> https://open-ui.org/components/popup.research.explainer/
18:20:28 <hdv> tantek: are we standardising one specific presentation of a popup… or are we standardising semantics with multiple potential presentations?
18:20:45 <bkardell_> tbh "transient user interface (UI)" is a good explanation in the explainer
18:20:55 <hdv> melanierichards: in the explainer, we say, the popup component is a foundational component that other components can build on top of
18:21:07 <tantek> got it
18:21:22 <hdv> melanierichards: it doesn't lock you into a specific presentation
18:22:03 <silverdust> I have a demo of how a browser may implement the popover for mobile https://lqcoj.csb.app/
18:22:12 <hdv> 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
18:22:48 <hdv> tantek: the big semantic distinction in listboxes is 'choose one' vs 'choose multiple' , there are many ways you could display this
18:23:03 <hdv> tantek: so that's the kind of abstractions we've historically tried to explore
18:24:07 <hdv> tantek: maybe people think popup, but they actually think 'choose one', they may not know about different ways to show it
18:25:05 <hdv> 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
18:25:34 <hdv> masonf: it sounds like the comments are more about the select proposal… I agree with the comments
18:26:02 <hdv> 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
18:26:40 <hdv> bkardell_: it still applies I think… tantek is making a similar point to the point I made
18:27:15 <hdv> bkardell_: a lot of existing systems will be popup-like, but it may not be like that on all possible systems
18:27:51 <hdv> tantek: I got confused by the examples I saw first
18:27:57 <hdv> masonf: illustrates the need to pick a good name
18:28:08 <melanierichards> q?
18:28:14 <hdv> tantek: also good to think about what this means in contexts like audio
18:28:42 <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
18:28:58 <hdv> melanierichards: we can explore this a bit more. There is a popup research PR that thinks about different use cases
18:29:16 <hdv> melanierichards: maybe we need to resolve on the use cases, then get back to  the element naming
18:30:02 <hdv> melanierichards: we didn't want to flood the platform and create elements for all the possible use cases
18:30:03 <bkardell_> popup *might*be totally fine, even in the case I described
18:30:18 <melanierichards> q?
18:30:31 <hdv> melanierichards: let's wrap here and go to the next. Action for us is to go back to the research
18:30:38 <tantek> popover does nicely distinguish it from the overloaded "popup" term
18:30:42 <melanierichards> action: melanierichards bring back up the research PR
18:30:54 <melanierichards> topic: https://github.com/WICG/open-ui/issues/311
18:30:59 <bkardell_> ugh, I *meant* to say popover might be totally fine :-p
18:31:31 <hdv> 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
18:32:05 <hdv> 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
18:32:28 <hdv> melanierichards: we got some feedback early on… that it is important that it is declarative, i.e. does not require JavaScript
18:32:38 <hdv> melanierichards: so the open attribute is part of that
18:32:59 <flackr> q+
18:33:05 <hdv> melanierichards: I wanted to discuss today: is this element relevant for developers?
18:33:06 <silverdust> q+
18:33:14 <hdv> masonf: what Melanie said
18:33:30 <bkardell_> q+
18:33:42 <davatron5000> q+
18:33:47 <hdv> 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?
18:34:08 <hdv> s/complexity?/complexity required to make it work declaratively?
18:34:26 <hdv> masonf: I've also heard about the open attribute in dialog, it does not always seem to work well
18:34:35 <melanierichards> q- flackr
18:34:55 <hdv> flackr: there may be other components that have a more obvious use case for the 'open' attribute
18:34:59 <flackr> https://jsbin.com/leyosok/edit?html,js,output
18:35:08 <hdv> flackr: I was just putting together a demo with radio buttons
18:35:38 <hdv> flackr: I wonder if the attribute could set an initial state, but it is not live… 
18:36:04 <hdv> masonf: it would simplify all of the complexity
18:36:05 <bkardell_> defaultOpen
18:36:19 <hdv> flackr: my argument is that this is already the case with some input elements
18:36:27 <hdv> masonf: right, but they have been around for a long time
18:37:17 <hdv> 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
18:37:48 <hdv> 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
18:38:07 <hdv> masonf: one of the key differences between dialog and popup is light dismiss, so it may be a better fit for your use case
18:38:26 <hdv> masonf: I almost want 'transient' to be in the name of the popup element… that is really the key difference
18:38:30 <bkardell_> ttui
18:38:35 <Francis_Storr> q+
18:38:36 <dandclark> q+
18:38:37 <melanierichards> q?
18:38:42 <melanierichards> q- silverdust
18:38:42 <hdv> melanierichards: <transient-top-layer-ui>
18:39:18 <hdv> bkardell_: dialog was not shipped to three major engines… way more common is <summary>/<details>, which also has an open attribute
18:40:02 <hdv> 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
18:41:05 <hdv> 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.)
18:41:25 <melanierichards> q?
18:41:31 <melanierichards> q- bkardell_
18:41:34 <hdv> bkardell_: I would be in favour of an attribute that lets you declaritively set an initial state, not reflectively and not called 'open'
18:41:39 <melanierichards> q- davatron5000
18:41:45 <melanierichards> q- davatron
18:41:57 <hdv> davatron5000: I like 'open', in the same way that I like 'hidden', I like the binary flip of it, from a developer perspective
18:42:04 <bkardell_> you can do that on the DOM API tho dave
18:42:50 <bkardell_> the DOM API IDL can can an open boolean, it just doesn't reflect to a live attrbute called open
18:42:54 <tantek> q+ to note the searchability (find in browser) aspect we missed with HIDDEN and with the summary/details interaction, that makes this at least a tri-state rather than a binary
18:43:12 <hdv> davatron5000: what's nice about hidden that I can transition it
18:43:23 <bkardell_> +1 tantek
18:43:25 <bkardell_> :)
18:44:06 <hdv> davatron5000: I like to be able to use the DOM IDL, things like element.open = !open
18:44:46 <hdv> 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
18:45:23 <hdv> 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
18:45:50 <melanierichards> q?
18:45:59 <melanierichards> q- Francis_Storr
18:46:05 <hdv> 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
18:46:27 <Francis_Storr> https://www.w3.org/TR/wai-aria-1.2/#dialog
18:46:40 <hdv> 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
18:46:50 <tantek> good pointer Francis
18:47:06 <hdv> ack dandclark
18:47:10 <melanierichards> q- dandclark
18:47:58 <hdv> 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.
18:48:05 <Francis_Storr> thanks @tantek :)
18:48:28 <hdv> 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
18:48:46 <hdv> dandclark: having an IDL attribute I could look at would help with that
18:49:03 <melanierichards> q?
18:49:14 <hdv> 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
18:50:00 <bkardell_> also for some components, just linking to content inside
18:50:41 <hdv> 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
18:51:04 <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
18:51:11 <hdv> tantek: it would be useful for that to have some way for a developer to declare whether their element is 'findable'
18:51:15 <silverdust> Wish I could've articulated that better
18:51:37 <bkardell_> notes that linking to content inside as a solution could be declarative and work for melanie's use case
18:51:42 <hdv> tantek: sometimes elements may need to be hidden but also findable
18:52:44 <hdv> melanierichards: thanks everyone!
18:52:55 <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)
18:52:56 <melanierichards> thank you hdv for scribing!
18:53:31 <hdv> tantek: we do this thing on the WAI website! (https://www.w3.org/WAI/teach-advocate/accessible-presentations/  'Expand all sections')
18:53:33 <melanierichards> rrsagent, make minutes
18:53:33 <RRSAgent> I have made the request to generate https://www.w3.org/2021/04/08-openui-minutes.html melanierichards
18:53:39 <melanierichards> zakim, please part
18:53:39 <Zakim> leaving.  As of this point the attendees have been masonf, melanierichards, hdv, dandclark, Francis_Storr, silverdust, flackr, miriam, bkardell_, tantek
18:53:39 <Zakim> Zakim has left #openui
20:07:20 <tantek> FYI melanierichards that last statement in the minutes should be attributed to hdv, not me :)
20:07:44 <tantek> https://www.w3.org/2021/04/08-openui-minutes.html#x186
20:08:21 <tantek> I'm not sure how to tell RRSAgent to change the attribution of a statement
21:04:03 <myles> myles has joined #openui
22:01:36 <myles> myles has joined #openui
23:03:43 <silverdust> silverdust has joined #openui
23:40:19 <melanierichards> ah shoot, I don't either. gregwhitworth do you know how to fix? (can we, after they've been generated?)
23:58:41 <gregwhitworth> melanierichards: nope - no idea
23:59:06 <gregwhitworth> we can re-gen them but it gathers between the meeting sections which I think is the issue here