On Fri, Dec 2, 2011 at 5:05 PM, Charles Pritchard <ch...@jumis.com> wrote: > On 12/2/11 4:52 PM, Jonas Sicking wrote: >> >> On Fri, Dec 2, 2011 at 4:38 PM, Charles Pritchard<ch...@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.
So what specifically do you mean by "trying to move away from data uris"? "move away" generally involves taking an action. You seem to be using some alternative meaning? > There have been no steps to expand or otherwise support base64 encoding, nor > data uris, from a higher level. What do you mean by this? base64 encoding has been supported in datauris as long as data uris have been supported, and base64 encoding in general has been supported far longer than that. >>> 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. Indeed, but in the context you were using this it sounded like you were saying that this was an active step taken by IE. The limitation has always been there. >>> 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? If/when we get to a point when blob-uris can be used to launch social engineering attacks I don't see why we wouldn't block it. This could for example happen if websites start running untrusted code in the context of their origin, for example using technologies like Caja. >>> 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. "failing to move towards data uris at the speed you like" is not the same as "moving away from data uris". Additionally "having limitations on string lengths in various situations" is not the same as "intentionally limiting data uris". > 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). Holy crap man, why on earth would you express this as a limitation in pasting data uris then?? You are bordering on FUD here. Please stop. >> 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". Again, not adding support for data uris at the speed you want is not the same as moving away from data uris. > Within Webkit, it seems that blob url will not be supported in the null > scope. What data do you have for "will not be supported" rather than "is currently not supported"? / Jonas
