On Sun, 12 Apr 2015, Anne van Kesteren wrote:
> On Thu, Apr 9, 2015 at 9:05 PM, Ian Hickson 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?
> 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.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
