- From: <bugzilla@wiggum.w3.org>
- Date: Tue, 20 Oct 2009 09:44:40 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=7842
Maciej Stachowiak <mjs@apple.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|NEEDSINFO |
--- Comment #4 from Maciej Stachowiak <mjs@apple.com> 2009-10-20 09:44:40 ---
Same as the use case for creating a document programatically in general, in
cases where it's useful to have some processing where the HTMLness bit matters.
Some potential (maybe contrived) examples:
- Create a non-rendered HTML document to upload via XMLHttpRequest (instead of
sending an XML document).
- Feature-test the HTML DOM in library code in a way that is guaranteed to
avoid side effects on the displayed document.
- Create an isolated non-rendered document from a rich text editing area, so
client-side cleanup can be done before uploading without disturbing the live
DOM that the user may still edit further.
- Implement HTML5 parsing algorithm client-side in JavaScript for testing and
comparison purposes, or for virtualization or object-capability-based security.
An invisible iframe can be used for most of these purposes but that is more
expensive in terms of resources.
I think these use cases are not necessarily the most compelling. Mainly it
seems non-orthogonal that HTML documents can only be created by the HTML
parser, and thus offscreen / non-rendered documents all have to be XML
documents. This seems like an unnecessary asymmetry.
Reopening for consideration of provided info.
--
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 Tuesday, 20 October 2009 09:44:45 UTC