On the HTML pages of many sites there are hyperlinks like
<a href="#idName"> ... </a> , which lead not to another page, but to some place on the same page where the link is. This is a common case for extensive articles with a table of contents (if each point of the table of contents is a hyperlink that leads to the title indicated in it) or with notes (if the superscript sign of the note serves as a hyperlink and leads to a note at the end of the text, and there is a hyperlink in the reverse direction). There are many such articles in online encyclopedias (wikis, for example) or in serious online journals.
Unfortunately, the transition through such an internal hyperlink in most modern web browsers is instantaneous, not at all noticeable to the reader. It’s not at all that manual page-wiping, which happens smoothly and takes some (noticeable) time, so it gives the reader some idea of the volume of the text that he flies past.
It's a shame, isn't it?
')
Fortunately, there is a plugin for jQuery, which allows you to achieve what you want unhindered, that is, you can easily turn every transition through the internal hyperlink of a document into such a skimming, all manual like, but only automatically and in a fairly short time
(by default - in a second ), so that the reader just has time to realize what is happening and assess the direction of the squander and the distance traveled, but still does not have time to get bored.
This plugin is called
jQuery.LocalScroll , and, apart from jQuery, it will require another plugin
( jQuery.ScrollTo ) for its work, which is a wrapper for it. So it is enough to install jQuery
and both of these plugins - and then in the future the function call, including automatic scrolling for all internal hyperlinks, can be recorded as simply as possible:
$ ($. localScroll ());
It seems to be all right. But the problem is
that by default such a flush is
just a flush: the document scrolls through the reader’s window, and nothing else.
But in order to completely recreate the result of the transition to the internal hyperlink, you must also add the
line "#idName" to the address (in the address bar taken into account by the browser). Not that the “Back” button in the browser would return the reader too far: by expressing a desire to return back to the table of contents from the subsection (or from a note to the text explained by it), the reader would suddenly return to the previous page.
So that the imitation of the transition through the internal hyperlink remains perfect, that is, to add the
line "#idName" to the page address, Ariel Flesler (the author of the
jQuery.LocalScroll plugin
) suggests including the "hash" parameter:
$ ($. localScroll ({
hash: true
}));
After that, the # -part of the address really changes,
and the Back button starts working normally.
But does such an imitation of a transition through an internal hyperlink reach the desired perfection?
Unfortunately no.
Further problems begin if the document styles use the “: target” selector that
appeared in CSS3 . For example, the style rule
*: target {background-color: red} would seem to highlight the area of the document to which the transition to the internal hyperlink occurred. And it really highlights in new browsers
( as the MDC says , this selector is supported
in Firefox 1.0, in Opera 9.5, in Safari 1.3, and in newer ones). However, if a call to
$ ($. LocalScroll ()) or $ ($. LocalScroll ({hash: true})) is involved, then in Firefox scrolling is smooth,
but the CSS highlighting is cut down. Completely
What to do?
I would never have guessed the reason for this glitch when I would not have looked at the sources of
the LocalScroll plugin of the current version (1.2.7).It turns out that Ariel Flesler decided to radically simplify his life: instead of waiting for the end of the scrolling (and hanging an event that would change the
# -part of the address after the scrolling was completed), the plug-in assigns
# -parts before the scrolling page addresses desired value. Like this:
location = link.hash;
Simple, isn't it?
But after all, such an assignment automatically
(and immediately! ) Scrolls the document to the specified destination, and then the whole idea of a smooth scrolling
will go to ashes?Right!
And therefore, since Ariel Flesler decided to radically simplify his life for himself, he intends to the end: his plugin first selects the attribute
"id =" idName "" (or "name =" idName " )
" at the destination of the hyperlink, then creates
in sight (to eliminate scrolling) a new empty element with this attribute, then assigns
# the address parts to the desired value (scrolling does not occur), then kills this newly created empty element, returns the selected
attribute to the destination of the internal hyperlink
- and only then begins to calm but slowly dissipate it.
Firefox, of course, applies the “: target” selector to the new empty element (which is killed), while the death of this element and the subsequent appearance of a similar attribute in another
element is ignored coolly. I have not decided yet whether this behavior can be considered a Firefox bug. I also did not check how Opera, Safari and Chrome will behave in this situation. It is enough for me that now I know how to overcome this behavior.
It is enough to call
$ .localScroll () with a normal human handler that is triggered
exactly after the skewing is completed:
$ .localScroll ({
onAfter: function (target) {
location = '#' + (target.id || target.name);
}
});
That's all.
Simple, isn't it?
It is always so simple when everything is clear.