Although it may (will?) incur additional reflows, here's a short term hack:
1. On DOMContentLoaded (or equivalent), sniff the element ID from the
hash and visually hide that element. This will prevent the browser from
auto-scrolling.
2. On load, visually show that element again and then
*Oh, another option:*
As long as the element does not have CSS styles applied via an ID selector,
you could just change the element ID temporarily rather than visually
hiding it in order to avoid the reflows.
Sincerely,
James Greene
On Wed, Jun 12, 2013 at 12:20 PM, James Greene
when should autoscroll be called? only after a url with a hash is clicked in
the same page? when following a link to a : url#specific_hash? both cases?
I initially conceived it as only firing on initial page load for a URL#hash, so
definitely that case. But I can also see how it might be
So, to that end, what about just adjusting the spec for the hashchange
event to also fire when the page is initially loaded if the URL contains a
fragment identifier (hash)? The other scenarios mentioned would already be
covered by the hashchange event.
Sincerely,
James Greene
On Tue, May
So, to that end, what about just adjusting the spec for the hashchange
event to also fire when the page is initially loaded if the URL contains a
fragment identifier (hash)? The other scenarios mentioned would already be
covered by the hashchange event.
I think there's one critical thing
Kyle Simpson get...@gmail.com schrieb am Tue, 14 May 2013 16:08:17
-0500:
There have been times this automatic behavior has been quite annoying
because of accidential ID/hash overlap.
Please explain how a document subresource can be “accidentally”
referred to by a URL be “accidental”. I do not
On Tue, May 14, 2013 at 2:31 PM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
Kyle Simpson get...@gmail.com schrieb am Tue, 14 May 2013 16:08:17
-0500:
There have been times this automatic behavior has been quite annoying
because of accidential ID/hash overlap.
Please explain
I thought the point was that the JavaScript event would fire before the scroll,
which would allow you to cancel the default action, no?
Tab Atkins Jr. jackalm...@gmail.com wrote:
On Tue, May 14, 2013 at 2:31 PM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
Kyle Simpson
Tab Atkins Jr. jackalm...@gmail.com schrieb am Tue, 14 May 2013
14:34:09 -0700:
On Tue, May 14, 2013 at 2:31 PM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
[…]
Please explain how a document subresource can be “accidentally”
referred to by a URL be “accidental”. I do not
On Tue, May 14, 2013 at 3:01 PM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
The simplest solution (by far) would be to stop storing “information
that is used by JS” in a hash. Even Internet Explorer has pushState()
these days: http://caniuse.com/history.
Applying private
There have been times this automatic behavior has been quite annoying
because of accidential ID/hash overlap.
Please explain how a document subresource can be “accidentally”
referred to by a URL be “accidental”. I do not understand it.
In my case, I ran across this once (not too long ago)
On Tue, May 14, 2013 at 5:01 PM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
The simplest solution (by far) would be to stop storing “information
that is used by JS” in a hash. Even Internet Explorer has pushState()
these days: http://caniuse.com/history.
Web APIs have to deal
Increasingly, sites are doing client-side rendering at page load time, which is
breaking the (useful) functionality of being able to have a #hash on a URL that
auto-scrolls the page to make some element visible after page-load.
A perfect example of this problem is that most #hash URLs (as far
I love that idea!
Sincerely,
James Greene
On Mon, May 13, 2013 at 9:53 PM, Kyle Simpson get...@gmail.com wrote:
Increasingly, sites are doing client-side rendering at page load time,
which is breaking the (useful) functionality of being able to have a #hash
on a URL that auto-scrolls
14 matches
Mail list logo
