Meeting minutes
How to use the <selectmenu>
dandclark: *presents presentation* https://
<miriam> The demos: https://
<una> beautiful demos
<masonf> +1 awesome demos!
<davatron5000> These demos are incredible.
masonf: awesome demos
masonf: you don't need to go demo by demo
masonf: how much JS was needed for those
patrick: most are CSS & HTML, but when re-positioning the popup required JS and the multiselect
patrick: otherwise everything was CSS
patrick: almost all JS was positioning and thus anchor-position would help
bkardell_: echo the demos are amazing
bkardell_: whether we could get the demos
bkardell_: I am curious mainly about the accessibility characteristics
bkardell_: there were a couple that I thought to understand how they work
patrick: none at this point
dandclark: the a11y stuff is wired up by default by behavior
dandclark: so it should work across the gradient as long as the behavior's are applied
dandclark: if you're adding non-trivial interaction inside the listbox they'll need to add the aria
davatron5000: great demos
davatron5000: is it the same as select regarding the value?
dandclark: what gets posted to the form is what gets posted to the selected option. It works the same way as the current select
davatron5000: then I see behavior listbox and button
dandclark: it is how our vision will be how the controller code is wired up
<davidluhr> gregwhitworth: Behavior aspect is key piece that missing in accessibility discussion. The behavior attribute used to be referred to as part. Once we standardize on parts, that allows us to concretely say what accessibility attributes will become.
<davidluhr> gregwhitworth: We basically took an MVC approach. The behavior essentially allows you to connect to the Controller code. If the accessibility isn't as expected, please file issues so we can update how this works.
<Zakim> gregwhitworth, you wanted to respond to bkardell_
scotto_: you've done a great job on this
scotto_: regards to some of the a11y stuff, I've mentioned a few of the issues
scotto_: I've found a few issues but I'm sure there are really intteresting path way forward we can take here
scotto_: we want to also do something a little bit more
scotto_: the level of arbitrary content that can be added in to make it a11y out of the boxx
scotto_: there will be issues but I'm excited to solve them
dandclark: I do owe you a response but I agree with you
<patrickbrosset> Demos are available here: https://
<bkardell_> +1 scotto_ said what I was trying to articulate much better.
<patrickbrosset> And docs: https://
Popup proposal
<masonf> presentation: https://
masonf: *presents slides posted above*
<masonf> explainer: https://
davidluhr: I really like this new direction
davidluhr: it allows us to author very tailored experiences
davidluhr: only question was the hidden attribute use it to toggle
davidluhr: details/summary and dialogue utilized the open attribute
davidluhr: have you considered that?
masonf: we can discuss that
masonf: hidden is already wired up so that's why I went that way. Hidden I think has issues animating too
bkardell_: I have some minor things to think about
bkardell_: I *really* like the approach you're taking here
bkardell_: we've discussed this for years and it's clearly a very useful thing
bkardell_: that actually is used in IDL
bkardell_: this would become a global attribute mixin, should we limit it somehow?
bkardell_: the other question is how does positioning work?
masonf: it feels like it should be limited
masonf: there are probably some other limits that should be applied
masonf: we'd like to be as general as possible
masonf: positioning, yes we need to discuss this which is the anchor-position proposal but isn't exactly this proposal
<davidluhr> The `triggerpopup` attribute is a great idea as it allows for non-JS implementations and the triggering button(s) to be located anywhere in the DOM without being limited by a wrapper element.
bkardell_: it's hard to think about without something there
bkardell_: you could create them easily but without you saying how you position them I don't know
<davidluhr> gregwhitworth: Love this. I have a tactical question.
<davidluhr> gregwhitworth: It sounds like there's general interest in path forward. Some of the things Brian raised leans toward moving the spec over to Open UI and incubating the spec?
<davidluhr> masonf: Certainly interested in doing that once we're close to consensus about what it should like.
scotto_: thank you very much
scotto_: this is really interesting and just wanted to say that
scotto_: I also was thinking about open vs hidden
scotto_: obviously we've talked about that
scotto_: one benefit of hidden is you can change the display of that
scotto_: the popup attribute could likewise have a UA mapping to hidden and the open could be used to display it
scotto_: really good feedback we got back here
scotto_: the way that it's used now is that it's visible so get rid of one of the attr that are needed by default
scotto_: to bkardell_ point regarding limiting this, I've thought about that too
scotto_: there is a case where text level semantics don't need a popup
scotto_: I think those can be fleshed out a bit more but I'm really happy where this is now
scotto_: it's what people are asking for with the popup element
<davidluhr> +1 to limiting to specific elements. It would be great if the attributes simply didn't do anything if applied to a non-approved element.
<miriam> This is all very exciting, thank you all!