- From: Aryeh Gregor <Simetrical+w3c@gmail.com>
- Date: Tue, 13 Jul 2010 17:57:51 -0400
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.
Received on Tuesday, 13 July 2010 14:57:51 UTC