Incorrectly triggered `node_invalid_placement` error when `<button>` is first child of `<select>`

[kass-kass]

Describe the bug

According to MDN documentation for styling <select> elements (link), a first-child <button> is allowed in modern browsers as a means to style the element, and is progressively enhanced / ignored when unsupported.

However, putting HTML akin to the example in the MDN, where a <select> has a single <button> as the first child, triggers node_invalid_placement compiler error.

Reproduction

Put the following HTML in any Svelte file:

<select>
	<!-- Select button -->
	<button>
		<selectedcontent></selectedcontent>
	</button>
	<option value="hello">Hello</option>
</select>

Logs

[Error [CompileError]: src/lib/Dashboard/sharedComponents/Dropdown.svelte:14:1 `<button>` cannot be a child of `<select>`. `<select>` only allows these children: `<option>`, `<optgroup>`, `<#text>`, `<hr>`, `<script>`, `<template>`. The browser will 'repair' the HTML (by moving, removing, or inserting elements) which breaks Svelte's assumptions about the structure of your components.
https://svelte.dev/e/node_invalid_placement]

System Info

System:
    OS: macOS 15.5
    CPU: (10) arm64 Apple M1 Pro
    Memory: 10.62 GB / 32.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 20.10.0 - /usr/local/bin/node
    Yarn: 1.22.22 - /usr/local/bin/yarn
    npm: 10.9.2 - /usr/local/bin/npm
    pnpm: 10.4.1 - /usr/local/bin/pnpm
  Browsers:
    Safari: 18.5
  npmPackages:
    svelte: ^5.35.2 => 5.35.6

Severity

annoyance

[Prinzhorn]

In the top right corner there's a search input you can use to search for similar issues:

https://github.com/search?q=repo%3Asveltejs%2Fsvelte%20node_invalid_placement%20button%20select&type=code
#15963
#15617

[kass-kass]

@Prinzhorn I am aware of how search works. The only other issue the search query you linked yields is #15963, asking to "Have the ability to customize the rule AT YOUR OWN RISKS".

This issue is not about ignoring incorrectly formed HTML. It's about the compiler error being thrown for valid, widely-supported and documented HTML.

Therefore, I created a new issue. Hope this helps.

[kass-kass]

#15617 Is indeed directly related, and this might be considered a special case of that general issue. However, it's very hard to find with any reasonable search query as it doesn't mention node_invalid_placement anywhere in title or body.

[Prinzhorn]

Isn't this literally a duplicate of #15617? Sorry if my comment came across rude, but I'm literally referencing duplicates in the svelte repo almost daily from people not searching at all.

widely-supported and documented HTML.

Isn't this still in stage 3? Or is having a <button> something different? If yes, then #15963 was closed prematurely

[Prinzhorn]

it's very hard to find with any reasonable search query as it doesn't mention node_invalid_placement anywhere in title or body.

It's linked from #15963 though

[paoloricciuti]

This issue is not about ignoring incorrectly formed HTML. It's about the compiler error being thrown for valid, widely-supported and documented HTML.

That is not widely-supported at all...it's only supported in chrome at the moment and if we would allow that it would break hydration for all non chrome browsers as the browser parser of the other browsers remove every element that is not text inside the select.

On the contrary if we would just allow it without change in the compiled output it would break hydration for chrome.

I'm thinking hard on how to fix this issue from a long time but unfortunately it's not immediate. We will get there but yeah, this is a duplicate of #15617

[kass-kass]

That is not widely-supported at all...it's only supported in chrome at the moment and if we would allow that it would break hydration for all non chrome browsers as the browser parser of the other browsers remove every element that is not text inside the select.

See #15617 (comment) for why this appears to be widely supported at first glance: simply looking up documentation for <select> leads you to believe it is, and the fact that is at proposal stage is only clear if one directly looks at the standards, which almost nobody does in practice. It's more the fault of the documentation authors than Svelte, but the resulting issue will likely be encountered by many more a developer.