Intent to Ship: Allow more characters in javascript DOM APIs

275 views
Skip to first unread message

Joey Arhar

unread,
Jun 12, 2025, 10:05:49 PM (8 days ago) Jun 12
to blink-dev

Contact emails

jar...@chromium.org

Explainer

None

Specification

https://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 component

Blink>DOM

TAG review

None

TAG review status

Not 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?

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://flags

None

Finch feature name

RelaxDOMValidNames

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 bug

https://issues.chromium.org/issues/40228234

Measurement

I 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.

Domenic Denicola

unread,
Jun 13, 2025, 1:39:15 AM (8 days ago) Jun 13
to blink-dev, Joey Arhar
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. 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.

TAMURA, Kent

unread,
Jun 13, 2025, 1:42:46 AM (8 days ago) Jun 13
to blink-dev, Joey Arhar, Domenic Denicola
LGTM1.
The risk by shipping this feature would be very small.


--
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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/6ea1397c-879f-48f9-b5a8-72839e4f8ee5n%40chromium.org.


--
TAMURA Kent
Software Engineer, Google


Daniel Bratell

unread,
Jun 16, 2025, 5:15:28 PM (4 days ago) Jun 16
to TAMURA, Kent, blink-dev, Joey Arhar, Domenic Denicola

LGTM2

/Daniel

Yoav Weiss (@Shopify)

unread,
Jun 18, 2025, 2:59:45 PM (2 days ago) Jun 18
to blink-dev, Daniel Bratell, Domenic Denicola, Kent Tamura, Joey Arhar
LGTM3

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


--
TAMURA Kent
Software Engineer, Google


--
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+unsubscribe@chromium.org.

Joey Arhar

unread,
Jun 18, 2025, 3:48:03 PM (2 days ago) Jun 18
to Yoav Weiss (@Shopify), blink-dev, Daniel Bratell, Domenic Denicola, Kent Tamura
Thanks for the LGTMs!

> 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.

Thanks, I'll just do a normal rollout then via RuntimeEnabledFeatures with a killswitch.

LGTM3

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


--
TAMURA Kent
Software Engineer, Google


--
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.

--
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 visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/86b7f733-3465-422d-b022-ac6779b64c7cn%40chromium.org.
Reply all
Reply to author
Forward
0 new messages