This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 13094 - First there was the <img> tag. Now, with HTML5, <audio> and <video> tags are being introduced (which also have the helpful controls attribute). This covers the 3 most important media types, namely pictures, music, and videos. However, there is a fourth ty
Summary: First there was the <img> tag. Now, with HTML5, <audio> and <video> tags are ...
Status: RESOLVED DUPLICATE of bug 12957
Alias: None
Product: HTML WG
Classification: Unclassified
Component: LC1 HTML5 spec (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-06-30 03:08 UTC by contributor
Modified: 2011-08-04 05:12 UTC (History)
6 users (show)

See Also:


Attachments

Description contributor 2011-06-30 03:08:34 UTC
Specification: http://dev.w3.org/html5/spec/Overview.html
Multipage: http://www.whatwg.org/C#top
Complete: http://www.whatwg.org/c#top

Comment:
First there was the <img> tag. Now, with HTML5, <audio> and <video> tags are
being introduced (which also have the helpful controls attribute). This covers
the 3 most important media types, namely pictures, music, and videos. However,
there is a fourth type of digital media that is quickly becoming prevalent:
electronic publications such as ebooks and documents. As a matter of fact,
just like the other 3 media types have their own common codecs, the dominant
electronic publication codec/format is ePub. If there was such new element,
for instance it could be called <document>, it could be used to display ebooks
and other ePub documents (such as user manuals, academic papers, etc.) in a
webpage. And if there was an associated controls attribute, it could be used
to add next and previous button controls to switch between pages. Just as the
other media elements may help us eliminate the need to use proprietary
plug-ins such as Adobe Flash, a <document> element could help eliminate the
need for using other proprietary plug-ins, such as the Adobe Acrobat Reader
for PDF documents. It seems to me that such new element would be very popular,
especially now that ereaders and ebooks have been made widely available from
companies such as Apple (iPad), Google (Google eBookstore), Amazon (Kindle),
Sony (Sony Reader), and Barnes and Noble (Nook).

Posted from: 98.203.243.109
User agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0)
Comment 1 Tab Atkins Jr. 2011-06-30 03:11:06 UTC
That's called <iframe>, isn't it?
Comment 2 Leonard Rosenthol 2011-06-30 19:27:57 UTC
iFrame won't work because the underlying problem is the containment of the HTML5 inside of a ZIP archive.  (and then some).  The problem requires server-side as well as client-side help - and is really outside of the HTML5 spec (IMO)
Comment 3 Aryeh Gregor 2011-06-30 20:17:44 UTC
Authors can already embed documents using <iframe> or <object> or such.  Most browsers don't currently support rendering document formats this way, but there's no reason they couldn't.  The reason we have special elements for img/audio/video is because we have special standardized attributes that only make sense for them, and special standardized JavaScript APIs.

So to add an element like <document>, we'd need clear use-cases that explain what special standardized APIs would be needed, and proof that these use-cases are widespread.  We could have APIs that expose the number of pages, allow JS navigation between pages, stuff like that, but is this really something that's so important?  Video is a *huge* use-case, which millions of people use every day.  Document browsing is a lot less so, and (unlike video) can already be handled okay by writing your own display code in JavaScript.

So this really needs a convincing explanation of why doing it in JavaScript isn't good enough, and/or interest by a major browser implementer, before there's any reasonable possibility that we spec it.

*** This bug has been marked as a duplicate of bug 12957 ***
Comment 4 Michael[tm] Smith 2011-08-04 05:12:08 UTC
mass-move component to LC1