Maciej Stachowiak [EMAIL PROTECTED] wrote on 14/07/2008 22:32:02:
On Jul 14, 2008, at 1:46 PM, Mike Shaver wrote:
On Mon, Jul 14, 2008 at 4:37 PM, Mike Cowlishaw [EMAIL PROTECTED]
wrote:
(The decNumber code is quite stable, for example -- averaging fewer
than one
detected bug/year
On Mon, Jul 14, 2008 at 8:45 AM, Mike Shaver [EMAIL PROTECTED] wrote:
On Fri, Jul 11, 2008 at 7:10 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote:
[...] For example, would Rhino and SpiderMonkey count as
sufficiently independent implementations?
Similarly, if we end up with, f.e., both
The currently proposed rule for byte-order-mark (BOM) characters in
ES4 sources is to replace them by whitespace outside of tokens. But
what is exactly the tokens in a case like -bom-?
AFAICS it would be treated as - - turning cases like:
-bom-a;
into
- -a;
versus
--a;
that would be with
On 15 Jul 2008, at 18:39, Ash Berlin wrote:
On 15 Jul 2008, at 18:22, Igor Bukanov wrote:
The currently proposed rule for byte-order-mark (BOM) characters in
ES4 sources is to replace them by whitespace outside of tokens. But
what is exactly the tokens in a case like -bom-?
AFAICS it
On Tue, Jul 15, 2008 at 11:00 AM, Igor Bukanov [EMAIL PROTECTED] wrote:
2008/7/15 Ash Berlin [EMAIL PROTECTED]:
I'd say that a BOM should be treated just like any ordinary whitespace
char - namely that it should invalid in spaces, and beyond that why is
any conversion needed, since its a
Igor Bukanov wrote:
It seems the current IE7/IE8 behavior is to allow Cf only in srtring
and regexp literals and to allow BOM only in string/regexps or at the
beginning of the source,
Precisely what does in string and regexp literals mean? The exact
interpretation of this phrase is the core
