Coverflow?

[bkardell]

I have mentioned and we mention in the spec that coverflow is an example of one-at-a-time selection. This is absolutely true, therefore it seems like a natural target for something you might use panelsets for. Last week we had a need for a coverflow of videos - in many ways it is "just like" a carousel in terms of 'expected controls' I would think, but as we got into it we noticed one very key difference. We had assumed that the only real "difference" was some CSS, that instead of only showing the active panel, you'd technically "show" all the panels but clip them off with some container such that you could see the one before it and the one after it. Accessibility wise we were thinking that it would tell you that there were N of them, you'd use left/right/up/down to choose which one you were interested in and then press 'tab' to enter the content (the tab containing the video). Seemed pretty legit to me, until I realized that the reason that tab into the content really works is (currently) because only one is visible. Now, however, with multiple visible, you'd get set onto the first one. To further worsen this, the videos themselves of course have lots of keyboard controllable bits, and worse still these are youtube videos, so they are in independent iframes, so managing all of this while still leaving it simple to put interactive stuff into seems like, actually kind of hard.

I raised a question on twitter for ideas and as I understand there are some floating about, Rob Dodson wrote this up https://robdodson.me/building-better-accessibility-primitives/. So, a few questions fall out of this.

1) is it reasonable to think that panelset is in fact a good base-level element to be used to style as a coverflow? I still don't think this is necessarily unreasonable, but I'd be lying to say that I am as sure as I was two days ago.

2) Are we looking at those / involved in conversations - we should be sharing use cases, which is part of why I am writing this up.

3) Assuming that 1 above is "yes", does anyone have ideas on how we can actually accomplish this?

[Nevraeka]

Great points. Please excuse this comment if it's out of context as I have not delved into many other related items.

Panelset is so low level I think it makes sense that you would extend it to create a coverflow but as a developer defined web component.

That said, coverflow to me is more of a dated item ( not outdated ATM) meaning it's usefulness is not core to the future of the web platform like panelset could be.

Back to the tabindex - I have to think a bit on how I'd imagine this working

[bkardell]

@Nevraeka I think this is kind of my point, this is almost what I expected, that you could say 'visualize it like that' and the basic interactions would remain the same and you could simply build atop some mouse/touch sugary goodness - but keyboard and all would just 'work'. However, I'm not entirely sure that is plausible now that I look at it. Something that is more coverflow than carousel might be different... Not saying for sure that it is but as you say there is not a wealth of them to study on the Web and the ones that I find are not exactly like an apple coverflow as much as they are a carousel that shows N at a time, with the one in the center being the selected one.

[Nevraeka]

Agreed.

On a almost semi-related topic - I've encountered tabindex & activeElement very flaky in Shadow DOM right now, especially when tabbing & focusing on nested composed Web Components. Tabindex just isn't recognized in my shadowRoot tests sadly. I believe these issues are related to the ones @robdodson described in his recent article. Probably ways around my issues here but they shouldnt be so obtuse & difficult to manage. I'm not sure if this is an ES6 class issue since event.target and this are different objects when checking these conditions (one is a JS Class with the same prototype & one is a DOM node)...

document.activeElement == this vs document.activeElement == event.target