This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: http://dev.w3.org/html5/spec/Overview.html Multipage: http://www.whatwg.org/C#top Complete: http://www.whatwg.org/c#top Comment: 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 implementations? 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: 91.19.60.83 User agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.13) Gecko/20101203 Firefox/3.6.13
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.
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 http://html5pattern.com/#t=Expression%20delimiter&a=sun&d=1/1/1/1.1%5B1%5D1%5C%20and%201/1/121.1%5B1%5D1%5C%20might%20pass.%20The%20escape%20character%20seems%20to%20be%20%5C%2C%20but%20/%20is%20not%20the%20regex%20delimiter.%20What%27s%20the%20delimiter%3F&ta=&p=1/1%5C/1.1%5C.1%5C%5B1%5C%5D1%5C%5C 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
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: http://dev.w3.org/html5/decision-policy/decision-policy.html 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.