On 25 May 2017 at 17:02, Mark S. Miller wrote:
> Allen, I'm very glad to hear that it is unambiguous after all.
>
Gareth, could you file bugs against the non-conforming browsers? Thanks for
> finding this!
>
Yeah sure I'll file the bugs now.
Allen, I'm very glad to hear that it is unambiguous after all.
Gareth, could you file bugs against the non-conforming browsers? Thanks for
finding this!
On Thu, May 25, 2017 at 8:58 AM, Allen Wirfs-Brock
wrote:
> clause 10.1:
>
> ECMAScript code is expressed using
clause 10.1:
ECMAScript code is expressed using Unicode. ECMAScript source text is a
sequence of code points. All Unicode code point values from U+ to U+10,
including surrogate code points, may occur in source text where permitted by
the ECMAScript grammars.
Subject: Re: Unicode non-character being treat as space on Firefox/Chrome
On 25 May 2017 at 14:04, Mark S. Miller
<erig...@google.com<mailto:erig...@google.com>> wrote:
What is the relevant EcmaScript standards text that would delegate to this?
Even if Unicode implies an undefined
On 25 May 2017 at 14:04, Mark S. Miller wrote:
> What is the relevant EcmaScript standards text that would delegate to
> this? Even if Unicode implies an undefined case, EcmaScript should not. If
> EcmaScript behavior for such cases is undefined, we should define it.
>
I believe that Unicode specification make it undefined behaviour.
In effect, noncharacters can be thought of as application-internal
private-use code points. Unlike the private-use characters discussed in
Section 16.5, Private-Use Characters, which are assigned characters and
which are intended
Hi all
Not sure if this is a bug or not. Non-character is being treated as a space
even though it's not defined as one. Edge and Safari treat it as an invalid
character.
```javascript
�alert�(1)�
```
In case the characters get mangled:
```javascript
7 matches
Mail list logo