feat: support boolean attributes

[privatenumber]

#598

Supports:

• .attrSet('download') on Token
• .attrs.push(['download']) on Token
• .attrs.push(['download', null]) on Token
• .attrs.push(['download', undefined]) on Token

[puzrin]

It's not good idea to spread micro helpers as lib feature, when used in only one place. Such things clutter api significantly in long term.

[privatenumber]

Was trying to follow the existing organization.

Where do you want it?

[puzrin]

Until "helper" is not used wide, it should be in the same file where it's needed. Preferably - inlined, without separate fn at all.

[puzrin]

We need do discuss final data format in original issue. I don't like duality (null & undefined) for single case, especially when it's hidden behind api call.

[privatenumber]

@puzrin

I'm okay with just checking against undefined, but that would mean that doing .setAttrs('attr', null) -> attr="null" is expected behavior.

Let me know what you decide and I'll update.

[puzrin]

I'm okay with just checking against undefined, but that would mean that doing .setAttrs('attr', null) -> attr="null" is expected behavior.

Let me know what you decide and I'll update.

I understand. I left issue open to discuss signature proposals from other users. Did not thinked about it myself, because issue is not too hot and can be hacked at user side (without dependency on my personal opinion).

[septatrix]

I have no strong preference but would like to add that boolean attributes can also be set to their own name to signify a true value (e.g. <div hidden="hidden">Something hidden and HTML5 compliant</div>) which is what we just settled with for now.