[whatwg] Clarifying the use and requirements of Data URL

[Peter Beverloo]

On Tue, Aug 24, 2010 at 17:49, Julian Reschke <julian.reschke at gmx.de> wrote:
>
> On 18.08.2010 15:21, Peter Beverloo wrote:
>>
>> Currently the specification requires the use of Data URLs for
>> canvas.toDataURL[1] and refers to usage of them a number of times as
>> well[2][3].  While steps describing how to generate a Data URL are
>> defined in the specification[4], they are not being referenced by the
>> other occurrences.  These steps seem to be identical to the contents
>> of RFC 2397[5], "The "data" URL scheme" by Larry Masinter.
>
> I raised <http://www.w3.org/Bugs/Public/show_bug.cgi?id=10399>, but it appears Ian thinks that not citing RFC 2397 is ok.
>
>> Next to that, the specification does not list when Data URLs should be
>> supported by an User Agent. WebKit, Gecko and Presto seem to accept
>> them as any resource, including locations entered via the address bar,
>> while Trident only accepts Data URLs for images and scripts.
>
> Yes. But there aren't requirements for other schemes as well, right?
>
>> I believe the use and requirements of Data URLs in the specification
>> could be clarified by:
>>   - Referring to RFC 2397 for information about their composition and
>> syntax *or* generalize the steps described in the form submission
>> algorithm[4], so they can be applied on the entire document.
>>   - Extend the accepted values of @src, @href, @action et al to
>> include support for data: URLs.
>> ...
>
> Why do you think @src, @href etc need to be extended for that?
>
> Best regards, Julian

Hi Julian,

Thank you for pointing me towards the bug report.  Referring to rfc
2397 would be one solution to generalizing the steps involved in
creating and/or parsing data: URLs, moving these steps out of the form
submission algorithm is another solution. Right now I think that it's
under-defined, as some places don't refer to anything else than the
name.

I've learned that data URLs could validate as unescaped path-rootless
IRIs, defined by rfc 3987[1]. Because of that any extension of the
attributes will not be required.

Best regards,
Peter Beverloo

[1] http://www.ietf.org/rfc/rfc3987.txt