- From: <bugzilla@jessica.w3.org>
- Date: Thu, 30 Jun 2011 20:17:45 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13094 Aryeh Gregor <Simetrical+w3cbug@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |Simetrical+w3cbug@gmail.com Resolution| |DUPLICATE --- Comment #3 from Aryeh Gregor <Simetrical+w3cbug@gmail.com> 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 *** -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Thursday, 30 June 2011 20:17:47 UTC