ParseError on if-statement with open tag

[zedshaw]

This code causes a ParseError:

{#if true}
   <p>what was the question?</p>
{/if}

{#if true}
  <p>
{/if}

The first if-statement works, the second fails with:

[!] (svelte plugin) ParseError: Unexpected block closing tag
src/Videos.svelte
 7: {#if true}
 8:   <p>
 9: {/if}
      ^
ParseError: Unexpected block closing tag
    at error$1 (PATH/node_modules/svelte/src/compiler/utils/error.ts:25:16)
    at Parser$2.error (PATH/node_modules/svelte/src/compiler/parse/index.ts:93:3)
    at mustache (PATH/node_modules/svelte/src/compiler/parse/state/mustache.ts:59:11)
    at new Parser$2 (PATH/node_modules/svelte/src/compiler/parse/index.ts:45:12)
    at parse$2 (PATH/node_modules/svelte/src/compiler/parse/index.ts:208:17)
    at parse (PATH/node_modules/svelte/src/compiler/compile/index.ts:68:14)
    at preprocessPromise.then.code (PATH/node_modules/rollup-plugin-svelte/index.js:252:22)

This is essential for being able to conditionally add start/end tags that wrap groupings of other tags, and also appears to be a bug in the parser. Most likely the parser only looks for the / character to determine the end of a tag, or can't handle an open tag without an immediate closing html tag within the block. For example, with this bug you can't do:

{#each things as thing, i}
{if i % 3 === 0}<div class="row">{/if}
    <div class="column">
    Content
    </div>
{if i % 3 === 0}</div>{/if}
{/each}

You can test this theory by adding a </p> to the offending block so that it matches the first if-statement which passes.

Even if there's a way to work around this, the parse error is invalid since the if-statements are not part of the resulting HTML so shouldn't cause an error in parsing.

[Conduitry]

Duplicate of #2807.

[kylecordes]

@Conduitry I don't think this is a duplicate of that item. The first example uses the P tag (hinting at the self-closing categorization), but look at the second example.

This is a very interesting idea. A type of templating which is possible with old-fashioned server-side string based HTML generation, and which is not (from my very casual survey tinkering with many dozens of web frameworks) supported by common (or any?) client-side DOM-centric templating mechanisms.

Is this a good idea for Svelte to add? That I don't know.

[Conduitry]

Ah, I see, I didn't read the last example. Supporting that is not something we're interested in doing, though. Svelte needs to know about the structure of the component at compile time. When rendering in the browser, the compiled code is not just concatenating strings together to form the document, it's representing DOM elements in a tree.