classList is not usable yet

[paulirish]

There are issues at the spec level and the browser level that make classList untenable for authoring in javascript and authors of libraries.

Specific issues

• The API makes it too arduous to work with as a replacement for className manipulation. The authoring experience is very awkward.
• Performance of the method calls isn't good enough for libraries to consider adoption.

Specific Suggestions

• Return value of classList methods should be a DOMTokenList instead of undefined. This allows chaining.

elem.classList.remove('oldnbusted').add('newhostness'); 

• Methods need to take multiple class arguments:

elem.classList.remove('classone classtwo')

• Performance in implementations need to improve. An effort was made in jQuery to add classList support but performance was inferior to className manip: http://jsperf.com/classlist-vs-addclass/2

• On perf, Resig concluded:

  So it seems like this doesn't provide any perf benefit over our current solution (which is unfortunate) - thus we'll probably want to hold off on landing this until we can get some appreciable gains.

• On perf, I asked a WebKit engineer and he said:

One of the problem with almost all the js solutions I've seen is that they are not complete. In other words they fail with some input data. If it turns out that a js solution that is complete is faster than the webkit one we should probably look at this again.

For completeness see Webkit's classList layoutTests

Notes

Spec on classList: http://www.w3.org/TR/html5/common-dom-interfaces.html#domtokenlist-0

+@miketaylr

[Raynos]

Here's a benchmark that shows calculating .classList is slightly slower then a cached version

Basically caching needs to become "safe" and optimised. From my own experiments with classList the caching should be safe.

I file bugs with mozilla and webkit

However the example shows that .classList is just as fast as jQuery.addClass so jQuery should use it

Another thing to add to the list of complains is that classList is an attribute and attributes should correspond to getter/setters on prototypes which doesn't hold true in IE9 and chrome.

[dmethvin]

In jQuery our .addClass and .removeClass frequently are adding and removing multiple space-separated classes at once, which doesn't lend itself well to using the native methods.

[Raynos]

@dmethvin I can't think of a good use-case for adding multiple classes in a batch however your right there is some performance different. It's not that big though. (Chrome 16 is faster, so we're getting there slowly)

I don't know whether we need classList to be more optimised or whether we just need to wait for the a couple more releases of chrome and firefox.

[dmethvin]

jQuery UI adds and removes a lot of classes to support Themeroller themes for example, I don't know if these longer strings (and the possibility that the class attributes are much longer) change the performance picture:

https://github.com/jquery/jquery-ui/blob/master/ui/jquery.ui.accordion.js#L34

Based on those benchmarks it seems the small performance increase on some browsers don't justify the second code path and larger size.

[Raynos]

they don't justify it yet. I'd just really like .classList to be performant enough so we can stop hacking around with .className. I mean .classList exists because manipulation .className is a pain.

But then again for jQuery it doesn't matter. For developers .classList is really helpful.

[leobalter]

Closing this as it seems to be solved. Please re-open if necessary.