Export "DomTokenList Element.get.classList"

[DartBot]

This issue was originally filed by localvoi...@gmail.com

---

Can we get access to DomTokenList Element.get.classList?

When working on a library that implements its own abstraction to manipulate DOM, I would prefer to use api that is close to native DOM api as possible. I understand why it was implemented this way long time ago when dart supported browsers that didn't have classList implementation, but now all dart supported browsers have classList implementation.

Simple benchmark using Dart Element.get.classes and Javascript Element.get.classList: http://localvoid.github.io/dart-classlist-benchmark/

DBMonster Benchmark implementations using uix library:

Element.get.classes: http://localvoid.github.io/uix_dbmon/
Element.get.classList (patched dart-sdk with exported classList): http://localvoid.github.io/uix_dbmon/classlist/

[rakudrama]

By coincidence I am looking into this at the moment.

Like you say, classList is widely supported.
First I am going to re-implement Element.classes using classList.
This should make a huge improvement as it will avoid creating a Set for each operation.

Then I am going to see if it is possible to get myElement.classes.add() to be compiled to myElement.classList.add().
If I succeed at this, do you think there is still a need for making classList available?

Are you using element.classes.add() or querySelectorAll(...).classes.add() ?
It is hard to tell from the minified code :-)

---

Set owner to @rakudrama.
Removed Priority-Unassigned label.
Added Priority-Medium, Area-Library, Library-Html, Triaged labels.

[rakudrama]

Added this to the 1.10 milestone.

[DartBot]

This comment was originally written by loca...@gmail.com

---

I am using something like this:

updateClasses(a, b, classes) {
  final changes = diff(a, b); // in real implementation, diff/patch is implemented in one step
  for (final c in changes) {
    if (c.isAdd) classes.add(c.value);
    else classes.remove(c.value);
  }
}

final a = ['a', 'b'];
final b = ['a', 'c'];
final classes = element.classes;

updateClasses(a, b, classes);

I am using it in virtual dom implementation, so I already have list of old classes and list of new classes, I just need to do a diff on unordered lists of strings and apply changes to the real class list. I am already trying to optimize it by using className instead of classList whenever it is possible, but I can't do this for "Composite Components".

If I succeed at this, do you think there is still a need for making classList available?

I would be happy with any solution that will generate efficient access to classList :)

[rakudrama]

There are performance improvements for Element.classes in the upcoming 1.10 release.

In doing the work I discovered that IE11 does not fully support classList so I am leaving this issue open until we can find a uniform solution.

Other browsers define classList for Element, but IE11 defines it for HTMLElement, so classList is not available for SVGElements, even though you can select them with document.querySelectorAll('.class'). (The same is true of className - the only universal way of setting classes (in JavaScript) is element.attributes['class'] = ...)
I reviewed several public polyfills for classList and none of them seem to fix the IE11 SVG problem.

---

Removed this from the 1.10 milestone.