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

<inputpattern="[0-9][A-Z]{3}" name="part"

         title="A part number is a digit followed by three uppercase letters.">

</label>


When the patternattribute was first implemented, these regular expressions were compiled without any RegExp flags. In 2014, the HTML Standard changed this by implicitly enabling the uflag 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 vflag <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 vflag 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 patternattribute.)


        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 athttps://github.com/whatwg/html/pull/7908 <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 vflag — 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 UseCountercalled HTMLPatternRegExpUnicodeSetIncompatibilitiesWithUnicodeMode <https://chromestatus.com/metrics/feature/popularity#HTMLPatternRegExpUnicodeSetIncompatibilitiesWithUnicodeMode>in M112, which tracks patterns in any JavaScript uRegExps generated via the HTML patternattribute that would throw if they were used with the vflag.


Importantly, note that any throwing pattern gracefully degrades — it simply behaves as if the patternattribute wasn’t present, resulting in inputElement.validity.valid === truefor any input value. Consequently, the only compatibility risk is that some value/pattern combinations that would previously result in inputElement.validity.validbeing falsenow result in it being true. Thus, for every UseCounterhit, it could still be that there is no actual breakage — the UseCounterjust gives us the upper bound.The currently available data from Beta suggests the UseCounterhits 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...

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 <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 patternattribute 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 <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 <https://bugs.chromium.org/p/chromium/issues/detail?id=1412729>


        Sample links

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


        Estimated milestones

M114


        Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5149507107422208 <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.

Reply via email to