Require `%sveltekit.body%` to not be a direct child of `<body>`? #7585

Rich-Harris · 2022-11-10T14:49:33Z

Rich-Harris
Nov 10, 2022
Maintainer

The default src/app.html looks like this:

<body>
  <div>%sveltekit.body%</div>
</body>

The reason for that is articulated in the docs:

%sveltekit.body% — the markup for a rendered page. Typically this lives inside a <div> or other element, rather than directly inside <body>, to prevent bugs caused by browser extensions injecting elements that are then destroyed by the hydration process

Understandably, a lot of people miss that, and assume that the wrapping <div> is unnecessary. Since it looks redundant and adds some minor inconvenience for styling (you need to add display: contents or otherwise make it possible for height: 100% elements in your components to work as expected), some people remove it altogether.

I ran into an example of the problems that this can cause the other day when working on #7507 — if the Vite error overlay exists on the page before hydration occurs, the overlay is destroyed, because it's (understandably) appended to the <body>. Much worse, this sort of thing can happen in production because of various browser extensions, and when that happens you'll be lucky to find out about it, much less in a manner that leads to a successful diagnosis.

The web is a hostile environment. User agents, rather than app developers, are ultimately responsible for how stuff gets rendered. A web framework should protect against this sort of thing from happening.

I therefore propose that we require %sveltekit.body% to be in a wrapper element, to guard against people inadvertently making their apps fragile. The problems caused by the wrapper element are easily worked around (if we added display: contents by default then probably no-one would even encounter them; pay no heed to the caveats on caniuse.com as they don't apply to this usage), and we'd have the opportunity to explain to people, via an error message, why the wrapper is required.

What do people think? Would this create problems that can't easily be worked around?

stephane-vanraes · 2022-11-10T14:51:53Z

stephane-vanraes
Nov 10, 2022

What if we make this a custom element (not sure about the name) ? like

<body>
   <svelte>%sveltekit.body%</svelte>
</body>

and somehow force the styling for this to be display: contents ? that way it doesn't look like a superfluous element

2 replies

SrGeneroso Nov 10, 2022

<header>
    <sveltekit-title/>
</header>

<body>
    <sveltekit-content/>
</body>

dummdidumm Nov 11, 2022
Collaborator

While this looks appealing at first, it leaves a false sense of flexibility. People could think they can write things inside that tag, which a) would be erased b) makes it harder to replaces this tag - right now it's very straightforward to replace %sveltekit.body% with whatever the content is.

dummdidumm · 2022-11-10T14:52:11Z

dummdidumm
Nov 10, 2022
Collaborator

I'm for adding a comment above the div linking to that sentence.

<!-- do not remove this div element unless you are abolutely sure you don't need it. Read here why it matters: ... -->
<div>
...

All people getting that app will from now on see that comment and think twice before removing it.

Additionally, if we really want to, we could make this a warning at build time. I'm against throwing an error.

2 replies

Rich-Harris Nov 10, 2022
Maintainer Author

Since src/app.html is treated 'literally', that comment would appear in production apps, unnecessarily increasing the size of every HTML payload

leoj3n Feb 29, 2024

But isn't app.html processed to inject the %sveltekit.body% and head macros? Seems like a comment could be string replaced during that same step. The comment could even indicate that it should and will be stripped from the served HTML so as not to add bloat to every request. I'm not saying a verbose comment in app.html is the best solution but your argument against it doesn't seem like it would be an issue... Unless my assumption that it could be stripped out is a wrong assumption...

export const options = {
	templates: {
		app: ({ head, body, assets, nonce, env }) => "<!doctype html>\n<html lang=\"en\">\n\t<head>\n\t\t<meta charset=\"utf-8\" />\n\t\t<link rel=\"icon\" href=\"" + assets + "/favicon.png\" />\n\t\t<meta name=\"viewport\" content=\"width=device-width, initial-scale=1\" />\n\t\t" + head + "\n\t</head>\n\t<body data-sveltekit-preload-data=\"hover\">\n\t\t<div style=\"display: contents\">" + body + "</div>\n\t</body>\n</html>\n",
	},
};

david-plugge · 2022-11-10T21:33:46Z

david-plugge
Nov 10, 2022

Isn't it possible to wrap the generated HTML in a div with display: contents; internally? Any downsides to this?

1 reply

Rich-Harris Nov 11, 2022
Maintainer Author

It's better to leave it in the user's control — a selector like body > main wouldn't work if there was a <div> in between, for example. When frameworks silently insert extra elements it always creates problems

cooolbros · 2022-11-14T11:34:33Z

cooolbros
Nov 14, 2022

I've ran into trouble with the containing <div> while making Sveltekit apps where the body shouldn't overflow 100% to get an app-like feel. Every time, I've just removed this <div> as it is the easiest option.

I would prefer that the <div> was still allowed to be removed, as to provide more power to the developer and avoid confusion, but can understand if it has to stay for Vite to work and to accommodate browser extensions.

Another thing to consider: There may also be other times where the <div> is unnecessary, such as running Sveltekit in Electron/Tauri, where there should not be any external browser extensions

I think a warning would be a good compromise, but am mainly commenting to just to share my opinion.

0 replies

rbenzazon · 2023-02-03T13:28:49Z

rbenzazon
Feb 3, 2023

I would prefer to see the framework find a way to use the body directly. I'm kind of allergic to unjustified element depth, ok in the case of svelte alone but since sveltekit is in charge of rendering the whole page, the body must be directly accessible. I do understand that this issue is tricky to handle but I would rather have my content placed in the body and not support any client owned overlay than having the page content reside in the div. maybe the warning/rule could be disabled from configuration. this could be seen as a feature and not a bug.

0 replies

chazzmoney · 2023-06-09T22:57:35Z

chazzmoney
Jun 9, 2023

I maybe have a different use case. I have my pages split into two sections: (site) and (app). Each has a different layout - but I want it to function like that main app.html at the root. Literally, I want no body tag in app.html, because I want to put the body tags in (site)/+layout.svelte and (app)/+layout.svelte

Unfortunately, this isn't how svelte kit expects to be used, so....

0 replies

jerrygreen · 2024-02-26T03:18:36Z

jerrygreen
Feb 26, 2024

Is there a way to silence this warning? Placing %sveltekit.body% directly inside <body>... I don't care about extensions and so on, because the app is meant to be used internally. I don't like to have unnecessary wrappers. In my case, they're indeed unnecessary.

The web is a hostile environment

The web is also a messed-up environment with thousands of unnecessary wrappers. (I don't argue whether they're necessary in common cases, but definitely they're not for every single use-case)

P.S. btw no offense, svelte is still IMO the best among this messed-up environment

0 replies

leoj3n · 2024-02-29T03:11:14Z

leoj3n
Feb 29, 2024

I saw display: contents on the app start generated from CLI and assumed it had a purpose and left it alone. However, I did not know the purpose until now.

2 replies

jerrygreen Feb 29, 2024

This is one weird way to silence the warning lol.

P.S. I hope there will be a sane option.

leoj3n Feb 29, 2024

If you scroll up you will see why this div was added (to thwart browser extensions messing with the DOM that SvelteKit expects to own and be able to walk).

dominicfarr · 2024-05-21T17:22:21Z

dominicfarr
May 21, 2024

For what it is worth:

I'm getting this warning when I'm using app.html as suggested.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <link rel="icon" href="%sveltekit.assets%/favicon.png" />
    <meta name="viewport" content="width=device-width" />
    %sveltekit.head%
  </head>
  <body data-sveltekit-preload-data="hover">
    <div style="display: contents">%sveltekit.body%</div>
  </body>
</html>

The chrome[brave] DevTools console error

2c567e74-2845-409a-bcbe-da4128e37bce:1095 Placing %sveltekit.body% directly inside <body> is not recommended, as your app may break for users who have certain browser extensions installed.

Consider wrapping it in an element:

<div style="display: contents">
  %sveltekit.body%
</div>

I'm running this locally with vercel dev cmd.

0 replies

Rezi · 2024-07-08T10:03:24Z

Rezi
Jul 8, 2024

Couldn't the issue be fixed by prefixing and suffixing comment, instead of wrapping div? That would enable svelte to only replace its own code without erasing 3rd party code from body while keeping support for selectors like body > header, body footer etc.
I have when frameworks are breaking semantics :)

1 reply

rbenzazon Jul 8, 2024

there are many ways sveltekit can keep track of what it adds, comments don't seem to be right, they do offer advantages. Maybe data- attributes? it's often used to keep track on things right form the dom without keeping refs. Of course attributes won't work for text nodes, maybe text nodes are the most tricky. I wonder if we really need a solution, if you need things in the body outside what's rendered by sveltekit, use the div, if not, then use the whole body. as long as there's an option to remove the warning that's cool.

lorypelli · 2024-07-09T11:51:45Z

lorypelli
Jul 9, 2024

I don't understand while display needs to be contents, can't we just use div element without that style applied?

1 reply

Codezarre Aug 11, 2024

#7585 (comment)

Rezi · 2024-07-09T12:22:47Z

Rezi
Jul 9, 2024

It helps CSS with partially ignoring the DIV. Imagine you apply display:flex; flex-direction:column; on body. Normally the Div would be the aligned element in the flex container. But by setting its display to contents it is ignored and its children are the ones to be aligned in column flex layout. The div just make less harm as for styling. Unfortunately it won't help with selectors like body > header they still won't select anything

0 replies

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Require `%sveltekit.body%` to not be a direct child of `<body>`? #7585

{{title}}

Replies: 12 comments 9 replies

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

{{title}}

Select a reply

Require %sveltekit.body% to not be a direct child of <body>? #7585

Rich-Harris Nov 10, 2022 Maintainer

Replies: 12 comments · 9 replies

dummdidumm Nov 11, 2022 Collaborator

dummdidumm Nov 10, 2022 Collaborator

Rich-Harris Nov 10, 2022 Maintainer Author

Rich-Harris Nov 11, 2022 Maintainer Author

Require `%sveltekit.body%` to not be a direct child of `<body>`? #7585

Rich-Harris
Nov 10, 2022
Maintainer

Replies: 12 comments 9 replies

dummdidumm Nov 11, 2022
Collaborator

dummdidumm
Nov 10, 2022
Collaborator

Rich-Harris Nov 10, 2022
Maintainer Author

Rich-Harris Nov 11, 2022
Maintainer Author