Bug 15904 - pattern attribute does not clarify the reserved characters, nor the escape character, if any
Summary: pattern attribute does not clarify the reserved characters, nor the escape ch...
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML5 spec (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://www.whatwg.org/specs/web-apps/...
Depends on:
Reported: 2012-02-05 18:17 UTC by contributor
Modified: 2012-05-08 00:13 UTC (History)
7 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description contributor 2012-02-05 18:17:47 UTC
Specification: http://dev.w3.org/html5/spec/Overview.html
Multipage: http://www.whatwg.org/C#top
Complete: http://www.whatwg.org/c#top

On: The pattern attribute (forms)

The spec does not clarify what the reserved characters of the regular
expressions are, and what the escape character is, nor whether there is any.

The pattern attribute value example ("[0-9][A-Z]{3}") is a trivial one.

But what if the pattern value contains a forward-slash?

Is it:	  <input pattern="[0-9]/[A-Z]{3}" name="part" />

Or is it: <input pattern="[0-9]\/[A-Z]{3}" name="part" />

Are user agents supposed to escape reserved characters in the expression
before compiling it?  And if so, how can that work reliably across

As the pattern also needs to be validated on the server-side, and the
server-side also uses regular expressions, the same question exists there.  It
actually turns into a problem, as it's not clear who's responsible for
escaping characters in the regular expression, and which reserved characters,
if any, actually need to be escaped.

Reply-To: sun@unleashedmind.com
Cause: http://drupal.org/node/1174766

Posted from:
User agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv: Gecko/20101203 Firefox/3.6.13
Comment 1 Dave Reid 2012-03-02 05:51:18 UTC
I would greatly prefer that the spec be modified to assume that the pattern must be formatted in PRCE format since that seems to be the most universally supported syntax for regex patterns. I know that Google Chrome is fine having escaped characters, so I would really prefer this to be defined in the specification.
Comment 2 sun 2012-03-02 10:19:27 UTC
Further debugging by Dave Reid revealed that

    <input type="text" pattern="[0-9]/[0-9]" />

matches the string '0/0' even though the forward slash is not escaped.  However,

    <input type="text" pattern="[0-9]\/[0-9]" />

*also* succeeds to match the string '0/0'.  Hence, '/' does not seem to be the regular expression's delimiter (in some browser implementations).

Testing this on


seems to confirm that '/' is not the reserved expression delimiter.  It also seems to confirm that '\' is the escape character.

So the problem remains to be that we need to know what the expression delimiter is, in order to actually perform and ensure proper escaping of that character in the regular expression.

See: http://stackoverflow.com/questions/9526814/what-is-a-safe-pcre-regex-delimiter-to-use-on-html5-pattern-input-element-attrib
Comment 3 Ian 'Hixie' Hickson 2012-05-08 00:13:37 UTC
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:

Status: Rejected
Change Description: no spec change
Rationale: As far as I can tell this is already defined. The spec says "the attribute's value must match the JavaScript Pattern production". So it's up to the JS spec.