@developit any thoughts? I can devote some time for a PR.

@developit @jviide

TBH it doesn't seem like these fit with the minimalistic philosophy of htm. They are all relatively easy to accomplish already using objects, and the resulting output (when not over-transpiled) represents a real improvement over what we'd have to do to support the sugared syntax in HTM's parser.

let _data = Symbol('data')
html`<a ...${{ [_data]: data }} />`
// output:
h('a', { [data]: data })

Regarding the last example, this might be interesting to you (demo):

function draggable(el) {}
draggable['data-draggable'] = true;

html`<a ...${draggable}/>`

it doesn't seem like these fit with the minimalistic philosophy of htm

#121 suggests distinguishing min / max philosophies, since that's already shipped.

Would it be nice to have htm-max with syntactic sugar/sauce (html-compatible, validation, unclosed tags, dynamic attributes), and keep htm-min JSX-compatible?

I'd like to point out that htm/mini is functionally identical to the regular htm.

htm/mini is functionally identical

What is this argued by? What are the pros having it identical? Or, rather, what's the point of htm/max then? A safe-ground implementation? (mb the discussion belongs to #121).

This distinction potential seems to be underdeveloped.

htm and htm/mini implement the same "language" and produce the same output for the same given input.

Their only real difference is that htm/mini doesn't do caching, which allows us save some implementation bytes. The brotli-compressed htm/mini is 170 bytes (~29%) smaller than htm. Whether this size reduction is worth the effort of maintaining two different builds is IMHO a different issue and best left for #121.

Currently the point of htm/mini is to be a drop-in replacement for htm, allowing the library user make a tradeoff between execution speed and code size, depending on their specific situation.