feat: add `<svelte:html>` element #14397

dummdidumm · 2024-11-21T19:08:59Z

closes #8663

Companion PR in SvelteKit: sveltejs/kit#13065

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.
If this PR changes code within packages/svelte/src, add a changeset (npx changeset).

Tests and linting

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

closes #8663

changeset-bot · 2024-11-21T19:09:03Z

🦋 Changeset detected

Latest commit: 8df29aa

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
svelte	Minor

Not sure what this means? Click here to learn what changesets are.

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

Rich-Harris · 2024-11-21T19:09:35Z

preview: https://svelte-dev-git-preview-svelte-14397-svelte.vercel.app/

this is an automated message

github-actions · 2024-11-21T19:10:20Z

Playground

pnpm add https://pkg.pr.new/svelte@14397

Leonidaz · 2024-11-21T20:11:08Z

Nice! works as expected.

one minor issue that I noticed in the playground, if you add an attribute and then erase it from the code, the attribute stays in the <html>, unless you set the attribute to undefined and then it's removed.

dummdidumm · 2024-11-21T20:13:46Z

that sounds like something we need to specifically handle in the playground/during hmr

packages/svelte/src/internal/server/blocks/svelte-html.js

Rich-Harris · 2024-11-26T20:19:20Z

packages/svelte/src/internal/server/blocks/svelte-html.js

+ */
+export function svelte_html(payload, attributes) {
+	for (const name in attributes) {
+		payload.htmlAttributes.set(name, escape_html(attributes[name], true));


what if the attribute already exists? do we error, or overwrite?

what if it's a class attribute? e.g. you have one component like this...

<svelte:html class="{theme === 'dark' ? 'dark' : undefined}" />

...and another like this?

<svelte:html class="{prefers_typescript ? 'prefers-ts' : 'prefers-js'}" />

Neither behaviour would be desirable in that case. Maybe class needs to be treated as a special case?

Currently it's "last one wins" for all attributes, similar to how the last <title> would win if you had multiple of them within <svelte:head> - which I think makes the most sense. Agree that class could use special handling though.

Should we at least warn if attributes are getting clobbered? Seems more likely to be a mistake than anything. (The same is probably true of <title>, and possibly other unique head tags, though we don't need to solve that right now)

Yeah we can warn at dev time

Rich-Harris · 2024-11-26T20:24:14Z

packages/svelte/src/internal/server/index.js

+		htmlAttributes: [...payload.htmlAttributes]
+			.map(([name, value]) => `${name}="${value}"`)
+			.join(' ')


Someone might have an existing classname in their HTML template, in which case giving them a string would make it awkward to combine stuff. Should we return an object instead of a string, so that they have more flexibility?

I briefly thought about that but it seemed unnecessary - in which case would you have existing attributes on a html tag but in such a way that you know which ones to then merge them in some way? Even if, the regex for adjusting the html attributes string would be straightforward. So I opted for making the simple case more ergonomic.

It is an interesting question for SvelteKit specifically though, which currently sets lang="en" in app.html by default. What would we do here? (regardless of whether we return a string or an object). The easiest would be to have lang="en" after the string and rely on browser being forgiving about it (they ignore duplicate attributes) / the user removing it in case they set it themselves in <svelte:html>

it only really matters for new projects, I think, since we can't retroactively add %htmlAttributes% anyway. I think we just replace lang="en" with %htmlAttributes% in the template project's app.html, and add this to the root layout:

<svelte:html lang="en" />

dummdidumm · 2024-11-27T10:53:49Z

What should happen when someone has <svelte:html foo="bar" /> in a component, and that component is destroyed? Does foo="bar" stay as the attribute on the HTML tag, or is it removed?

Companion to sveltejs/svelte#14397

Rich-Harris · 2024-11-28T00:44:16Z

I think it should be removed, and if there's another component with <svelte:html foo="baz" /> that was previously overridden, the attribute should change to that instead. Which admittedly could be awkward to implement

ollema · 2024-11-29T12:06:16Z

will it be possible to make this work with localStorage to prevent FOUC upon initial page load?

not sure how to describe the problem in the best way. but currently, if you want to configure the dark/light mode, you can achieve this with e.g. the mode-watcher package.

the mode-watcher inserts a stringified function into the head that sets the correct <html> class based on localStorage and/or prefers-color-scheme, basically something along these lines:

<svelte:head>
  {@html `<script>(` +
    setInitialMode.toString() +
    `)(` +
    args +
    `);</script>`}
</svelte:head>

where:

export function setInitialMode(defaultMode: Mode, themeColors?: ThemeColors) {
  const rootEl = document.documentElement;
  const mode = localStorage.getItem('mode-watcher-mode') || defaultMode;
  const light =
    mode === 'light' ||
    (mode === 'system' && window.matchMedia('(prefers-color-scheme: light)').matches);

  rootEl.classList[light ? 'remove' : 'add']('dark');
  rootEl.style.colorScheme = light ? 'light' : 'dark';

  localStorage.setItem('mode-watcher-mode', mode);
}

but this approach is a bit brittle and it would be great if it could be simplified!

it is also complicated if you want to use nonce, then you can not use the mode-watcher component out of the box

Rich-Harris · 2024-11-29T14:13:40Z

No, it would still be necessary to inject a <script> into the head. Which... now that I think about it does make me question how valuable this feature really is, especially when we consider all the additional complexity it entails (figuring out how to revert to a previous attribute value when one instance is removed, combining classes from different components, adding new stuff to the render return argument, etc).

Maybe the status quo is actually fine?

dummdidumm · 2024-11-29T17:43:50Z

I think it's still valuabe:

works without JS
no idea how browsers behave if you change the lang attribute midway through on the client
an API everyone knows, compared to coming up with script tag workarounds which may all look a bit different

The fact that there are tricky things to figure out isn't really an argument against it to me, if we don't answer these questions / figure them out then we're essentially saying "good luck user, you gotta figure it out" - we question of "how to handle duplicate attributes" isn't solved in user land (even harder there, probably).

Leonidaz · 2024-11-30T07:16:24Z

document.documentElement

I agree with @dummdidumm It would be very valuable.

will it be possible to make this work with localStorage to prevent FOUC upon initial page load?

not sure how to describe the problem in the best way. but currently, if you want to configure the dark/light mode, you can achieve this with e.g. the mode-watcher package.

the mode-watcher inserts a stringified function into the head that sets the correct <html> class based on localStorage and/or prefers-color-scheme, basically something along these lines:
<svelte:head>
  {@html `<script>(` +
    setInitialMode.toString() +
    `)(` +
    args +
    `);</script>`}
</svelte:head>
where:
export function setInitialMode(defaultMode: Mode, themeColors?: ThemeColors) {
  const rootEl = document.documentElement;
  const mode = localStorage.getItem('mode-watcher-mode') || defaultMode;
  const light =
    mode === 'light' ||
    (mode === 'system' && window.matchMedia('(prefers-color-scheme: light)').matches);

  rootEl.classList[light ? 'remove' : 'add']('dark');
  rootEl.style.colorScheme = light ? 'light' : 'dark';

  localStorage.setItem('mode-watcher-mode', mode);
}
but this approach is a bit brittle and it would be great if it could be simplified!

it is also complicated if you want to use nonce, then you can not use the mode-watcher component out of the box

I think it would be possible to avoid FOUC in this use case given that:

<svelte:html> works server-side
cookies are used to send preference (just using localStorage obviously won't work)
and / or, specifically for the light / dark mode, Sec-CH-Prefers-Color-Scheme header is supported by more than just chromium browsers, (Safari and FF). But, still having the chromium support is nice. https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Sec-CH-Prefers-Color-Scheme

At the very least, if cookies are used, the returning visitors can get the behavior without FOUC.

I created a playground with an emulated <svelte:html> via a component as a proof of concept. The main logic is in the SvelteHtml.svelte component and the rest is just for a visual demo. Just wanted to see how difficult it would be to support. Obviously, this is a contrived example outside of svelte's internal code, perhaps the logic might be useful.

The attributes are added in the order of component instantiation.
If a component is removed and it was overwriting its "predecessors" / parents' attributes, then the predecessor's attributes are restored.
Pre-existing attributes added outside of the emulated <svelte:html> remain unless any one of the components overwrites them. I don't think figuring out how to deal with restoring attributes outside of the <svelte:html> makes sense as it can result in various racing conditions.
setting an attribute to undefined or null, removes it from the html attributes, unless a component downstream provides some kind of value
setting attribute to an empty string, keeps the attribute, the browser just sets the attribute in this case.
class as a special case, attribute remains with the predecessor classes are restored on destroy; can be expanded to support style with a different string parser.

Playground: emulated <svelte:html>

- revert to previous value on unmount, if it was the last one changing the value - special handling for classes: merge them

dummdidumm · 2024-12-06T21:10:36Z

Updated the implementation to handle duplicates including always correctly reverting to the previous value upon removal, and handling classes as a special case.

feat: add <svelte:html> element

81bd131

closes #8663

dummdidumm commented Nov 21, 2024

View reviewed changes

packages/svelte/src/internal/server/blocks/svelte-html.js Outdated Show resolved Hide resolved

dummdidumm commented Nov 21, 2024

View reviewed changes

packages/svelte/src/internal/server/blocks/svelte-html.js Outdated Show resolved Hide resolved

Apply suggestions from code review

5ba013e

Rich-Harris reviewed Nov 26, 2024

View reviewed changes

Merge branch 'main' into svelte-html

d61291e

warn on duplicates

a88e814

dummdidumm added a commit to sveltejs/kit that referenced this pull request Nov 27, 2024

feat: support server-rendering attributes of <svelte:html> blocks

f16f4d1

Companion to sveltejs/svelte#14397

dummdidumm mentioned this pull request Nov 27, 2024

feat: support server-rendering attributes of <svelte:html> blocks sveltejs/kit#13065

Draft

5 tasks

dummdidumm added 6 commits December 6, 2024 11:34

Merge branch 'main' into svelte-html

0c1c8b9

robustify for multiple blocks:

8634231

- revert to previous value on unmount, if it was the last one changing the value - special handling for classes: merge them

fix test setup

0a95949

tweak implementation

8f8a5b1

test

6bf6c74

Merge branch 'main' into svelte-html

dd748e2

Merge branch 'main' into svelte-html

8df29aa

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

feat: add `<svelte:html>` element #14397

feat: add `<svelte:html>` element #14397

dummdidumm commented Nov 21, 2024 •

edited

Loading

changeset-bot bot commented Nov 21, 2024 •

edited

Loading

Rich-Harris commented Nov 21, 2024

github-actions bot commented Nov 21, 2024

Leonidaz commented Nov 21, 2024

dummdidumm commented Nov 21, 2024

Rich-Harris Nov 26, 2024

dummdidumm Nov 26, 2024

Rich-Harris Nov 26, 2024

dummdidumm Nov 26, 2024

Rich-Harris Nov 26, 2024

dummdidumm Nov 26, 2024 •

edited

Loading

Rich-Harris Nov 26, 2024

dummdidumm commented Nov 27, 2024

Rich-Harris commented Nov 28, 2024

ollema commented Nov 29, 2024 •

edited

Loading

Rich-Harris commented Nov 29, 2024

dummdidumm commented Nov 29, 2024

Leonidaz commented Nov 30, 2024 •

edited

Loading

dummdidumm commented Dec 6, 2024

feat: add <svelte:html> element #14397

Are you sure you want to change the base?

feat: add <svelte:html> element #14397

Conversation

dummdidumm commented Nov 21, 2024 • edited Loading

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

Tests and linting

changeset-bot bot commented Nov 21, 2024 • edited Loading

🦋 Changeset detected

Rich-Harris commented Nov 21, 2024

github-actions bot commented Nov 21, 2024

Leonidaz commented Nov 21, 2024

dummdidumm commented Nov 21, 2024

Rich-Harris Nov 26, 2024

Choose a reason for hiding this comment

dummdidumm Nov 26, 2024

Choose a reason for hiding this comment

Rich-Harris Nov 26, 2024

Choose a reason for hiding this comment

dummdidumm Nov 26, 2024

Choose a reason for hiding this comment

Rich-Harris Nov 26, 2024

Choose a reason for hiding this comment

dummdidumm Nov 26, 2024 • edited Loading

Choose a reason for hiding this comment

Rich-Harris Nov 26, 2024

Choose a reason for hiding this comment

dummdidumm commented Nov 27, 2024

Rich-Harris commented Nov 28, 2024

ollema commented Nov 29, 2024 • edited Loading

Rich-Harris commented Nov 29, 2024

dummdidumm commented Nov 29, 2024

Leonidaz commented Nov 30, 2024 • edited Loading

dummdidumm commented Dec 6, 2024

feat: add `<svelte:html>` element #14397

feat: add `<svelte:html>` element #14397

dummdidumm commented Nov 21, 2024 •

edited

Loading

changeset-bot bot commented Nov 21, 2024 •

edited

Loading

dummdidumm Nov 26, 2024 •

edited

Loading

ollema commented Nov 29, 2024 •

edited

Loading

Leonidaz commented Nov 30, 2024 •

edited

Loading