fix: use valid HTML comment syntax

[harrisi]

Fixes #10976. While the shorter comment syntax saves a few bytes, it's not standard-compliant. This isn't generally that important, but it doesn't seem like a big enough gain to justify.

Before submitting the PR, please make sure you do the following

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• Prefix your PR title with feat:, fix:, chore:, or docs:.
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests and linting

• Run the tests with pnpm test and lint the project with pnpm lint

[changeset-bot]

⚠️ No Changeset found

Latest commit: c4b1d20

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[harrisi]

I'm not sure how useful it would be, but one improvement may be to collapse nested fragments. So, <!--[--><!--[--><p>foo</p><!--]--><!--]--> becomes <!--[[--><p>foo</p><!--]]-->, or possible <!--2[--><p>foo</p><!--2]-->, which would be an improvement where the nested depth is greater than 2. This is a contrived example (can it even happen?), and more likely it would be one side gets a big [[[[[ or ]]]]] (or 5[ or 5], respectively), and the rest are more spread out, of course, so it might not end up saving many bytes in actual codebases. If that's the case, it's probably not worth implementing.

It is something that can be done regardless of whether or not this PR is merged, though.

[harrisi]

Some discussion was happening about this on Discord, and here are a few reasons I thought of for why not to merge this:

• It doubles the payload for hydration, which was already pretty big, apparently.
• It's not very important if the document passes the validator for most people. If you need it to for whatever reason, you can do what this PR does easily enough. Maybe that's reason to add an option instead, which might not be a bad idea.
• It makes it more likely for people to accidentally break hydration in normal code. Most people won't write <!> or <![>, but they might write <!----> or <!--[-->. Probably not, but it is more likely.

[brianschwabauer]

The new comments also break svgs. I'm using svelte in a weird way where a svelte component is used to render svgs on the server. The output from the 'svelte/server' render function includes the <![> comments. Which make it so the browser won't render the svg.

[trueadm]

So there are two things here:

• Shorthand HTML that gets corrected in the component templates used in client rendering
• Rendering of SSR on the server

We don't need to change the first one, maybe only the second. We can likely make it work differently in SVG contexts too, but maybe that's too complicated. I put up a draft PR to revert the changes #10980.

[Rich-Harris]

I'm going to close this in favour of #10980, which changes the SSR output without using long comments in the template strings that are used in the browser to generate document fragments.

I'm not sure how useful it would be, but one improvement may be to collapse nested fragments

There are definitely opportunities for improvement that we plan to implement soon:

• replacing the <!--ssr:if:true--> and <!--ssr:each_else--> comments (which are used to enable hydration to gracefully recover in a case like {#if browser}..., rather than bailing on mismatched HTML) with a symbol in the closing hydration marker. something like <!--]^--> instead of <!--]-->

• skipping hydration markers when a block (a 'block' just being whatever it is that needs a hydration marker — if/each/await/component/whatever) is the only child of an element. e.g. here...

  <div><Foo /></div>

  we can do root = $.template(`<div />`) instead of root = $.template(`<div><!></div>`) in the client-side component, and the SSR output can be <div>...</div> instead of <div><!--[-->...<!--]--></div>

• being smarter about each blocks — we don't need to wrap each item in markers, we can just separate them. For a list of 100 items, we currently render 202 comments (2 for each item plus 2 for the block), when we really only need 101 (99 separators and 2 for the block)

Collapsing nested fragments is a possibility but it would require a lot of bookkeeping during SSR and again during hydration — it's probably too much complexity for what it would bring.