<scribe> scribe: hdv
<stephstimac> Hey folks, there are people who are having issues getting into the call.
melanierichards: a couple of weeks ago we discussed the popup proposal, an element rendered at the top layer, which can be used in things like comboboxes
... we got some great input from the community on the proposal and made a couple of changes based on the feedback, which we can go over now
<una> scribenick: hdv
melanierichards: the main question is: do we want to start working on formalising this proposal?
... I can share a bit about what has substantively changed since last time
<melanierichards> https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/main/Popup/explainer.md
<una> Proposal: Take up <popup> as a work item
melanierichards: one of the things that came up is: wouldn't it be nice if this would work without JavaScript?
... we've explored that and added some stuff to the proposal
... we added a few different options for invoking the popup. One would be an `popup` attribute
... this would apply only to a small subset of elements that we would define, like button
... this attribute would also take care of the ARIA that would normally be involved with a popup like this, it would be mapped for you
<una> zakim start meeting
<Francis_Storr> zakim controls: https://www.w3.org/2001/12/zakim-irc-bot.html
<scribe> scribenick: hdv
<una> Open UI Telecon 02/25: https://github.com/WICG/open-ui/blob/master/meetings/telecon/2021-02-25.md
melanierichards: in some other cases, there may be a reason you want to show the popup on page load, this is what the `open` attribute would be for, like in <dialog>
... the `show()` method is pretty much as shown before
... calling `show()` would also toggle the `open` attribute
... you can only show one popup at the time, unless there are descendants
... so, basically, we'll have multiple ways to describe descendant popups
... we've also ensured some actions are symmetrical, like if you call `hide()` the `open` attribute gets removed
... if you move focus away from the popup, we'll also hide the popup.
... we also removed some things. One behavior we described before was a difference in event bubbling… but it felt like this would introduce complexity and not really add author value
... if this change is important to you, please do let us know
... open question: should the anchor attribute hoist up a `popup` in other trees like the accessibility tree?
... we don't really have a clear answer for this, so we've kept it as an open issue in the explainer document
jan: what does it mean to not need JavaScript?
melanierichards: basically hiding and showing is the core use case… we would not need script for that
<bkardell_> not unlike title in some cases?
jan: how would closing work?
<silverdust> I am Joseph on the call
melanierichards: there are a couple of things that can cause closing, like moving out focus from the element
jan: if there are multiple elements that can cause closing it may get tricky
melanierichards: yes there are some details that we need to take care of
jan: why don't we let the user pick any element as the invoker, rather than just a couple of predefined like a and button
... for instance, custom elements
melanierichards: mostly for accessibility reasons, we want to encourage the right elements to be used
jan: it is hard to build a cross platform button, many design systems build their own buttons as custom components, I would encourage allowing for custom elements to work as invokers
... it may be useful too to have some way to have a programmatic reference that can be used across different trees (DOM/a11y)
melanierichards: we may need to do some exploration around what the right layer is to build these sorts of things into
<bkardell_> is there an open TAG issue on this?
jan: last question: if you have an attribute called open, why not call the method 'open' too (rather than 'show')?
melanierichards: interesting question! we did discover this design, but we also looked at being compatible with other parts of the platform
silverdust: I can see the open attribute conflict with light dismissal
melanierichards: that's a good point of feedback… you as an author may sometimes want to intercept opening/closing events, but a user may want to be sure it closes when they want it too… interesting discussion!
nsull: I'd love to collaborate on @@@!
una: does anyone have objections to melanierichards proposal to start working on popup?
jan: what's the alternative?
<una> Proposal: Take on spec work for <popup> in this group
melanierichards: alternatively we might start filing issues against the HTML spec in WHATWG space… but it could be interesting to start the work in this group
... in any case we need some place to graduate the explainer document to
... my preference would be to incubate here
una: I think it makes perfect sense to continue the discussion here and write the spec in the Open UI format… when that is ready we could get it to the next place, whether it be CSSWG, ARIA or HTML
... thanks for doing the work and putting it all together in this format, melanierichards!
... so what do people think about that proposal?
jan: others were interested in work on the anchor proposal… I think working on popup first makes sense
<una> Resolved: Take on spec work for <popup> in this group
una: yes and those proposals work together well
<una> https://github.com/WICG/open-ui/pull/262
flackr: one more question on <popup>: I wonder if there is any way for the author to specify what 'show'/'hide' means, for instance with their own animation or transition?
melanierichards: yes that would be interesting!
masonfreed: as it stands now you can transition while opening
flackr: but not the other direction
<jan> Hidde: shall I scribe the next topic?
masonfreed: this would open it up to abuse
jan: yes please!
<una> scribenick jan
<una> https://github.com/WICG/open-ui/issues/266
<jan> una: Topic naming badges v pills v chips v tags
<jan> una: Would like to propose a naming convention for design systems generally
<jan> una: If no one has thoughts now, please review issue #266 to help identify the path we should take
<jan> melanie: I think there's a functional difference between some of these things
<jan> melanie: I haven't used "chips", "badges" and "pills"/"tags" seem different
<jan> melanie: "badge" is purely descriptive in mind mind, a status or number
<jan> dave: have seen these terms in the context of Bootstrap
<jan> dave: "badging" as an OS concept makes this a little confusing
<jan> dave: i like "badge", "chip" is weird
<jan> dave: "pill" is rounded like a pill, it's limiting
<melanierichards> +1 pill does have a strong visual connotation
<jan> dave: i wouldn't take a rectangular pill
<jan> una: we should be sticking to the core semantic meaning
<jan> nicole: I think I've seen filters that have "round thing" (pills/tags)
<jan> me: badge and tag seem to tackle different semantic problems