Open theengineear opened 6 days ago
IMO, we should not allow .foo="bar"
— this binding can be expressed within the html syntax. And, if it’s really needed (e.g., the custom element doesn’t do attribute syncing), you can use .foo="${'bar'}"
as a last resort.
🤔 — I actually think we should do what we’re currently doing… just totally ignore that. You can do this today:
document.body.innerHTML = `
<div .foo="bar">
I have an attribute named dot-foo with a value bar!
</div>
`;
I want to try very hard not to mess with default behavior… I wonder if that means we ought to actually not fail in the case of:
html`<div .foo="bar" .another="${whatever}"></div>`;
… not totally sure what the “best” choice here is!
OK, one more thought, then I’m done commenting here 😸
I think we actually want to purposefully ignore this. I.e., expect that folks might put a .
in front of attributes. The spec allows for it!
In other words — we can be fussy about the naming conventions that we accept for binding, but we should not be fussy about other bits of the html not used for binding. I.e., we should stay in our lane a bit more here, I think.
I think I’ve only ever seen a literal property binding by mistake, so I’m tempted to keep this strict. However, I wanted to farm for dissent a little bit. Currently…
NOT OK
OK
or…
^^ But this last one is considered an anti-pattern and should not be used.