W3C home > Mailing lists > Public > public-html-bugzilla@w3.org > October 2010

[Bug 11011] Since Javascript does not support mode specifiers inside the regular expression, there is no simple way of matching a single word case-insensitively besides turning into [Ww][Oo][Rr][Dd]

From: <bugzilla@jessica.w3.org>
Date: Wed, 13 Oct 2010 00:50:15 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1P5pXr-0007QD-2K@jessica.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

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:30:59 UTC