I have noticed on certain websites that are implemented as a single page and free scrolling view in browsers that when you trigger a pop-up or modal window a second scrollbar appears to allow the user to scroll through the content of the window. The primary scrollbar is also active but not very effective since the pop-up or modal window blocks out most of the screen.
I cannot imagine that this implementation approach would have very strong usability reasons, so I was wondering if there is a valid technical reason or constraint. But if there is a valid argument from a UX design perspective then I am also interested in finding out the rationale behind it.
When content overflows (too big to fit in the container element), the browser adds a scrollbar. Looks like in your case, the modal is taking up 100% width/height of the viewport, but it's still too small to fit all the content, hence the vertical scrollbar.
To get rid of the scrollbar, people usually add overflow: hidden on the element which hides the scrollbars, but also doesn't allow the user to scroll. This is fine if the content is not important... such as a graphic that's meant to be a background image or something of that sort.
It's poor design in my opinion. If there is enough content that the user will have to scroll to see it, there's no reason to put it in a modal. If you have a modal, keep it small. In some cases where it's necessary though, you can hide the main scroll-bar when the modal is in view.
Related
I am encountering a problem that I'm not sure how to solve. If you look at the screenshot below, you'll see that the UI is laid out so that it neatly fits into the space between the safe area layout guide's top anchor and the top of the keyboard.
The keyboard will ALWAYS be shown in this view controller. But I need a way of knowing what the height of the keyboard is so that I can do some math to figure out how to tall to make the UITextView (the red box).
I tried the approach of registering for notifications on when the keyboard will show, but that is too late.
I need a way of knowing the height of the keyboard before the view renders so that I can configure the height of each of the elements in the UI.
Is there a way to do this?
Thank you!
One option would be to capture the dimensions of the Keyboard when it IS presented then pass those dimensions into this view.
However, you will also want to make sure that you are handling cases such as the split keyboard on an iPad and things of that nature.
For that you might choose to look at the documentation on using the keyboardLayoutGuide and use it with some constraints.
https://developer.apple.com/documentation/uikit/keyboards_and_input/adjusting_your_layout_with_keyboard_layout_guide
In Chrome 80 the devtools now seems to auto horizontal scroll, to the right, to the content in tree views, but not back to the left when navigating back to a parent node. This makes the Elements tab very difficult to use with Word Wrap disabled. I mainly use the Elements tab to highlight elements to view the styles or to see the the parent/child relationship of the nodes. Word wrap makes it hard to view the hierarchy, because a node with many attributes will just take up all the horizontal space when it wraps. Now every time I click a child element I have to manually scroll back to the left to see the start of the parent nodes.
I don't know if this would be considered a bug, because I could see scrolling to the content useful in some places, but it has made the Elements tab difficult to use. Does there happen to be a way to toggle this feature to make horizontal scrolling manual only, because if I need to scroll I will just use the scrollbar myself.
Update:
This is fixed on canary now. The commits that broke and fixed it are referenced from the issue I reported here: https://crbug.com/1050868
I am using iframe-resizer for cross domain application, The Iframe loads fine in desktop and andriod devices but on my Iphone, I am facing below issue:
The bootstrap modal pop ups on Iframe app is hiding and flickering behind when I scroll on page.
I tried
-webkit-overflow-scrolling: touch;
on container of Iframe but that does not work.
Any help/suggestion will be highly appreciated.
We fixed the issue by using position:absolute instead of position:fixed
Position fixed and absolute are somewhat similar in behavior. Both use x,y positioning in the view port and both are outside of the DOM document flow so other content is not affected by the placement of containers. Both require zIndex positioning to determine vertical priority in the view stack.
Position fixed keeps the element pinned at whatever position you set it to regardless of the scroll position of the browser. This makes sense in some scenarios where you actually want to scroll the entire page but leave content in place. The key to remember is to not use it when you build have your own scrollable content on the page.
It turns out in my case I don’t really need position:fixed because I manage the position and size of the container and toolbar headers and footers myself anyway. I know where everything is positioned and keep the content area effectively wedged in the middle of the statically sized elements. By way of CSS and media queries I can force the header to the top and the footer on the bottom using fixed sizes which means I can safely use position:absolute.
Some of the stakeholders on my project expressed doubt in easily recognizing hidden vertical content to scroll to in an MGWT ScrollPanel (without taking a swipe at it). As an attempt to address the concern I'd like to always show the pretty semi-transparent vertical scrollbar as both a hint of more content to scroll to and an indication of the ratio between the amount of displayed vs. all content in the panel.
Is it possible to keep the panel's scrollbars permanently displayed? At first I thought the setShowScrollBarY(boolean) would do the trick but quickly proved myself wrong.
P.S.: Shouldn't there be an m-gwt StackOverflow tag by now? AFAIKT MGWT has gained sufficient traction to have an MGWT-specific stream of questions.
I have had the same issues with clients that suggested that showing scrollbars would be a good idea. If you cut your content right its easy to see for the user that there is more content..
Anyhow I just added a setHideScrollBar(boolean) to the trunk. Download it from ( https://oss.sonatype.org/service/local/artifact/maven/redirect?r=snapshots&g=com.googlecode.mgwt&a=mgwt&e=jar&v=LATEST) and give it a try. Maybe we should also think of an option to flash the scrollbars once to indicate that there is more content.
By the way I would be supporting an mgwt specific tags as I do with the mailing list: https://groups.google.com/group/mgwt
I Am trying to create a Tab Panel where I can add and delete tabs on demand.
Where I am getting stuck is that if a potential user adds too many tabs the new tabs go off the screen.
Each Tab is to contain a text area widget where a user may enter text.
Is there any way of horizontally scrolling the just the TabBar and not the whole browser window?
I could use a scroll panel but I was hoping to scrol just the Tabs, not the panel contents.
I cannot see any available method in the com.google.gwt.user.client.ui.TabPanel API that will perform this function and no real way to split the panel.
Help!
It's not what you've asked for, but you might consider using a StackPanel instead of a TabPanel, since if the user can enter a long list of items it's generally better to have vertical scrolling instead of horizontal scrolling.
The gwt TabPanel isn't the greatest, and there's not a real easy way to do what you want. You could take a look at the tab widget in Ext-GWT, which scrolls the tabs, but I don't think extjs is generally a good idea.
There's a bunch of new layout-based widgets arriving with GWT 2.0. Look at TabLayoutPanel. It places tabs in a very wide container inside a div with overflow=hidden. You might be able to add some controls to scroll that container and get the effect you want.
Good luck, and report back if you get something working. GWT really needs more widget contributors.