Panels and panelsets


On Sun, 08 Nov 2015 16:08:50 +0100, patrick_h_lauke wrote:

I agree with @heydonworks here that it may offer more flexibility to allow the <paneltitle> to exist outside of the <panel> it refers to.

Making it like a label element for a form control?

Having automagical counting to relate them seems really fragile, so I wouldn’t be keen on that.

One worry I do have, however, is how much stylability is offered. […]

Yes, I think this is absolutely critical. If we don’t make it work, we are not going to achieve much, IMHO.



Having the construct only work when <paneltitle> is inside <panel> will be constraining for many scenarios … simply resulting in authors not using these elements back in favor of hacked-together HTML/CSS/JS. I’d strive for maximum flexibility here.


Can you lay out some of the many scenarios where this would be problematic? We have something like a half dozen visualizations that can all be achieved in the prollyfill and the number is effectively infinite because there is an imperative API that allows you to activate a panel in a set by proxy. You can pretty easily aria-hidden crazy controls and simply clip the ones you don’t want visually in those scenarios. It seems pretty flexible to me, but I’m very interested in hearing which cases it doesn’t work for.


let’s take one step back first and let me ask: does the construct allow for something like

  <!-- some more content here -->

say i want something that visually appears like, oh i don’t know, a horizontal strip of images which, when clicked, open individual modal-looking overlays. i’d want to style the overall container for those images, maybe place extra markup after them, etc. would the proposal as it stands now support this, or are only <paneltitle> and <panel> allowed as children of <panelset> ?

as for the imperative API and triggering by proxy…i’m assuming you mean i could have any arbitrary element in my page, and use JS to then trigger the correct panel to appear? in which case my question would be: as i’d still then need to add all the usual aria-controls, aria-expanded etc info myself to the triggering elements, what’s the value in even using <panelset>/<panel> and triggering that with JS?


Some of this still needs to be defined pending discussions, but in the proposal yes you could do that, but not how you’re thinking. Maybe this is the thing that is missing: The proposal here is that this is the markup, not the composed thing you’re styling. In other words, panelset has a shadow dom and that’s the stuff that winds up styled and exposed in interesting ways with lots of hooks available for the stuff like you’re talking about - something like (which again, take with a grain of salt). As proposed it definitely seems to me that what you briefly describe could be handled. Infinite flexibility really isn’t the goal in my mind in the sense that there are points at which it’s just no longer really a right choice - but a lot of flexibility to work within as wide constraints as possible seems pretty reasonable.

re: the API, no that’s not what I’m saying. As above, a lot of flexibility is possible, but there are times when you want still more ‘visual’ embellishment. Let me give you an example: I have something which lists meetings you have today in sequential order. Each course has a title and then a bunch of stuff about it, links, etc. You decide use a panelset for this. On a big screen you arrange them (again sequentially in time) as tabs and on a small screen as an accordion (just as an example). Along comes someone who says "I really want to see a visualization of time there - like a time chart or something which allows you to see the meetings with just their titles and then when you click them you see details below - because that feels really nice on a desktop. It’s true that might be nice visually but it doesn’t really add any new value otherwise. In a case like this, you could visualize the panelset then like a deck of cards on a desktop to show the details and allow it to remain universally understood as ‘a panelset’ or revisualized as appropriate. The time visualization is purely visual in benefit though, non-visually it is still just the same sequence of course tabs - so you can make that nice chocolately “chart” and have it simply activate tab imperatively and just aria-hidden it because it adds no accessible value at all. The deck is still a deck and how you navigate via keyboard or sr through the sequence - there are just additional ways to link to items in the sequence. I fear that is clear as mud, but if you want to hit me offline I’m happy to show you some stuff and maybe you can even help me explain it better.