W3C home > Mailing lists > Public > public-html@w3.org > November 2007

Re: Feedback on "Offline Web Applications" (Editor's Draft 17 November 2007)

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 19 Nov 2007 02:02:13 -0800
Cc: Henri Sivonen <hsivonen@iki.fi>, "public-html@w3.org" <public-html@w3.org>
Message-Id: <97AA42DD-45FF-4BCC-99A6-445975A00032@apple.com>
To: Julian Reschke <julian.reschke@gmx.de>

On Nov 19, 2007, at 12:31 AM, Julian Reschke wrote:

>>>>> (CR only as line delimiter???)
>>>> Quoting the draft:
>>>> "Newlines must be represented by U+000A LINE FEED (LF)  
>>>> characters, U+000D CARRIAGE RETURN (CR) characters, or U+000D  
>>> Yep, that's what I meant. Why invent a new text format that has  
>>> line ending rules other than others?
>> LF, CR and CRLF being all valid line breaks is consistent with XML,  
>> HTML, CSS and the way text/plain is actually implemented in browsers.
>> Demos: http://hsivonen.iki.fi/test/moz/linebreak/
> That seems to contradict <http://www.w3.org/TR/REC-xml/#sec-line- 
> ends>:
> "To simplify the tasks of applications, the XML processor  MUST  
> behave as if it normalized all line breaks in external parsed  
> entities (including the document entity) on input, before parsing,  
> by translating both the two-character sequence #xD #xA and any #xD  
> that is not followed by #xA to a single #xA character."

The text you quote appears to treat all three of LF, CR, and CR LF  
pairs as line breaks, by normalizing them all to LF. This appears to  
agree with what Henri said, rather than contradicting it.

> So, what is the perceived problem here? People writing manifest  
> files in a Mac text editor pre-OSX????
>>> Did anybody consider how well this works with existing language  
>>> libraries for reading text streams?
>> This approach works great with e.g. the readLine method in Java  
>> BufferedReader:
>> http://java.sun.com/j2se/1.4.2/docs/api/java/io/BufferedReader.html#readLine()
> But not with things like InputStreamReader, right? So sorry, I still  
> believe that the requirement to support single CRs introduces  
> completely useless complexity. (As the introduction of a new text- 
> based format anyway.)

For browser-hosted implementations, it's easier if newline rules are  
consistent between different text-based formats. This argues for  
allowing CR in this format.

Received on Monday, 19 November 2007 10:02:30 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:28 UTC