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

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

From: Henri Sivonen <hsivonen@iki.fi>
Date: Sun, 18 Nov 2007 23:17:38 +0200
Cc: "public-html@w3.org" <public-html@w3.org>
Message-Id: <75DCCB85-09B7-4545-A2EB-D4511A0ADE78@iki.fi>
To: Julian Reschke <julian.reschke@gmx.de>

On Nov 18, 2007, at 21:53, Julian Reschke wrote:

> Henri Sivonen wrote:
>> On Nov 18, 2007, at 20:54, Julian Reschke wrote:
>>> However, *what* is defined over there ("Note: This is a willful  
>>> double violation of RFC2046.") makes me nervous.
>> RFC 2046 was created with email legacy considerations in mind. The  
>> encoding rules there are not only unhelpful but downright harmful  
>> in the contemporary HTTP context with UTF-8 decoding readily  
>> available.
>> The Web needs a text/5 spec.
>
> That may be true, but then take that to the relevant standards body,  
> instead of simply violating a spec on purpose. This seems to follow  
> a pattern of "we ignore what the specs do, we can do better" with  
> which I Strongly disagree.
>
> If a base spec needs fixes, fix it.

I'm all for someone fixing the RFC, but in the interim it isn't  
productive to pretend that the RFC properly defined what needs to be  
implemented to get useful software.

> If you don't like the defaults for a text/* format, use application/*.

Has the migration from text/xml to application/xml been a productive  
use of humanity's resources? Wouldn't it have been more productive to  
redefine text/xml to have the same rules as application/xml, which is  
what non-validator apps have to implement anyway?

>>> (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 CARRIAGE RETURN  
>> (CR) U+000A LINE FEED (LF) pairs."
>
> 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/

> 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()

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/
Received on Sunday, 18 November 2007 21:17:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:09 GMT