Use `v` regexp flag instead of `u`

whatwg / urlpattern

URL Pattern Standard

Other

157 stars 22 forks source link

The v flags add more support to regular expression features:

"set operation", such as [[a-z]--[dhk]] to express "the set a-z, excluding the set dhk (https://github.com/tc39/proposal-regexp-v-flag)
multi-codepoint properties in \p, such as \p{RGI_Emoji_ZWJ_Sequence} (https://github.com/tc39/proposal-regexp-unicode-sequence-properties)

The HTML <input>'s pattern attribute has also been recently updated to use v instead of u (https://html.spec.whatwg.org/#compiled-pattern-regular-expression).

The “set operations” would be useful. I‘m pretty sure the second never will be, though, because ...

$new URLPattern({ pathname: "/🍒" }).test("https://bar.com/🍒"); true new URLPattern({ pathname: "/(\\p{Emoji})" }).test("https://bar.com/🍒"); false new URLPattern({ pathname: "/(\\p{Ll})" }).test("https://bar.com/a"); true new URLPattern({ pathname: "/(\\p{Ll})" }).test("https://bar.com/é"); false new URLPattern({ pathname: "/%F0%9F%8D%92" }).test("https://bar.com/🍒"); true$

— the illusion that non-ASCII is matchable is limited to literal input: it converts non-ASCII input to percent encoded UTF-8, but regexp pattern components aren’t likewise “translated”, so expressing things like \p{RGI_Emoji_Sequence} seems to always require input that’s similar to what transpilers might produce today for engines that don’t support multi- or single- codepoint properties at all.

whatwg / urlpattern

Use `v` regexp flag instead of `u` #178