- From: James Greene <james.m.greene@gmail.com>
- Date: Wed, 12 Jun 2013 12:22:21 -0700
- To: Kyle Simpson <getify@gmail.com>
- Cc: WHATWG <whatwg@lists.whatwg.org>, Glenn Maynard <glenn@zewt.org>, "Tab Atkins Jr." <jackalmage@gmail.com>, Nils Dagsson Moskopp <nils@dieweltistgarnichtso.net>
*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 <james.m.greene@gmail.com>wrote:
> 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 scroll to it
> (or not, up to you).
>
>
> Sincerely,
> James Greene
>
>
>
> On Tue, May 14, 2013 at 4:44 PM, Glenn Maynard <glenn@zewt.org> wrote:
>
>> On Tue, May 14, 2013 at 5:01 PM, Nils Dagsson Moskopp <
>> nils@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 with how things are actually used, not how you wish
>> they were. Storing state in the hash is a reality.
>>
>> Additionally, pushState does not replace storing state in the hash, nor
>> was
>> it intended to.
>>
>> --
>> Glenn Maynard
>>
>
>
Received on Wednesday, 12 June 2013 19:23:06 UTC