Vertical page scrolling with jQuery and cross-browser compatibility
The following is a cross-browser implementation of page scrolling using jQuery.
Recently, on many sites you can see in one or another variation of the button to scroll the page up or down. It looks pretty nice, easy to use, and easy to implement. Faced with the problem of scrolling volumetric content in the next developed project, I decided to implement this functionality.
The task was as follows: make two buttons. By clicking on one, scroll the page to the very beginning, by clicking on the other - to the very end. It was also decided to further implement the possibilities of a purely visual nature, such as animation, the disappearance of buttons, etc., I will not dwell on this here, since the theme is cross-browser compatibility. Actually it became the main problem in the process of writing code.
Having drawn pretty buttons, screwed up the animation and the disappearance of the buttons, and implementing the actual scrolling itself, I found that there are problems with scrolling in different browsers. Frustrated (and for some reason not a bit surprised ...) by this fact(as well as by the fact that it would not be possible to leave work early) , I decided to familiarize myself with similar implementations on the Internet. After reviewing several examples, in the same way, not perceiving any browser, and sometimes working only in one specific one, it was decided to start prototyping, experimenting, and solving the problem using a click method (underline).
Next, I will give a cross-browser version of the implementation of a simple page scrolling up / down, with explanations of where and what can go wrong and in what browser (in no case do I pretend to the originality of the solution, it's just a desire to share my own experience, and save people time solving similar problems). Oh yeah, I forgot to make a reservation, the overwhelming part of the code is written in jQuery.
So what are we going to do. We will make two buttons "up" and "down", by clicking on which a smooth page scrolling to the very beginning and to the very end is carried out, respectively. In this case, the implementation should work equally in all modern browsers.
The task is clear, let's get down to implementation. To begin with, we will write the simplest, namely the HTML code of the buttons and the corresponding CSS styles.
HTML code of buttons:
')
CSS styles:
As a result, we have two circles with the words "Up" and "Down" in the lower left corner of the browser.
Now the most interesting begins - JavaScript, or rather jQuery. As you know, to organize scrolling, manipulations are performed on the scrollTop and scrollLeft properties. In jQuery, these manipulations are performed using the .scrollTop () and .scrollLeft () methods, respectively. We are only interested in .scrollTop.
The first, simplest version of scrolling was as follows:
Everything is, well, very simple and straightforward. But, here's the bad luck, if everything was quite cloudless and pretty in Chrom, in Oper it was also quite tolerable (scrolling up was carried out instantly), then “Harmful Lis” refused to scroll completely. Without hesitation, replacing the line: $ ("body"). Animate "body" with "html", I changed the situation dramatically: FireFox started working, Opera stopped scrolling upwards and began to do it smoothly, but now Chrome stopped responding to button manipulations. From the above ordeals, the following version was digested by all browsers: $ ("html, body"). Animate ... No other acceptable ways to scroll working in all browsers were found.
With the simplest part sorted out. The basic functionality is obtained, now you can think of something more interesting. The first thing that catches your eye is the speed of scrolling. In the presence of however rich content, the use of scrolling becomes a real test for the tendency to epilepsy. Therefore, I want the scrolling to be smoother. Solution to the forehead, set a specific time constant for which should be scrolled. Obvious plus: elementary decision. Not less obvious minus: does not take into account the amount of content. Reasonable solution: calculate scrolling time depending on the size of the content. Let's get started
In the code of both buttons you need to add, the calculation of the current position. To do this, just use the jQuery () method .scrollTop ().
Here, already known problems appear: $ ("body"). ScrollTop () only works in Chrome, $ ("html"). ScrollTop () does not work in Chrome. What, generally speaking, is surprising, since it turns out that with Opera (body). Animate ({“scrollTop”: height}, ”slow”) in Opera we can scroll the body, and upon receiving, the scrollTop property of the body tag is zero, that, judging from the description of element. scrollTop is valid for elements that can not be scrolled.
Option $ ("body, html"). ScrollTop () for obvious reasons does not suit us. We are looking for alternatives. It turns out that the current position can be obtained from the window and document objects, so that it suits all browsers. I think it should be mentioned that using them for animation (for example like this: $ (document) .animate.) Does not lead to anything good.
So, for the working version of the clarification of the current position we take: $ (document) .scrollTop ();
Now let's think about how we will calculate the time. Generally speaking, the solution is trivial and everyone knows: time = path / speed. To determine the path, we just need the current position. Also, the coordinates of the destination point are needed. With the “Up” button everything is simple, the coordinate of the destination point along the vertical axis is zero, which means that the path is equal to the current position. For the "Down" button, everything is a little more complicated, we need to get the "height" of the document. Already anticipating problems, yes? But no, everything is very simple. A very suitable height can be obtained using “body”, “html” or document as a selector.
So. We have a way, now we need speed. Here everything depends on you personally. By visual estimations, the speed of 1.73 seemed to me comfortable (the figure has no, no matter how serious justification, and pretended to be on the eye).
Thus, the working code looks like this:
In addition, you can hang coefficients for which you can multiply time or speed depending on the path to provide more flexibility, but I will not stop here anymore.
As a result, we got a very simple page scrolling implementation that works in any modern browser.
The tests were carried out for DOCTYPE: XHTML 1.0 Strict in browsers Chrome 10, Opera 10, Opera 11, Firefox 4, Internet Explorer 8, Internet Explorer 9.
UPD: Fixed the final example.
How it all began
Recently, on many sites you can see in one or another variation of the button to scroll the page up or down. It looks pretty nice, easy to use, and easy to implement. Faced with the problem of scrolling volumetric content in the next developed project, I decided to implement this functionality.
The task was as follows: make two buttons. By clicking on one, scroll the page to the very beginning, by clicking on the other - to the very end. It was also decided to further implement the possibilities of a purely visual nature, such as animation, the disappearance of buttons, etc., I will not dwell on this here, since the theme is cross-browser compatibility. Actually it became the main problem in the process of writing code.
Having drawn pretty buttons, screwed up the animation and the disappearance of the buttons, and implementing the actual scrolling itself, I found that there are problems with scrolling in different browsers. Frustrated (and for some reason not a bit surprised ...) by this fact
Next, I will give a cross-browser version of the implementation of a simple page scrolling up / down, with explanations of where and what can go wrong and in what browser (in no case do I pretend to the originality of the solution, it's just a desire to share my own experience, and save people time solving similar problems). Oh yeah, I forgot to make a reservation, the overwhelming part of the code is written in jQuery.
Preparing the base
So what are we going to do. We will make two buttons "up" and "down", by clicking on which a smooth page scrolling to the very beginning and to the very end is carried out, respectively. In this case, the implementation should work equally in all modern browsers.
The task is clear, let's get down to implementation. To begin with, we will write the simplest, namely the HTML code of the buttons and the corresponding CSS styles.
HTML code of buttons:
')
<div id="up"><p class="pPageScroll"></p></div> <div id="down"><p class="pPageScroll"></p></div> CSS styles:
#up
{
width:60px;
height:60px;
position:fixed;
bottom:50px;
left:20px;
background-color:#000000;
border-radius:30px;
}
#down
{
width:60px;
height:60px;
position:fixed;
bottom:50px;
left:90px;
background-color:#000000;
border-radius:30px;
}
.pPageScroll
{
color:#FFFFFF;
font:bold 12pt 'Comic Sans MS';
text-align:center;
}As a result, we have two circles with the words "Up" and "Down" in the lower left corner of the browser.
Problems begin
Now the most interesting begins - JavaScript, or rather jQuery. As you know, to organize scrolling, manipulations are performed on the scrollTop and scrollLeft properties. In jQuery, these manipulations are performed using the .scrollTop () and .scrollLeft () methods, respectively. We are only interested in .scrollTop.
The first, simplest version of scrolling was as follows:
// ""
$("#up").click(function(){
//
$("body").animate({"scrollTop":0},"slow");
});
// ""
$("#down").click(function(){
//
var height=$("body").height();
$("body").animate({"scrollTop":height},”slow”);
});Everything is, well, very simple and straightforward. But, here's the bad luck, if everything was quite cloudless and pretty in Chrom, in Oper it was also quite tolerable (scrolling up was carried out instantly), then “Harmful Lis” refused to scroll completely. Without hesitation, replacing the line: $ ("body"). Animate "body" with "html", I changed the situation dramatically: FireFox started working, Opera stopped scrolling upwards and began to do it smoothly, but now Chrome stopped responding to button manipulations. From the above ordeals, the following version was digested by all browsers: $ ("html, body"). Animate ... No other acceptable ways to scroll working in all browsers were found.
Add ryushechek and bows
With the simplest part sorted out. The basic functionality is obtained, now you can think of something more interesting. The first thing that catches your eye is the speed of scrolling. In the presence of however rich content, the use of scrolling becomes a real test for the tendency to epilepsy. Therefore, I want the scrolling to be smoother. Solution to the forehead, set a specific time constant for which should be scrolled. Obvious plus: elementary decision. Not less obvious minus: does not take into account the amount of content. Reasonable solution: calculate scrolling time depending on the size of the content. Let's get started
In the code of both buttons you need to add, the calculation of the current position. To do this, just use the jQuery () method .scrollTop ().
Here, already known problems appear: $ ("body"). ScrollTop () only works in Chrome, $ ("html"). ScrollTop () does not work in Chrome. What, generally speaking, is surprising, since it turns out that with Opera (body). Animate ({“scrollTop”: height}, ”slow”) in Opera we can scroll the body, and upon receiving, the scrollTop property of the body tag is zero, that, judging from the description of element. scrollTop is valid for elements that can not be scrolled.
Option $ ("body, html"). ScrollTop () for obvious reasons does not suit us. We are looking for alternatives. It turns out that the current position can be obtained from the window and document objects, so that it suits all browsers. I think it should be mentioned that using them for animation (for example like this: $ (document) .animate.) Does not lead to anything good.
So, for the working version of the clarification of the current position we take: $ (document) .scrollTop ();
Now let's think about how we will calculate the time. Generally speaking, the solution is trivial and everyone knows: time = path / speed. To determine the path, we just need the current position. Also, the coordinates of the destination point are needed. With the “Up” button everything is simple, the coordinate of the destination point along the vertical axis is zero, which means that the path is equal to the current position. For the "Down" button, everything is a little more complicated, we need to get the "height" of the document. Already anticipating problems, yes? But no, everything is very simple. A very suitable height can be obtained using “body”, “html” or document as a selector.
So. We have a way, now we need speed. Here everything depends on you personally. By visual estimations, the speed of 1.73 seemed to me comfortable (the figure has no, no matter how serious justification, and pretended to be on the eye).
Final option
Thus, the working code looks like this:
$(document).ready(function(){
// ""
$("#up").click(function(){
//
var curPos=$(document).scrollTop();
var scrollTime=curPos/1.73;
$("body,html").animate({"scrollTop":0},scrollTime);
});
// ""
$("#down").click(function(){
//
var curPos=$(document).scrollTop();
var height=$("body").height();
var scrollTime=(height-curPos)/1.73;
$("body,html").animate({"scrollTop":height},scrollTime);
});
});In addition, you can hang coefficients for which you can multiply time or speed depending on the path to provide more flexibility, but I will not stop here anymore.
Summary
As a result, we got a very simple page scrolling implementation that works in any modern browser.
The tests were carried out for DOCTYPE: XHTML 1.0 Strict in browsers Chrome 10, Opera 10, Opera 11, Firefox 4, Internet Explorer 8, Internet Explorer 9.
Some problems:
- border-radius is not known to work in IE8, but cross-browser layout is not a topic of this topic.
- In Opera 10 instruction: $ ("body, html"). Animate ({"scrollTop": 0}, scrollTime); leads to an instant transition to the top of the page. This problem disappears with the transition to Opera 11.
UPD: Fixed the final example.
Source: https://habr.com/ru/post/120960/
All Articles