It should conceivably be possible to type-check slots in HTML templates (html` `). However, this would require an editor extension, or a plugin to TypeScript language services. I don't know what the most practical approach would be, or where to even get started. Needs investigation.
Normal attributes (no namespace) should be strings
Properties (prop:) assign to a property on the DOM object of the element, so it should use the interface of the element in question. For example, with <input type=checkbox prop:checked=${foo}>, foo should be boolean, because HTMLInputElement.checked is boolean.
Event listeneres (on:) add event listeners using HTMLElement::addEventListener(), so it should be type-checked accordingly. Example: <div on:click=${"hello!"}></div> should error, because the event handler should be a function, not a string.
Method calls (call:) call a method on the element in question. Ex: <form call:request-submit=${[]}></form> calls HTMLFormElement::requestSubmit(). It shouldn't allow it to be called incorrectly.
destiny: namespace specifies custom lib-specific behavior, that should be easy enough to type-check if the rest is implemented.
It should conceivably be possible to type-check slots in HTML templates (
html` `). However, this would require an editor extension, or a plugin to TypeScript language services. I don't know what the most practical approach would be, or where to even get started. Needs investigation.stringsprop:) assign to a property on the DOM object of the element, so it should use the interface of the element in question. For example, with<input type=checkbox prop:checked=${foo}>,fooshould beboolean, becauseHTMLInputElement.checkedisboolean.on:) add event listeners usingHTMLElement::addEventListener(), so it should be type-checked accordingly. Example:<div on:click=${"hello!"}></div>should error, because the event handler should be afunction, not astring.call:) call a method on the element in question. Ex:<form call:request-submit=${[]}></form>callsHTMLFormElement::requestSubmit(). It shouldn't allow it to be called incorrectly.destiny:namespace specifies custom lib-specific behavior, that should be easy enough to type-check if the rest is implemented.