Data uris, was: Re: Enable compression of a blob to .zip file

On 12/2/11 4:52 PM, Jonas Sicking wrote:
> On Fri, Dec 2, 2011 at 4:38 PM, Charles Pritchard<chuck@jumis.com>  wrote:
>> On 12/2/11 5:22 AM, Julian Reschke wrote:
>>> On 2011-11-30 19:42, Charles Pritchard wrote:
>>>> On 11/30/2011 8:04 AM, Julian Reschke wrote:
>>>>> On 2011-11-30 16:50, Charles Pritchard wrote:
>>>>>>> Nope. If you need gzipped SVG in data URIs, the right thing to do is
>>>>>>> to either extend data URIs to support that, or to mint a separate
>>>>>>> media type.
>>>>>>
>>>>>> Why? Seems like a lot of complexity for blob, data and file for
>>>>>> something that could otherwise be handled by minimal code.
>>>>>
>>>>> It would mean that the semantics of a data URI depends on who's
>>>>> processing it. It would probably also cause lots of confusion about
>>>>> what types is applies to.
>>>>
>>>> It's already the case that data URIs depend on UA quirks.
>>>
>>> There's no reason to add more quirks. Instead we should try to remove the
>>> quirks.
>>
>> This in no way changes the scheme of data URIs. Data uri quirks are mainly
>> about string length.
>> As far as I can tell, vendors are trying to move away from data uris and
>> toward blob uris.
> Just to clear something up. I have not heard anything about "vendors
> trying to move away from data uris".

I didn't mean it in the sense of retiring the protocol. The "URL", such 
as createObjectUrl and blob specs get around a lot of the issues present 
in data uris. The simple action of copying and pasting a data uri from 
the user-side is becoming more difficult.

There have been no steps to expand or otherwise support base64 encoding, 
nor data uris, from a higher level.

>> IE has string length issues;
> Bugs are in general not a sign of moving away from a technology. It's
> rather a sign that there isn't a comprehensive test suite that the
> vendor is using.
>
> And last I checked IEs length issues were a generic uri limitation.
> Nothing data-uri specific.


It's an intentional limitation, and though it's certainly not data-uri 
specific (neither are the string length limitations of webkit), they are 
absolutely and primarily an issue in the use of data uris. I don't think 
it's fair to call it a bug.


>> recently, Chrome started limiting paste into
>> address bar length, Firefox limited paste into address bar altogether.
> This is due to a recent rise of social engineering attacks which
> tricked users into pasting unknown contents into the URL bar. It might
> apply to to blob uris as much as data uris. Though given that blob
> uris still require script to be created, it isn't currently a problem.
> But this might change in the future.

Yes, that's exactly what Firefox reports, now. I wouldn't call this a 
bug. It's also an intentional limitation.

What motivations are there for Firefox to block user-copying of blob urls?


>> Webkit can not cope with data uris in any copy/paste text field (input
>> type=text / textarea) if they are more than ~20k and have no spaces.
> Again, just seems like a bug. Not a intended decision to move away
> from data uris.

And a third browser, out of the top three, where data uris are 
less-operable.
It's also intentional, for memory management in widgets.

All three of these cases are intentional. I wrote them out to support my 
statement that vendors are moving away from data uris, opposed to trying 
to support them in additional manners.

I'm sure everybody is hoping for blob urls and dataTransfer to continue 
to gain more features.

> Also, is webkit really parsing uri contents of text fields?? That
> seems like a big waste. Is this not just a limitation in number of
> characters pasted?

It's just a limitation of characters copied (not pasted).

> At least at mozilla we have in fact been moving in the opposite
> direction. Workers recently started supporting data uris and the new
> architecture for uri loading specifically tries to make data uris more
> consistently working.

There are some interesting semantics with blob and data uris in relation 
to file:/// and essentially anonymous / non-scoped origins.
Otherwise known as "null".

Within Webkit, it seems that blob url will not be supported in the null 
scope.

Browsers have various ways of handling what amounts to : iframe 
src="<meta refresh url(data:)>".

With Webkit, when you're working on file:///, you simply can't create 
blob urls, and so data uris are the only choice.

Otherwise though, I'd really recommend that people use blob uris. It 
would be nice to have  data uri to blob uri method.
btoa and atob are not meant for binary data.

I'll keep an eye on Mozilla and see how data uris and sharedworker scope 
and worker scopes operate.

-Charles

Received on Saturday, 3 December 2011 01:06:21 UTC