I'm currently trying to use JavaScript to find out how far down the page the user has scrolled; for Firefox 8.0, the keyword is pageYOffset.
To say things mechanically:
The page has a certain height. In Firefox, the useful object is document.documentElement.scrollHeight.
The browser's visible area also has a certain height. In Firefox, the object is window.innerHeight; in IE8, document.documentElement.clientHeight.
I need to know where the user is in the page vertically; in other words, how many pixels down the page the user has scrolled.
Does Webkit have a DOM object that refers to the current scroll position?
Thank you.
I think all you need is:
var scrollTop = document.body.scrollTop || document.documentElement.scrollTop;
var scrolLeft = document.body.scrollLeft || document.documentElement.scrollLeft;
The first half covers webkit and mozilla, the latter for IE.
Ah, there's the IE problem solved.
Also, it turns out that in the case of Chrome and Safari, as well as IE, the scrollbar is brought back to the top for a split second when the page is reloaded.
The window.onload event which I used for testing was called before the bar was brought back to the right position.
Thank you, I was worried about what I was going to do with IE.
Related
I have this code:
window.addEventListener("orientationchange", orientation);
But it isn't firing orientation() on iPhone SE running iOS 10.3, but it is firing on Moto G running Android 5.1.
I need it to update something that depends on the screen width. I have it using window.innerWidth and screen.width if it is undefined (browser differences).
My orientation() is the following:
cpr = Math.floor(window.innerWidth/100) - 3;
if (navigator.userAgent.match(/iPhone|iPad|iPod/i) || navigator.userAgent.match(/Android/i)) cpr = Math.min(Math.floor(screen.width/100) - 1, 8);
if (!cpr || cpr <= 0) cpr = 1;
id('times').innerHTML = "";
updateTimes();
The code works fine, it is just not working on iOS. I tried it in the Chrome dev tools device viewer which lets you use different specific phones or devices to test out the screen size and browser/device styling/code/user-agent. It worked fine there.
I tried looking at all the other Stack Overflow questions about this but they didn't answer my problem.
You can view the website at http://rucubing.bitballoon.com to see how it works.
Thanks!
I have a similar problem with the resize event.
I find the reason on this page.
Up until recently Mobile Safari has correctly posted the resize event after the viewport was resized and after page layout. However, that’s no longer the case. Instead it’s posted before the page has been completely laid out. Any JavaScript relying on clientWidth, clientHeight, getBoundingClientRect etc. in an onresize callback is now broken.
Maybe the orientationchange event is also fired before the the page has been completely laid out,so window.innerWidth return a wrong value.
EDIT:
Recently I find that document.documentElement.clientWidth returns the right value. Maybe this can help you.
I have a layout where I need to call a resize function that resizes a bunch of individual elements when I resize based on other element widths. In Chrome and Safari it does not update the elements correctly although inspector says everything is perfect.
Note: this can't be done with CSS and isn't a responsive web design thing.
The problem seems to be some WebKit based bug that got carried over into Blink. It doesn't happen in Firefox or IE even back to 9. It only happens in Chrome and Safari. I have this code that fires on window resize
var els = this.getElements();
$(els.fauxTable).width($(els.contentContainer).outerWidth());
var sizes = [];
$(els.contentContainer).find('[data-id]').first().find('td').each(function(i) {
sizes.push($(this).outerWidth())
$(els.fauxHeaderContainer).find('th').eq(i).css('width', $(this).outerWidth());
});
console.log(sizes)
return this;
The console logs output the correct values and even more bizarre, you know how if you hover an element in the inspector in Chrome and Safari it highlights the element in the browser window? That position and width and height is perfect. If I change something completely unrelated to sizing like text color in the inspector it all snaps into place like it should.
Here's some screenshots after a resize. You'll see how the headers don't match. And the 2nd pic is after changing the text color and that's it
Does anyone know why this happens or how to work around this?
I think I've got a hack to get it to work. If I add this to the code above just above the return and below the console log it all works
$(els.fauxHeaderContainer).hide().show(0);
My assumption of why this works is because the browser is forced to redraw the element and all it's children.
Page scrolling using the keyboard (PgUp/PgDown, Space) sometimes gets difficult if there are elements with fixed positions at the top of the page, e.g. navigation bars: content that was not visible at the bottom of the viewport might be hidden by the fixed elements after scrolling.
How to address this problem? Do browsers calculate, how far they should scroll? I observed different behaviors for different browsers and also for the same browsers on different pages (for example, Firefox leaves about 80px of old content on http://www.sueddeutsche.de/, but far less on http://www.taz.de. Chromium leaves much more content.).
Is this a problem at all, i.e. does anybody beside me use the keyboard to scroll a web page? Do you know any statistics?
To illustrate the problem, I created a Fiddle:
https://jsfiddle.net/x7hj8c4m/
Try to scroll the content using Space on Firefox. The fixed element will cover text that was not yet visible before scrolling. If you add left: 0, it works.
Very interesting observation.
Firstly, pressing space is equivalent to pressing PgDn. And when PgDn is pressed, the page should scroll vertically by roughly "one page's worth of px". As shown by the OP's fiddle, Firefox in particular calculates this value differently, depending on whether it detects a fixed header.
From my own tests on IE, Chrome, Firefox, I deduced that:
Without a position: fixed element, Chrome and IE scroll down by ~87.5% of the document height; Firefox scrolls down by document height - scrollbar height - ~20px.
With a position: fixed; width: 100% element at the top-left of the screen, Firefox intelligently understands that the element perceptually reduces the document height, and so applies: document height - scrollbar height - fixed element height - ~20px. The condition appears to be quite specific: the element must be fixed exactly at the top-left of the document's box model with full width in order for it to work. The other browsers (Chrome, IE) don't perform such compensation, and performs the standard 87.5% scroll.
I don't know if this is relevant, but it might have something to do with support for position: sticky.
Scrolling by keyboard is a pretty basic behaviour that probably doesn't interact too much (if at all) with the DOM, so expecting it to account for fixed elements is probably too much. There seem to be browser-specific predefined increments (I have no idea if or how they can be customized), but note that the increments are usually smaller (presumably small enough) when you use the up/down arrow keys.
I am creating a web page in which when user hovers on an image it displays a paragraph which is enclosed in a division under it. When the user moves the cursur out of the image the division disappears.
My problem is that when the user clicks the image which is in the bottom of the screen.. i want the page to be scrolled using javascript until the division at the bottom is visible...
I want to know how to do this one. Which function to use??
Thanks in Advance..
Basically you will need to calculate height of your browser window.... then also know the height of your image and it's offset (i.e. where it is placed)...
doing some maths you will get the additional page scroll you want to have...
simply do it...
Here are some functions for you:
in Internet Explorer (backward-compatibility mode):
document.body.offsetWidth, document.body.offsetHeight
in Internet Explorer (standards mode, document.compatMode=='CSS1Compat'):
document.documentElement.offsetWidth, document.documentElement.offsetHeight
in most other browsers – as well as IE9 (standards mode):
window.innerWidth, window.innerHeight (the page's visible width/height)
window.outerWidth, window.outerHeight (the browser outer width/height)
take directly from here: http://www.javascripter.net/faq/browserw.htm
you can check more specific examples here on how to calculate required parameters.
I have a horizontally scrolling div with sections inside. I'm using Ariel Flesler's scrollTo plugin to scroll from one section to another.
Please see: http://jsfiddle.net/carienf/qZeEe/
The fiddle works perfectly in IE 9, Safari 5.1, Opera 11.5 and Chrome 14 (all the latest versions). I can click on a link to scroll to the corresponding section and scroll or mousewheel around in it.
Problem:
In Firefox 7 (and earlier), when I have scrolled to Section 2 or Section 3 and then scroll down using the scrollbar, my position is reset to the first section. This also happens when I resize the browser window. If I scroll using the mousewheel, Firefox behaves (in other words, I stay in the current section).
My question is pretty much an exact repeat of this question: Problem mixing overflow-x, FireFox, and Javascript
Only, the accepted answer (which is to allow the horizontal scrollbar to be visible) doesn't work for my specific case. Also, the guy who posted the question has removed his example. I really need that scrollbar to stay hidden and I really don't like the idea of hiding it behind a div.
Is there a way (other than setting overflow to "auto") to stop Firefox from resetting my scroll position? Or some other way to hide the scrollbar?
UPDATE: Updated Firefox to 8.0 (still a beta version) and then the behaviour is consistent with the other browsers.
I can see a couple of options.
clip off the scroll bar. Takes some measuring and you have to position absolutely.
Add a 2nd div outside that does the vertical scrolling. That breaks your code as it currently stands, but it does resolve the scrolling problem. jsfiddle.net/s2YFM
I just ran into the same exact issue. When my "modal window" pops up, I set html.noscroll { overflow: hidden }, which unfortunately causes the window to scroll-to-top.
Here's the only solution I could make work:
function RemoveScrollbar(html) {
var scrollTop = html.scrollTop;
html.addClass('noscroll');
html.scrollTop = scrollTop;
}
This is MooTools code, but super simple to convert to jQuery or other frameworks.