15904 2012-02-05 18:17:47 +0000 pattern attribute does not clarify the reserved characters, nor the escape character, if any 2012-05-08 00:13:37 +0000 1 1 1 Unclassified HTML WG HTML5 spec unspecified Other other RESOLVED WONTFIX http://www.whatwg.org/specs/web-apps/current-work/#top P3 normal --- 1 contributor ian dave ian lrosenth mike public-html-admin public-html-wg-issue-tracking sun public-html-bugzilla oldest_to_newest 63722 0 contributor 2012-02-05 18:17:47 +0000 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 64884 1 dave 2012-03-02 05:51:18 +0000 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. 64892 2 sun 2012-03-02 10:19:27 +0000 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 67444 3 ian 2012-05-08 00:13:37 +0000 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.