zurb
implicit overflow:hidden design issue
First I wanna say, well done, I't collects common patterns and design approaches into one single powerful package.
Unfortunately I found the following a severe design decision made: Automatically giving all grid-block / frame scrolling capabilities.
In fact webapps just need a few scrollable area's - so I wanna state that it is not the most needed feature. And with having overflow: hidden at nearly all elements causing really heavy lifting for doing stuff like "drag n' drop" based upon position:relative.
Further more it automatically cuts of overlapping stuff even if you don't want it to do so - date pickers.
A much better holistic approach would be a distinct .scrollable class and distinct overflow control classes.
Because the framework is geared towards responsive web apps, in general we assume that any pane of content could need to scroll, as its dimensions will change wildly between mobile and desktop. But you're right that the overflow issue has come up multiple times.
We have a .noscroll class for grid elements, but right now it actually applies overflow: hidden, which is also problematic. So I just added a change to make it overflow: visible instead.
We've had a number of issues with overflows and scrolling, so we're definitely looking at ways to better handle that stuff. For example, most JavaScript plugins assume the window is always the thing scrolling, not some nested scrolling panel, and F4A projects are made entirely out of those. (Tether has been problematic in this regard.)
thanks for your quick reply. I see your point.
I would suggest to make this scrolling feature it's own module, which has to be set explicitly. This separation will avoid messing up with overflow styles by default and will give you much more control.
Targeting devices would be possible with classes like say .scroll-small (if that makes sence in practice...)
Hi Geoff, Andreas,
I've found what appears to be a secondary issue with the (very understandable) existing use of the overflow property on grid-block and grid-content elements.
On iOS (iPad, touch) a modal may be visually "clipped" by the overflow property of the parent container, if the parent container has a style of overflow auto or hidden AND -webkit-overflow-scrolling: touch.
Reproduce case: go to the modal documentation at http://foundation.zurb.com/apps/docs/#!/modal and add the following inline styles to the ng-include for 'partials/examples-modal.html'.
overflow: auto;
-webkit-overflow-scrolling: touch;
You should see the modal become 100% "clipped" (it will look like a z-index issue.) The modal is still "there" and correctly fixed to the viewport - but it isn't displayed.
I did some research into this, the better, albeit somewhat old posts I found describe the problem:
- https://miketaylr.com/posts/2015/06/position-fixed-overflow-hidden.html
- https://benfrain.com/z-index-stacking-contexts-experimental-css-and-ios-safari/
I realize at first this may seem a bit like an edge case, but as we work on our (significantly complex) F4A-based web application we're finding that the need to include modals via the ui-view template files is pretty frequent. We don't want a large set of empty modals sitting on a page which cannot use them.
The approach we've taken to date is:
- Use a replacement for the modal factory, a "master modal" when possible for generic cases
- Use specific CSS styles (overflow: visible) for specific or semi-generic cases
- Where possible, move the modals "up" a level or two in the template tree
That said, we've already seen some self-contained conflicts, for example a page that has:
- A menu bar
- A content area, template based, which requires overflow: auto - and also includes a modal
If it wasn't so damn ugly, one potential quick fix would be to target the parent container of any modal and set it to overflow: visible while said modal was active. I'm not sure if something like that can be done in a performant way.
Anyway - that's my report. Hope it helps and wish I could include an elegant solution as well :)
Andrew H.
