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.
On Mon, Apr 3, 2023 at 10:26 AM Philip Jägenstedt <foo...@chromium.org> wrote: > 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? > > On Fri, Mar 31, 2023 at 5:07 PM 'Mathias Bynens' via blink-dev < > blink-dev@chromium.org> wrote: > >> >> >> On Fri, Mar 31, 2023 at 4:35 PM Mike Taylor <miketa...@chromium.org> >> wrote: >> >>> Hey Mathias, >>> On 3/31/23 5:56 AM, Mathias Bynens wrote: >>> >>> Contact emails >>> >>> math...@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. >>> <https://chromestatus.com/feature/4753420745441280> >>> >>> Now, we’re taking this to the next level by enabling the new RegExp v >>> flag <https://v8.dev/features/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 <https://chromestatus.com/feature/5144156542861312>. This new >>> ChromeStatus entry is specifically about integrating it with the HTML >>> pattern attribute.) >>> >>> Blink component >>> >>> Blink>Forms >>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EForms> >>> >>> Search tags >>> >>> unicode <https://chromestatus.com/features#tags:unicode>, regexp >>> <https://chromestatus.com/features#tags:regexp>, pattern >>> <https://chromestatus.com/features#tags:pattern>, validation >>> <https://chromestatus.com/features#tags: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 >>> <https://chromestatus.com/metrics/feature/popularity#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. >>> >>> I'm somewhat curious to see how much that UseCounter will grow (if at >>> all) when 112 goes to stable next week... >>> >> 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 >> >> >>> >>> Gecko: Positive (Mozilla standards position request >>> <https://github.com/mozilla/standards-positions/issues/745>, implementation >>> tracking issue <https://bugzilla.mozilla.org/show_bug.cgi?id=pattern-v>) >>> >>> WebKit: Positive (WebKit standards position request >>> <https://github.com/WebKit/standards-positions/issues/132>, implementation >>> tracking issue <https://bugs.webkit.org/show_bug.cgi?id=pattern-v>) >>> >>> 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 >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>> ? >>> >>> 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+unsubscr...@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 >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADizRgaAq4FwzJbUqLQVo%2BQdd_V0PT7rBr510OGe8fenHA%3D3HQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >>> -- >>> 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 on the web visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c9571b2a-a35b-3824-0f37-c93a9bb522fc%40chromium.org >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/c9571b2a-a35b-3824-0f37-c93a9bb522fc%40chromium.org?utm_medium=email&utm_source=footer> >>> . >>> >> -- >> 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 on the web visit >> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADizRgYxU2v2ANQgzNiLD%2B4P-qJHxzTYJfRDsKNCtY0Yb_0bdg%40mail.gmail.com >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADizRgYxU2v2ANQgzNiLD%2B4P-qJHxzTYJfRDsKNCtY0Yb_0bdg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- 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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADizRgbT0ZwZJ91qJYj3%3D%2B38FjortMzmpoWE5VPn7eOGu%2BejxQ%40mail.gmail.com.
