Customizable Select elements break Astro pages

[KingOfTac]

Astro Info

Astro                    v5.13.0
Node                     v24.1.0
System                   Windows (x64)
Package Manager          npm
Output                   static
Adapter                  none
Integrations             none

If this issue only occurs in one browser, which browser is a problem?

No response

Describe the Bug

The markup of a page becomes broken and mangled if a customizable select element is used anywhere on the page, unless is:raw is applied to the select element.

MDN Docs

What's the expected result?

Newer and experimental platform features should just work if the browser supports it.

Link to Minimal Reproducible Example

https://stackblitz.com/edit/withastro-astro-umwytfmj?file=src%2Fpages%2Findex.astro

Participation

• I am willing to submit a pull request for this issue.

[delucis]

Because Astro aims to parse HTML the same way browsers do, we maintain lists of what elements are allowed as children so I'm guessing those will need updating for the new syntax.

[KingOfTac]

I can see the broken behavior beginning as soon as a button is placed as a child of the select so that tracks. I believe select would need to be updated to allow arbitrary elements as children since you can wrap the options in custom markup as well.

[KingOfTac]

Example from the spec. https://html.spec.whatwg.org/multipage/form-elements.html#example-customizable-select

[delucis]

I’m not super familiar with the compiler code, but this looks like a promising place to look:

compiler/internal/parser.go

Lines 146 to 149 in 89c80fe

	case selectScope:
	if tagAtom != a.Optgroup && tagAtom != a.Option {
	return -1
	}

I’ll move this across to the compiler repo.

AST output looks OK to me, but the TS transform is where the tree gets messed up: compiler playground

[KingOfTac]

@delucis I wasn't aware of the compiler repo when I opened this issue which I have now found to be a duplicate of #1093. Closing this one in favor of the existing issue.