- From: <bugzilla@jessica.w3.org>
- Date: Wed, 10 Nov 2010 10:50:45 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11011
Maciej Stachowiak <mjs@apple.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mjs@apple.com
--- Comment #15 from Maciej Stachowiak <mjs@apple.com> 2010-11-10 10:50:43 UTC ---
(In reply to comment #9)
> Browsers aren't going to gate their implementation of next-gen JS features
> until the next JS spec is done, any more than they are going to gate their
> implementation of HTML features until HTML is done. :-)
>
> So I think the solution here is for us to at least try to see if browser
> vendors can implement this in their RegExp implementations before we add new
> attributes here. From a holistic point of view, it seems like the objectively
> better long-term solution.
>
JavaScript regexps take a case-insensitive flag that is not part of the regexp
per se. The syntax looks like this:
case sensitive regexp: /foobar/
case-insensitive regexp: /foobar/i
It's near-certain the /i flag won't become part of the JavaScript regexp syntax
as such (the Pattern production), since it is already provided for in the part
of the regexp syntax that is not the Pattern production.
That's regular expression literals, but the RegExp constructor also takes the
flags as a separate parameter, so there is very little chance of this being
added as part of the core pattern syntax there too.
One simple way to address this without adding a new HTML attribute, and still
deferring to ECMAScript, would be to allow the RegularExpressionLiteral
production as an alternative to the Pattern production.
--
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, 10 November 2010 10:50:46 UTC