I'll recuse myself from LGTMing this given that I drove the spec work, but I want to encourage other API owners to approve it. This fixes a small, but quite annoying, pain point, which we've heard complaints about since at least 2014 <https://www.w3.org/Bugs/Public/show_bug.cgi?id=24271>. I'm really glad that we've taken the time as the Chromium project to work on this sort of thing.
I agree with Joey's assessment that a TAG review is not needed for this sort of small loosening. Also, my judgement is that doing a normal rollout (with a Finch killswitch) is probably better than a Finch rollout, just for developer predictability. I think the compatibility risks of throwing *less* are basically nonexistent. But I don't feel strongly. On Friday, June 13, 2025 at 7:05:49 AM UTC+9 Joey Arhar wrote: > Contact emailsjar...@chromium.org > > ExplainerNone > > Specificationhttps://dom.spec.whatwg.org/#namespaces > > Summary > > The HTML parser has always (or for a long time) allowed elements and > attributes to have a wide variety of valid characters and names, but the > javascript DOM APIs to create the same elements and attributes are more > strict and don't match the parser. This change relaxes the validation of > the javascript DOM APIs to match the HTML parser. More context here: > https://github.com/whatwg/dom/issues/849 I don't anticipate any compat > issues from this change because all of the previously allowed > element/attribute names are still allowed with the new behavior. > > > WHATWG has merged the spec changes for this already: > > - https://github.com/whatwg/dom/pull/1079 > > - https://github.com/whatwg/html/pull/7991 > > Blink componentBlink>DOM > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EDOM%22> > > TAG reviewNone > > TAG review statusNot applicable > > Risks > > > Interoperability and Compatibility > > I believe it is very likely that webkit and gecko will ship this change > after we do, so I believe that the interoperability and compat risks are > low. > > > *Gecko*: No signal - This spec PR lists gecko as an interested > implementor, so maybe firefox view is positive? > https://github.com/whatwg/dom/pull/1079 > > *WebKit*: No signal > > *Web developers*: Positive ( > https://github.com/whatwg/dom/issues/849#issuecomment-2876716958) > > *Other signals*: > > Ergonomics > > The validation of element and attribute names is fairly isolated and the > new validation logic does not have different complexity than the old logic. > The default usage of this API will not make it hard for chrome to maintain > good performance. > > > Activation > > It will not be hard to developers to use this change immediately, and I > don't think we need outreach for it. It is more of a bug fix than a new > feature. > > > Security > > https://github.com/whatwg/dom/issues/849#issuecomment-1090076902 > > > 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 > > If an element or attribute name is not allowed, then just like with the > old logic an exception will be thrown explaining that the name is not > valid. There are no specialized DevTools features for this name validation, > and I don't think any DevTools changes are needed for this feature. > > > 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 > <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> > ?Yes > > https://github.com/web-platform-tests/wpt/pull/38503 > https://chromium-review.googlesource.com/c/chromium/src/+/6570951 > https://github.com/web-platform-tests/wpt/pull/52982 > https://chromium-review.googlesource.com/c/chromium/src/+/6615057 > > Flag name on about://flagsNone > > Finch feature nameRelaxDOMValidNames > > Rollout plan > This seems fairly safe so I was going to go with "Will ship enabled for > all users," but there is no rush for this change so I am thinking that > rolling out via finch would be better just to be safe. > > Requires code in //chrome?False > > Tracking bughttps://issues.chromium.org/issues/40228234 > > MeasurementI didn't add UseCounters for this, and I don't think it is > necessary to track. > > Estimated milestones > > No milestones specified > > > 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/6278918763708416?gate=5097618073714688 > > This intent message was generated by Chrome Platform Status > <https://chromestatus.com/>. > -- 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+unsubscr...@chromium.org. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6ea1397c-879f-48f9-b5a8-72839e4f8ee5n%40chromium.org.
