Add content covering the limitations of <selectedcontent>

[philipwalton]

Description

This PR updates the <selectedcontent> reference document to:

1. Include more details about the limitations of cloning, and
2. Add a note emphasizing that sites built using JavaScript frameworks may prefer not to use <selectedcontent> and instead rely on the framework's existing UI synchronization feature.

Motivation

After seeing this Angular bug related to <selectedcontent> as well as testing the behavior of <selectedcontent> in several other frameworks and discovering issues, I believe it's important to update the MDN docs to clarify both the use cases for <selectedcontent> as well as its limitations. This should help ensure developers aren't confused by issues they run into when trying to use this new element.

FYI, I've discussed this recommendation with folks on the Chrome team working on the customizable <select> feature, and they're comfortable with this recommendation.

Additional details

Related issues and pull requests

[github-actions]

Preview URLs

• /en-US/docs/Web/HTML/Reference/Elements/selectedcontent

[estelle]

I am not even sure should be included yet on MDN. This review is based on us keeping it for now

[estelle]

Suggested change

	> [!NOTE]
	> The `<selectedcontent>` element's built-in synchronization features that make it ideal for websites built with minimal or no JavaScript. However, its use is not required when building customizable selects. Developers using JavaScript frameworks may prefer to use the UI synchronization features provided by their framework instead of using `<selectedcontent>`.

Let's remove this.
My thought is, if <selectedcontent> is useful and has semantic meaning, it should be used even by frameworks. If it doesn't, it shouldn't be used by anyone. We definitely don't want to start making suggestions that markup produced by frameworks should ever differ.

[philipwalton]

While I understand this objection (I initially felt the same way), I believe this is one of those cases where the element being documented has a very specific use case, and the documentation should be clear about what what use case is, and when it makes sense to use this element versus some other mechanism to achieve the same result.

We definitely don't want to start making suggestions that markup produced by frameworks should ever differ.

The suggestion here isn't that the markup produced by frameworks should differ, it's that people using a framework likely do not need to use this element (since it doesn't meet their use case).

The goal of this note is to signal to framework users that it's perfectly okay not to use the <selectedcontent> element and instead rely on the framework's existing APIs to mirror content in multiple places in the DOM.

My thought is, if <selectedcontent> is useful and has semantic meaning, it should be used even by frameworks.

The <selectedcontent> element has no semantic meaning (or ARIA role, or anything like that), and its only use is to enable authors to mirror the content of the selected <option> within the <select> button—without having to write any JavaScript code to do so.

This is a very useful feature for authors who don't want to write JavaScript. However, due to the element's limitations (that I mention in this PR), it may not work as expected for highly dynamic sites (which we're seeing in the wild based on the bug reports already coming from framework users). I think the documentation should warn author of that possibility.

[hamishwillee]

Thanks @philipwalton

I tend to think the chrome team need a swat around the ears - they should push this whole thing through a proper specification process and work with angular to clearly address this case. Generally though I agree with @estelle - the tail (framework) should not wag the dog (Angular). Angular have already stated that they will look at fixing this in due course.

Anyway, my take on this is that I very much like the added paragraph, but this note is not acceptable.
It too general and after the issue is addressed it would live here forever with no trigger to remove.

I propose we are much more specific (if you and @estelle are both OK with it):

Suggested change

	> [!NOTE]
	> The `<selectedcontent>` element's built-in synchronization features that make it ideal for websites built with minimal or no JavaScript. However, its use is not required when building customizable selects. Developers using JavaScript frameworks may prefer to use the UI synchronization features provided by their framework instead of using `<selectedcontent>`.
	> [!NOTE]
	> The `<selectedcontent>` may not work properly with JavaScript front-end frameworks that dynamically modify options after creation, such as Angular.
	> For more information and workarounds see the issue [angular#60636: Angular breaks `<selectedcontent>`](https://github.com/angular/angular/issues/60636#top)