Re-allow consecutive, leading and trailing dots in EMAIL_REGEXP #189
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
osyoyu
force-pushed
the
restore-whatwg-email-regexp
branch
from
4bc6c3d to
a1770c3
Compare
osyoyu
force-pushed
the
restore-whatwg-email-regexp
branch
from
a1770c3 to
0c5c1f3
Compare
osyoyu
changed the title
osyoyu
force-pushed
the
restore-whatwg-email-regexp
branch
from
9a089d2 to
53f8b74
Compare
Contributor
Author
|
Edited. |
Effectively reverts commit 788274b and 0abac72. EMAIL_REGEXP was mostly drawn from WHATWG HTML LS. This spec states that it intentionally violates RFC 5322 to provide a practical regex for validation. > This requirement is a willful violation of RFC 5322, which defines a > syntax for email addresses that is simultaneously too strict (before the > "@" character), too vague (after the "@" character), and too lax > (allowing comments, whitespace characters, and quoted strings in manners > unfamiliar to most users) to be of practical use here. The allowing of consecutive dot s(`a..a@`) and leading/trailing dots (`.a@`, `a.@`) is not the only derivation from RFC 5322. If a truly RFC 5322-compliant regexp is needed, tt should be organized under a different name, since too much departure from the original EMAIL_REGEXP must be introduced.
osyoyu
changed the title
osyoyu
force-pushed
the
restore-whatwg-email-regexp
branch
from
53f8b74 to
c551d70
Compare
sorah
approved these changes
Nov 4, 2025
Member
|
Bit hesitant to cut into this issue without waiting people involved in the original pull request, but merging this as the issue appears to have major impact. |
Member
|
While minor release (increment of Y in X.Y.Z) may have a breaking change, it must be well communicated - and the comment says it is based on WHATWG practical pattern, disallowing the email addresses in question can be considered a bug/regression. The comment on the constant mentions WHATWG even in 1.1.0, there's no doubt that this is a bug. |
Contributor
Author
|
Thank you! |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Effectively reverts commit 788274b and 0abac72.
EMAIL_REGEXP was mostly drawn from WHATWG HTML LS. This spec states that it intentionally violates RFC 5322 to provide a practical regex for validation.
The allowing of consecutive dot s(
a..a@) and leading/trailing dots (.a@,a.@) is not the only deviation from RFC 5322. If a truly RFC 5322-compliant regexp is needed, it should be organized under a different name, since too much departure from the original EMAIL_REGEXP must be introduced.