Boolean attributes break in XML syntax

[chris-morgan]

Describe the bug

a86e52b restored XML¹-compatible syntax for void elements (emitting <br/> instead of <br>) and placeholder comments (emitting <!----> instead of <!>).

But it didn’t handle boolean attributes due to these two locations:

svelte/packages/svelte/src/compiler/phases/3-transform/client/transform-template/template.js

Line 104 in 8067841

if (value !== undefined) str += `="${escape_html(value, true)}"`;

svelte/packages/svelte/src/internal/shared/attributes.js

Line 27 in 8067841

const assignment = is_boolean ? '' : `="${escape_html(normalized, true)}"`;

If you want to support XML syntax, you can’t omit ="".

Otherwise, I recommend reverting a86e52b because all it does is falsely raise hopes—better to obviously and quickly not support XML syntax, rather than leaving a couple of fatal² footguns around, especially when there’s no workaround for one of them.

I think the options are to always emit XML-compatible syntax, never emit XML-compatible syntax, or add another option to import("svelte/server").render and detect it at runtime on the client.³

It’s not entirely related, but I also want to record mild discomfort at is_boolean: it makes me uncomfortable that there’s just a list of 29 attribute names where the server side will just ignore an attribute value, and only use its truthiness. Makes it a little more dangerous to use Svelte to emit XML, which would otherwise be very reasonable (e.g. I’m just now trying out producing an Atom feed directly from a component, that’s where this report is coming from).

¹ We don’t talk about XHTML any more; that spec is long dead, and the HTML Standard switched to talking of XML syntax instead some years ago.

² In XML syntax, one syntax error and the entire document doesn’t render. Big risk of accidental and unnoticed breakage.

³ These days, document.contentType != "text/html" will do to detect XML syntax. In the past, document.documentElement.tagName == "html" was good. Actually, that makes me think: are there places that assume tagName is uppercase, which will not function correctly in an XML syntax document? Yeah, there are a couple. I won’t file an issue, though, unless it becomes apparent there’s will to behave correctly in XML syntax on the client: on the server I think it’s an easy argument, but on the client not so compelling: it’s pretty rare to see XML syntax being used, though it does happen.

Reproduction

Firstly, plain HTML: <audio controls></audio> doesn’t work, but you can work around it with <audio controls=""></audio> (… which I feel shouldn’t have yielded a different result).

Secondly, with curlies: <input checked={true}> doesn’t work, which is more debilitating as there’s no workaround I can see.

Logs

System Info

HEAD

Severity

blocking all usage of svelte