Re: [w3c/FileAPI] Add BlobPropertyBag.endings back to the spec. (#90)

inexorabletash commented on this pull request.



> @@ -230,8 +231,11 @@ interface Blob {
             optional DOMString contentType);
 };
 
+enum EndingTypes {"transparent", "native"};

nit: whitespace inside { } (from a survey of other specs)

>  
   <dt id="dfn-BlobPropertyBagMembers">An *optional* {{BlobPropertyBag}}
-  <dd>which takes one member:
+  <dd>which takes two members:

Maybe "these optional members" ?

>  </dl>
 
+<div algorithm="process-blob-parts">
+To <dfn lt="process blob parts|processing blob parts">process blob parts</dfn> given a sequence of {{BlobPart}}'s |parts|
+and {{BlobPropertyBag}} |options|,
+run the following steps:
+
+1. Let |bytes| be an empty sequence of bytes.
+
+1. For each |element| in |parts|:
+
+  1. If |element| is a {{USVString}}, run the following substeps:
+
+    1. Let |s| be |element|.
+
+    1. If the {{BlobPropertyBag/endings}} member of |options| is set to {{"native"}},

nit: I think "set" is a verb in spec language, so "is set to" is used during initialization, not testing. Could just be `|options| is {{"native"}}` here.

> +
+    Note: The {{Blob/type}} of the {{Blob}} array element is ignored and will not affect {{Blob/type}} of returned
+    {{Blob}} object.
+
+1. Return |bytes|.
+
+</div>
+
+<div algorithm="convert-line-endings-to-native">
+To <dfn lt="convert line endings to native|converting line endings to native">
+convert line endings to native</dfn> in a [=string=] |s|,
+run the following steps:
+
+1. Let |native line ending| be be the [=code point=] U+000A LF.
+
+1. If it matches the underlying platform's conventions,

"it" reads ambiguously here in English (in a naive reading it refers to the previous step's context)

Better would be something phrased as: "If the underlying platform's conventions are ... then ... "

(And the clause might be "to represent newlines as a carriage return and line feed sequence" but I'm more concerned about the sentence structure)



> +    {{Blob}} object.
+
+1. Return |bytes|.
+
+</div>
+
+<div algorithm="convert-line-endings-to-native">
+To <dfn lt="convert line endings to native|converting line endings to native">
+convert line endings to native</dfn> in a [=string=] |s|,
+run the following steps:
+
+1. Let |native line ending| be be the [=code point=] U+000A LF.
+
+1. If it matches the underlying platform's conventions,
+  set |native line ending| to the [=code point=] U+000D CR
+  followed by the [=code point=] U+000A.

nit: Previous line has `U+000D CR` but this line has only `U+000A`

https://infra.spec.whatwg.org/#code-points says to use the name when it's not printable.

Super nitpicky: per http://www.unicode.org/charts/PDF/U0000.pdf it would be **U+000D CARRIAGE RETURN (CR)** and **U+000A LINE FEED (LF)** although Infra itself just uses LF

> +  followed by the [=code point=] U+000A.
+
+1. Set |result| to the empty [=string=].
+
+1. Let |position| be a [=position variable=] for |s|,
+  initially pointing at the start of |s|.
+
+1. Let |token| be the result of [=collecting a sequence of code points=]
+  that are not equal to U+000A LF or U+000D CR
+  from |s| given |position|.
+
+1. Append |token| to |result|.
+
+1. While |position| is not past the end of |s|:
+
+  1. If the [=code point=] at |position| within |s| equals U+000D CR:

Subsequent steps would be simpler if you assign a local variable (e.g. _cp_) to _code point at position within s_

> +
+1. Append |token| to |result|.
+
+1. While |position| is not past the end of |s|:
+
+  1. If the [=code point=] at |position| within |s| equals U+000D CR:
+
+    1. Append |native line ending| to |result|.
+
+    1. Advance |position| by 1.
+
+    1. If |position| is not past the end of |s|
+      and the [=code point=] at |position| within |s| equals U+000A LF
+      advance |position| by 1.
+
+  1. If the [=code point=] at |position| within |s| equals U+000A LF,

Needs an "Otherwise" (or to handle position being past the end)


-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/FileAPI/pull/90#pullrequestreview-79958983