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

[Zachary Ozer]

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