– DRAFT –
Open UI Telecon

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

[Notification/Message] Defining component behaviour

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

andrico1234: a few weeks back, we graduated a notification/message/alert/toast proposal to stage 0. Under the reqs we need to choose an appropriate name. std-toast was contentious, it's a name not all are familiar with. The pattern/impl is different across design systems

andrico1234: opened disc to think about appropriate name. We didn't have a broad definition of the behavior, so can't choose a name. So opened up the current issue and had a good disc from a number of people about behavior. Converged around impl around an existing aria role, like alert or status

andrico1234: based on [missed]'s comment, the proposal is most close to an alert role. My question I'd like resolved, can we create an implementation for the alert ARIA role?

andrico1234: can add more context, I know there was difficulty distinguishing between alert dialog and popup? Maybe worth covering?

melanierichards: I was not here for it but it would be good to cover points of confusion

andrico1234: Google alert disruption was top of mind, requires an action, but for alert should be no interactive children

<gregwhitworth> melanierichards: from my pov, it seems like alert could be a subclass of popup

<gregwhitworth> melanierichards: I'm going to guess the light dismiss behaviors are different

<gregwhitworth> melanierichards: that is distinguishing factore

<gregwhitworth> melanierichards: alerts shouldn't have interactive children

<gregwhitworth> melanierichards: it seems like having something like this in HTML is worthwhile

gregwhitworth: my biggest qualm, and it's alignment with Melanie to an extent, I do feel that if you look at scenario you ref with alert/confirm/etc, there's subclasses of alerts w/ different interactive models, they popup for different contextual reasons. I don't think it's good to have all statuses/alerts/etc becoming alerts...should be some root foo that does the popping up. Maybe it's <popup> and light dismissal becomes a

primitive. Rarely would you use message...more alert, confirm, etc. Windows leverages the same message scheme, they show up in the same spot, one might have a confirm and one might have an action.

gregwhitworth: personally I like a base class of something. I don't think everything is technically an alert.

andrico1234: would you suggest something like creating a component that we would then give the person implementing the component the ability to specify something more specific via an attr? And they would worry more about the impl themselves? So if it's an alert wouldn't do anything w/ focus mgmt, but if it's a confirm they make decision themselves about focus mgmt

gregwhitworth: totally up to debate about we reuse <popup> or not. But let's say we have a new thing called <message>. Would expect <alert>, <confirm>, <prompt> component. Wouldn't want to just provide container and force dev to figure out focus trapping.

gregwhitworth: expect 3-4 components to use a base class, pop up over all content, there can be many of me, and so on

gregwhitworth: so maybe let's start with <message>...but there should be a convo of should that be <popup>? I think we shouldn't encourage to use message since it's just generic

gregwhitworth: would be in favor of making <popup> this top-level component and just making lightdismiss a primitive

<gregwhitworth> melanierichards: I am aligned with you in the spirit of not making everything an alert

<gregwhitworth> melanierichards: I think I disagree with making popup the base class for that

<gregwhitworth> melanierichards: there is a specific content model and light dismiss and mutual exclusivity

<gregwhitworth> melanierichards: we wouldn't use that for message for example

<gregwhitworth> melanierichards: I don't necessarily have THE solution

<gregwhitworth> melanierichards: a whole ton of new components

<gregwhitworth> melanierichards: if anything - dialog is actually closer to something that is built on top of

<gregwhitworth> melanierichards: I was going to say the same thing as melanierichards

<gregwhitworth> melanierichards: light dismiss probably doesn't apply

<gregwhitworth> melanierichards: all of those work just as well with dialog

masonf: pretty much same thing, all of these use cases sound much closer to dialog than popup. Light dismiss doesn't apply, having only one doesn't apply here, all of these work for dialog so maybe the base class is dialog

gregwhitworth: ok maybe good next steps, I don't hear any drastic disagreements

gregwhitworth: one concern w/ dialog, and everyone knows it, historical baggage with that. That doesn't stop us from doing it. Andrico I'd probably recommend starting from there. Pursue alert component starting from dialog. We can loop in Domenic, spec editor for dialog. I can see the intro being this builds on top of dialog, adding more constraints on top of it.

masonf: it's just a shell, a div you can fill up. Some styling rules.

gregwhitworth: I could see you saying it extends dialog element. And then you have your OUI component, here's what can be included, ARIA role adjustments. Doesn't have to be a long doc, light dismiss handled by dialog. The other thing we'll have to handle is mods done to popup for initial rendering, rendering w/o JS

gregwhitworth: any disagreements to pivoting to individual components built on top of dialog rather than one-size-fits-all?

masonf: I'm not even sure any other el in the HTML spec uses a concept of a base class or element. They are defined independently. Maybe that's the way to handle this. Define how it behaves itself.

gregwhitworth: we could dupe the light dismiss behavior. Andrico, would you want to own the entire thing inside an alert modal? Given Mason's comments, maybe want to triculate behaviors or pull them out? I think reused behaviors are pulled out?

masonf: yes, you can reuse. I don't know of els that say, I'm this element with other stuff

flackr: I did some code searches, I see subclasses of div element. output a subclass of form element. [some other examples]

masonf: in impl, you're correct. Not sure about spec land

flackr: spec land does specify some of those relationships

andrico1234: think this would be a good start. Anything more complex probably beyond my capabilities as web dev. Don't have as much experience w/ underlying web tech. But for impl a base class that we can then extend, that might be something I can't quite...

gregwhitworth: they're great resources to utilize, but don't worry about how they're implemented. You're authoring a spec and we're here to help. Rob, if you can @ mention Andrico in Discord where WHATWG specifies that, so that if we want to say extend dialog we can start there

gregwhitworth: one thing to note, while people were strong on name, landing a stage 0 spec proposal does not limit us from changing the name down the road. We can argue about names for next 20 years. Would move forward with getting initial alert proposal going.

<gregwhitworth> melanierichards: I don't have pushback

<gregwhitworth> melanierichards: I thought we wanted to make a proposal that would land in the web platform

<gregwhitworth> melanierichards: if that doesn't happen we're happy with folks having a WC

andrico1234: was talking about moving to a world where we don't need to use ARIA roles. So maybe that would make this land in HTML spec and not as an OUI component

<masonf> Example of spec base class usage: HTMLAudioElement extends HTMLMediaElement: https://html.spec.whatwg.org/#htmlaudioelement

<nicole> +1 to Greg: we should land as much as we can in WhatWG

gregwhitworth: to be blunt, I have every expectation this would land as a new element in WHATWG. I have yet to see us talk about a component that would land in HTML spec. Convo justifies separate components. Any opposition?

Resolution: stage 0 of alert as separate component

[Scrollbars] Force bad scrollbar designs to apply accessibility patches

<flackr> https://html.spec.whatwg.org/#htmlvideoelement is the only example in the html spec i found

<andrico1234> Woo!

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

tantek: not sure what they're asking for, tried to respond to issue filer. We do say in scrollbar spec that impl should make scrollbars activatable. That language is in the spec. If there's other suggestions, suggest they file on the scrollbar spec.

gregwhitworth: setting context, they have a progress indicator scrollbar here ~3px in width. This person has something that makes this scrollbar hard to use. Want to interact with the scrollbar. There's an implied assumption that if you see small one you have to engage with the contents to scroll. They were engaging with one and it wasn't adjusting. No idea who's done this, maybe the site making their own scrollbar, they're not

accommodating the scenario. Wanted to see from Tantek whether we should tackle or hand to CSS. Good to know that's in CSS.

gregwhitworth: for all I know, that site might be leveraging their own custom scroller. Sounds like the solution is resolved (do you want stronger terminology). Would like to know if it's from a certain site/in a certain browser.

tantek: this might be site-constructed, not a browser scrollbar at all. I wanted to answer the CSS spec question concretely, with an avenue to improve if that's where you think that is where the problem is. Potentially additional layers of problems. Sites creating their own scrollbars is a problem. Maybe we should give guidance, and the guidance is "don't". Almost certainly going to get it wrong. 99.9% chance of making it

inaccessible.

tantek: that being said, telling web authors don't do that doesn't always get the best response. I have to do it because I was told to. Well, what problem are they trying to solve? Can we dig into that? What's not addressed by existing solutions. That's a higher-level Q that OUI should consider.

gregwhitworth: that was my other thing, within a select, we're going to hit this, we end up with too many contents to show, so we add a scroller. We say have at these controls...this person is somewhat aligned, when we get to selectmenu need to look at scrollbars independently. Maybe we use the CSS ones, but possibly leaving something on the table.

gregwhitworth: want to raise it, people impl their own

tantek: good cross-spec issue. Everywhere OUI has something that can cause a scroller to be displayed, we can direct impl guidance. Impl should implement the scrollbar styling spec to allow customization. Delegate presentational side of it to CSS while defining functional aspect of it. That would help address that side of it. If the impl is implementing an OUI control, and if they're doing it wrong, are they implementing scrollbar

styling correctly? They should. Maybe bugs in scrolling styling that should be improved.

tantek: the other layer of problem is issue is the jank. They tried to use scroll wheel, and it didn't work because of jank. I don't know how we, OUI, can address that. It's a platform-level problem.

gregwhitworth: highly recommend reading the original issue. User can't interact with the control. One rec is I would add in a MUST into your spec. That's basically what this person is asking for. If you implementing a designable scrollbar, it must be wide enough to be usable.

tantek: can you file that?

tantek: on the CSS spec

tantek: I would +1 immediately

gregwhitworth: hit testing near it, increase max width, we'll argue in that WG about layout impacts, but I do feel we should discuss it

tantek: concern for scenarios where they don't have access to hover behaviors, like touch, where the scrollbar might be too small for fingers to touch. Usually a diff gesture for scrolling. Just want to note that's a consideration, we're talking pointer-centric

flackr: if UA aware there's a scrollbar, there's solutions like when you scroll, show the scrollbar. Can scroll by grabbing the page. And then you can grab the scrollbar. I think we're saying should be customizable enough to use in custom components?

gregwhitworth: from browser-land...when you get closer to the scroller, adjust the width. In CSS we'll argue about it.

flackr: with touch, we have freedom to adjust where touch hits. Nearest thing in bounding box you meant to touch on.

flackr: grab scrollbar if you touch near it

tantek: re hit testing, if that's something we can improve by adding more prose to scrollbar styling spec, that's something I would be open to

masonf: to have more impact, it might be better to file issues against specific browsers

gregwhitworth: I asked for a link to the site to file bugs on browsers, and then also adjust the spec

tantek: if we get it in the spec, hopefully implementers do the right thing. But yes, bugs are a direct way to ask them to do it. But those bugs can have more weight if the spec says to do this