This is shipping in browsers. E.g. try

<script>
document.body.classList.toggle("test", false); document.body.classList.toggle("x", true); 
</script>

in Live DOM Viewer or some such. Seems like a pain to change now.

OK, but is it used yet?

I guess someone would need to add telemetry / use counters to browsers. I can't answer that question.

I strongly disagree with this bug. "Toggling something to true" is a very common phrase in English. Even if it were not, jQuery's usage of it as such for many years has made it a common developer expectation. In fact, I remember specific developer complaints that classList's toggle did *not* have this functionality, back in the day: a kind of "why didn't they just copy jQuery; they still Just Don't Get It" diatribe.

No, it's definitely a bad, unintuitive API.  I would never expect x.toggle(true) to mean "set x to true".  It should have been "x.set(true/false)".  We shouldn't copy bad APIs from jQuery because we think people will scoff at us for doing things better.

However, I don't know if it's worth the effort it would take to find out if we can change this, and then to change it, with it already implemented in multiple browsers.  It's probably just another ugly API that we'll have to live with.

We could add set(value) and leave toggle(value) in, but then we pay the cost of redundant APIs, which is probably worse.

(In reply to Domenic Denicola from comment #4)
> I strongly disagree with this bug. "Toggling something to true" is a very
> common phrase in English.

To clarify, "toggle something to X" isn't what "toggle" actions mean; the word programmers use is "set" (or "assign", or occasionally "put" or "write", but never "toggle").  "Toggle" means a change based on the previous state.

I disagree that the word programmers use is "set." The word programmers use is often "toggle," especially in the case of classes, visibility, or animations.

This was not fixed. It might be WONTFIX, but that depends on research per comment 3.