On Tue, Apr 21, 2015 at 4:58 PM Ian Hickson <i...@hixie.ch> wrote: > On Sun, 12 Apr 2015, Anne van Kesteren wrote: > > On Thu, Apr 9, 2015 at 9:05 PM, Ian Hickson <i...@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
