Meeting minutes
ScribeNick una
<gregwhitworth> github-url: https://
<gregwhitworth> github: https://
https://github.com/openui/open-ui/issues/410
<gregwhitworth> github-url: https://
Github topic: https://
semantics for popup
<hdv> github: https://
mason: one of the things we have is position: top-layer that lets you put any element into the top layer, the other is lightdismiss so what takes you out of it. These can concievably both be CSS props
mason: the way the discussion is very much brainstorming at this point
mason: in the popup spec there are a few things that are harder to make into seperate APIs (i.e. anchor, popup attribute that lets you declaratively open a popup)
gregwhitworth: are you looking for opinions? concrete element vs. primitives
masonf: q started as what is the semantic role for popup, need to find something that satisfies standards and a11y
masonf: need general feedback
gregwhitworth: we talked about this 3 years ago RE: what are the primary goals
gregwhitworth: primitives or elements
gregwhitworth: primitives can be an implementation detail at the end of the day
gregwhitworth: the way I view the popup is that in and of itself it doesnt have that semantic meaning. it takes on semantic meaning when its utilized within something else
gregwhitworth: so im all for having as many of the primitives put together as possible
gregwhitworth: but i dont want to backtrack where we're working on primitives consistently
masonf: agree would love to get these things out, the idea is that shippign primitives willmake it easier to get the semantic things out
<flackr> +1
masonf: would become easier to implement and spec bc they're based on things that already exist
+1 to masonf
chrisdholt: i would prefer to have a primitive bc I thihnk that attaching a role lets me ship elements tomorrow
chrisdholt: the same time, underlying apis is core to our needs
chrisdholt: independent elements seems to create a lot of overhead
melanierichards: we also lose things w/primitives: autofocus behavior
melanierichards: do we have enough for select menu and controller code to apply semantics to listbox portion
melanierichards: open to moving to CSS primitves that could unlock more scenarios
melanierichards: as the need arises, add more semantics to UA stylesheet
melanierichards: it was nice to have an element that comes packaged with all of these behaviors
melanierichards: it will prob be very generic as listed in this issue
melanierichards: its not like semantically the element is super interesting, but theres prior art in html
melanierichards: not every html element has super unique semantic meaning
melanierichards: i dont think thats a reason not to introduce the element but woul dbe open to exploring if issues w/tag
<hdv> una: I think I've always had the perspective, the more reusable the better, and the more declarative the better
<hdv> una: it's been hard to do popups because it requires JS to create… some of the things we got that have come out of using this element were great for CSS. Having some of these primitives will make it easier to build and implement the semantic <popup> element
<hdv> una: so I think we should focus on the primitives, and then it will be easier to get the HTML element out later
<hdv> una: and be useful for other parts of the platform
<hdv> una: we've broken out a number of things, like anchor and dismiss, we've thought that trough
<hdv> una: going down the route of primivites provides most flexibility and easiest implementation
<hdv> una: we also need to define primitive, HTML primivite and CSS primitive have different meanings how we're discussing them
<Zakim> BoCupp, you wanted to say popup has semantics (I think they are menu semantics)... but maybe the name is too generic
BoCupp: popup has semantics
BoCupp: if a modal dialog is displayed i would expect the popup disapear, but if a modal is displayed witha popup on top of it i would expect the modal to stay visible
BoCupp: set of behaviors UA can enforce in top layer
BoCupp: UA can coordinate the top layer
<tantek> +1 to una's points about reusability, more declarative, and defining primitives
BoCupp: we want it to contain arbitrary content (context menu, teaching ui)
BoCupp: they appear at different times, popup can be the right level of semantics
BoCupp: dont have to take it so far as to declare details like menu and menuitems
BoCupp: makes the popup elment less generic
BoCupp: dont want to lose ability for browser to control top-layer interactions
<gregwhitworth> +1 to what Bo just said, I don't want another z-index world
hdv: ARIA notoriously hard for devs to get right
hdv: browsers are the only ones who can ensure different levels are correct
hdv: html would be super helpful for ensuring a11y
hdv: would make it harder for implementors to make mistakes
flackr: i dont think these 2 ideas are at odds w/each other
flackr: huge advantage i see here is not forcing us to define specific accesibility role for somethign that can be used on a lot of use cases
flackr: per-element can decide on the a11y role
gregwhitworth: my question is if you think theyre mutually exclusive
I think they're not mutually exclusive, I just dont think we should not implement primitives in leu of elements
^ una
gregwhitworth: im not disagreeing if we have the primitives it would make it easier to implement, im worried primitives will slow down shipping/the magic
gregwhitworth: wed need to define every primitive fully and every usecase, leveraging that
gregwhitworth: would gate release of those elements
gregwhitworth: if we require primitives to be defined before elements, im concerned we're going to be 2-3 years out from shipping anything
gregwhitworth: is that truly needed
miriam: keep hearing an assumption that if primitives are in CSS they cant trigger ARIA & a11y
miriam: in CSS overflow already does that: adds interactions an a11y features
miriam: i think we need to keep pushing on that: have primitives in css that are already have a11y tied in w/o needing the a11y to be re-stated in HTML
BoCupp: wanted to respond to flackr
BoCupp: if you have a primitive that says just show this in top layer, i do think they're mutually exclusiv
BoCupp: you can have even more metadata exposed w/the primitives
BoCupp: should it be modal, dismiss other dailogues, etc.
BoCupp: options felt unweildly, might have a higher level property that says 'it should have popup behvaior', once we do that - semantics through name of element
BoCupp: to make sure devs can get it right we want a packaged set of behaviors assigned to popup or menu
BoCupp: UA can make sure special behaviors are honored
<hdv> +1 to packaged set of behaviors to not rely on authors specifying eveything correctly
<hdv> una: not sure if implementing primitives will slow down implementing elements? we would need to figure out the primitives either way
<tantek> +1 una, will absolutely still need to figure out the primitives before launching the elements, otherwise the elements will be (even more) weird exceptions
una: so I feel it is still going to take a long time before we have a semantic element that will have all the primitives built in, don't think it would necessarily be slowed down by discussing primitives first
<tantek> (we're *still* unwinding / backspecifying the legacy weird behaviors of HTML elements, e.g. in CSS etc.)
una: declarative styling can still be accessible, and it should be
<una> masonf: one thing ive realized from this discussion is we still want to ship an element called popup based on these behaviors
<una> masonf: still need to answer question on semantic roleof popup
<una> masonf: need to define popup and its pieces
<una> masonf: wanted to +1 we need to figure out pieces of toplayer interaction anyway to figure out popup, it might be easier to once we figure that out, isolate it
<una> masonf: i think we still can and even should spec toplayer access and css prop that leaves UA in control of top layer (i.e. interactions bw full screen, modal dialogs, and this new prop)
<una> masonf: we need to know what the interaction of these 3 things is - have some ideas for css property that gives this to you. Can set priority list
<una> melanierichards: i'm not sure we're all talking about semantics and behaviors in the same way. Semantics = "what is this thing" & a11y mappings -- thats the core question from the thread
<tantek> +1 melanierichards, yes semantics and behaviors are different things. semantics are definitely tightly connected to a11y mappings, which may happen to have default behaviors
<una> melanierichards: definition will be generic like: window control w/ui automation
<chrisdholt> +1 to Melanie - I understood as the same which is where I found the sticking point. IE, we are getting an ask specifically around a11y mapping and our intent with popup as low-level is to support _many_
<una> melanierichards: resonate w/unas characterization of breaking down the problem into small chunks. Bo's point of certain things that arent resolved by focusing on primitives
<una> melanierichards: theres no CSS A11y model right now and how the two are linked
<una> gregwhitworth: just wanted to clarify im not opposed to primitives, i.e. anchor should exist on its own
<una> gregwhitworth: if we want to break popup apart, thats fine but we need to get a resolution on the threads question
<una> gregwhitworth: we want a popup element to exist, standardize generic primitives, and make standardization of popup elements easier
<una> gregwhitworth: i hear general support of primitives existance as well as the individual element
<una> gregwhitworth: want to resolve on where the folks working on popup are spending their time
<una> gregwhitworth: next discuss semantic role
<una> masonf: ive seen/.heard a lot of +1s that we still want to ship popup element
<una> masonf: it is a question of a11y modeling/semantics
<una> masonf: then its just an ordering question
<una> masonf: lets resolve that we think thre is a semantic role for popup
<tantek> +1 masonf, agreed there are semantic roles here
Action: next week we will resolve on a semantic role defitinition
<BoCupp> I believe popup has a semantic role
<masonf> proposed resolution: <popup> has a semantic role, and deserves a place as an HTML element. TBD what the exact verbiage is for that semantic role.
<BoCupp> +1 to mason's proposed resolution
<masonf> +1 to hdv: we should get screenreader user input
<una> dandclark: still confused what this means practically
<una> dandclark: theres a specific mapping for listbox, what does a new semantic mean
<chrisdholt> +1 with Dan, I don't think anything exists that wouldn't need to be overridden for a number of elements/usage
<una> flackr: i think whether we define css properties for these mgiht affect how universal the semantic meaning of popup needs to be
<una> flackr: can create popup -like things w/other semantic props that might have different aria roles
<una> masonf: popup would be more generic, and selecmenu would override it as a more specific role
<una> chrisdholt: is it acceptible to propose one and then override it in all these places?:
<una> gregwhitworth: popup is a div with additional behaviors
<una> chrisdholt: not sure semantic role adds value to popup
<una> chrisdholt: might add more confusion
<una> chrisdholt: +1 to div with behaviors
<BoCupp> also disagree that popup is best described as a div with behaviors
<tantek> it's ok to have "lightweight" or "broad" semantics rather than precise/narrow semantics
<melanierichards> to Una's point: https://
<BoCupp> +1 to tantek's "broad" semantics point
<chrisdholt> RE: Bo's disagreement, I think I'm specifically saying that an ARIA role doesn't fit here universally. Doesn't meant there aren't semantics, but I don't see an existing ARIA role that fits
<melanierichards> +1 to lightweight semantics on the element itself
<una> chrisdholt: my emphasis is there are semantics but i dont think there is a universal aria role that is applicable to popup
<tantek> I'd prefer no more (even nearly) non-semantic elements, as we've seen that's more confusing than helpful e.g. section vs div has only been a timewaster IMO
<una> BoCupp: the mroe narrow we go the less useful the element is
<una> chrisdholt: if the ask isnt to provide an aria role, rather semantics for the interaction that seems reasonable
<chrisdholt> maybe a bad example as well - abbr?
<una> melanierichards: role dialog mappings in core AM, i imagine popup is going to be very similar
<chrisdholt> has unique semantics based on context but I'm not sure it has an ARIA role, does it?
<una> melanierichards: can also do an excersize in all the different subtypes of popup
<tantek> +1 melanierichards
<chrisdholt> On generic, the popup could be useful for composition - IE I have a menu and I want to wrap it in the popup and delegate focus to it. No reason to add additional semantics there...