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

[Aryeh Gregor]

On Tue, Jul 13, 2010 at 2:31 AM, Gordon P. Hemsley <gphemsley at gmail.com> 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.
> 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?)

If this is your use-case, you don't want or need type="".  You just
want browsers to handle unsupported content in iframes differently
than they do now.  Offering a download sounds like it's probably
better behavior than just ignoring it.  Maybe it would be best to
display a "click to download" thing where the iframe is supposed to
display, instead.  But this is really a UI issue, not an HTML-level
issue.  I suggest you file bugs against browsers that have annoying UI
here.

I don't think there's any reason why a browser would need to know the
type (which might be incorrect) of an <iframe> before it actually
issues the HTTP request.  This is useful on <source>, but only because
the common case there right now is that at least one <source> is
unsupported.  (But when a common baseline codec is settled on, the
useless type="" can be dropped.)  The common case for <iframe> is that
the content is supported, and where it's not, often the page becomes
useless anyway, so it's not worth optimizing for.