Document BlobPropertyBag "endings", or keep pushing to remove?

[inexorabletash]

https://jsfiddle.net/422r7n3z/ - exercises new Blob([s], {endings:e}).size

On Windows, in Chrome/Firefox:
transparent + "abc\r\n" = 5
transparent + "abc\n" = 4
transparent + "abc\r" = 4
native + "abc\r\n" = 5
native + "abc\n" = 5
native + "abc\r" = 5

On Windows, in IE11:
transparent + "abc\r\n" = 5
transparent + "abc\n" = 4
transparent + "abc\r" = 4
native + "abc\r\n" = 5
native + "abc\n" = 4
native + "abc\r" = 4

On OSX and Linux, in Chrome/Firefox/Safari:
transparent + "abc\r\n" = 5
transparent + "abc\n" = 4
transparent + "abc\r" = 4
native + "abc\r\n" = 4
native + "abc\n" = 4
native + "abc\r" = 4

(I have not tested Opera or Edge; I assume those match Chrome and IE11)

Note that all 4 browsers - including IE which does not appear to respect the option otherwise - throw if an invalid option is passed as endings.

I gathered usage stats in Chrome stable: https://www.chromestatus.com/metrics/feature/timeline/popularity/1320 - it's 0% to several significant figures (people running web-platform-tests would account for the absolute #s).

Should we proceed with removing, or does anyone want to advocate for keeping it? @smaug----, @foolip, @aliams, .... ?

[aliams]

I can confirm that Edge has the same results as IE11. Do you happen to know what the use case for this was?

[inexorabletash]

I don't know what use cases were discussed. (Could dig, but don't know offhand.)

Also, note that I didn't test reading the blob back to see if e.g. any browser morphs \r into \n; (inspecting the WebKit source it might...?)

[smaug----]

There are some use cases, like creating blob and then let user download it and have the right kind of file.
But I don't know the history behind the property, and
https://bugzilla.mozilla.org/show_bug.cgi?id=721569 doesn't help with that either. That bug hints that the property was in the spec for some time, or was supposed to be added, but dunno what has happened.
I don't advocate keeping it, but before removing it from Gecko, I'd like to understand why it was added and why it isn't in the spec.

[mkruisselbrink]

For what it's worth https://www.w3.org/TR/2012/WD-FileAPI-20120712/#dfn-BlobPropertyBag seems to be the last version of the spec endings was defined in. The next WD of the spec three months later doesn't have it anymore.

[mkruisselbrink]

And https://www.w3.org/Bugs/Public/show_bug.cgi?id=16733 is where its removal was discussed it seems.

[mkruisselbrink]

And apparently "endings" was added because BlobBuilder in the File Writer spec had it (https://dev.w3.org/2009/dap/file-system/file-writer.html#widl-BlobBuilder-append-void-DOMString-text-DOMString-endings), although even there it already had a note wondering if endings was really needed...

[foolip]

Given the extremely low usage and that it seemingly doesn't actually work in IE/Edge, I won't argue for keeping this :)

[annevk]

The bug @mkruisselbrink seems to discuss all the details @smaug---- cares about. Did we ever introduce the alternative API and is that widely supported? The main use case is making sure text is rendered properly in the user's platform of choice.

[inexorabletash]

No, we never introduced the alternative API

[smaug----]

@bakulf wanted to follow the spec here[1], but I'm not ready to make the change to Gecko yet given that 3 out of 4 browsers already support this. Shouldn't we just spec the reality?

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1321541

[foolip]

@inexorabletash, what's your preference here?

[inexorabletash]

No strong preference from me. Specing reality (and adding a test) might help Edge make the fix. On the other hand, the usage and it's not an ideal API to begin with. But removing it without a replacement will lead to using navigator.platform. But if usage is that low maybe that's what everyone is already doing.

Sorry, I'm a waffle.

[foolip]

There must be lots of ways to create files in-memory for download, like <a href="data:text/plain,..." download>. In such cases, I guess people are using some other way to pick line ending style?

I also have no strong preference really, but if there is no appetite for removal then I suppose defaulting to what a majority of implementations already do is a good default.