I'd like to detect in some "nice" way (Modernizr most likely, but whatever) whether a layout should have embedded scrollable regions of the page, or else (for some mobile use) should just flow all content as one scrollable mass.
The specific case is a "EULA"-like page, where there's a form with an "I ACCEPT" button or whatever, and then a mass of hideous all-caps legal stuff. On a big screen I'd like the whole form visible, so I'd like to put the legal stuff in its own scrolling box. However, on a mobile device that would be kind-of ugly (though I'm no mobile ux expert), so I was thinking of just dropping it all in-line so that the user could read the text (LOL) with simple swipes to scroll, and then at the bottom the buttons would scroll into view.
I suppose I could just check for touch with Modernizr, but that doesn't seem quite right.
edit — though I'm pretty sure that what I described would probably be a usability win anyway, the thing is I'm finding that my Android devices won't pay any attention to "overflow: auto" on a <div> in the middle of a page.
The approach I've taken is to rely on Modernizr.touch and Modernizr.overflowscrolling tests. If Modernizr inserts the touch and no-overflowscrolling classes in the html element in the DOM (or just check Modernizr.touch and Modernizr.overflowscrolling directly), then I avoid overflow:auto. This means that Android devices that mishandle overflow:auto do not get it.
This might be an imperfect solution; there might be devices that can handle overflow:auto that don't get it in this case. But that's not exactly the end of the world, at least in my case. And it seems to work correctly for all the most common devices/browsers.
And it has the virtue of being simple. I already had Modernizr loaded for other uses.
As others have said, the Modernizr.overflowscrolling checks for the overflow-scrolling css property, not for whether the device can scroll content within a div using overflow: auto.
In fact, in my recent testing, the Nexus 5 actually returns Modernizr.overflowscrolling as false, so it cannot be relied on.
This very small script (with no dependencies) seems to enable touch scrolling for devices (Android 2.3) lacking support...
http://chris-barr.com/2010/05/scrolling_a_overflowauto_element_on_a_touch_screen_device/
Link to repo:
https://github.com/chrismbarr/TouchScroll
Related
The problem: I'm working hard to implement a responsive UI in my app. But the keyboard IME on Android squishes my entire page layout into a frame that's about 96 pixels high when in landscape orientation. Typically this means that the input control being edited is not visible in the space above the IME. And one cannot edit a value that's not visible in Chromium. I'm assuming iOS has the same problem.
Setting a minimum height for the page helps. But the Chromium scroll-into-view implementation is not robust enough to keep up with some of the more complex page rewrites that are triggered by a change in window size in my app.
Ideally, I'd like to run the keyboard IME in "extract" mode, where the page is entirely hidden, and only the value being edited is displayed in the space above the IME. But as far as I can tell, there's no way to do that, even in Android native apps. Chromium never runs the keyboard IME in "extract" mode, even in landscape orientation.
The solution I'm current implementing: simulate "extract" IME mode by perform editing of values in a full-screen dialog that contains nothing but a single dedicated <input>.
The question is: how should I detect when to use this solution. it's easy enough to check the browser's navigator.userAgent. The Mozilla foundation recommends checking for /Mobi|Android/ (although I've seen solutions that have 40 or 50 patterns). But I'm wondering whether there's a feature-driven way to check for this instead -- something more along the lines of if ("geolocation" in navigator) ....
But as far as I can tell, there are no features related to whether and how a keyboard IME will change the layout of a page. If there are, I'd like to know. The "feature" I'm looking for is something along the lines of "Will this browser lay out my entire page in a frame that's 96 pixels high (in landscape) whenever an input control gets focus". But "does this browser uses a keyboard IME" would be satisfactory.
Any ideas appreciated.
I am trying to implement a chat application, more precisely a scroll behavior for chat application. I think it's best described with a gif.
https://i.imgur.com/NnpMeOx.gif
As you can see, I want to support a few key features:
Scrolling is reversed so on page load, the messages start on the bottom along with the scrollbar
Chat is scrolled to the bottom when user types in a message. (this is easy, no need to pay attention to this part)
If new messages appears (pushed by websocket in real life) it shouldn't disrupt the existing scroll position, unless it's already at the bottom. Then it should scroll to reveal the message automatically.
So far I've implemented 2 solutions:
a) Display flex and flex-direction column-reverse on the scrollable element. This works beautifully out of a box, but only on chrome :( IE (and Edge) as well as firefox just ignores this totally. NOT A GOOD SOLUTION
b) I flipped the container with transform: scaleY(-1) then I reversed the messages and fliped every one of those with the same transform. The main obvious problem here is the scroll (mouse wheel and arrows) is reversed. I sort of fixed it, didn't manage smooth scroll (sucks) but yet again, Edge (and probably IE) just shows scrollbar as disabled. NOT A GOOD SOLUTION
I am really hoping to find somebody who can point me in the right direction because so far, my efforts while logically ok totally failed browser compatibility.
The code is on https://github.com/PeterKottas/react-bell-chat, it's react but tbh, that doesn't matter much as this seems more like a general web dev exercise.
P.S.: I can't use jQuery, hope that's fair. So either css or plain javascript. Like I've said, this doesn't have much to do with react
Well I got no replies and managed to fix it myself so I'll accept this in case it helps somebody in the future.
3rd and final solution:
I kept the direction of scrolling and didn't do any reversing at all. Instead I hooked into onScroll and wheel event, created a few callbacks and managed to mimic the behavior perfectly. You can find more details in the code on https://github.com/PeterKottas/react-bell-chat.
So, I am developing an app using phonegap and jqm. Everything works great and it's all pretty easy thanks to phonegap build. However, I've started to see some 'stutter issues' that are really annoying. My app at the moment only has two pages and the transition effect between them is 'slide'. The first page has a background color set to it and the second one does not. Some of the issues:
When I navigate from page 1 to page 2, half of the page has the background color from the previous page. It goes away after I do some random swipes on screen.
On one of the pages, I have a regular form with some text input fields and a radio button set at the end. When I move from an input box to the radio button the keyboard slides down but it is replaced by a black area for a short period of time.
The fixed header that I have at the top randomly decides to disappear and reappear again.
These are only few of the annoying ones and these only happen on the mobile device and it works fine on the computer. So, I know it's a performance issue.
I've read up about this on the internet and here on SO and different solution have been proposed like writing custom CSS3 transitions (to take advantage of hardware acceleration) or using something like zepto.js.
What in your opinion would be the best 'cross device compatible' method to overcome these? Is there a way to force hardware acceleration with jquery mobile? Is CSS3 performance even across device platforms?
PS. I have been testing on jelly bean 4.2.2. I am not posting any of my code because they are just plain form elements and some input tags and this happens on multiple pages which are totally different so I am pretty sure this isn't code related.
Any help will be much appreciated.
JQuery writes animations using Javascript which dynamically writes inline styles that change quickly. The issue with that, is that it isn't using the hardware acceleration and if you are testing on a retina device, it animates using pixels as they are a unit of measurement. So it is skipping half of your pixels which causes the stutter.
I have written apps using PhoneGap and the best way I came up was to use CSS3 animations/transitions. Super smooth and they feel just like a native app. You will still use JQuery to add/remove classes, etc., but the movement should come from your CSS.
My users and I are running into a rendering glitch in Chrome only (on both Windows and Mac) where an overlaid div that I'm using for on-hover tooltip-style "popouts"(see first image below) does not get rendered properly in certain cases (see second image below). In all other browsers I've tested, it works as expected.
Here's how the hover popouts are supposed to look (and what happens in Firefox, Safari, IE):
Here's what happens in Chrome:
You can see it in action on this site if you look at May 24 using a browser window width of ~ 1200px (significnatly wider or narrower windows do not seem to work). The glitch only affects the popouts in the bottom right of the menu that are popping left, e.g. those on May 24. Hovers using the same exact mechanism higher up in the page work just fine. Glitched popouts are invisible (except for part of the carat), but if you click on the link to lock the popout in place and then hold left click while moving your mouse around as if to "select text" in the area where the popout should be, it will then render partially. Also if I open dev tools and try to select the popout, it will render just fine at that point.
I've been looking at this all day and trying different work arounds with opacity, z-index, etc. and getting nowhere. Does this glitch ring any bells for anyone? Is there a way to force Chrome to render the div, once its been positioned and unhidden? I'm fine with any work-around or hack.
I use a custom (and fairly complicated) jquery plugin for popouts. If it would be helpful to see the non-minified javascript for the plugin, I can post or provide a link to that, but general guidance that leads me to a work around will be sufficient to be accepted as an answer.
Edit: My Browser Build: 26.0.1410.65
(Per my comments)
This does indeed seem to be a bug in Chrome, though without a smaller test case to reproduce it, it could be very hard to track down. You may want to report it to the Chrome team with as much information as possible.
In support of my "it's a bug" assertion:
The hidden/clipped elements become visible when they are selected.
The elements underneath the hidden/clipped elements are not clickable.
This indicates that z-index and height is correct.
It only happens under very specific circumstances; the rest of the items with the same style work fine. The same item may work fine at a slightly bigger/smaller screen width.
Applying a 3D transform fixes it.
The problem goes away when I apply a CSS transform such as scale3d or translate3d. I imagine this is because certain CSS properties cause the browser to switch to GPU acceleration.
In this case, switching to the fast path for rendering seems to alter the drawing sequence enough to fix the problem.
Super hacky but this fixes it for me:
$('.drop-link.food').on('hover',function() {
$('.tool-tip').css('overflow', 'hidden').height();
$('.tool-tip').css('overflow', 'auto');
});
Obviously this isn't a "good" solution, and even remaining hacky you could probably optimize it to only force the redraw on the tooltip it needs to, but hopefully it helps...
Another clue:
$('.drop-link').on('hover',function() {
$(this).siblings('.tool-tip').css('display','block');
});
This won't fix it right away, but it seems like if this is there, once you've hovered on something, it will work the next time you hover on it.
Not sure if this helps with your situation, but over the last couple of days I've started to notice that certain site elements on Facebook and Weight Watchers no longer show up. Specifically it seems to be affecting items that (I believe) to be controlled by or dependent on Javascript. When I call up these sites in Firefox and Safari they work as expected.
So, by now we all know that iOS mobile Safari uses viewports (as does Android browser), rather than a 'standard' browser window. And this causes issues with overflow:hidden, and position:fixed.
This unfortunately is the same case with the iPad. I presume this is the case for other Android tablets too.
Rather than browser sniffing each time, is there an easy way to determine if the browser has a viewport or if it is standard?
Unfortunately, there's currently no good fix for mobile browsers' lack of support for position:fixed. The reason position:fixed is "broken" in the first place is because—among other things—no browser vendor knows exactly how to handle what happens when zooming in on the document. If you have some time to do some reading, I highly recommend the following articles, which will explain browser viewports and the problems surrounding fixed positioning on mobile in great, painstaking detail:
A tale of two viewports – part two — how viewports work and the problem of mobile browsers. (If you're not familiar with viewports in desktop browsers or want the background info, see also part one.)
The fifth position value does a fantastic job of explaining the problems surrounding position:fixed in a mobile browser, and suggests we might need a new position value – device-fixed.
Those articles will give you the why, but not the how to fix it. For a truly fixed position, you're mostly out of luck. However, if your goal is to have a fixed toolbar below scrolling content, there are a few ways to hack it. I've had success with iScroll.
Edit: The correct way to determine if you are running on a touch-based device is the following feature detection:
var isTouch = ('ontouchstart' in window);
ontouchstart is an event fired in mobile Safari and the Android browser. It is not present on desktop browsers, where you can just use overflow:auto and have regular scrollbars. If isTouch is true, you can then use iScroll.
Try media queries: you can include stylesheets, or apply parts of a stylesheet conditionally, based on the device and viewport dimensions the browser reports.
This article gives a decent enough introduction: http://www.alistapart.com/articles/responsive-web-design/