Reject JS-y escapes in html strings.

[theengineear]

Any \-escaping is a JS-y thing — not an HTML-y thing per-se. For example, \n, \b, \t, etc. have no real meaning within html content (they’re just literal characters). Rather than allow a confusing mix of JS-isms and HTML-isms — we could just throw when we encounter such escapes.

const foo = 'this is okay\u2026'; // This is normal JS
const moo = 'this will not fail, but is not what you want…'; // This is HTML-in-JS.
const mar = 'sure, you do you…'; // Also JS-y
const bar = html`this is not okay\u2026`; // This is JS-in-HTML
const pip = html`more\nbad\nthings`; // Newline escapes are also JS-in-HTML
const yuk = html`\w\h\y\?`; // Not that you would do this, but this would be silly.
const baz = html`this is okay…`; // This is HTML-y
const zip = html`also okay…`; // This is HTML-y
const zap = html`also okay, for completeness…`; // Also HTML-y
const yap = html`also okay, you do you…` // Also HTML-y

Technically, this simply involves looking at the strings.raw array (a special, raw version of the strings array passed to a tagged template function). If you see any unescaped \ patterns (other than for a literal backtick or backslash), we reject that input.

[Osintedx]

I agree with the idea of separating JS and HTML escapes for clarity. It’ll help avoid confusion and bugs.

A couple of things to consider:

Error Messages: It might be helpful to add clear error messages when throwing errors, so developers know exactly how to fix the issue (e.g., replace \u2026 with …).

Linting/Pre-commit: We could also add a linting rule or pre-commit hook to catch these errors earlier.

Edge Cases: Are there any situations where this might accidentally flag valid escapes? It could be useful to document these cases.

[klebba]

Hi @Osintedx — thanks for your interest — can you share more about how you are using x-element in your projects?

[Osintedx]

Hi @Osintedx — thanks for your interest — can you share more about how you are using x-element in your projects?

I’m using x-element to build lightweight, reusable custom elements for my projects. It’s great for:

Efficient Templating: Handling DOM updates and data binding.
Syncing Attributes & Properties: Keeping data consistent in interactive components.
Event Delegation: Managing events cleanly in complex UIs.
Reactive Systems: Observing and computing properties easily.

[klebba]

@Osintedx what is your purpose?