Behavior of updating the checkedness state of the elements in the same radio button group is unclear

[EdgarChen]

What is the issue with the HTML Standard?

https://html.spec.whatwg.org/multipage/input.html#radio-button-state-(type=radio) lists the cases where the checkedness state of elements in the same radio button group should update,

When any of the following phenomena occur, if the element's checkedness state is true after the occurrence, the checkedness state of all the other elements in the same radio button group must be set to false:

• The element's checkedness state is set to true (for whatever reason).
• The element's name attribute is set, changed, or removed.
• The element's form owner changes.
• A type change is signalled for the element.

However, all browsers also update the checkedness state of elements in the same radio button group when the element becomes connected. Note that Chrome/Safari don't update the checkedness state of elements in the same radio button group when the element is appended to a disconnected subtree and the form owner remains unchanged, e.g. https://software.hixie.ch/utilities/js/live-dom-viewer/?saved=13369. Some pages rely on this behavior, see the report in https://bugzilla.mozilla.org/show_bug.cgi?id=1938489, so we are going to behave the same in Gecko for compatibility. I suggest we also make it clear in the spec by perhaps adding

• The element becomes connected.

into https://html.spec.whatwg.org/multipage/input.html#radio-button-state-(type=radio)?

[annevk]

cc @domfarolino

[domfarolino]

While I'd love to get rid of the COMEFROM-ey "becomes foo" hooks, I don't think that dream should block this issue, and adding "becomes connected" to the list makes a lot of sense. Do you know if there are WPTs for this @EdgarChen? If so we can get a PR up for this I think.

[EdgarChen]

There are some WPTs add in https://bugzilla.mozilla.org/show_bug.cgi?id=1938489 which would be merged in web-platform-tests/wpt#50048. I will prepare a PR for this.