– DRAFT –
Open UI Telecon

Let's discuss popup states and events (@smaug----)

scribenick una

https://github.com/openui/open-ui/issues/342

melanierichards: this issue came out of an HTML triage meeting

melanierichards: basically we shared the idea with some of the HTML editors, and theres interest in seeing how the proposal does/doesnt aline w/Firefox's Zule? popup elements

melanierichards: proposed events here are transitional events (showing, shown, hiding, hidden)

melanierichards: emmited at begining and end of showing and hiding operation

melanierichards: is this something we feel we need?

gregwhitworth: im supportive of it

gregwhitworth: the general concept of havign this events

<chrisholt_> +1 for having events

<hdv> +1 to have these events

<davatron5000> I think it's great. I would love to have before/after events for each show and hide.

<gregwhitworth> una: it helps to have these, they're useful. I want to add that in CSS they're asking for more of these types of events

<gregwhitworth> una: such as :stuck for sticky

melanierichards: I like the idea, should we support this is one resolution, and then an actual name for these is a different resolution

flackr: the most concerning part to me is the exact text of when these events ar fired

flackr: when does display: none get applied, i want to know the exact timing

flackr: presumably they cant do anything to stop it when its opening

melanierichards: is there an order of operations here, can resolve on it existing/names and then someone can write up spec text, RE: order and can review it as a PR

gregwhitworth: we have a resolution on "this thing should exist"

gregwhitworth: we can even use the Zule? implementation as a path forward

Proposed Resolution: Events should be emitted when show or hide state changes. Event timing to be defined.

flackr: we have events in input like beforeShow beforeHide

Proposed Resolution: Events should be emitted when show or hide state changes (i.e. beforeShow, show, beforeHide, hide). Event timing and names to be defined.

<davatron5000> fwiw, Vue has put a lot of thought into this and has a lot of compelling demos https://vuejs.org/v2/guide/transitions.html

Resolution: Events should be emitted when show or hide state changes (i.e. beforeShow, show, beforeHide, hide). Event timing and names to be defined.

davatron5000: the Vue link above shows 6 states

[Popup] Supporting transitions and animations on open and dismiss

<gregwhitworth> https://github.com/openui/open-ui/issues/335

flackr: currently the way Popup works is that the style is all applied at once when you show popup, you dont have an opportunity to initiate transitions

flackr: you can do an intro animation but can't do an outtro because the element is display: none immediately

flackr: my proposal here is a state before the popup is completely visible - it has a computed style (beforeTransition style state), after which we apply the :open pseudo class, enabling you to do a transition on open

flackr: you can do the opposite on exit by removing :open pseudo class

flackr: the tricky thing is on popup where you have to wait a reasonable ammt of time for this to finish

flackr: see mockup in attached issue

https://jsbin.com/piqebiw/edit?css,js,output

demo uses 'visible' class add/remove, spec would be :open pseudo class instead

flackr: proposal is to have this intermediate pseudo state

<gregwhitworth> una: I think making this declarative is going to be very useful for developers

melanierichards: i was going to bring up: detecting that there's an animation running, Mason might have thoughts on this

melanierichards: we should have some kind of time limit on the finish operation, can abuse the user to never let it close

<gregwhitworth> una: to respond to that

<gregwhitworth> una: if someone was going to abuse the popup they could just not put a close button on it

<gregwhitworth> una: I don't think the transition timing is where to do that

<gregwhitworth> melanierichards: popup does have light dismiss

melanierichards: user should be able to close it w/lightdismiss

flackr: the developer can always trap the user if they want

gregwhitworth: there's an assumption that everyone that puts the content on their site is aware of it, might be a 3P

gregwhitworth: but are there technically ways around this anyway

gregwhitworth: the developer isnt always in control of everything running on the page

flackr: i think it'll be hard to set a canonical time limit (dev-expectation-wise)

<gregwhitworth> una: there isn't a pattern on the web currently for that

gregwhitworth: this may be one of those things that need interop if we go with this route

<Zakim> gregwhitworth, you wanted to discuss a meta discussion about engaging with CSSWG and to

<gregwhitworth> una: what if you made a CSS game and you had some time to play the game, there may be some real world scenarios. I note both are edge cases

melanierichards: if we were going to impose a limit, it would have to be in spec text, limit could be generous to protect against abuse but its unlikely you'll run into it for a transition

<flackr> Proposed resolution: popups have an intermediate state where they are display: block but not yet :open which they transition to when showing / hiding. On hiding, the UA will wait for ongoing animations before setting display: none.

<gregwhitworth> gregwhitworth: any objections?

<gregwhitworth> una: if they're display block are they visible?

<gregwhitworth> flackr: they don't have the open pseudo - this is the same as triggering a transition on something

Resolution: popups have an intermediate state where they are display: block but not yet :open which they transition to when showing / hiding. On hiding, the UA will wait for ongoing animations before setting display: none.

gregwhitworth: Additional agenda item: Switch Element Graduation

https://github.com/openui/open-ui/issues/338

gregwhitworth: potentially new pseudo element or element down the road -- should checkbox and switch be two seperate things? You *can* style a checkbox as a switch -- behaviorally they are similar

gregwhitworth: behaviors and anatomies might be different

chrisholt_: theres similarities in behavior on a lot of things on the web but they present differently on the web

chrisholt_: convoluting them will only create problems

bret little: the actual blueprint of a switch will be different

bret little: primary label, what switch is for, secondary label is the state of the switch

<davatron5000> +1 to graduate, mostly because I never want to ever read a "how to make a toggle with CSS checkboxes" article ever again.

una: I think these are 2 different components, switch is binary - the labeling would be different than if you tried to create one out of radio buttons or checkboxes

gregwhitworth: per iOS guidelines, they're the same as checkboxes

una: interesting that we keep relating to checkboxes when they're more like radios

link from iOS guidance https://developer.apple.com/design/human-interface-guidelines/macos/buttons/switches/

Proposed Resolution: Open-UI should have a separate Switch blueprint proposal

una: +1

Resolution: Open-UI should have a separate Switch blueprint proposal