You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
html`<div.foo="bar"></div>`;
OK
html`<divfoo="bar"></div>`;
or…
html`<divfoo="${'bar'}"></div>`;
^^ But this last one is considered an anti-pattern and should not be used.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: