Meant to be valid HTML?

[matthewp]

The readme says:

Other frameworks, which use a template syntax built atop HTML — Svelte, Vue, Ractive, Glimmer etc — have historically been fragmented, meaning those tools need to be reinvented many times.

However many of these templating languages are not HTML. My question is, is this new template engine meant to be valid HTML or is it more correct to say that it is intended to be HTML-like?

[developit]

After doing some experimentation, I'm wondering what we mean when we say valid HTML. For example, take the following:

<button {...foo}>bar</button>

Is it valid? It seems to be. Is it a typical usage? definitely not.

[Rich-Harris]

I don't think it's an important goal for HTMLx to be valid HTML, as long as tooling like syntax highlighters and autocompleters can work with it. Having that additional constraint means that all sorts of perfectly reasonable things, like this...

<select>
  {#each options as x}
    <option>{x}</option>
  {/each}
</select>

...are impossible, and I haven't found any real benefit in exchange.

[matthewp]

@developit I mean passes HTML parsing. This enables putting the template into HTML via a <template> element. One example is Mustache templates that do <div {{#foo}}class="foo"{{/foo}}>". Browsers won't parse this correctly.

[matthewp]

@Rich-Harris The benefit is mostly being able to include the template in HTML. For SPAs this isn't as important, but progressively enhanced server-rendered apps it's helpful.

Personally I find using something like <template each="{options as x}"> ... to be just as good for the each/if use cases. It feels more right to me, the part inside of the each is a template.

But I'm not here to argue the syntax, just wanted clarification on the constraints of this project. Sounds as though HTML-like is the answer here.

[Rich-Harris]

Got it 👍 The assumption is that a server-rendered app is, well... rendered — in other words the raw component template would never hit the browser, it would either have been turned into real HTML or compiled to JavaScript or some intermediate representation (JSON, bytecode etc).

We (Svelte, when we were bikeshedding syntax for v2) toyed with the idea of using angle bracket tags for control flow, but decided against it — it just ended up looking like tag soup, with a structure that was much harder to discern at a glance. The other major downside was that you can't split a block into multiple 'clauses' — it's much harder to do this sort of thing, because :else doesn't have an analogous concept with tags:

{#if porridge.temperature > 100}
  <p>too hot!</p>
{:elseif 80 > porridge.temperature}
  <p>too cold!</p>
{:else}
  <p>just right!</p>
{/if}

Anyway, will close this issue since the original point has been clarified — thanks.