Re: Enable compression of a blob to .zip file

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".

> 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.

> 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.

> 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.

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?


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.

/ Jonas

Received on Saturday, 3 December 2011 00:53:46 UTC