Intent to Implement and Ship: Use RegExp v flag instead of u for HTML pattern attribute

[Mathias Bynens]

Contact emails

mat...@chromium.org

Specification

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

Summary

The <input pattern> attribute allows developers to specify a regular expression pattern against which the input’s values are checked for validity.

<label>   Part number:   <input pattern="[0-9][A-Z]{3}" name="part"          title="A part number is a digit followed by three uppercase letters."> </label>

When the pattern attribute was first implemented, these regular expressions were compiled without any RegExp flags. In 2014, the HTML Standard changed this by implicitly enabling the u flag for the pattern attribute, enabling better Unicode support (including support for Unicode character properties like \p{Letter}). This change shipped in Chrome 53.

Now, we’re taking this to the next level by enabling the new RegExp v flag instead of u, enabling the use of set notation, string literal syntax, and Unicode properties of strings.

(Context: The RegExp v flag is a JavaScript language feature which previously went through the Blink Intents process and shipped in Chrome 112. This new ChromeStatus entry is specifically about integrating it with the HTML pattern attribute.)

Blink component

Blink>Forms

Search tags

unicode, regexp, pattern, validation

TAG review

TAG review status

Not applicable

Risks

Interoperability and Compatibility

The spec patch at https://github.com/whatwg/html/pull/7908 lists the potentially breaking changes. Some patterns that previously would compile, now throw an early error with the v flag — specifically those with a character class including either an unescaped special character or a double punctuator.

We expect such patterns to be rare. To validate this assumption we’ve added a UseCounter called HTMLPatternRegExpUnicodeSetIncompatibilitiesWithUnicodeMode in M112, which tracks patterns in any JavaScript u RegExps generated via the HTML pattern attribute that would throw if they were used with the v flag. 

Importantly, note that any throwing pattern gracefully degrades — it simply behaves as if the pattern attribute wasn’t present, resulting in inputElement.validity.valid === true for any input value. Consequently, the only compatibility risk is that some value/pattern combinations that would previously result in inputElement.validity.valid being false now result in it being true. Thus, for every UseCounter hit, it could still be that there is no actual breakage — the UseCounter just gives us the upper bound. The currently available data from Beta suggests the UseCounter hits for 0.0393% of Chrome page loads.

Gecko: Positive (Mozilla standards position request, implementation tracking issue)

WebKit: Positive (WebKit standards position request, implementation tracking issue)

Web developers: No signals

Other signals:

Debuggability

The pattern attribute is already well-supported in DevTools and other tooling; no changes are necessary.

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

Yes

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

Pull Request: https://github.com/web-platform-tests/wpt/pull/38547

Flag name

N/A

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1412729

Sample links

https://mathiasbynens.be/demo/pattern-u-vs-v

Estimated milestones

M114

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5149507107422208

[Mike Taylor]

Hey Mathias,

I'm somewhat curious to see how much that UseCounter will grow (if at all) when 112 goes to stable next week...

Do you have any concerns about certain inputs being sent to a server that might not have any backend validation, that would previously be prevented by the u-vintage validation?

Gecko: Positive (Mozilla standards position request, implementation tracking issue)

WebKit: Positive (WebKit standards position request, implementation tracking issue)

Web developers: No signals

Other signals:

Debuggability

The pattern attribute is already well-supported in DevTools and other tooling; no changes are necessary.

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

Yes

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

Pull Request: https://github.com/web-platform-tests/wpt/pull/38547

Flag name

N/A

Requires code in //chrome?

False

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1412729

Sample links

https://mathiasbynens.be/demo/pattern-u-vs-v

Estimated milestones

M114

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5149507107422208

--
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/CADizRgaAq4FwzJbUqLQVo%2BQdd_V0PT7rBr510OGe8fenHA%3D3HQ%40mail.gmail.com.

[Mathias Bynens]

Me too, and FWIW I'd understand if you and the other API owners prefer to wait until there’s some data for Stable before responding to this Intent.

Do you have any concerns about certain inputs being sent to a server that might not have any backend validation, that would previously be prevented by the u-vintage validation?

That’s indeed the only scenario in which there would be breakage. So far we haven’t heard of such cases in the wild. (Arguably, such web pages are already broken, since DevTools could easily be used to remove the `pattern` attribute, or requests could be made with tools like `curl`.) FWIW, there was a similar discussion in this old blink-dev thread: https://groups.google.com/a/chromium.org/g/blink-dev/c/XUNMtri0tI4/m/mjPkwXKNAQAJ

I forgot to mention that we explicitly added a console warning in M112 for any `pattern` attribute values that would be affected by this change, to help developers prepare for the potential change. One developer reported seeing the warning and adjusting their `pattern` attribute values accordingly, but it’s unclear whether inaction would have really broken their web page: https://bugs.chromium.org/p/chromium/issues/detail?id=1412729#c7

 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c9571b2a-a35b-3824-0f37-c93a9bb522fc%40chromium.org.

[Philip Jägenstedt]

I took a look at https://github.com/whatwg/html/pull/7908 and it looks like there's agreement to merge it, but it's waiting on this intent to be approved. Normally we block in the other direction, but that's fine, as long as the spec change is merged.

Looks like there's broad support for this change, and it's just a question of the site compat risk. ~0.04% as an upper bound is quite high. Can we wait until the use counter is in stable and look at a random set of sites hitting the use counter to determine what the real-world breakage looks like?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADizRgYxU2v2ANQgzNiLD%2B4P-qJHxzTYJfRDsKNCtY0Yb_0bdg%40mail.gmail.com.

[Mathias Bynens]

Thanks to the UseCounter + UKM + M112 hitting Stable, more results are starting to come in. I’ll be collecting public examples of potential incompatibilities here: https://bugs.chromium.org/p/chromium/issues/detail?id=1412729#c11 So far 0 out of the 2 examples cause any actual breakage — fingers crossed that trend continues.

[Alex Russell]

I don't understand why TAG review is not applicable for this intent.

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

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADizRgaAq4FwzJbUqLQVo%2BQdd_V0PT7rBr510OGe8fenHA%3D3HQ%40mail.gmail.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+unsubscribe@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c9571b2a-a35b-3824-0f37-c93a9bb522fc%40chromium.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+unsubscribe@chromium.org.

[Mathias Bynens]

On Wed, Apr 5, 2023 at 5:23 PM Alex Russell <sligh...@chromium.org> wrote:

I don't understand why TAG review is not applicable for this intent.

Fair enough. I’ve filed a TAG review request here: https://github.com/w3ctag/design-reviews/issues/832 I’ll update the ChromeStatus entry to refer to it.

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/CADizRgaAq4FwzJbUqLQVo%2BQdd_V0PT7rBr510OGe8fenHA%3D3HQ%40mail.gmail.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+...@chromium.org.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c9571b2a-a35b-3824-0f37-c93a9bb522fc%40chromium.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.

[Mathias Bynens]

So far, none of the UseCounter hits I investigated constitute any actual breakage. The vast majority of hits seem to be login forms backed by server-side validation. I’ll keep looking though.

In the meantime, this feature is now available behind the `--enable-blink-features=HTMLPatternRegExpUnicodeSets` flag (disabled by default).

[Rick Byers]

Thanks for doing a thorough compat analysis of this Mathias. I can totally see this being one where all the examples we can find don't seem to cause breakage in practice. I know it's a lot, but if we looked at 40 random examples and found none of them to break, that would suggest an upper bound of <0.001% of pages impacted (probably much lower) and I'd be OK giving this a shot with a finch killswitch ready in case of reports of serious breakage. Does that sound reasonable to you?

Also feel free to set your flag to status=experimental, that'll get us some additional usage coverage (from the small population that runs with --enable-experimental-web-platform-features) and also signal that this is close to becoming shipping behavior.

Rick

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/bf73fe5b-fde2-42df-90f0-582a905d1948n%40chromium.org.

[Mathias Bynens]

Thanks for the guidance, Rick. I’ve prepared a CL moving the flag to status=experimental and I can commit to investigating 40 unique UseCounter hits and summarizing my findings. Fingers crossed the trend of “no actual breakage detected” continues. I’ll keep you posted.

[Philip Jägenstedt]

I wonder if we can get enough confidence with less work than investigating 40 randomly chosen sites from UseCounter hits.

This is a population proportion problem, and https://sample-size.net/confidence-interval-proportion/ is a useful tool. If you check 40 cases and find no breakage (N=40, x=0) that gives us 95% confidence that breakage is less than 7.2% of samples in this data set. If it's useful to check that much depends on the value of the use counter.

Is https://chromestatus.com/metrics/feature/timeline/popularity/4463 the right use counter, and has it reached stable yet? Why is marked as obsolete?

For purposes of illustration, let's use 0.04% from earlier in the thread and say we want to be (95%) confident that real breakage is less than 0.01%. Then we just need to get below 25% in the linked tool, and checking 11 samples and finding nothing is enough to do this.

[Rick Byers]

On Wed, Apr 19, 2023 at 3:41 PM Philip Jägenstedt <foo...@chromium.org> wrote:

I wonder if we can get enough confidence with less work than investigating 40 randomly chosen sites from UseCounter hits.

This is a population proportion problem, and https://sample-size.net/confidence-interval-proportion/ is a useful tool. If you check 40 cases and find no breakage (N=40, x=0) that gives us 95% confidence that breakage is less than 7.2% of samples in this data set. If it's useful to check that much depends on the value of the use counter.

Is https://chromestatus.com/metrics/feature/timeline/popularity/4463 the right use counter, and has it reached stable yet? Why is marked as obsolete?

For purposes of illustration, let's use 0.04% from earlier in the thread and say we want to be (95%) confident that real breakage is less than 0.01%. Then we just need to get below 25% in the linked tool, and checking 11 samples and finding nothing is enough to do this.

I like your more sophisticated math, but it's <0.001% that we want I'm afraid, not 0.01%. So, if I'm following your instructions right, that's ~42 samples to have 95% confidence :-)

Of course 0.001% is just a rough guideline that has often proven to be too high or too low. So this is all a judgement call anyway.

[nightpool]

I will say personally, as an author, I am generally accustomed to using special characters in my regex character classes freely, and hearing that the HTML spec is making a backwards incompatible breaking change that would prevent me from doing so is kind of surprising, and personally i would probably find it a little bit annoying. Especially since it puts the HTML spec out of sync with every other major regex implementation that I know if, meaning that new authors would have a hard time checking their patterns for validity on any of the common regex visualization/testing sites. 

Additionally, what we're considering as "not real breakage" here is still a decreased user experience for users, right? As well as extra work for developers who's pages previously had perfectly acceptable UX (warned users about invalid values prior to submission) and now have pages where that feature no longer functions. 

Going off of the discussion on backwards compatibility in the original TC39 proposal, https://github.com/tc39/proposal-regexp-v-flag#is-the-new-syntax-backwards-compatible-do-we-need-another-regular-expression-flag it feels like a lot of the considerations in that discussion boiled down to "flags are an accessible and convenient way to opt in". But in this case the opposite is true—flags are completely unexposed by the HTML spec, so there's no easy and accessible way to opt in to the new behavior. It feels like some of the other options they considered (for example, a way of specifying flags "in pattern" like some engines allow for, or a prefix like \U[ to allow for set operations) would make much more sense when considered in the HTML usage context where flags aren't readily available to authors.

I guess if I had to summarize my concerns, it's that by making this change for all users with no opt in, we're adopting the letter of the TC39 proposal but not the spirit, which leaves the HTML spec out of step with user expectations. 

However, I do understand the actual potential for breakage here is pretty small and it's the price we pay for a more featureful and expressive regex language. Has the HTML spec considered any small changes they could do to improve backwards compatibility and usability in this area, like falling back to parsing regexes as /u if /v parsing fails? True, that would encode legacy behavior in the platform where it's arguably not necessary to, but I feel like the improvement in developer ergonomics is worth the tradeoff.

[Mathias Bynens]

On Wed, Apr 19, 2023 at 9:41 PM Philip Jägenstedt <foo...@chromium.org> wrote:

I wonder if we can get enough confidence with less work than investigating 40 randomly chosen sites from UseCounter hits.

This is a population proportion problem, and https://sample-size.net/confidence-interval-proportion/ is a useful tool. If you check 40 cases and find no breakage (N=40, x=0) that gives us 95% confidence that breakage is less than 7.2% of samples in this data set. If it's useful to check that much depends on the value of the use counter.

Is https://chromestatus.com/metrics/feature/timeline/popularity/4463 the right use counter, and has it reached stable yet? Why is marked as obsolete?

Yes, that’s the correct use counter, and yes it’s in M112. It’s marked “obsolete” on the site because we removed it from the source tree as part of M113, and ChromeStatus uses the latest HEAD as the source of truth for the UseCounter labels. The rationale for removing the code triggering this UseCounter was that a full milestone cycle (M112) should be more than enough data to make a decision in this particular case.

[Mathias Bynens]

I’ve continued analyzing UKM results and have now reached n=40 as Rick suggested:

| origin                                   | link to analysis              | continues to work with the change? |
| :--------------------------------------- | :---------------------------- | :--------------------------------- |
| https://account.amazon.jobs              | https://crbug.com/1412729#c23 | ✅                                 |
| https://code.earthengine.google.com      | https://crbug.com/1412729#c41 | ✅                                 |
| https://ekartlogistics.com               | https://crbug.com/1412729#c52 | ✅                                 |
| https://go.thepersonalfinancialguide.com | https://crbug.com/1412729#c29 | ✅                                 |
| https://heliyatra.irctc.co.in            | https://crbug.com/1412729#c47 | ✅                                 |
| https://identity.appen.com               | https://crbug.com/1412729#c11 | ✅                                 |
| https://login.vitalsource.com            | https://crbug.com/1412729#c17 | ✅                                 |
| https://login.yahoo.com                  | https://crbug.com/1412729#c16 | ✅                                 |
| https://m.betpix365.com                  | https://crbug.com/1412729#c27 | ✅                                 |
| https://m.esportesdasorte.com            | https://crbug.com/1412729#c21 | ✅                                 |
| https://m.estrelabet.com                 | https://crbug.com/1412729#c22 | ✅                                 |
| https://m.vaidebet.com                   | https://crbug.com/1412729#c32 | ✅                                 |
| https://my1.konami.net                   | https://crbug.com/1412729#c33 | ✅                                 |
| https://particuliers.engie.fr            | https://crbug.com/1412729#c34 | ✅                                 |
| https://register.betway.de               | https://crbug.com/1412729#c25 | ✅                                 |
| https://renegociacao.itau.com.br         | https://crbug.com/1412729#c51 | ✅                                 |
| https://signin.costco.com                | https://crbug.com/1412729#c12 | ✅                                 |
| https://smartkey.xertica.com             | https://crbug.com/1412729#c19 | ✅                                 |
| https://sports.coral.co.uk               | https://crbug.com/1412729#c35 | ✅                                 |
| https://sports.ladbrokes.com             | https://crbug.com/1412729#c31 | ✅                                 |
| https://tazkarti.com                     | https://crbug.com/1412729#c36 | ✅                                 |
| https://voterportal.eci.gov.in           | https://crbug.com/1412729#c53 | ✅                                 |
| https://www.acesso.gov.pt                | https://crbug.com/1412729#c26 | ✅                                 |
| https://www.air.irctc.co.in              | https://crbug.com/1412729#c37 | ✅                                 |
| https://www.bancoestado.cl               | https://crbug.com/1412729#c15 | ✅                                 |
| https://www.bienlinea.bi.com.gt          | https://crbug.com/1412729#c50 | ✅                                 |
| https://www.coachoutlet.com              | https://crbug.com/1412729#c49 | ✅                                 |
| https://www.enterprise.de                | https://crbug.com/1412729#c40 | ✅                                 |
| https://www.etopaz.az                    | https://crbug.com/1412729#c44 | ✅                                 |
| https://www.gamestop.com                 | https://crbug.com/1412729#c38 | ✅                                 |
| https://www.iliad.it                     | https://crbug.com/1412729#c39 | ✅                                 |
| https://www.irctctourism.com             | https://crbug.com/1412729#c42 | ✅                                 |
| https://www.leroymerlin.fr               | https://crbug.com/1412729#c18 | ✅                                 |
| https://www.mediafire.com                | https://crbug.com/1412729#c20 | ✅                                 |
| https://www.midatacredito.com            | https://crbug.com/1412729#c43 | ✅                                 |
| https://www.milanuncios.com              | https://crbug.com/1412729#c30 | ✅                                 |
| https://www.portaleargo.it               | https://crbug.com/1412729#c14 | ✅                                 |
| https://www.readworks.org                | https://crbug.com/1412729#c48 | ✅                                 |
| https://www.saksfifthavenue.com          | https://crbug.com/1412729#c46 | ✅                                 |
| https://www.thebay.com                   | https://crbug.com/1412729#c45 | ✅                                 |

This is not quite a "random" sample, as I instead started with the most common sources of UseCounter hits and then went down the list. I looked at a total of 58 unique origins, but some of the sites failed to load for me, or the offending `pattern` was hidden behind a paywall or login that I couldn’t get past.

WDYT? 

[Yoav Weiss]

LGTM1 to ship with a killswitch flag, just in case.

Thanks for the thorough analysis!

[Philip Jägenstedt]

On Wed, Apr 19, 2023 at 10:28 PM Rick Byers <rby...@chromium.org> wrote:

On Wed, Apr 19, 2023 at 3:41 PM Philip Jägenstedt <foo...@chromium.org> wrote:

I wonder if we can get enough confidence with less work than investigating 40 randomly chosen sites from UseCounter hits.

This is a population proportion problem, and https://sample-size.net/confidence-interval-proportion/ is a useful tool. If you check 40 cases and find no breakage (N=40, x=0) that gives us 95% confidence that breakage is less than 7.2% of samples in this data set. If it's useful to check that much depends on the value of the use counter.

Is https://chromestatus.com/metrics/feature/timeline/popularity/4463 the right use counter, and has it reached stable yet? Why is marked as obsolete?

For purposes of illustration, let's use 0.04% from earlier in the thread and say we want to be (95%) confident that real breakage is less than 0.01%. Then we just need to get below 25% in the linked tool, and checking 11 samples and finding nothing is enough to do this.

I like your more sophisticated math, but it's <0.001% that we want I'm afraid, not 0.01%. So, if I'm following your instructions right, that's ~42 samples to have 95% confidence :-)

Of course 0.001% is just a rough guideline that has often proven to be too high or too low. So this is all a judgement call anyway.

Ah, then I understand where the number 40 came from (0.04/0.001). I may well be wrong, but I think to get a 40-fold reduction in the upper bound, we need to sample until our upper bound is <=0.025, and with CL=90 (to get a 95% one-sided CI) we'd need 119 samples with no breakage to get there.

But definitely let's not do that, I was probing to see if we could do less work, not more. Checking 40 cases and finding nothing is better than we've done in many cases, so the risk feels quite low.

[Philip Jägenstedt]

LGTM2, thank you Mathias for the detailed analysis!

[Rick Byers]

Thanks for the great analysis! LGTM3 with a killswitch in case we predicted wrong.