W3C home > Mailing lists > Public > whatwg@whatwg.org > July 2010

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

From: Aryeh Gregor <Simetrical+w3c@gmail.com>
Date: Tue, 13 Jul 2010 17:57:51 -0400
Message-ID: <AANLkTimFqm_mDM9Q3Xc1i6qaO60_h925Zskf1n95uTuV@mail.gmail.com>
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

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.
Received on Tuesday, 13 July 2010 14:57:51 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:24 UTC