Re: [whatwg] DOMTokenList methods would be more useful with a space separated token list
On Wed, 2 May 2012, Rick Waldron wrote:
> On Wed, May 2, 2012 at 7:17 PM, Ian Hickson wrote:
> > On Wed, 2 May 2012, Rick Waldron wrote:
> > >
> > > JS APIs like this should always return the object (constructed
> > > instance or not) and therefore chain implicitly.
>
> Let me rephrase, I simply expect modern DOM APIs to return something
> useful.
I don't think a function should return something just for the sake of
returning something. I agree that when there is something useful to return
(something that the caller doesn't already have at hand, in particular,
and might be able to make use of) that it makes sense to return it.
> > I understand that this is mostly a matter of taste in API design, but
> > IMHO that's an anti-pattern.
>
> If you're writing and designing specifications that will be implemented
> in JavaScript, then you should design them _for_ JavaScript. Section 15
> of EcmaScript specifies more then enough "prior art" that supports my
> statement above.
There's plenty of prior art in the Web platform to support pretty much any
pet design philosophy.
> > It encourages poor style;
>
> 60% of the JavaScript written on the web disagrees.
Disagrees with what? You really think that 60% of the Web is written in
good style?
> > it discourages functional programming patterns, instead favouring
> > state mutation patterns;
>
> JavaScript is a multi-paradigm language, leave your design hangups at
> the door.
...says the guy arguing for a particular paradigm. :-)
> > it makes APIs harder to extend;
>
> This is just outright false, considering JavaScript is probably the most
> extendable and historically extended language at the API level.
If you have a return value, you can't change it. If you don't, you at
least have the chance that you might be able to introduce one. So yes, it
makes APIs harder to extend.
> > it makes APIs that do have useful return values inconsistent with
> > other APIs;
>
> elem.classList.add("foo") returns "undefined". That's hardly what I
> would consider a "useful return value".
Right. But elem.classList.contains() returns a boolean, and
elem.classList.item() returns a string. So they can't be consistent with
the APIs that return self.
> Returning the element's classList instance makes an incredible amount of
> rational sense.
It's an aesthetic choice with some advantages and some disadvantages. I
don't think it's an obvious choice, by any means.
> > it is, in fact, a layering violation: it attempts to shoehorn what
> > should be a language design feature into the API layer.
>
> Much like the DOM and its weird C++ and Java influences.
We're trying to reduce them, not
> Is this group aiming to define APIs that developers will always paper
> over with abstractions, guaranteeing all app code needs a good 50k just
> to provide a decent API?
There are certainly design decisions where one might wonder whether I am
just actively trying to make the Web bad (localStorage comes to mind). But
when it comes to chaining vs not chaining, it's just not the same. I
understand that some people prefer:
a.foo().bar().baz();
...rather than:
a.foo();
a.bar();
a.baz();
...but if an author cares so much about the difference that they'll write
50,000 lines of code (!) to abstract out the difference (!) then I think
they might have their priorities set up wrong.
On Thu, 3 May 2012, Jake Verbaten wrote:
>
> Choosing some mechanism to add multiple classes at once is useful, whether
> that's making add have an arbitary arity, allow it to take an array, allow
> it to take a space seperated string or allowing add calls to be chained.
>
> My personal vote is for arity.
This API is now in the DOM Core specs, so I'll let the DOM Core editors
respond to this.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] DOMTokenList methods would be more useful with a space separated token list
Sidetracking whether chaining is a useful API design or not isn't useful. Choosing some mechanism to add multiple classes at once is useful, whether that's making add have an arbitary arity, allow it to take an array, allow it to take a space seperated string or allowing add calls to be chained. My personal vote is for arity.
Re: [whatwg] DOMTokenList methods would be more useful with a space separated token list
On Wed, May 2, 2012 at 7:17 PM, Ian Hickson wrote:
> On Wed, 2 May 2012, Rick Waldron wrote:
> >
> > JS APIs like this should always return the object (constructed instance
> > or not) and therefore chain implicitly.
>
Let me rephrase, I simply expect modern DOM APIs to return something useful.
>
> I understand that this is mostly a matter of taste in API design, but IMHO
> that's an anti-pattern.
If you're writing and designing specifications that will be implemented in
JavaScript, then you should design them _for_ JavaScript. Section 15 of
EcmaScript specifies more then enough "prior art" that supports my
statement above.
> It encourages poor style;
60% of the JavaScript written on the web disagrees.
> it discourages
> functional programming patterns, instead favouring state mutation
> patterns;
JavaScript is a multi-paradigm language, leave your design hangups at the
door.
it makes APIs harder to extend;
This is just outright false, considering JavaScript is probably the most
extendable and historically extended language at the API level.
> it makes APIs that do have
> useful return values inconsistent with other APIs;
elem.classList.add("foo") returns "undefined". That's hardly what I would
consider a "useful return value". Returning the element's classList
instance makes an incredible amount of rational sense.
> it is, in fact, a
> layering violation:
it attempts to shoehorn what should be a language
design feature into the API layer.
>
Much like the DOM and its weird C++ and Java influences.
>
> But I'll leave it up to the DOM guys to decide what to do for that
> interface. :-)
>
Is this group aiming to define APIs that developers will always paper over
with abstractions, guaranteeing all app code needs a good 50k just to
provide a decent API? Or shall we craft APIs that developers will actually
write code for?
Rick
>
> --
> Ian Hickson U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
> Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
>
Re: [whatwg] DOMTokenList methods would be more useful with a space separated token list
On Wed, 2 May 2012, Rick Waldron wrote: > > JS APIs like this should always return the object (constructed instance > or not) and therefore chain implicitly. I understand that this is mostly a matter of taste in API design, but IMHO that's an anti-pattern. It encourages poor style; it discourages functional programming patterns, instead favouring state mutation patterns; it makes APIs harder to extend; it makes APIs that do have useful return values inconsistent with other APIs; it is, in fact, a layering violation: it attempts to shoehorn what should be a language design feature into the API layer. But I'll leave it up to the DOM guys to decide what to do for that interface. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] DOMTokenList methods would be more useful with a space separated token list
On Wednesday, May 2, 2012 at 6:41 PM, Ian Hickson wrote:
> On Wed, 2 May 2012, Rick Waldron wrote:
> > On Wed, May 2, 2012 at 6:13 PM, Ian Hickson wrote:
> > > On Fri, 28 Oct 2011, David Håsäther wrote:
> > > >
> > > > It would be more useful if the DOMTokenList methods (contains, add,
> > > > remove, toggle) would take a space separated list of tokens. This is
> > > > the behavior most DOM libraries have when dealing with class names.
> > > >
> > > > So, when setting two classes, instead of
> > > >
> > > > ele.classList.add("hey");
> > > > ele.classList.add("ho");
> > > >
> > > > you could do
> > > >
> > > > ele.classList.add("hey ho");
> > > >
> > > > Currently, the latter results in an INVALID_CHARACTER_ERR.
> > > >
> > > > The behavior of all methods should be obvious I guess.
> > >
> > > This has now moved to DOM Core. If you still want this I recommend filing
> > > a bug on that spec.
> > >
> > > http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html
> > >
> > >
> > > On Fri, 28 Oct 2011, Mike Taylor wrote:
> > > >
> > > > I would prefer if it returned the DOMTokenList, to enable chaining like:
> > > >
> > > > foo.toggle('bar baz').remove('bat');
> > >
> > > That makes for very hard to read code, IMHO. I much prefer:
> > >
> > > foo.toggle('bar');
> > > foo.remove('bat');
> > >
> >
> >
> > Mike's recommendation is the same API introduced by jQuery a few years
> > ago and since then, there have been many requests to expand the
> > signature to other jQuery APIs. The toggle('bar baz') is not a good
> > example, it should be illustrated with .add() and .remove():
> >
>
>
> It was the chaining I was talking about with respect to Mike's example,
> not the multiple values.
>
>
Great, in both cases, what _you_ prefer is not what is desired based on most
common patterns and use cases.
JS APIs like this should always return the object (constructed instance or not)
and therefore chain implicitly.
I'll take this to DOM Core.
Rick
>
>
> > Adding >1 class at a time is a _very_ common pattern in "real world" web
> > development.
> >
>
>
> As mentioned above, this API has now moved to DOM Core. If you still want
> this I recommend filing a bug on that spec.
>
> http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html
>
> --
> Ian Hickson U+1047E )\._.,--,'``. fL
> http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,.
> Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
>
>
Re: [whatwg] DOMTokenList methods would be more useful with a space separated token list
On Wed, 02 May 2012 15:41:07 -0700, Ian Hickson wrote: On Wed, 2 May 2012, Rick Waldron wrote: Adding >1 class at a time is a _very_ common pattern in "real world" web development. As mentioned above, this API has now moved to DOM Core. If you still want this I recommend filing a bug on that spec. http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html We have one, thanks! https://www.w3.org/Bugs/Public/show_bug.cgi?id=13999 -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] DOMTokenList methods would be more useful with a space separated token list
On Wed, 2 May 2012, Rick Waldron wrote:
> On Wed, May 2, 2012 at 6:13 PM, Ian Hickson wrote:
> > On Fri, 28 Oct 2011, David H�s�ther wrote:
> > >
> > > It would be more useful if the DOMTokenList methods (contains, add,
> > > remove, toggle) would take a space separated list of tokens. This is
> > > the behavior most DOM libraries have when dealing with class names.
> > >
> > > So, when setting two classes, instead of
> > >
> > > ele.classList.add("hey");
> > > ele.classList.add("ho");
> > >
> > > you could do
> > >
> > > ele.classList.add("hey ho");
> > >
> > > Currently, the latter results in an INVALID_CHARACTER_ERR.
> > >
> > > The behavior of all methods should be obvious I guess.
> >
> > This has now moved to DOM Core. If you still want this I recommend filing
> > a bug on that spec.
> >
> > http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html
> >
> >
> > On Fri, 28 Oct 2011, Mike Taylor wrote:
> > >
> > > I would prefer if it returned the DOMTokenList, to enable chaining like:
> > >
> > >foo.toggle('bar baz').remove('bat');
> >
> > That makes for very hard to read code, IMHO. I much prefer:
> >
> > foo.toggle('bar');
> > foo.remove('bat');
>
> Mike's recommendation is the same API introduced by jQuery a few years
> ago and since then, there have been many requests to expand the
> signature to other jQuery APIs. The toggle('bar baz') is not a good
> example, it should be illustrated with .add() and .remove():
It was the chaining I was talking about with respect to Mike's example,
not the multiple values.
> Adding >1 class at a time is a _very_ common pattern in "real world" web
> development.
As mentioned above, this API has now moved to DOM Core. If you still want
this I recommend filing a bug on that spec.
http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] DOMTokenList methods would be more useful with a space separated token list
On Wed, May 2, 2012 at 6:13 PM, Ian Hickson wrote:
> On Fri, 28 Oct 2011, David Håsäther wrote:
> >
> > It would be more useful if the DOMTokenList methods (contains, add,
> > remove, toggle) would take a space separated list of tokens. This is the
> > behavior most DOM libraries have when dealing with class names.
> >
> > So, when setting two classes, instead of
> >
> > ele.classList.add("hey");
> > ele.classList.add("ho");
> >
> > you could do
> >
> > ele.classList.add("hey ho");
> >
> > Currently, the latter results in an INVALID_CHARACTER_ERR.
> >
> > The behavior of all methods should be obvious I guess.
>
> This has now moved to DOM Core. If you still want this I recommend filing
> a bug on that spec.
>
> http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html
>
>
> On Fri, 28 Oct 2011, Mike Taylor wrote:
> >
> > I would prefer if it returned the DOMTokenList, to enable chaining like:
> >
> >foo.toggle('bar baz').remove('bat');
>
> That makes for very hard to read code, IMHO. I much prefer:
>
> foo.toggle('bar');
> foo.remove('bat');
>
Mike's recommendation is the same API introduced by jQuery a few years ago
and since then, there have been many requests to expand the signature to
other jQuery APIs. The toggle('bar baz') is not a good example, it should
be illustrated with .add() and .remove():
foo.add("many class name strings");
foo.remove("many class name strings");
Adding >1 class at a time is a _very_ common pattern in "real world" web
development.
Rick
>
> --
> Ian Hickson U+1047E)\._.,--,'``.fL
> http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
> Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] DOMTokenList methods would be more useful with a space separated token list
On Fri, 28 Oct 2011, David H�s�ther wrote:
>
> It would be more useful if the DOMTokenList methods (contains, add,
> remove, toggle) would take a space separated list of tokens. This is the
> behavior most DOM libraries have when dealing with class names.
>
> So, when setting two classes, instead of
>
> ele.classList.add("hey");
> ele.classList.add("ho");
>
> you could do
>
> ele.classList.add("hey ho");
>
> Currently, the latter results in an INVALID_CHARACTER_ERR.
>
> The behavior of all methods should be obvious I guess.
This has now moved to DOM Core. If you still want this I recommend filing
a bug on that spec.
http://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html
On Fri, 28 Oct 2011, Mike Taylor wrote:
>
> I would prefer if it returned the DOMTokenList, to enable chaining like:
>
>foo.toggle('bar baz').remove('bat');
That makes for very hard to read code, IMHO. I much prefer:
foo.toggle('bar');
foo.remove('bat');
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] DOMTokenList methods would be more useful with a space separated token list
On 10/28/11 4:55 PM, Ojan Vafai wrote: I agree in general. Changing add/remove is definitely worth doing. In the case of toggle, WebKit already returns a boolean Gecko likewise. -Boris
Re: [whatwg] DOMTokenList methods would be more useful with a space separated token list
On Fri, Oct 28, 2011 at 4:55 PM, Ojan Vafai wrote:
> I agree in general. Changing add/remove is definitely worth doing. In the
> case of toggle, WebKit already returns a boolean. Returning the
> DOMTokenList
> is clearly preferable IMO. It's a new enough API that maybe the web doesn't
> yet depend on the return value of toggle?
>
The return value of toggle() seems more useful than chaining.
if(foo.toggle("purple"))
alert("now purple");
else
alert("no longer purple");
This is preferable to me over the following, because the token ("purple")
doesn't have to be duplicated:
foo.toggle("purple");
if(foo.has("purple"))
...
--
Glenn Maynard
Re: [whatwg] DOMTokenList methods would be more useful with a space separated token list
On Fri, Oct 28, 2011 at 2:03 PM, Glenn Maynard wrote:
> On Fri, Oct 28, 2011 at 4:55 PM, Ojan Vafai wrote:
>
>> I agree in general. Changing add/remove is definitely worth doing. In
>> the
>> case of toggle, WebKit already returns a boolean. Returning the
>> DOMTokenList
>> is clearly preferable IMO. It's a new enough API that maybe the web
>> doesn't
>> yet depend on the return value of toggle?
>>
>
> The return value of toggle() seems more useful than chaining.
>
> if(foo.toggle("purple"))
> alert("now purple");
> else
> alert("no longer purple");
>
> This is preferable to me over the following, because the token ("purple")
> doesn't have to be duplicated:
>
> foo.toggle("purple");
> if(foo.has("purple"))
> ...
>
The counterargument is that it's possibly more confusing to have some of
these methods allow chaining and some return a boolean. It's not clear to me
which is better in this case. I don't feel strongly about it either way.
Leaving toggle alone would have the benefit of avoiding any web compat
concerns.
Re: [whatwg] DOMTokenList methods would be more useful with a space separated token list
On Fri, Oct 28, 2011 at 1:55 PM, Ojan Vafai wrote: > I agree in general. Changing add/remove is definitely worth doing. In the > case of toggle, WebKit already returns a boolean. Returning the DOMTokenList > is clearly preferable IMO. It's a new enough API that maybe the web doesn't > yet depend on the return value of toggle? I know that I, at least, assumed that it was horrible like every other DOM API and just returned undefined, so I've certainly never depended on it. ~TJ
Re: [whatwg] DOMTokenList methods would be more useful with a space separated token list
On Fri, Oct 28, 2011 at 1:23 PM, Jonas Sicking wrote:
> On Fri, Oct 28, 2011 at 9:42 AM, Aryeh Gregor wrote:
> > On Fri, Oct 28, 2011 at 12:07 PM, Mike Taylor
> > wrote:
> >> I would prefer if it returned the DOMTokenList, to enable chaining like:
> >>
> >> foo.toggle('bar baz').remove('bat');
> >>
> >> Same for the rest of the DOMTokenList methods, as well.
> >>
> >> foo.add('bar').remove('baz');
> >>
> >> See also https://github.com/jquery/standards/issues/13 for relevant
> >> discussion.
> >
> > This is not how existing DOM methods tend to behave, but in general I
> > support adding it in more places, because it's very useful for methods
> > that mutate the object they're called on.
>
> Agreed! "That's not how things used to be" is a terrible argument.
> Especially for something that had such bad (== java-esq) design as the
> DOM originally had and to a great extent still has.
>
I agree in general. Changing add/remove is definitely worth doing. In the
case of toggle, WebKit already returns a boolean. Returning the DOMTokenList
is clearly preferable IMO. It's a new enough API that maybe the web doesn't
yet depend on the return value of toggle?
Ojan
Re: [whatwg] DOMTokenList methods would be more useful with a space separated token list
On Fri, Oct 28, 2011 at 9:42 AM, Aryeh Gregor wrote:
> On Fri, Oct 28, 2011 at 12:07 PM, Mike Taylor
> wrote:
>> I would prefer if it returned the DOMTokenList, to enable chaining like:
>>
>> foo.toggle('bar baz').remove('bat');
>>
>> Same for the rest of the DOMTokenList methods, as well.
>>
>> foo.add('bar').remove('baz');
>>
>> See also https://github.com/jquery/standards/issues/13 for relevant
>> discussion.
>
> This is not how existing DOM methods tend to behave, but in general I
> support adding it in more places, because it's very useful for methods
> that mutate the object they're called on.
Agreed! "That's not how things used to be" is a terrible argument.
Especially for something that had such bad (== java-esq) design as the
DOM originally had and to a great extent still has.
/ Jonas
Re: [whatwg] DOMTokenList methods would be more useful with a space separated token list
On Fri, Oct 28, 2011 at 12:07 PM, Mike Taylor
wrote:
> I would prefer if it returned the DOMTokenList, to enable chaining like:
>
> foo.toggle('bar baz').remove('bat');
>
> Same for the rest of the DOMTokenList methods, as well.
>
> foo.add('bar').remove('baz');
>
> See also https://github.com/jquery/standards/issues/13 for relevant
> discussion.
This is not how existing DOM methods tend to behave, but in general I
support adding it in more places, because it's very useful for methods
that mutate the object they're called on.
Re: [whatwg] DOMTokenList methods would be more useful with a space separated token list
On Fri, Oct 28, 2011 at 11:52 AM, Philip Jägenstedt wrote:
> On Fri, 28 Oct 2011 12:58:01 +0200, David Håsäther
> wrote:
>
> It would be more useful if the DOMTokenList methods (contains, add,
>> remove, toggle) would take a space separated list of tokens. This is
>> the behavior most DOM libraries have when dealing with class names.
>>
>> So, when setting two classes, instead of
>>
>> ele.classList.add("hey");
>> ele.classList.add("ho");
>>
>> you could do
>>
>>ele.classList.add("hey ho");
>>
>> Currently, the latter results in an INVALID_CHARACTER_ERR.
>>
>> The behavior of all methods should be obvious I guess.
>>
>
> +1, but what should toggle return?
>
> toggle("a") returns true if "a" was added, which is equivalent to
> !contains("a") on the initial string or contains("a") on the final string.
> For toggle("a b"), !contains("a b") on the initial string may not be the
> same as contains("a b") on the final string, so which should it be? Put
> simpler, should it return true if any token is added or if all tokens are
> added?
I would prefer if it returned the DOMTokenList, to enable chaining like:
foo.toggle('bar baz').remove('bat');
Same for the rest of the DOMTokenList methods, as well.
foo.add('bar').remove('baz');
See also https://github.com/jquery/standards/issues/13 for relevant
discussion.
Re: [whatwg] DOMTokenList methods would be more useful with a space separated token list
On Fri, 28 Oct 2011 12:58:01 +0200, David Håsäther
wrote:
It would be more useful if the DOMTokenList methods (contains, add,
remove, toggle) would take a space separated list of tokens. This is
the behavior most DOM libraries have when dealing with class names.
So, when setting two classes, instead of
ele.classList.add("hey");
ele.classList.add("ho");
you could do
ele.classList.add("hey ho");
Currently, the latter results in an INVALID_CHARACTER_ERR.
The behavior of all methods should be obvious I guess.
+1, but what should toggle return?
toggle("a") returns true if "a" was added, which is equivalent to
!contains("a") on the initial string or contains("a") on the final string.
For toggle("a b"), !contains("a b") on the initial string may not be the
same as contains("a b") on the final string, so which should it be? Put
simpler, should it return true if any token is added or if all tokens are
added?
--
Philip Jägenstedt
Core Developer
Opera Software
[whatwg] DOMTokenList methods would be more useful with a space separated token list
It would be more useful if the DOMTokenList methods (contains, add,
remove, toggle) would take a space separated list of tokens. This is
the behavior most DOM libraries have when dealing with class names.
So, when setting two classes, instead of
ele.classList.add("hey");
ele.classList.add("ho");
you could do
ele.classList.add("hey ho");
Currently, the latter results in an INVALID_CHARACTER_ERR.
The behavior of all methods should be obvious I guess.
--
David Håsäther
