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

On Tue, Apr 21, 2015 at 4:58 PM Ian Hickson <ian@hixie.ch> wrote:

> On Sun, 12 Apr 2015, Anne van Kesteren wrote:
> > On Thu, Apr 9, 2015 at 9:05 PM, Ian Hickson <ian@hixie.ch> wrote:
> > > I'd strongly recommend against adding new methods. It'll mean we now
> > > have two different ways to do the same thing, which means more bugs,
> > > which means less interoperability, more confusing behaviour for
> > > authors, more to document, etc.
> >
> > If the existing method didn't have the flaw with the title argument I
> > wouldn't have suggested it. Also, since they both built upon the same
> > primitive I think we'd be okay in the bugs and interop department.
>
> You are more optimistic than I. In any case, I strongly recommend against
> such redundancy.
>
>
> On Wed, 15 Apr 2015, Majid Valipour wrote:
> >
> > Actually URL is optional in current spec and it defaults to current URL.
> > Why is this suboptimal?
>
> Because it means you can't bookmark the state or share the state,
> reloading the page loses the state, etc.
>
>
> > In anycase If making URL required is a goal then it is best done by
> > introducing a new method to avoid breaking compatibility.
>
> Why is that better?
>
> Changing the optional third argument to become required on the existing
methods will break any call site that is not passing it. This is a non
trivial compatibility issue which does not exists with a new method.


>
> > I personally find a dictionary with only optional members which have
> > appropriate defaults to be very convenient.
>
> I don't disagree... for new APIs. But when we already have an existing
> API, maintaining consistency and lack of redundancy IMHO trumps pretty
> much everything else, if you want the end result to be usable.
>
> A lot of the pain with using the Web's APIs is the inconsistency and
> redundancy that is rampant throughout.
>

I understand the desire for maintaining consistency and reducing
redundancy. On the other hand a new API will allow fixing some existing
warts. I can see merits in both arguments. I am happy to defer the API
decision to spec editors.

I created the W3C bug for this proposal:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=28553

Majid

Received on Thursday, 23 April 2015 22:25:28 UTC