No normalization of add/remove/toggle in IE10 and IE11

[PatrickEickmeier]

I tested the polyfill in IE10 and IE11 (Win7 on a virtual machine) and the functions still have partial support of classList. Multiple parameters in the add() and remove() functions still don't work.

    if (!("classList" in document.createElement("_"))
        || document.createElementNS && !("classList" in document.createElementNS("http://www.w3.org/2000/svg", "g"))) {

The last condition !("classList" in document.createElementNS("http://www.w3.org/2000/svg", "g")) evaluates to true, so the part for no classlist support will be executed. The part for partial classlist supported browsers won't be executed in IE10/11.

I could "fix" the issue by changing || to && in line18/19:

    if (!("classList" in document.createElement("_"))
        && document.createElementNS && !("classList" in document.createElementNS("http://www.w3.org/2000/svg", "g"))) {

It seems to work for IE10/11, but don't know if is could be an issue for other browsers.

[Rendez]

+1 having the same issue here.

[dgraham]

This regression was introduced by https://github.com/eligrey/classList.js/commit/6379aea0dc04843b4c1505dfa4e80c06fdc93f45 in #40.

[Tokimon]

+1 on this. Having the same issue.

[stevenvachon]

@eligrey hello?

[tremby]

The suggested fix here breaks SVG support in IE11.

[vestride]

@tbranyen would you mind publishing and older version of this package on npm? Right now the only release on npm contains this bug. You could check out the 2014-12-13 tag and publish it as 1.1.20141213, which won't break semver. Here's an example in a stackoverflow answer you can follow to publish an older version.

[drgullin]

What about simplification? We may just use:

if (!("classList" in document.createElement("_"))) {

So the normalization would also work as expected.

[tremby]

Does that detect also whether support exists for SVG elements?

[stevenvachon]

@eligrey are you deceased?

[stevenvachon]

@PatAtMacadamian comments?

[stevenvachon]

For anyone needing this, I have a pull request in, but since that will probably never get merged, you can point to my branch in your projects: https://github.com/stevenvachon/classList.js

[drgullin]

@stevenvachon make it available at npm, please.

[stevenvachon]

@fronteed it already is:

"dependencies": {
  "classlist.js": "stevenvachon/classList.js"
}

[kmohrf]

apart from failing to normalize the api, the current toggle/force polyfill also doesn’t really conform to what everyone else is doing. while I’m not 100% sure that the spec defines this exact edge case (it comes down to the definition of what a passed value is and truthy-/falsyness), every browser seems to consider undefined as not passed, while the current implementation considers undefined false and therefor breaks compatibility.

[tremby]

In my opinion undefined should definitely be considered "not passed". null should probably be considered false, though I'm not so sure about that.

Probably best to do what the majority of native browser implementations do, if the spec isn't clear enough.

[kmohrf]

null is considered false in other implementations. I suppose the usual thruthy/falsy conversion applies except for undefined. The spec explicitly mentions true and false and in the chromium codebase toggle accepts a bool in the DOMTokenList interface. So I guess they have a standard behaviour concerning function call value transformations for these kind of APIs and undefined is simply dropped while other values are converted to bool.

[beck]

This should be fixed: https://github.com/eligrey/classList.js/pull/57

Published via: https://github.com/yola/classlist-polyfill