W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2015

Re: [whatwg] Proposal: Allow disabling of default scroll restoration behavior

From: Philip Jägenstedt <philipj@opera.com>
Date: Mon, 13 Jul 2015 16:55:50 +0200
Message-ID: <CAMQvoCmA=eSbuQ4-p-YV1=vQheTZBoA_ztf85W_TwKVRNfEc9A@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Rick Byers <rbyers@chromium.org>, WHATWG <whatwg@whatwg.org>, Olli Pettay <olli@pettay.fi>, Majid Valipour <majidvp@chromium.org>, Ian Hickson <ian@hixie.ch>, Jonas Sicking <jonas@sicking.cc>
On Mon, Jul 13, 2015 at 4:26 PM, Anne van Kesteren <annevk@annevk.nl> wrote:
> On Mon, Jul 13, 2015 at 3:58 PM, Majid Valipour <majidvp@chromium.org> wrote:
>> It is only used as way to group properties (perhaps similar to
>> ValidityState?) and to keep History interface clean and stack-like. If that
>> is not valuable enough to introduce a new interface then putting these on
>> the History interface is fine.
> I personally prefer flatter structures, but you're correct that
> there's precedent for both and given a 1:1 relationship without setter
> it does seem rather harmless.

FWIW, I also think that just history.scrollRestoration would be fine,
better even. Given the generic name "options", any future additions to
it would still have the same names as if they're added directly to the
History interface, I'm guessing.

If the StateOptions interface could be implemented with no internal
reference back to its owning History object it seems pretty harmless,
a mere holder of values, but it'll look pretty weird if no additions
are actually made to it in the future.

Received on Monday, 13 July 2015 14:56:18 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 July 2015 14:56:19 UTC