Revert "separate code spans"

This reverts commit 7ce30c0.

Author: Rich-Harris

apps/svelte.dev/content/docs/kit/20-core-concepts/10-routing.md

@@ -14,9 +14,9 @@ Each route directory contains one or more _route files_, which can be identified
 
 We'll introduce these files in a moment in more detail, but here are a few simple rules to help you remember how SvelteKit's routing works:
 
-- All files can run on the server
-- All files run on the client except `+server` files
-- `+layout` and `+error` files apply to subdirectories as well as the directory they live in
+* All files can run on the server
+* All files run on the client except `+server` files
+* `+layout` and `+error` files apply to subdirectories as well as the directory they live in
 
 ## +page
 
@@ -291,7 +291,7 @@ If an error is thrown (either `error(...)` or an unexpected error), the response
 
 ### Receiving data
 
-By exporting `POST` / `PUT` / `PATCH` / `DELETE` / `OPTIONS` / `HEAD` handlers, `+server.js` files can be used to create a complete API:
+By exporting `POST`/`PUT`/`PATCH`/`DELETE`/`OPTIONS`/`HEAD` handlers, `+server.js` files can be used to create a complete API:
 
 ```svelte
 <!--- file: src/routes/add/+page.svelte --->
@@ -362,8 +362,8 @@ export async function fallback({ request }) {
 
 `+server.js` files can be placed in the same directory as `+page` files, allowing the same route to be either a page or an API endpoint. To determine which, SvelteKit applies the following rules:
 
-- `PUT` / `PATCH` / `DELETE` / `OPTIONS` requests are always handled by `+server.js` since they do not apply to pages
-- `GET` / `POST` / `HEAD` requests are treated as page requests if the `accept` header prioritises `text/html` (in other words, it's a browser page request), else they are handled by `+server.js`.
+- `PUT`/`PATCH`/`DELETE`/`OPTIONS` requests are always handled by `+server.js` since they do not apply to pages
+- `GET`/`POST`/`HEAD` requests are treated as page requests if the `accept` header prioritises `text/html` (in other words, it's a browser page request), else they are handled by `+server.js`.
 - Responses to `GET` requests will include a `Vary: Accept` header, so that proxies and browsers cache HTML and JSON responses separately.
 
 ## $types

apps/svelte.dev/content/docs/kit/20-core-concepts/30-form-actions.md

@@ -509,7 +509,7 @@ Some forms don't need to `POST` data to the server — search inputs, for exampl
 <form action="/search">
 	<label>
 		Search
-		<input name="q" />
+		<input name="q">
 	</label>
 </form>
 ```

apps/svelte.dev/content/docs/kit/20-core-concepts/40-page-options.md

@@ -80,9 +80,9 @@ If you encounter an error like 'The following routes were marked as prerenderabl
 
 Since these routes cannot be dynamically server-rendered, this will cause errors when people try to access the route in question. There are a few ways to fix it:
 
-- Ensure that SvelteKit can find the route by following links from [`config.kit.prerender.entries`](configuration#prerender) or the [`entries`](#entries) page option. Add links to dynamic routes (i.e. pages with `[parameters]` ) to this option if they are not found through crawling the other entry points, else they are not prerendered because SvelteKit doesn't know what value the parameters should have. Pages not marked as prerenderable will be ignored and their links to other pages will not be crawled, even if some of them would be prerenderable.
-- Ensure that SvelteKit can find the route by discovering a link to it from one of your other prerendered pages that have server-side rendering enabled.
-- Change `export const prerender = true` to `export const prerender = 'auto'`. Routes with `'auto'` can be dynamically server rendered
+* Ensure that SvelteKit can find the route by following links from [`config.kit.prerender.entries`](configuration#prerender) or the [`entries`](#entries) page option. Add links to dynamic routes (i.e. pages with `[parameters]` ) to this option if they are not found through crawling the other entry points, else they are not prerendered because SvelteKit doesn't know what value the parameters should have. Pages not marked as prerenderable will be ignored and their links to other pages will not be crawled, even if some of them would be prerenderable.
+* Ensure that SvelteKit can find the route by discovering a link to it from one of your other prerendered pages that have server-side rendering enabled.
+* Change `export const prerender = true` to `export const prerender = 'auto'`. Routes with `'auto'` can be dynamically server rendered
 
 ## entries
 
@@ -104,7 +104,10 @@ This can be done with [`config.kit.prerender.entries`](configuration#prerender),
 /// file: src/routes/blog/[slug]/+page.server.js
 /** @type {import('./$types').EntryGenerator} */
 export function entries() {
-	return [{ slug: 'hello-world' }, { slug: 'another-blog-post' }];
+	return [
+		{ slug: 'hello-world' },
+		{ slug: 'another-blog-post' }
+	];
 }
 
 export const prerender = true;
@@ -136,11 +139,11 @@ export const csr = false;
 
 Disabling CSR does not ship any JavaScript to the client. This means:
 
-- The webpage should work with HTML and CSS only.
-- `<script>` tags inside all Svelte components are removed.
-- `<form>` elements cannot be [progressively enhanced](form-actions#Progressive-enhancement).
-- Links are handled by the browser with a full-page navigation.
-- Hot Module Replacement (HMR) will be disabled.
+* The webpage should work with HTML and CSS only.
+* `<script>` tags inside all Svelte components are removed.
+* `<form>` elements cannot be [progressively enhanced](form-actions#Progressive-enhancement).
+* Links are handled by the browser with a full-page navigation.
+* Hot Module Replacement (HMR) will be disabled.
 
 You can enable `csr` during development (for example to take advantage of HMR) like so:
 
@@ -197,7 +200,7 @@ export const config = {
 	foo: {
 		bar: true
 	}
-};
+}
 ```
 
 ...is overridden by this page configuration...
@@ -209,7 +212,7 @@ export const config = {
 	foo: {
 		baz: true
 	}
-};
+}
 ```
 
 ...which results in the config value `{ runtime: 'edge', regions: ['us1', 'us2'], foo: { baz: true } }` for that page.

apps/svelte.dev/content/docs/kit/30-advanced/40-service-workers.md

@@ -32,7 +32,7 @@ const CACHE = `cache-${version}`;
 
 const ASSETS = [
 	...build, // the app itself
-	...files // everything in `static`
+	...files  // everything in `static`
 ];
 
 self.addEventListener('install', (event) => {
@@ -64,7 +64,7 @@ self.addEventListener('fetch', (event) => {
 		const url = new URL(event.request.url);
 		const cache = await caches.open(CACHE);
 
-		// `build` / `files` can always be served from the cache
+		// `build`/`files` can always be served from the cache
 		if (ASSETS.includes(url.pathname)) {
 			const response = await cache.match(url.pathname);
 
@@ -134,7 +134,6 @@ Setting up proper types for service workers requires some manual setup. Inside y
 
 const sw = /** @type {ServiceWorkerGlobalScope} */ (/** @type {unknown} */ (self));
 ```
-
 ```generated-ts
 /// <reference types="@sveltejs/kit" />
 /// <reference no-default-lib="true"/>

apps/svelte.dev/content/docs/kit/30-advanced/70-packaging.md

@@ -146,7 +146,10 @@ If your package has files with side effects, you can specify them in an array:
 ```json
 /// file: package.json
 {
-	"sideEffects": ["**/*.css", "./dist/sideEffectfulFile.js"]
+    "sideEffects": [
+    	"**/*.css",
+    	"./dist/sideEffectfulFile.js"
+    ]
 }
 ```
 
@@ -219,10 +222,10 @@ You should think carefully about whether or not the changes you make to your pac
 
 `svelte-package` accepts the following options:
 
-- `-w` / `--watch` — watch files in `src/lib` for changes and rebuild the package
-- `-i` / `--input` — the input directory which contains all the files of the package. Defaults to `src/lib`
-- `-o` / `--output` — the output directory where the processed files are written to. Your `package.json`'s `exports` should point to files inside there, and the `files` array should include that folder. Defaults to `dist`
-- `-t` / `--types` — whether or not to create type definitions (`d.ts` files). We strongly recommend doing this as it fosters ecosystem library quality. Defaults to `true`
+- `-w`/`--watch` — watch files in `src/lib` for changes and rebuild the package
+- `-i`/`--input` — the input directory which contains all the files of the package. Defaults to `src/lib`
+- `-o`/`--output` — the output directory where the processed files are written to. Your `package.json`'s `exports` should point to files inside there, and the `files` array should include that folder. Defaults to `dist`
+- `-t`/`--types` — whether or not to create type definitions (`d.ts` files). We strongly recommend doing this as it fosters ecosystem library quality. Defaults to `true`
 - `--tsconfig` - the path to a tsconfig or jsconfig. When not provided, searches for the next upper tsconfig/jsconfig in the workspace path.
 
 ## Publishing

apps/svelte.dev/content/docs/kit/40-best-practices/20-seo.md

@@ -75,7 +75,7 @@ const config = {
 export default config;
 ```
 
-...disabling `csr` in your root `+layout.js` / `+layout.server.js`...
+...disabling `csr` in your root `+layout.js`/`+layout.server.js`...
 
 ```js
 /// file: src/routes/+layout.server.js
@@ -86,8 +86,7 @@ export const csr = false;
 
 ```html
 <html amp>
-	...
-</html>
+...
 ```
 
 ...and transforming the HTML using `transformPageChunk` along with `transform` imported from `@sveltejs/amp`:

apps/svelte.dev/content/docs/kit/60-appendix/10-faq.md

@@ -142,7 +142,6 @@ onMount(() => {
 ```
 
 Finally, you may also consider using an `{#await}` block:
-
 ```svelte
 <!--- file: index.svelte --->
 <script>
@@ -178,7 +177,7 @@ export function GET({ params, url }) {
 }
 ```
 
-(Note that you may also need to proxy `POST` / `PATCH` etc requests, and forward `request.headers`, depending on your needs.)
+(Note that you may also need to proxy `POST`/`PATCH` etc requests, and forward `request.headers`, depending on your needs.)
 
 ### How do I use middleware?
 

apps/svelte.dev/content/docs/kit/98-reference/50-configuration.md

@@ -124,6 +124,8 @@ Any additional options required by tooling that integrates with Svelte.
 </div>
 </div></div>
 
+
+
 ## KitConfig
 
 The `kit` property configures SvelteKit, and can have the following properties:
@@ -140,6 +142,8 @@ Your [adapter](https://kit.svelte.dev/docs/adapters) is run when executing `vite
 
 <div class="ts-block-property-children">
 
+
+
 </div>
 
 ## alias
@@ -180,6 +184,8 @@ const config = {
 
 <div class="ts-block-property-children">
 
+
+
 </div>
 
 ## appDir
@@ -196,12 +202,16 @@ If `paths.assets` is specified, there will be two app directories — `${paths.a
 
 <div class="ts-block-property-children">
 
+
+
 </div>
 
 ## csp
 
 <div class="ts-block-property-bullets">
 
+
+
 </div>
 
 [Content Security Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy) configuration. CSP helps to protect your users against cross-site scripting (XSS) attacks, by limiting the places resources can be loaded from. For example, a configuration like this...
@@ -288,6 +298,8 @@ Directives that will be added to `Content-Security-Policy-Report-Only` headers.
 
 <div class="ts-block-property-bullets">
 
+
+
 </div>
 
 Protection against [cross-site request forgery (CSRF)](https://owasp.org/www-community/attacks/csrf) attacks.
@@ -331,12 +343,16 @@ Note that it is generally not supported to embed multiple SvelteKit apps on the
 
 <div class="ts-block-property-children">
 
+
+
 </div>
 
 ## env
 
 <div class="ts-block-property-bullets">
 
+
+
 </div>
 
 Environment variable configuration
@@ -408,6 +424,8 @@ A prefix that signals that an environment variable is unsafe to expose to client
 
 <div class="ts-block-property-bullets">
 
+
+
 </div>
 
 Where to find various files within your project.
@@ -634,6 +652,8 @@ Inline CSS inside a `<style>` block at the head of the HTML. This option is a nu
 
 <div class="ts-block-property-children">
 
+
+
 </div>
 
 ## moduleExtensions
@@ -648,6 +668,8 @@ An array of file extensions that SvelteKit will treat as modules. Files with ext
 
 <div class="ts-block-property-children">
 
+
+
 </div>
 
 ## outDir
@@ -662,12 +684,16 @@ The directory that SvelteKit writes files to during `dev` and `build`. You shoul
 
 <div class="ts-block-property-children">
 
+
+
 </div>
 
 ## output
 
 <div class="ts-block-property-bullets">
 
+
+
 </div>
 
 Options related to the build output format
@@ -692,7 +718,6 @@ preloadStrategy?: 'modulepreload' | 'preload-js' | 'preload-mjs';
 
 SvelteKit will preload the JavaScript modules needed for the initial page to avoid import 'waterfalls', resulting in faster application startup. There
 are three strategies with different trade-offs:
-
 - `modulepreload` - uses `<link rel="modulepreload">`. This delivers the best results in Chromium-based browsers, in Firefox 115+, and Safari 17+. It is ignored in older browsers.
 - `preload-js` - uses `<link rel="preload">`. Prevents waterfalls in Chromium and Safari, but Chromium will parse each module twice (once as a script, once as a module). Causes modules to be requested twice in Firefox. This is a good setting if you want to maximise performance for users on iOS devices at the cost of a very slight degradation for Chromium users.
 - `preload-mjs` - uses `<link rel="preload">` but with the `.mjs` extension which prevents double-parsing in Chromium. Some static webservers will fail to serve .mjs files with a `Content-Type: application/javascript` header, which will cause your application to break. If that doesn't apply to you, this is the option that will deliver the best performance for the largest number of users, until `modulepreload` is more widely supported.
@@ -706,8 +731,12 @@ are three strategies with different trade-offs:
 
 <div class="ts-block-property-bullets">
 
+
+
 </div>
 
+
+
 <div class="ts-block-property-children">
 
 <div class="ts-block-property">
@@ -784,6 +813,8 @@ In 1.0, `undefined` was a valid value, which was set by default. In that case, i
 
 <div class="ts-block-property-bullets">
 
+
+
 </div>
 
 See [Prerendering](https://kit.svelte.dev/docs/page-options#prerender).
@@ -843,7 +874,7 @@ entries?: Array<'*' | `/${string}`>;
 
 </div>
 
-An array of pages to prerender, or start crawling from (if `crawl: true`). The `*` string includes all routes containing no required `[parameters]` with optional parameters included as being empty (since SvelteKit doesn't know what value any parameters should have).
+An array of pages to prerender, or start crawling from (if `crawl: true`). The `*` string includes all routes containing no required `[parameters]`  with optional parameters included as being empty (since SvelteKit doesn't know what value any parameters should have).
 
 </div>
 </div>
@@ -969,8 +1000,12 @@ The value of `url.origin` during prerendering; useful if it is included in rende
 
 <div class="ts-block-property-bullets">
 
+
+
 </div>
 
+
+
 <div class="ts-block-property-children">
 
 <div class="ts-block-property">
@@ -1018,8 +1053,12 @@ Determine which files in your `static` directory will be available in `$service-
 
 <div class="ts-block-property-bullets">
 
+
+
 </div>
 
+
+
 <div class="ts-block-property-children">
 
 <div class="ts-block-property">
@@ -1050,13 +1089,14 @@ This is useful for extending a shared `tsconfig.json` in a monorepo root, for ex
 
 <div class="ts-block-property-bullets">
 
+
+
 </div>
 
 Client-side navigation can be buggy if you deploy a new version of your app while people are using it. If the code for the new page is already loaded, it may have stale content; if it isn't, the app's route manifest may point to a JavaScript file that no longer exists.
 SvelteKit helps you solve this problem through version management.
 If SvelteKit encounters an error while loading the page and detects that a new version has been deployed (using the `name` specified here, which defaults to a timestamp of the build) it will fall back to traditional full-page navigation.
 Not all navigations will result in an error though, for example if the JavaScript for the next page is already loaded. If you still want to force a full-page navigation in these cases, use techniques such as setting the `pollInterval` and then using `beforeNavigate`:
-
 ```html
 /// file: +layout.svelte
 <script>

apps/svelte.dev/content/docs/svelte/02-runes/01-what-are-runes.md

@@ -6,7 +6,7 @@ title: What are runes?
 >
 > A letter or mark used as a mystical or magic symbol.
 
-Runes are symbols that you use in `.svelte` and `.svelte.js` / `.svelte.ts` files to control the Svelte compiler. If you think of Svelte as a language, runes are part of the syntax — they are _keywords_.
+Runes are symbols that you use in `.svelte` and `.svelte.js`/`.svelte.ts` files to control the Svelte compiler. If you think of Svelte as a language, runes are part of the syntax — they are _keywords_.
 
 Runes have a `$` prefix and look like functions: