Specifying the "u" flag to pattern attribute may cause backward compatibility issue

[arai-a]

https://html.spec.whatwg.org/multipage/forms.html#the-pattern-attribute

ES6 requires more strict syntax when "u" flag is specified for RegExp (see the difference between [+U] and [~U] there), and it rejects some patterns that was working without "u" flag.

for example, escaping single-quote is disallowed when "u" flag is set, and following case does no pattern matching, because of SyntaxError.

var input = document.getElementById("id_of_input");
input.pattern = "foo\\'bar";
input.value = "foo\\'bar";    // the input is not suffered
input.value = "baz";           // the input is not suffered (!)

IIUC, the flag for pattern attribute is changed at some point from "", and this may cause backward compatibility issue.
Also, it could be hard to figure out the regression, for web content authors, because the SyntaxError is not reported, according to the spec.

(this is originally reported to https://bugzilla.mozilla.org/show_bug.cgi?id=1227906)

[domenic]

I recognize the problem, but I personally at least think it is OK. Strange regexes now become more lenient, allowing some previously-invalid inputs to be submitted. This is not a big issue; client-side validation is in general easy to bypass, so making it more lenient in edge cases is not cause for concern. Nobody's app will fail to load if this change is made.

I think if there is a concern about web authors not figuring out the change, user agents should consider a console log when such SyntaxErrors occur.

[arai-a]

thanks, I agree that this change won't introduce critical issue.

then, are those error handling and informative message under the scope of the spec?
or is it all just an implementation detail?

[domenic]

In general dev console messages aren't something the spec mandates, but it might be a good idea to include a non-normative note suggesting it. I can work on that if we're all agreed.

[arai-a]

yeah, having the note in the spec would be nice :)

[zcorpan]

Would it be good to also send events when there's a SyntaxError? (error on the input; maybe also send to window.onerror)

[arai-a]

will it specify when to compile the pattern and send the error event?
for example, should the error be sent when opening the page, or on first input event? if latter, should it be sent on subsequent input events too?
if it does, in either case, I feel it's a bit overkill, to be honest.

IMO, showing informative console message, that is not visible to the script, is sufficient.

[zcorpan]

Probably when the attribute is set or changed, or the element is created with the attribute present. But yeah...

[smaug----]

FYI, there has been a backwards compatibility issue now
http://stackoverflow.com/questions/36953775/firefox-error-unable-to-check-input-because-the-pattern-is-not-a-valid-regexp

[annevk]

Reopening for further consideration.

[zcorpan]

@mathiasbynens' comment at http://stackoverflow.com/questions/36953775/firefox-error-unable-to-check-input-because-the-pattern-is-not-a-valid-regexp#comment61507597_36956352

The reason unnecessary escapes throw in u mode is so that the spec can later assign a special meaning to some of them, such as \p and \P. That would be a backwards-incompatible change if \p were equivalent to just p.

If we assume that we want to support u and other future regexp features, it seems to me we either need to power through (by shipping the current spec in more browsers), or revert pattern and mint a new pattern-u attribute.

[mathiasbynens]

See https://bugs.ecmascript.org/show_bug.cgi?id=3157 where it was decided to throw on invalid [a-zA-Z] IdentityEscapes in u mode.

I’d strongly prefer powering through for now, and helping the affected sites update their code through DevRel. If more breakage comes to light we can still reconsider.

[zcorpan]

Bugs to implement "u" flag for pattern:
https://bugs.chromium.org/p/chromium/issues/detail?id=535441
https://bugs.webkit.org/show_bug.cgi?id=151598
https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/7113940/

[mathiasbynens]

Support table with links to bugs for both u and u-for-pattern: https://mathiasbynens.be/notes/es6-unicode-regex#support

[domenic]

It seems people are powering through on shipping this. As predicted any back-compat issues are not actually problematic but are just letting some extra things pass client-side validation. So, re-closing.