- From: Zachary Ozer <zach@longtailvideo.com>
- Date: Tue, 13 Jul 2010 14:15:44 -0400
It think that offering some hinting makes sense. If the goal is to try and move away from plugins, giving a hint would allow browsers to display appropriate UI elements before the request is completed (in the case of PDF, something like the embedded Scribd controls). -- Zachary Ozer Developer, LongTail Video w: longtailvideo.com ? e: zach at longtailvideo.com ? p: 212.244.0140 ? f: 212.656.1335 JW Player | Bits on the Run | AdSolution On Tue, Jul 13, 2010 at 7:37 AM, Marques Johansson <marques at displague.com> wrote: > In one of the video related threads someone from Opera said that browsers > have a rough time trying to figure out how to intelligently handle video > content fetches. ?I think that a type suggestion, before the Content-type > could help a browser use a more optimal fetch behavior. > If the type of a resource is predefined then the browser can do a partial > request to fetch the meta data of the?alleged?file format and in the case of > a PDF perhaps the first few pages of content, leaving the rest to be loaded > on demand as the content is scrolled / paginated. ?I don't know if this is > really possible with the structure of PDF documents but there are certainly > some media types for which this could be applied. > I would think 'size' may be a partner attribute for hinting fetch behavior. > ?The browser doesn't want to have to make more than one request unless there > is good reason to do so. ?If the entire PDF is only one page long then a > meta data prefetch and continued fetch would be wasteful. ?However if the > filesize was 26mb then a meta data prefetch could indicate where partial > fetches should be made to acquire the 1mb of content that will actually need > to be displayed to the user immediately. ?If "type" is a reasonable > attribute to add to all of these elements I would think "size" should also > be considered. ?It wouldn't have to be accurate, Content-length would take > priority, but this attribute would serve for hinting purposes. > Perhaps some alternative could be found with a DOM solution. > > On Tue, Jul 13, 2010 at 3:45 AM, Gordon P. Hemsley <gphemsley at gmail.com> > wrote: >> >> On Tue, Jul 13, 2010 at 3:26 AM, Boris Zbarsky <bzbarsky at mit.edu> wrote: >> > On 7/12/10 11:31 PM, Gordon P. Hemsley wrote: >> >> >> >> The particular use case that prompted me to think about this is >> >> including a PDF via <iframe>. In Firefox (last I checked), one is >> >> required to install a separate add-on in order to support in-browser >> >> display of PDF files on Mac OS X, since there is no native or >> >> integrated >> >> Adobe Reader support available. >> > >> > I'm pretty sure you can install the Adobe Reader plug-in on Mac if you >> > want >> > to. >> >> Perhaps now, but that wasn't always the case?at least not for Firefox. >> I admit that my experience is somewhat outdated. Installing the >> third-party PDF viewer add-on is one of the first things I did, in a >> "set it and forget it" kind of way. (Plus, I'm still on Tiger.) >> >> But, again, the PDF example was just one possible use case. I'm sure >> there are plenty of other file types that cause similar situations, >> including the TIFF issue that I mentioned. >> >> >> Without the add-on, the user will be prompted to download the PDF file >> > >> > Which is exactly what would happen for a type="application/pdf" iframe, >> > no? >> > ?Silently not showing the content doesn't seem acceptable. >> > >> > -Boris >> > >> Well, the idea is to have the browser operate more intelligently than >> that. The page in the iframe is (by definition) not the primary >> document that the user is trying to load, so it shouldn't have the >> power steal the user's attention immediately upon page load. It would >> be very disorienting, and would likely cause the user to lose their >> train of thought. >> >> I was thinking more along the lines of Flashblock does or what happens >> when the window in an <iframe> can't load: The content would be >> replaced somehow by a message and a button/link to allow the user to >> manually download the contents of the iframe, if they so choose. It >> shouldn't make that decision for the user, as it's not the user's >> fault that their browser does not support the format of some ancillary >> document. >> >> At least, that's how I see it. >> >> Gordon >> >> -- >> Gordon P. Hemsley >> me at gphemsley.org >> http://gphemsley.org/ ? http://gphemsley.org/blog/ >> http://sasha.sourceforge.net/ ? http://www.yoursasha.com/ > >
Received on Tuesday, 13 July 2010 11:15:44 UTC