Last call for consensus on format-control char. issues

David-Sarah Hopwood david-sarah at
Fri Jun 19 10:54:41 PDT 2009

Douglas Crockford wrote:
> John Cowan wrote:
>> David-Sarah proposes treating BOM in an identifier, string literal,
>> or other token as an error, since the intent is unclear (non-initial
>> BOMs shouldn't appear in properly formatted text any more, now that the
>> "zero-width separator" semantics has been taken over by U+2060 WORD
>> JOINER), and ignoring all other instances of BOM.  That seems like TRT
>> to me.
> The reality is that BOM is placed at the top of .js files by some text
> editors and that .js files get concatenated together to improve page
> startup times. The reality is that BOM in that context is whitespace.

My proposal works perfectly well for that case. When .js files are
concatenated, they are concatenated with one of the existing whitespace
characters between them. Otherwise the resulting file would look
obviously wrong in a way that a programmer would expect to have to fix:

file1 line1
file1 line2
file1 lineNfile2 line1
file2 line2

(where there is a <BOM> between "lineN" and "file2").

David-Sarah Hopwood  ⚥

More information about the es5-discuss mailing list