Currently vertical tabs and the overlay are turned off for screens with a width below 640px by default. We can do better.

A possible solution would be to run Drupal.attachBehaviors() on orientation change.

#1277352: Responsive vertical tabs
#1260800: Kill the overlay for widths below 640 pixels

Comments

A possible solution would be to run Drupal.attachBehaviors() on orientation change.

I imagine we'd also need to detach some behaviors. To repeat myself from #1277352: Responsive vertical tabs:

So suppose you trap the orientation change / window resize event, and run vertical-tabs if there's enough space. You'd need code to reverse the effect if the dimensions change again, hiding the markup vertical-tabs.js must generate to make the document flow correctly, synchronizing the summaries, and uncollapsing the fieldset of the open tab while collapsing the others. [...] And actually, I've been talking about orientation changes / window resizes that increase width. What happens [...] if width decreases through the breakpoint?

I'm not sure I like the idea of attaching/detaching behaviors as the orientation changes. For one, we'd be adding Javascript to a mobile device's burdens during an orientation change, when the effect may be manageable in faster CSS. Secondly, it seems like one wouldn't want behaviors to appear and disappear on an orientation change, e.g. collapsible-fieldsets to vertical-tabs and vice versa; rather, they should adjust in a way that brings their width down, or takes advantage of additional width, but doesn't fundamentally change the interface.

These comments are, however, likely biased by having thought far more about vertical tabs than the overlay.

Any idea is welcome, from the way we implemented things the detach/attach would be the easiest way of making it work, not the best. Feel free to think up a proper way of handling this, I was merely pointing out a quick and dirty solution for concerned people without much JS XP :p

We can do much better indeed :)

"width below 640px by default" one quick remark, don't use px, use ems to support people with zoom level != 100%

I agree with #1 that maybe it's not desirable to do this, suppose I'm editing something on a tablet (portrait), and I want to type something, so I rotate my tablet to have a bigger keyboard and all of a sudden all fieldsets are transformed into vertical tabs, leaving me probably completely clueless where I was.

Does it seem like a good idea to have a resize or reorient method on our behaviors, so each behavior can decide how it should handle those changes, and we can just fire them on all behaviors when resize/reorient occurs? This might, however, cause a significant perf impact upon changing orientation.

This is possible since #1815602: Introduce a polyfill for matchMedia is committed, but maybe providing an easy php wrapper is good idea.

Issue tags:+d8mux

Tagging to d8mux

Turning vertical tabs to details could be a solution, but what about the overlay?

Version:8.x-dev» 9.x-dev

Past API freeze

Issue summary:View changes

add related issues