I don't understand why TAG review is not applicable for this intent. On Tuesday, April 4, 2023 at 5:21:16 AM UTC-7 mt...@google.com wrote:
> 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/51e1e696-5349-423b-88db-ad8237283497n%40chromium.org.
