W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2012

[Bug 19003] New: Bugs in toNativeLineEndings()

From: <bugzilla@jessica.w3.org>
Date: Tue, 25 Sep 2012 07:40:55 +0000
To: public-webapps@w3.org
Message-ID: <bug-19003-2927@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=19003

           Summary: Bugs in toNativeLineEndings()
           Product: WebAppsWG
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: File API
        AssignedTo: arun@mozilla.com
        ReportedBy: simonp@opera.com
         QAContact: public-webapps-bugzilla@w3.org
                CC: public-webapps@w3.org


https://www.w3.org/Bugs/Public/show_bug.cgi?id=16733
http://dev.w3.org/2006/webapi/FileAPI/#convenienceAPI

The IDL should say:

Window implements LineEndings;
WorkerGlobalScope implements LineEndings;

And remove this:
[[
In environments where the global object is represented by a Window or
WorkerGlobalScope object, the toNativeLineEndings method should be available.
]]

(assuming we want this in the global scope)

The algorithm seems bogus. It seems to assume that there will only be one "line
ending" and that it is at the end of the string. It doesn't define what a "line
ending" is. "Expected by the underlying platform" also seems unclear. It seems
unexpected that this methods *adds* a line ending if there isn't one.

I would have expected that this method does this:

function toNativeLineEndings(string) {
  ...snip impl of WebIDL voodoo here...
  return string.replace(/(\r\n|\r|\n)/g, nativeLineEnding);
}

As for spec language, I would probably do this:

1. Let /input/ be /string/.
2. Let /position/ be a pointer into /input/, initially pointing at the start of
the string.
3. Let /lines/ be an empty array.
4. While /position/ is not past the end of /input/:
    1. Collect a sequence of characters that are not U+000A or U+000D.
    2. Add the string collected in the previous step to /lines/.
    3. If the character at /position/ is U+000D, and the character at
/position/+1 is U+000A, advance /position/ by two characters. Otherwise,
advance /position/ to the next character.
5. Let /native line ending/ be a sequence of characters that represent a line
ending according to the underlying platform's conventions, or U+000A if there
is no particular convention. [issue: should we only allow \n and \r\n here?]
6. Let /output/ be the result of joining /lines/ with /native line ending/.
7. Return /output/.

where "collect a sequence of characters" is defined here:
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-microsyntaxes.html#collect-a-sequence-of-characters

or here: http://dom.spec.whatwg.org/#collect-a-sequence-of-characters

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
Received on Tuesday, 25 September 2012 07:41:45 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:54 GMT