Meeting minutes
Session 1: 00:00 UTC
Travis: As the title suggests, we'd like to talk about the relationship of a few different proposals
Travis: we'lll review the concepts and use cases and then discuss
Travis: focusgroup is a proposal I put together recently, toggle was something tab presented 10 years ago, I think they are here and can represent it
Travis: focus and state management are concepts of ui and control design. Both are fundamental and available in the platform, but not really exposed as a general concept for easy reuse
Travis: I think putting them together can unlock better scenarios for authors in the future
Travis: an attribute => focusgroup that one could apply to an element... I won't go into great detail, there is an openui review in a lot of detail if you want more
Travis: the first implication of focusgroup would be to potentially reduce the number of tabstops, and let users navigate more efficently and group together sets of related controls... here are some examples (shows github page and how navigation works) 40 tabstops to get to the explainer - but they are in some natural groups visually and how we thinkabout them
Travis: if you reserve focus for the groups you can navigate more efficiently
Travis: some controls have a concept like this intrinsically (shows edge user interface and how arrow keys move between 'groups') for the address bar, toolbar, tabs, etc
Travis: next, as an accessibility affordance... some accessibility patterns require keyboard interactions that require this - native built in things let you arrow among name named ones, for example -- custom controls are expected to do those things too, more in aria
Travis: another conceptto highlight is the difference between focus and state - often they are combined but they can be separated. Inradio buttons, as the focus moves, so does the checked state... contrast this with the tab band of the native browser, tab moves your focus but doesn't change which is selected
note: 'manual activation' in aria
Travis: so the basic summary is that the proposal enables a set of elements in a particular scope to respond to arrow keys, it just lets the focus move, and doesn't change state or anything... Want to also mention that this was built for content navigation, not spatial nav
Travis: it has a bunch of options about how it "works" - it's all inthe proposal if you want to read the details
Travis: toggle is the other proposal we'll talk about - it introduces some different concepts. One is a 'toggleable' state you can toggle on any element.
Travis: toggle gives you a lot of features like a checkbox has - users can activate it
Travis: it also has an interesting concept that it is not necessarily boolean - it's kind of a cycle of N states
Travis: it has another option of"sticky" cycling - kind of like a radio button where once you have a chosen state you can't go back to unselected
Travis: scope is interesting here... descendant subtree can activate ancestor toggles
Travis: the scope can be extended to be "wider" andinclude next siblings too
Travis: part of this also has this thing where you can group the toggles and create something like radio buttons... toggles in the same scope are joined together to create an exclusive selection idea
Travis: you can also in theory have n-toggles, but only one focus state ...
Travis: it makes things activatble, that's a difference from focusgroup
Travis: there are things that are TODO in the spec in the future like named toggles or DOM access
Travis: did I cover it pretty well?
miriam: yes, I think so - there was some interest in kind of abitrary state machine changes
Travis: I tried to take tabs at bkardell_'s suggestion to try to put it together --
Travis: spicy-sections is a custom element illustrating another proposal in open-ui... it gives this ability to present on different sections different affordances... it can be regular sections, or it could gain an expand/collapse pattern, or present as tabs... so I'l going to use this to focus on tabs and show this and the relationships
Travis: as I arrow on the tabs, it's moving through the tab group
Travis: pretty much as it could/would in the focusgroup proposal
Travis: there is only one stop to the group - just like the aria pattern and our focusgroup example
Travis: we're going to try to pretend we have these things -- there is a focusgroup for the tabs... you can kind of move between them. Focus group wouldn't let you choose and activate... there can also be toggles here.
Travis: I think one of the goals here that isimplicit in the proposal is that we don't want to have to resort to JavaScript to do this
<fantasai> +1
Travis: I want to call out this observation - it seems like maybe you could combine these two ideas of focusgroup and toggle, but I think it is useful to decouple them... let me show you an example of why...
Travis: you might for example have a more button and it's not part of the same control perhaps...
miriam: I think there is also a difference here in that the toggle scope might want to be the whole thing... if the scope includes the content that can be useful for toggles, but probably not useful in the tab group
Travis: so where are we missing something here... "the tab stop for the toggled items" -- today this is implemented with the roving tab index pattern
Travis: focusgroup doesn't solve the problem of moving the focus
Travis: toggle group if I understand, doesn't make the things activatable but i think it doesn't do the other thing
it doesn't but the intention expressed to me was "we will figure out how to make it expressive enough to do this"
Travis: here are some ideas... we need to teach the browser that the toggle inthe group is part of the navigation sequence and replace the roving tab index
Travis: the other is to teach it how to allow you to express focus by explicit or automatic on activation
Travis: there are other scenarios that aren't tab related, of course --and it's worth looking at those too
Travis: multiselect groups, all/none linked toggles
Travis: I did a thought experiment trying to figure out how to do that, but I couldn't figure it out... I think you'd need something mmore like a state machine, like you mentioned to make that work
Travis: CSS or HTML is a good question... we started with HTML, and I have spent the last week or so thinking about it as a CSS feature... I thought of some current good aspects of that, it is worth discussion... we should work on trying to align... is there something common we could align there
Travis: on the toggle side of things, this 'one time creation' thing that rubbed me the wrong way, it didn't feel very css-y to me, maybe uaing an attribute is a better way to do that
<fantasai> bkardell_: ...
<fantasai> bkardell_: ...
<fantasai> bkardell_: ...
<fantasai> bkardell_: ...
<fantasai> bkardell_: Splitting out the programmatic aspects might be useful
Travis: Yes, first, create definitions and abstractions, algorithms, and lastly the dev-facing control surface
fantasai: could you paste links to those in the irc, so we can have them
<Travis> Focusgroup proposal: https://
fantasai: it seemed to me more an HTML thing to me - anything that tends to have behavioral aspects tends to fit better in my mind than in css
<Travis> CSS Toggles proposal: https://
<jcraig> Spicy-Sections https://
fantasai: we try to avoid this idea in css where you try to both set and select on a state
fantasai: like, when we introduced :dir, it can't then set the dir in css - what would that mean, it would be circular
miriam: we did solvethat in our proposal, you can't actually remove it
fantasai: in general I am pretty excited this stuff is being worked on
Travis: it probably is time to get it into the platform
fantasai: it is past time
masonf: thanks for presenting this, I do think they are really connected concepts...
masonf: I wanted to echo a thing fantasai just said in that it does seem to me that it is kind of a thing that you tightly connect, fits in HTML
Travis: an observation that came to me, after buiding a polyfill and looking at toggles - this idea of having potentially N toggles on the same element is pretty intruiging... in thinking about how to rectify it I <pleasefill>
<Zakim> fantasai, you wanted to comment on CSS selector binding
Travis: It seemed easier to specify some of this stuff in CSS syntax, with selector syntax etc.
fantasai: CSS style rules, the way they bind properties with selectors is _terribly_ convenient -- and the fact that we can't do that in attributes in the DOM is frustrating across the board
<miriam> +1 fantasai
fantasai: however... this is anexisting problem. It wouldbe amazing to solve generally, but I don' t think that working around like this would be the way to think about it
fantasai: it is a separate kind of thing to solve
masonf: the semantic difference seems to belong in html
<miriam> relevant: https://
masonf: e.g. div vs togglable div seems quite different
bkardell_: Spicy sections is built on observation
bkardell_: originally went down road of how to make tabs element
bkardell_: But people don't want that. They want something that is sometimes a tab element and sometimes not
bkardell_: Lots of examples in our research, observation that scrollbars in the platform do have a 1:1 with components in a lot of toolkits
bkardell_: ut there's no native scroll? element
bkardell_: That's a design element, pursued in design
bkardell_: but it doesn't change things, it intercepts your keyboard, it becomes a tab stop, etc.
bkardell_: This seems similar
bkardell_: Sometimes display as normal sections, and sometimes display as tabs, and sometimes as collapsible sections
Travis: Does manifestation of feature in HTML or CSS make a difference?
bkardell_: I think it's in pursuit of a design
bkardell_: e.g. on my blog, I have things presented as tabs, but if printing would treat as sections
bkardell_: similarly, have a sidebar that I want to present on mobile as collapsible sections
bkardell_: in the way on mobile
bkardell_: but on desktop is just a section
bkardell_: So I think it naturally fits in CSS
bkardell_: But it's possible we could define something in HTML that would be able to convey that
Travis: So because you have design pattern of sometimes representing content in tab form and sometimes in printed form
Travis: that means if you put all of your affordances in HTML, then you have to manually remove them perhaps when taking away the tabbed presentation
Travis: so if all in CSS, then you can tie the behavior together there
miriam: I think that gets to your question of whether still need JS to use
miriam: adding/removing attributes requires JS
miriam: so that would be a downside
bkardell_: It would definitely be possible to represent a subset of these needs in HTML statically
bkardell_: definitely cases where there's no question it would be tabs, and could work for that case for sure
bkardell_: many cases where having HTML way to do this is preferable
Travis: My understanding, and why landed in HTML to begin with, is idea that all the current a11y affordances are HTML attributes
Travis: and I was thinking about focusgroup as an accessibility affordance
Travis: but as you describe, not an exclusive property of HTML
Travis: as you mention, CSS can create scrollers
Travis: Maybe might not be as natural, but as implementable I suppose
bkardell_: for some subset seems implementable
jcraig: Thanks for presentation, I like the progress
jcraig: thanks for the presentation - I like the progress, and thanks for pointing me at this set of topics before
jcraig: Want to acknowledge benefits to making interaction easier
jcraig: ...
jcraig: as style changes, for example in spicy-sections
jcraig: depending on platform conventions
jcraig: e.g. Safari changes how it handles ? keys in contexts that are not activatable
jcraig: How should that change?
jcraig: for Tabs using left right arrow keys makes sense
jcraig: but if collapse to accordian, then would be up and down keys
jcraig: you mentioned both were implemented in Brian's example
jcraig: but have you thought about the complexities with implementing those in scenarios where users might want to use the arrow keys differently?
jcraig: arrow keys are default scroll pattern in Safari
jcraig: keydown and keyup are interceptable in Safari
jcraig: This is something Web devs often get wrong
jcraig: they forget that in WebKit arrow key interaction pattern is a little different than in Chrome/Firefox
jcraig: This is something challenging with Aria-based widgets
jcraig: I noticed you implemented both left/right and up/down
jcraig: but would interfere with user expectations in a Webkit-based browser
Travis: So WebKit, user expectations for moving around in a tab or vertical list
Travis: are different enough that you would need to code them up differently?
jcraig: User expectation is, all things equal, up/down will scroll the page
jcraig: So in tab situation, left/right is OK
jcraig: but up/down is odd
jcraig: But since primitive, different presentation might change user's expectation of how it works
Travis: but in general case you're thinking up/down ...
Travis: but if in some widget with up/down affordances would be expected
bkardell_: isn't up/down generally a page scroll?
bkardell_: even in Chromium?
Travis: Yes, and to be honest, this is a real fuzzy part of at least the focusgroup proposal
Travis: what's the interplay there between the browser's default behavior after processing arrowkey events
Travis: and having chance of interception
Travis: where does focusgroup kick in?
Travis: idk where we would need to insert the logic in the spec, or if we can
Travis: But there are affordances for up/down control or left/right control
Travis: And it does need to work with other behaviors
Travis: and also with controls that already use arrow keys
Travis: e.g. if you tab into a real <select> element ..
Travis: Does this behavior control native elements?
Travis: or wrap those up in a black box that can't be changed?
bkardell_: Another thing wrote down here
bkardell_: There's another 10yr old proposal, also from Tab
bkardell_: that aims at the other thing
fantasai: yeah, I told him to write that up :)
bkardell_: It was seconded/thirded/fourthed in a Houdini meeting
bkardell_: was allowing to explore CSS-like languages without saying "this belong in CSS"
bkardell_: because a lot of things would be useful to expose in a CSS-like way
bkardell_: want rules and selectors, but not ...
<jcraig> Cascading Attribute Sheets mentioned by Brian, also by Miriam earlier https://
bkardell_: still a dream for me to make that possible
bkardell_: I wrote a polyfill for that
fantasai: awesome
Travis: over time, so wrapping up
Meeting closed.
<Travis> thanks fantasai for scribing!
thanks bkardell_ for scribing also!
<Travis> +1
<Travis> RRSAgent: generate the minutes
Session 2: 15:00 UTC
presence+
presentation scribing is already in https://
[ Travis gives presentation ]
<miriam> the toggle proposal (so far): https://
<fantasai> bkardell_: Travis stressed goal is to reduce JS to hopefully none
bkardell_: one the goals to reduced JS is hopefully done
<fantasai> bkardell_: ...
<fantasai> bkardell_: ...
<fantasai> bkardell_: In our example relies on semantics, so we use names for the patterns you can switch
<fantasai> ... and the you can infer from names where things go
<fantasai> Travis: Zero JS is difficult, so you need something to manage change / fire events
<fantasai> ... maybe aria
<Zakim> jamesn, you wanted to ask about a11y API mappings for toggle
<fantasai> jamesn: My question is about a11y mappings for toggle.
jamesn: I would hate to see something like this without api mappings
jamesn: I can see them being simple for many cases
… but things that have checked and selection ... Idk what we would map to when there are multiple choices
Travis: I think it's a great question, anyone with a response?
… My thoughts are that toggle like focusgroup are lower-level primitives, not higher-level concepts such as what aria roles express
… you can imagine them as aria states
… so when you put a role of tabbar on a particular element, and toggle gets layered onto it, that will provide state needed for it, and needs to communicate with the higher-level role on the element
… seems tricky to et right
jamesn: With mappings can do that, but when get to something like a tree item, which potentially has possibility of selection and checkedness
… it becomes difficult when only a single thing to determine what it is
Travis: thinking out loud, maybe need indicator of what intent is for a toggle, e.g. this is intent to be checkedness or whatever
TabAtkins: Me and Nicole Sullivan have been trying to figure out to what extent we can reliably infer roles from toggle patterns
TabAtkins: ideally majority of things you can do will map to aria roles
TabAtkins: part of why we didn't take out of ED to WD is to make sure don't have worse accessibility, because if authors can move things out of page to CSS they will
TabAtkins: Would love to have help in this area
TabAtkins: Will publish some notes in this area soon
… areas of research, what holes are there
… work will happen in CSSWG
jamesn: ARIA group will be very interested to work on this
<bkardell_> yeah, I think that is all you will need - some hinting, esp if we could somehow limit this to some predictable patterns
jamesn: I think most cases will be easy to handle, worried about the last 5%
jamesn: Maybe if CSS-AAM gets off the ground, this could fit into that
smaug: How does this interact with Shadow DOM?
… if you have focusgroup outside and focusgroup inside shadow
Travis: I have given it a bit of thought, and thought is it will be tricky!
… as thinking about how to adapt focusgroup to CSS
… wondering if there is really only one universal focusgroup
… and to participate you toggle on
… and you participate with related elements as long as they are your proper children
… so perhaps a shadow DOM can participate in a focusgroup by declaring to be so
… if they are shadow of a host, then that naturally extends group down in
… but just speaking off the cuff
smaug: Cases where shadow DOM wants to have its own focusgroup which contains slotted elements
… but then cases where host might want to keep elements for its own purposes
Travis: Also thinking about the delegates-focus attribute
… there's some interplay there that I need to rationalize
smaug: yeah, that part of spec keeps changing all the time
TabAtkins: First thanks for presentation
… for whatever reason I kept putting off reading about focusgroup
… but this is extremely good, and should be very complementary to toggle work
TabAtkins: On the subject of shadow DOM specifically, toggle is designed to work safely and composable across shadow DOM boundaries
… because scoping is by name, explicitly
… only way to interfere with outside of element is to request explicitly
… I suspect there's a design space we can have for focusgroup
<bkardell_> minutes from yesterday's meeting if anyone wants to review them after the fact https://
TabAtkins: where can [missed]
bkardell_: briefly, I noticed last night when presented, you made note of interesting idea of single element can have multiple toggles
… and focusgroup doesn't have, but might be interesting
bkardell_: I think we should consider both of these as work in progres
… both really good ideas, good stuff in both of them
bkardell_: but interesting thing that our spicy-sections has similar concept
… have potentially multiple ways of interaction, not maintained in DOM itself
Travis: continuing on that subject, I struggle to come up with a use case where a element might want to participate in more than one focusgroup
… do you have a use case for that?
bkardell_: Depends where you draw definitions, but normally sections aren't focusable at all
… so in some cases wouldn't have any focus group
… tabs obviously have a single focusgroup
… but if presenting as non-exclusive collapses (like summary/details)
… then ...
… they're not part of a group, they're independent
Travis: in theory might have different focus groups active at different times
… and choose to activate or de-activate?
… can't imagine 2 working at once though, seems weird
<smaug> (we're running out of time)
bkardell_: for focus especially doesn't make much sense
smaug: Was wondering about toggles
… it's moving some of the state handling in the DOM to the CSS side
… so I wonder if ppl have thought what the API would look like
… if it were in the DOM
… maybe doesn't make sense, because this is non-trivial CSS state handling.
TabAtkins: Have a sketch in my spec in an appendix
… idea is that while toggle-create will create toggles
… can create manually as well in JS
… will be map on elements from toggle names to toggle info
… and can always create manually, establish same type of toggle as in CSS
… activation would work via CSS, or by setting state in JS
… I think that should address a fully JS-driven handling of toggle
… but I realize not enough details right now to judge
… if any details want to make sure we consider, pls let us know
bkardell_: Last night a lot of discussion about where this belongs and why, see minutes
Travis: I think we're at time
… Thanks to everyone for showing up
… many good opportunities
… I agree with TabAtkins, these two concepts work very well together
… and hope we can move it forward towards prototyping
<Travis> Slides (PDF): https://
<Travis> Slides (PPTX): https://