Supporting `@...` for events
mcjazzyfunky opened this issue · comments
Kudos, Andrea, you really have some pretty cool projects running 👍
A little (slightly opinionated 😉) proposal (I do not know, whether this has already been discussed somewhere):
Now that uhml supports . and ? ...
<an-element an-attr="..." .aProp=${...} ?a-bool-attr=${...} onan-event=${...}/>... wouldn't it make sense to go the extra mile and also add support for @... for events (similar to lit-html) as alternative to on...?
on... should of course continue to be allowed (I personally would declare on... deprecated and get rid of it in the major version after the next major version, but anyway).
<an-element an-attr="..." .aProp=${...} ?a-bool-attr=${...} @an-event=${...}/>I guess that if the development of uhtml had been started in 2021 with all the current knowledge, there would not have been this ugly JSX-like on... convention (which makes sense in JSX but not in uhtml, or does it?)
Things would be at least a bit more compatible with lit-html .... and please compare the readabilty of
<sl-details summary="..." onsl-show=${...} onsl-hide=${...}>...</sl-details>to
<sl-details summary="..." @sl-show=${...} @sl-hide=${...}>...</sl-details>
<button onclick=...> is how we write HTML and it looks much better than @ ugly prefix to me ... what does that even mean?
I am not sure I like that, I'll think about enabling it if it doesn't affect performance, code size, and if it works in IE11 too without issues.
P.S. in uhtml-ssr if the function can be serialized as string it gets out in the layout ... which I like, because that's how HTML works ... so, I am actually more keen to keep things like this as it's more practical too, but surely I won't ever deprecate what is valid HTML from an HTML template based engine.
<button onclick=...>is how we write HTML and it looks much better than @ ugly prefix to me ... what does that even mean?
That's exactly the problem: In HTML/DOM <button onclick=...> primarily means: "Set the attribute onclick", it does not primarily mean "Register an event handler for event type click" (what DOM is doing under the hood is not that important here, I guess).
In lit-html
xyz=...means: "set an attribute".xyz=${...}means: "set a property"@xyz=${...}means: "register an event listener"
That means that the semantic of the following snippet is perfectly clear with lit-html:
<button onclick="alert(123)" @click=${() => alert(456)}>
Press me
</button>Also it is completly clear with lit-html what this is doing (this is working in lit-html but not in uhtml as uhtml is mixing the syntax for 'setAttribute' and 'addEventListener' semantics a bit):
<button onclick=${'alert(123)'}>
Press me
</button>Also, what are the semantics of this with lit-html or with uhtml (just a rhetorical question of course 😉)?
<my-element online></my-element>
<my-element online=""></my-element>
<my-element online=${someString}></my-element>
<my-element online=${''}></my-element>P.S. in uhtml-ssr if the function can be serialized as string it gets out in the layout ... which I like, because that's how HTML works ... so, I am actually more keen to keep things like this as it's more practical too, but surely I won't ever deprecate what is valid HTML from an HTML template based engine.
Frankly, I do not know what you mean by "if the function can be serialized" - which JavaScript functions can be serialized (using Function.prototype.toString is surely not really a solution)?
And what's important: I've never suggested that <button onclick="alert(123)">... should ever be deprecated in uhtml ... I'm just saying that (quote) "I personally" (but really no need to follow this opinion) would (in 12 month or whenever) change the semantic to:
onwhatever=... always means "set the attribute"
... ignoring that the attribute name starts with 'on' (no special heuristics any longer).
Means:
This would always work: <button onclick="alert(123)">...
This would not work in 2022 (or whenever) any longer: <button onclick=${callbackFunction}>...
I find this fine too, to be honest:
<button onclick="alert(123)" onclick=${() => alert(456)}>
Press me
</button>I do not know what you mean by "if the function can be serialized"
It's explained in that repository. A function with a toString that is not the native/inherited one can be used in uhtml-ssr and also in uhtml, it's about isomorphic between client/server.
People writing this syntax that comes from 2017 (hyperHTML) have found themselves very comfortable, including people working with Web standards (see Respec project).
This is very subjective, but I understand your argument and the extreme edge case like online attribute, although that's disambiguated via ?online=${...} or it can be used as accessor via .onlone=${...} so I don't see it as a real-world issue, and likely the only word that could have such issue (indeed first time in 3+ years I hear this complain).
As counter edge case example, if an event would like to be weirdly named I reason more with on@private than @@private, and oneventname=${value} is also semantic in terms of developer intent, at event name via @eventname feels weird.
Again, subjective, and I don't disagree with neither approaches, so I'll try to see what I can do.
It's in, it works on LinkeDOM without any issue, I haven't tested IE11 but I also don't care about IE11 there, in case it has troubles.
Hope this is fine, let's see how many will use this instead.