Provide an affordance that automatically changes based on tab list overflow?

[hidde]

Should we be able to have spicy-sections work automatically, eg apply tabs behavior only if the tab labels fit without wrapping?

Rik wrote:

Not sure if this is covered but imho this needs a “switch to list when would wrap” setting.

The media query values are just numbers guessing at when the tabs would wrap. Best to calculate what the max width is before it wraps and use that.

[bkardell]

Leaving aside the larger question for a moment -- Which 'list' would you switch to by default? collapses? exclusive-collapses? no affordances/inline?

[rikschennink]

Collapse based on total length of content in sections relative to viewport height.

[bkardell]

@rikschennink I "get" the intent of idea, but the details are still kind of fuzzy in my head... Can you expand on how you imagine this working a little more? Like.. .what should an author write (understanding that what an author will write in the custom element isn't probably what we will ultimately propose - it's just an easy way to currently move it 'into css' and think about the problem space)... So, using our element for reference - if an author asks for 'tab-set' as the affordance - it would ... sometimes not be a tab set... automatically? Can you override that? Or are you suggesting this is a kind of different keyword value, or...?

[rikschennink]

@bkardell I think most authors don't know what they want and don't even consider the problems that arise when using tabs on more narrow viewports. So it would be better to automatically handle that.

I think if an author asks for a tab-set you need to fix it to a tab-set, even if it breaks. Same with collapsible, as that is a component that would at least function in every context.

Maybe you can use prefers-{affordance-key} vs {affordance-key}

Use tab-set if possible

<spicy-sections affordance="prefers-tab-set">

Force tab-set

<spicy-sections affordance="tab-set">

[bkardell]

I can definitely see the appeal of this, and maybe some kind of prefers- or auto mode like this makes sense... seems useful to have some discussion and see if there is something larger to discuss in open-ui or something we'd like to experiment with here.. Would be great to hear opinions from @davatron5000 @mirisuzanne and @jonathantneal ...

Here are my own thoughts: As an author who is frequently 'fine' with native controls - I like the idea, even more generally than this, that there could be a 'more like traditional controls` mode that has some decisions and design built in. Currently we make only the very most core decisions necessary for styling (there has to be some default padding between tabs when they go into flow/flex, for example). As an author I would be happy to have the ability to opt into something with some nice 'tab' design - maybe even this.

One thing to note tho - this definitely would seem to open a lot of new doors for disagreements and discussions. There is less agreement at almost every level than one would think. Even "Should controls match the OS, or be consistent across browsers?" is almost exactly 50/50 in polls. Reviewing the tabs in other systems (who we are also trying to coordinate with) there are almost as many opinions on how overflow of tabs should work as there are implementations, for example).

Maybe some second property, or a prefers- version solves some of that? Unsure... What do you all think?

[mirisuzanne]

I like the idea that I could change controls based on some relationship between content & context (like overflow of tabs). And I like the idea of having some clever preset heuristics, so you can get nice stuff "out of the box". And I agree with @bkardell that there would be a lot of complexities to resolve around how that should actually work.

[scottaohara]

i think this thread is the best place to post this comment, rather than making a new one. but, I was wondering if I was missing something, when playing around with the demo today, in how to make the component consistently render as tabs. Rik's comment makes me wonder if I was not actually missing something, and this is not a current feature?

As the tab rendering and the accordion rendering behave differently (and rightly so), I would expect there to be a feature to allow for a persistent rendering of one version of the component or another. I tried doing this in the demo by setting the media query for tabs to just be min-width 1em. But that didn't do what I had expected.

The use case I'm thinking of here are for people who have low vision and are purposefully zooming in and out of their browser to better view a page as a whole, and then zoom in to read content as necessary. Presently, as I mention in #19, the experience here would introduce some hurdles as users who may need to zoom in/out will have the content they are trying to view auto-collapse on them. They'd then have to re-orientate themselves to the new semantic structure. And, if they are also primarily relying on keyboard to navigate the page/component, they would then also need to realize they need to revise their key presses for the altered UI.

Allowing for authors to specify that tabs stay tabs, and then allowing for a tablist to overflow (scroll, generate an overflow menu... I'm sure you all have spoken about this, and I'm sorry I'm likely just rehashing ideas), would be a welcome option to mitigate against my outlined scenario.

Thanks

[bkardell]

i think this thread is the best place to post this comment, rather than making a new one. but, I was wondering if I was missing something, when playing around with the demo today, in how to make the component consistently render as tabs. Rik's comment makes me wonder if I was not actually missing something, and this is not a current feature?

You just only specify that affordance, instead of any others... These are read one time (the implementation of this is not the proposal, we'll figure that part out next) so if you used devtools or something that won't work...

  --const-mq-affordances: [screen] tab-bar;

Basically like https://codepen.io/bkardell/pen/QWMGNzO (other than text, the only diff is in the css pane on line 4).. Can you share a pen of what you tried/expect? There is some more documentation about things we were playing with in the implementation, but we thought better to keep it simple on details and start getting feedback.

[scottaohara]

thank you @bkardell

i was again just using the app that was included with Dave's blog post. I tried playing around with the CSS in that to create what you've demonstrated here. I unfortunately didn't save what I did, since it wasn't working for me. But this this functionality does exist per your demonstration, this is definitely promising. Thank you.