I kinda expected a little pushback on using "empty string" in toggleAttribute due to JS assuming it's value is falsy. There is lots of places in M-C code that assumes [attr=attr] and also [attr=true]. Also there is a lot of code that checks if (dom.hasAttribute("disabled")) { etc.
https://html.spec.whatwg.org/#boolean-attributes makes it clear that "true" and "false" is invalid however would there be concerns in setting the boolean to be the attribute name instead?
I think there was concerns about crossorigin and others because they are boolean but also have attributes.
I think the assumptions about attribute presence can remain the same as it currently is, but instead it would set the attribute name when the current state is !el.hasAttribute("attrname")
/cc @johannhof @bzbarsky @annevk
Part of me thinks this is a really bad idea given that:
<input type="checkbox" checked id="thing" />
document.getElementById("thing").getAttribute("checked") === ""
Right, using the value "" for boolean attributes to mean "true" is the normal thing in HTML. It used to be that they defaulted to their own name as the value in theory (but not in practice), which is why that's allowed by the spec. But I'm not sure we should be adding new APIs that do that.
Another relevant data point: when doing this:
<input type="checkbox" id="thing">
<script>
document.getElementById("thing").defaultChecked = true;
</script>
you land in https://html.spec.whatwg.org/#reflect for the boolean case, which says:
On setting, the content attribute must be removed if the IDL attribute is set to false, and must be set to the empty string if the IDL attribute is set to true.
and it seems to me like toggleAttribute should match the reflection behavior.
Yeah, I don't think we should do this. Check for null with getAttribute() or use hasAttribute(). If your code relies on empty string meaning not present it's already somewhat broken.
Cool, just wanted to double check. Other people will ask and now I have the answer :+1:
I'll close this :).
Most helpful comment
Yeah, I don't think we should do this. Check for
nullwithgetAttribute()or usehasAttribute(). If your code relies on empty string meaning not present it's already somewhat broken.