Intent to Ship: Select parser relaxation

380 views
Skip to first unread message

Joey Arhar

unread,
Oct 10, 2024, 4:33:16 PMOct 10
to blink-dev

Contact emails

jar...@chromium.org

Explainer

https://open-ui.org/components/customizableselect

Specification

https://github.com/whatwg/html/pull/10557

Summary

This change makes the HTML parser allow additional tags in <select> besides <option>, <optgroup>, and <hr>. This change is in support of the customizable <select> feature but is being shipped first because it can be done separately and has some compat risk which I'd like to get feedback on. Customizable select explainer: https://open-ui.org/components/customizableselect/ I did a compat analysis and determined that the vast majority of sites which would see the effects of the parser changes would not have their behavior changed. More details here: https://github.com/whatwg/html/issues/10310 If there are major issues with this change, I will reassess and make adjustments to the parser as needed.



Blink component

Blink>HTML>Parser

TAG review

None

TAG review status

Pending

Risks



Interoperability and Compatibility

I believe there is low interop risk because other vendors are reviewing the proposal in WHATWG and are not objected to changing the parser behavior here. There is a compat risk if websites are relying on the old parser behavior. As I mentioned in the main description, I have done an analysis and based on the websites I have investigated I believe there is low risk. If we encounter issues then I will adjust the parser as needed.



Gecko: Positive of experimenting: https://github.com/whatwg/html/issues/10310#issuecomment-2189178702

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/414)

Web developers: No signals (https://github.com/mozilla/standards-positions/issues/1086)

Other signals:

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None



Debuggability

None



Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes

Flag name on chrome://flags

SelectParserRelaxation

Finch feature name

SelectParserRelaxation

Requires code in //chrome?

False

Tracking bug

https://crbug.com/335456114

Estimated milestones

Shipping on desktop130
DevTrial on desktop128
Shipping on Android130
DevTrial on Android128
Shipping on WebView130


Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5145948356083712?gate=5114873999261696

This intent message was generated by Chrome Platform Status.

Domenic Denicola

unread,
Oct 10, 2024, 9:23:15 PMOct 10
to Joey Arhar, blink-dev
On Fri, Oct 11, 2024 at 5:33 AM Joey Arhar <jar...@chromium.org> wrote:

This PR is still getting pretty active review comments. At least some of them seem like they'll impact the behavior. Do you think it would be reasonable to wait for the PR to settle before approving? I don't think we necessarily need to wait for formal approval or merging, but it seems like right now normative steps (like "Reconstruct the active formatting elements, if any") are being added and removed within the last 2 hours.
 



Summary

This change makes the HTML parser allow additional tags in <select> besides <option>, <optgroup>, and <hr>. This change is in support of the customizable <select> feature but is being shipped first because it can be done separately and has some compat risk which I'd like to get feedback on. Customizable select explainer: https://open-ui.org/components/customizableselect/ I did a compat analysis and determined that the vast majority of sites which would see the effects of the parser changes would not have their behavior changed. More details here: https://github.com/whatwg/html/issues/10310 If there are major issues with this change, I will reassess and make adjustments to the parser as needed.



Blink component

Blink>HTML>Parser

TAG review

None

TAG review status

Pending


I suspect this doesn't need a separate TAG review from the general customizable <select> one. But could you update ChromeStatus and this thread to link to the customizable select TAG review?
 



Risks



Interoperability and Compatibility

I believe there is low interop risk because other vendors are reviewing the proposal in WHATWG and are not objected to changing the parser behavior here. There is a compat risk if websites are relying on the old parser behavior. As I mentioned in the main description, I have done an analysis and based on the websites I have investigated I believe there is low risk. If we encounter issues then I will adjust the parser as needed.



Gecko: Positive of experimenting: https://github.com/whatwg/html/issues/10310#issuecomment-2189178702


https://github.com/mozilla/standards-positions/issues/1086 is probably the better link, which looks like "No signal but leaning positive pending confirmation".
 

WebView application risks

Does this intent deprecate or change behavior of existing APIs, such that it has potentially high risk for Android WebView-based applications?

None



Debuggability

None



Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

Yes

Is this feature fully tested by web-platform-tests?

Yes


The spec PR says "I still need to implement html5lib test changes". Did that get done?
 



Flag name on chrome://flags

SelectParserRelaxation

Finch feature name

SelectParserRelaxation

Requires code in //chrome?

False

Tracking bug

https://crbug.com/335456114

Estimated milestones

Shipping on desktop130
DevTrial on desktop128
Shipping on Android130
DevTrial on Android128
Shipping on WebView130


Are these accurate? The branch point for 130 has passed a while ago, and it sounds like the behavior is still changing (per the 2-hours-ago discussions on the spec PR).
 


Anticipated spec changes

Open questions about a feature may be a source of future web compat or interop issues. Please list open issues (e.g. links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (e.g., changing to naming or structure of the API in a non-backward-compatible way).

None

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5145948356083712?gate=5114873999261696

This intent message was generated by Chrome Platform Status.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btw%2B2u4-MY3c2x5uci_dOJWw8UdDNGfr_BiSfNESQwmPh5w%40mail.gmail.com.

Alex Russell

unread,
Oct 11, 2024, 2:33:22 PMOct 11
to blink-dev, Domenic Denicola, blink-dev, Joey Arhar
I agree with Domenic about TAG risk; just flagging this as part of the larger package is great.

Will the rollout of this change be Finch controlled? Do you expect the launch to happen over a single release? If you do a partial rollout for compat reasons and it goes sideways, please let us know.

LGTM1

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+unsubscribe@chromium.org.

Chris Harrelson

unread,
Oct 11, 2024, 3:12:42 PMOct 11
to Alex Russell, blink-dev, Domenic Denicola, Joey Arhar
LGTM2

I think it makes sense at this point to start finching/turning on this API freely on the stable channel, in order to inform the final spec language and landed PR. This is also the main risk factor identified in the Mozilla standards position request.

I think this is inherently a chicken-and-egg situation, where we'll have to try to ship the changes, and this experience will inform the final form of the spec and tests. I've spoken offline with Joey and his team, and am confident we'll follow through with finishing and landing the PR, carefully testing compat and achieving interop over time in this area.

Chris

To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/304f1ceb-9cdf-4b8e-8d1b-4fa540a1eae4n%40chromium.org.

Vladimir Levin

unread,
Oct 11, 2024, 4:29:09 PMOct 11
to Chris Harrelson, Alex Russell, blink-dev, Domenic Denicola, Joey Arhar

Joey Arhar

unread,
Oct 11, 2024, 7:35:59 PMOct 11
to Vladimir Levin, Chris Harrelson, Alex Russell, blink-dev, Domenic Denicola
> This PR is still getting pretty active review comments. At least some of them seem like they'll impact the behavior. Do you think it would be reasonable to wait for the PR to settle before approving? I don't think we necessarily need to wait for formal approval or merging, but it seems like right now normative steps (like "Reconstruct the active formatting elements, if any") are being added and removed within the last 2 hours.

I believe that we are very close, and I still have time to merge changes to 131 if there are any made after the branch point.

> https://github.com/mozilla/standards-positions/issues/1086 is probably the better link, which looks like "No signal but leaning positive pending confirmation".

I put this in the chromestatus entry

> The spec PR says "I still need to implement html5lib test changes". Did that get done?

Yes, and I updated the spec PR

> Are these accurate? The branch point for 130 has passed a while ago, and it sounds like the behavior is still changing (per the 2-hours-ago discussions on the spec PR).

I moved the milestone to 131
Reply all
Reply to author
Forward
0 new messages