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

mkruisselbrink commented on this pull request.



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

Done

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

done

>  </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"}},

Done

> +
+    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,

Yeah, I didn't like that sentence structure either, but wasn't quite sure what clause to use otherwise. You're suggestion works, thanks.

> +    {{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.

Agreed that the shorter variant is clear enough, and seems to match what infra suggests. Added here, which I believe was the only place I was missing the name.

> +
+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,

Added an otherwise.

> +  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:

Not sure about that. It's only used twice (at least with the Otherwise added below, else it would only be referenced once) so I don't think we gain much by adding a temporary local variable.

> +1. While |position| is not past the end of |s|:
+
+  1. If the [=code point=] at |position| within |s| equals U+000D CR
+    and the [=code point=] at |position|+1 within |s| equals U+000A LF,
+    advance |position| by 2 and append |native line ending| to |result|.
+
+  1. If the [=code point=] at |position| within |s| equals U+000A LF,
+    advance |position| by 1 and append |native line ending| to |result|.
+
+  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. Return |result|.

Okay, I think I'll leave it for future cleanups to decide what might make sense to move into infra.

-- 
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#discussion_r154026819