On Wed, Apr 5, 2023 at 5:23 PM Alex Russell <slightly...@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.

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/CADizRgYfTYz%2BYsC3qp%3Dq6-mV7%2BuWccY5zkY7VXkuygTWajbyWA%40mail.gmail.com.

Reply via email to