Last call for consensus on format-control char. issues
david-sarah at jacaranda.org
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 lineNfile2 line1
(where there is a <BOM> between "lineN" and "file2").
David-Sarah Hopwood ⚥ http://davidsarah.livejournal.com
More information about the es5-discuss