Repository navigation
data: URL generator #665
Description
Activity
As a concept, or also as a web-exposed API?
Just a concept (for now anyway). The API is
toDataURL().Does
FileReaders.readAsDataURL()not generate expected result?That's another API that'll need this primitive.
What are the expected parameters?
Blob,File,FormData,TypedArray, and plain text? Is the function synchronous or asynchronous?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.
If the concept is internal why would a MIME type need to be passed?
The mime type is part of the output (a data: URL) so if no mime type is given, well what would the output be?
If the processing is internal the processor should determine the correct MIME type
For example, users will undoubtedly attempt to convert
"audio/ogg"to"audio/mp3"or"image/jpg"to"image/png"usingtoDataURL(). 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 validdata URI; for example, a media fragment URI which is capable of being played at anHTMLMediaElement, though does not contain the necessary metadata to be played after converting to a validdata URI.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.
@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.
Reacted by Anne van KesterenThen the validity of the output is not a concern of this processor?
Not gathering why a MIME type would be passed as argument if actually irrelevant to the processor?
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().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??)
Yeah, that was noted in #665 (comment). I wonder if @mkruisselbrink has done some testing on that.
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.
#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.