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

[Ian Hickson]

On Tue, 13 Jul 2010, Gordon P. Hemsley wrote:
> 
> There a number of attributes that are designed to give the user agent a 
> preview of what MIME type to except for referenced resource. (And there 
> are also attributes like @hreflang that preview other things.) And yet, 
> <iframe>, which has to load a full document, has no ability to allow the 
> user agent to determine compatibility.
> 
> Thus, I propose doing one of the following:
> (1) add @srctype to <iframe>
> (2) extend the meaning of @type that applies to <a>, <area>, and <link> to
> apply to <iframe>, as well
> 
> I'm more inclined to believe that option (2) is the better option.

What problem would this solve? User agents fetch anything specified in an 
<iframe>; are you proposing we change that?


> It should not be assumed that whatever resource included via <iframe> is 
> going to be of type 'text/html' or another easily parsable type. Thus, 
> it could be helpful for the author to give the user agent a hint as to 
> what type of document it is requesting be displayed inline, and allow 
> the user agent to choose not to display the contents of the <iframe> if 
> it feels it cannot support it.
> 
> 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. Without the add-on, the user will be 
> prompted to download the PDF file, which can be very disconcerting if 
> the user wasn't even expecting a PDF file. And I'm sure there are plenty 
> of other instances where this same situation occurs. (TIFF files, 
> perhaps? Like on the U.S. Patent Office's website?)
> 
> Now, I'm not a spec implementor by any means, but I am a web author and 
> a web user, so I've been on both sides of this issue. And it doesn't 
> appear that it would be too complicated to extend the existing support 
> of @type.

Surely a better solution is to make files that would be downloaded simply 
display an inline prompt (rather than a pop-up prompt) in this case.


On Tue, 13 Jul 2010, Gordon P. Hemsley wrote:
>
> 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.

It seems that if browsers wanted to do that, they could do it today using 
the information from the Content-Type header. The type="" attribute would 
only allow them to do it slightly quicker, and slightly less accurately.


On Tue, 13 Jul 2010, Marques Johansson 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.

For <video>, where it makes sense, we already have it.


In any case, I recommend following this suggestion from the FAQ for new 
features such as this:

   http://wiki.whatwg.org/wiki/FAQ#Is_there_a_process_for_adding_new_features_to_a_specification.3F

Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'