I'm trying to read the current y-scroll of a page to fadeIn/out elements while the user scrolls past them.
I tried many different solutions from this site, things like .scrollTop, .pageYOffset, .scrollY etc. , with $(window) and $(document), $("element"), convert it to percentage and so on...
First they all work fine, But when I zoom in the browser, the results I get change each time:
I have this simple setup as a page
<div style="height: 800px"></div>
<h1 style="" id="test"> Test </h1>
<div style="height: 2000px"></div>
and for example this to read the scroll position:
$(window).scroll(function() {
console.log($(this).scrollTop());
When I scroll down to my header and go just above the T of Test it says 830px.
But when I zoom in (tried chrome and firefox), first of all my console stops giving continous values and seems to get laggy(?) and going to the same place (right above the T) returns a different value (smaller when zooming in) depending on my zoom, so for example 500px.
Is there a solution to this, or Is there maybe another approach to achieve what I'm trying to do?
Additional information
After more reading I know also see the difference between Zooming with Ctrl+/- (e.g. changing the font-size) and zooming by using my touchpad and 2 fingers. That also changes the results I get, so sometimes the element appears when window.scrollY returns 800px and sometimes it starts appearing when it says 300px. I'm getting more and more confused by this, maybe someone can help me with be basics here ;)
Came across this : this, Set precise scroll position when pinch-zoomed in sounds kind of what I'm experiencing.
Thanks in advance for any insights!
My Question is obsolete.
After reading more about browser zoom vs OS zooming, pixel vs pixelDensity etc.
it all makes sense now.
Related
if (element.getBoundingClientRect().bottom < window.innerHeight) {...}
I'm loading content when scrolling to the bottom of the page. The problem is, at a certain point getBoundingClientRect().bottom ain't smaller than window.innerHeight - 640.390625 640. I don't know where this slightly bigger number comes from. There's no margin or anything else preventing the container getting to the end of the page.
If you need more details, just ask and I'll add it.
EDIT: The problem just seems to appear when simulating mobile devices in the dev tools. As a workaround I just substracted 25 from getBoundingClientRect().bottom but this seems ugly.
Try using IntersectionObserver. You can read up on it here
I'm currently pulling my hair out with this one. Im a new web developer using bootstrap themes and templates just to get a feel for the industry, and have hit a bump in the road that needs an experienced input
Ive got a website that Ive created at the minute, where certain parts of the screens don't resize properly when the aspect ratio is lower than mine (1920px). However zooming out on the browser corrects this issue. For instance 1440px needs to be zoomed out to 75% in order for everything to be correct. A number of images have fallen out of the bootstrap framework due to a positioning request from my friend, although ive used #media queries to correct a number of these issues but thats clearly where the problems have arisen.
I'm aware that I should go back and fix this bugs from scratch but I seriously will go crazy if I have to do that. I do know that it is possible to resize the browser zoom being used if the aspect ratio is below a certain level however Ive heard thats not the way to go.
Does anyone have any advice on how to proceed with this one? Is there an "entire page/html" zoom query that can be put in place rather than a browser zoom?
Use CSS zoom:
body {
zoom: 0.75;
}
If you're just starting out, I would recommend you right click on elements that are not appearing as expected, and inspect them in your Chrome console (or whatever browser you're on). You can then first adjust styling properties and transfer over the appropriate changes to your actual code once you confirm that the adjustments you make do what you want.
I'm working on a responsive website and I'm so frustrated with finding a solution for this one.
this is the basic structure:
I used 'vh' sizes and when ever the URL bar slides up - the page changes the sizes of the elements and kinda "jumps", which makes a bad user experience especially when reading.
I changed the size of the second part (orange) to 'em's because I thought maybe it will not "jump" so at least where there are texts this will not happen - and I was wrong. it's still happening.
What I'm trying to get to is to make the first part (in baby-blue) opened on all of the screen no matter what screen size is displaying the page (but without making it "jump").
I'm very frustrated finding a solution to responsive pages, can you please help me solve this, or help me with some reading material that will help me solve this ?
Note: I found some codes to add that should remove the URL bars from iPhones and it didn't work :I
Since you've tagged Javascript/jQuery I'd suggest assigning the height by getting the height the specific element (eg: window, document or viewport) you want. A good comparison can be found here. From the looks of it, you might want window.outerHeight which may account for what's "under" the URL bar. On my desktop, it's the only value that's different from the rest but on mobile other values may be different as well.
document.querySelectorAll(".whatever").style.height=window.outerHeight;
In the project I currently work on we experience very strange rendering issue. The worst thing is that this issue emerges completely spontaneously and after several days of testing we haven't managed to find the sequence of actions wich would reproduce this issue. Here is an explanation of how this bug look like. Here is a screenshot of how the page should look like:
But instead of this after some manipulations content block pops up so only the part of the content is visible and its look like:
The most strange thing is that such a position of the block is not based on values of CSS properties as shown by Web Inspector.
As you can see the CSS properties are ok, while the position of the block is not. This fact suggest me that it could be some rendering bug of the WebKit engine
The project is built using Ext JS 3.4 and it is a classical one-page web application. This issue was seen in the last versions of Chrome and Safari on Mac OS 10.7/10.8. Though due to the spontaneous nature of this issue it might be present in other browsers and platforms too.
Any piece of advice on how to debug such issues or how it could arise is welcome.
Please check if any of your code or Ext JS's code is using scrollIntoView method, we have seen similar issue when scrollIntoView is called on any element that does not have overflow set to auto and it is inside an clipped element that is probably placed relatively positioned.
It seems bug in webkit because it scrolls clipped element which is not happening in other browsers.
I also see two elements in same hierarchy which has overflow set to auto. And scrollIntoView is scrolling wrong element.
Chrome and safari on Mac are having problems with scrolling. If the element has been scrolled and the content changes, the scroll position is kept even if the content is not high enough to require a scrolling.
The work around we have found in our application is to resize the container (the one that has the scroll) so that it has the scrollbar (or else you cannot play with the scrolling properties) and then reset the scrolling, and the height.
$(container).css('height',1).scrollTop('1').css('height','');
Here is how we do it in jQuery. You will not even see a flickering :)
I am not sure if it is the problem, but this thing kept us on our feet for a while.
i went through the same problem while working with a sencha touch 2 app and because thats same as ExtJS i have a solution for you
this probably is a bug in the framework and this happens when the ExtJS renders the application before the browser populates mayb the correct window.innerWidth and window.innerHeight and thus the viewport cannot take the correct width and height. this also explains the randomness of the event. This becomes more prominent when used on mobiles probably because of the limited resources and slow response.
the solution that i took to handle this mayb isnt a good one but i couldnt find a better one considering is a glitch in the framework itself
i poll for the correct height and width of the browser for around a sec after every say 100ms for the correct height and width of the window and if i find that the height OR width of the viewport isnt same i re adjust it. because you are working with ExtJS and app would run on high powered systems(as compared to mobile phones) i would recommend a smaller interval and then to be safe a larger time period to which it polls.
heres the code that i use currently edit according to your needs
var aId = setInterval(function () {
if (Ext.Viewport.getWidth() !== window.innerWidth || Ext.Viewport.getHeight() !== window.innerHeight) {
Ext.Viewport.setSize(window.innerWidth, window.innerHeight);
clearInterval(aId);
}
num = num + 1;
if (num > 10) {
clearInterval(aId);
}
}, 100)
i currently use this code inside the launch function of the app. but you can also use this inside the show event of the viewport for which you should keep the interval time to minimum possible to avoid any lags.
with this if you think this app might be used on devices where the window height and width would be changed by the user (like that of mobile browser when the orientation changes or if you think user would change the height and width of the browser window). then just copy & paste the same code piece inside the viewports resize event so that it also polls and resizes viewport when the size of the viewport changes.
Did you try adding a clear:both; block after the toolbar div ?
<div style="clear:both;"></div>
#bjornd it's pretty hard to debug without any code :)
Is the toolbar positioned and has the content an ID that's called in the URL?
In other words: is there some link (e.g.) that triggers #content and has no preventDefault() etc? This would scroll the page probably.
I dunno, this was the first thing that came to mind.
It could also be the toolbar content that is (for some reason) no longer cleared or some change in the content's top position (relative to another changed/removed element?)
Try and create a stripped-down test-case that contains the simplest of code but still triggers the bug. If you post that (through e.g. a Fiddle etc) we can have a proper look.
It might be a css issue;
I've had a similar issue using equal height divs by setting a padding-bottom: 99999px; and margin-bottom: -99999px;. Which workes fine in all cases, except when you use hashtag anchors to jump to a div further on the page. Jump down.
In that case the top of the page clipped and started with the div I wanted to see.
Since you say the problem is pretty hard to track, this might be something to have a look at. The solution was to remove these 2 css lines and use another method of setting div heights.
I'm working on a jQuery lightbox type plugin that needs to function for mobile devices and desktops. I'm having a problem with the full screen overlay effect. From my research, it seems that the standard solution for this is to use position: fixed or background-attachment: fixed to accomplish the overlay effect. Of course, mobile devices don't support fixed positioning, and so I'm trying to find another way.
Right now, I'm attaching a function to $( window ).on( 'resize' ) to get the new dimensions of the window and set the overlay to them. The problem I'm seeing is that this is triggering flickering scroll bars that make the whole thing really jumpy when I size the window down. You can see the effect here: (http://jsfiddle.net/dominic_p/ZqLCx/3/ or http://3strandsmarketing.com/lightbox.php).
Any idea how I can solve this? The code is still in heavy development so it's kind of a mess, but I tried to highlight what I think the 2 problem areas are in the jsFiddle with a comment that says "THE PROBLEM: START".
UPDATE:
I had a brilliant idea to just change the positioning to fixed for desktop browsers and still rely on my resizing scripts for mobile browsers. It seems to have helped a lot, but there is still some significant flicker when the browser window starts to get small (especially when shrinking it vertically). Also, when using position: fixed on Android 4 there is suddenly a large white gap on the side of the screen that I can horizontally scroll to in portrait mode only. Anyone have an idea of how to resolve either problem?
The solution for the flicker problem seems to be to set the overflow-x (or just overflow if you prefer) property for the <body> element to hidden. For curiosity's sake, it actually wasn't the overlay layer, but the lightbox contents that were causing the flicker.
I'm still struggling with the white gap that shows up on Android, but that's a separate problem, so I'm posting this as the solution.