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 i...@hixie.ch 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 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 Wed, May 2, 2012 at 6:13 PM, Ian Hickson i...@hixie.ch 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 Wed, 2 May 2012, Rick Waldron wrote:
On Wed, May 2, 2012 at 6:13 PM, Ian Hickson i...@hixie.ch 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, 02 May 2012 15:41:07 -0700, Ian Hickson i...@hixie.ch 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 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 i...@hixie.ch 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, 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 Wed, May 2, 2012 at 7:17 PM, Ian Hickson i...@hixie.ch 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 Fri, 28 Oct 2011 12:58:01 +0200, David Håsäther hasat...@gmail.com 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
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 phil...@opera.comwrote:
On Fri, 28 Oct 2011 12:58:01 +0200, David Håsäther hasat...@gmail.com
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, Oct 28, 2011 at 12:07 PM, Mike Taylor
michaelaarontay...@gmail.com 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 9:42 AM, Aryeh Gregor a...@aryeh.name wrote:
On Fri, Oct 28, 2011 at 12:07 PM, Mike Taylor
michaelaarontay...@gmail.com 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 1:23 PM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Oct 28, 2011 at 9:42 AM, Aryeh Gregor a...@aryeh.name wrote:
On Fri, Oct 28, 2011 at 12:07 PM, Mike Taylor
michaelaarontay...@gmail.com 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 1:55 PM, Ojan Vafai o...@chromium.org 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 2:03 PM, Glenn Maynard gl...@zewt.org wrote: On Fri, Oct 28, 2011 at 4:55 PM, Ojan Vafai o...@chromium.org 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 4:55 PM, Ojan Vafai o...@chromium.org 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 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
