[whatwg] Proposal: @srctype or @type on <iframe>

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/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100713/263d9b00/attachment.htm>

Received on Tuesday, 13 July 2010 04:37:04 UTC