data: URL generator

[annevk]

#579 defines a processor, but it seems that HTML at least could use a generator for canvas's toDataURL().

I guess this needs to accept a MIME type and a bag of bits and maybe a base64 flag.

[foolip]

As a concept, or also as a web-exposed API?

[annevk]

Just a concept (for now anyway). The API is toDataURL().

[guest271314]

Does FileReaders .readAsDataURL() not generate expected result?

[annevk]

That's another API that'll need this primitive.

[guest271314]

What are the expected parameters? Blob, File, FormData, TypedArray, and plain text? Is the function synchronous or asynchronous?

[foolip]

Since it's an internal concept and not an API, it would presumably be just a mime type, the bytes of the body, and possibly an "use base64" flag.

[guest271314]

If the concept is internal why would a MIME type need to be passed?

[foolip]

The mime type is part of the output (a data: URL) so if no mime type is given, well what would the output be?

[guest271314]

If the processing is internal the processor should determine the correct MIME type

[guest271314]

For example, users will undoubtedly attempt to convert "audio/ogg" to "audio/mp3" or "image/jpg" to "image/png" using toDataURL(). The processor itself should be capable of determining the correct MIME type of the input - or if the input is not possible of being converted into a valid data URI; for example, a media fragment URI which is capable of being played at an HTMLMediaElement, though does not contain the necessary metadata to be played after converting to a valid data URI.

[annevk]

No, the data: URL generator should just encode the input and not apply MIME type-specific processing. Then it would no longer be generic. It's given a MIME type because data: URLs contain a MIME type in their representation.

[foolip]

@guest271314 This is a much smaller thing that. In the case of https://html.spec.whatwg.org/multipage/canvas.html#dom-canvas-todataurl, it's to replace step 5, simply taking the same information that is now in file and producing a canonical data: URL from it. The (small) problem right now is that "a data: URL representing file" isn't very clear about what the data: URL should look like, byte-for-byte. And it should be. That's all.

[guest271314]

Then the validity of the output is not a concern of this processor?

[guest271314]

Not gathering why a MIME type would be passed as argument if actually irrelevant to the processor?

[guest271314]

Perhaps the mention of MIME type is being misinterpreted. The inquiry is as to how the MIME type is derived from the input, not specific processing for a given MIME type the is either passed the to toDataURL() or determined by the algorithm.

If the processor algorithm determines the MIME type of the input file there is no reason for a MIME type to be passed as argument to toDataURL().

[annevk]

I recommend reaching out on IRC to clear up the confusion.

[domenic]

https://w3c.github.io/FileAPI/#readAsDataURL also appears to need this, although it's rather under-specified. (E.g., does the base64 parameter get used??)

[annevk]

Yeah, that was noted in #665 (comment). I wonder if @mkruisselbrink has done some testing on that.

[mkruisselbrink]

Yeah, that was noted in #665 (comment). I wonder if @mkruisselbrink has done some testing on that.

Nothing specifically, no. But indeed having some hooks to call out to from the FileAPI spec to better define this would be great.