Rationale behind bool in attrs

[CheloXL]

Why you treat bool in attributes as strings, instead of simply switching on/off the attribute?

While of course you can do .attribute for certain things, that doesn´t solve the above issue and also doesn´t work in SVG (.hidden does nothing in SVG. You have to actually switch the attribute).

I know that changing that behavior now would be a breaking change, but could that be implemented in a major version release?

[WebReflection]

it's already implemented in both hyperHTML and lighterhtml, and it's ambiguous for the following reasons:

• sloppy code/lazy developers not passing along boolean values but null or undefined instead, or even empty strings, expected attributes to be removed or added same way (null is an explicit intent to remove listeners as DOM Level 0, as example, while false is not even allowd in there)
• what uhtml provides via the . prefix, is a 1:1 behavior of what you would do via JavaScript, if you had the node reference. .contentEditable=${true | false} is an example, and please note the camelCase, while .hidden is another one, and the mistake there is to believe SVG elements have an .hidden accessor, which is apparently not the case so ... let's take it also as an opportunity to better learn standards, shall we? :-)
• there are non boolean-only attributes, and I'm not planning to go maintenance hell for these. contenteditable itself is one of those, where it could have a third "inherit" state

but ... did I say lighterhtml already does these magic tricks for you behind the scene? that's the beauty of having choices: whatever you've done with uhtml will also work in lighterhtml, plus the extra magic you are looking for 👋

[CheloXL]

If you set the attribute hidden in svg, it becomes hidden (the attribute works very much like the html counterpart, that's it, you can set its value to whatever you want, and that hides the element). It doesn't work with property accessor (as you mentioned, there are no property hidden in svg nodes).

And yes, ?attribute sound fine to me, although what I expected was more in line with jtml. But using ? as an indicator that that would be an on/off version offers better readability.

[CheloXL]

If you implement the ?attribute, it would be nice (since you already know you will be dealing with a bool value) that you evaluate to falsy [""|null|undefined|0] (and even array.length and object.keys.length... but that's a surplus).

[WebReflection]

once ? is in (working on it) any truthy or falsy will work, as the check is against if (value) ... so I don't care screening value at all, and all falsy you mentioned, including NaN, would work as on/off: deal?

[CheloXL]

I'm loving it ❤️

[WebReflection]

it's up and running 👋

[WebReflection]

To whom it might concern, we just had an issue with hyperHTML and custom elements, because if an element has an accessor, but it hasn't been defined yet in the registry, hyperHTML, as well as lighterhtml, won't be able to recognize such accessor, hence once the element gets updated, reaching the accessor will instead add or remove an attribute.

This is the price you pay when too much magic is involved, so that the workaround to avoid surprises is to use specialized syntax in there too, because there's no way these declarative libraries can know upfront what an element is going to be, or how its properties will behave in the future.

This is a golden opportunity to bring in ?boolean=${value}, among .accessor=${value}, in these libraries too, because disambiguating in the template literal will never suffer these kind of issues, and will never fail developers expectations.

I hope this extra detail, about a bug we're trying to solve in the real world, convinces skeptical developers even more on "why magic behavior based on value, instead of intent, can be a footgun".