- From: <bugzilla@jessica.w3.org>
- Date: Wed, 13 Oct 2010 00:50:15 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11011 --- Comment #7 from Jonas Sicking <jonas@sicking.cc> 2010-10-13 00:50:14 UTC --- > 1. Drop the requirement that the regular expression must match the entire > value, and let HTML author write a complete Javascript regex in the pattern > attribute. This is probably the easiest route to take that fixes the problem. > (There are probably reasons behind the "match entire value"-policy that I fail > to see) The problem here is that it's very unintuitive to not use the "match entire value" policy. For example if you want to enforce a US phone number, the pattern \d\d\d-\d\d\d-\d\d\d\d is incorrect, as it would match "hi all, i have several phone numbers, my home phone is 555-1234, but my cell phone is 415-555-4711". Regexps are generally designed for searching, i.e. to find a substring within a bigger string. This makes them designed for being generally inclusive. What we want is something that enforces that something uses a particular pattern, i.e. we want to err on the side of being exclusive. If we didn't use the "match enture value" policy, almost everyone would have to write patterns like "^stuff here$", and many would forget leading to bad user experience. > 3. Try to enforce a change in Javascript's regular expression syntax to > support inline mode specifiers, even for parts of a regular expression (it > really doesn't make sense only to allow setting an inline mode specifier for > the whole regex). This is probably a lot of bureaucratic work, but would also > have other positive side effects. This would likely take a looooong time and not be fully standardized until harmony is released (years away). It'd be nice to do this as well, since as you notice it'd be nice to be able to match some parts case insensitively and some parts case sensitively. But I'd rather not wait for that. > 4. Delegate this functionality to scripting. Won't require a change to > existing implementations. (This is the "ignore the issue, hope I go > away"-alternative) If we do this then we likely want to make ignore-case the default behavior. That is probably more commonly useful. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Wednesday, 13 October 2010 00:50:16 UTC