W3C home > Mailing lists > Public > www-html@w3.org > March 2004

Document.parseHTML(txt) - Why not?

From: Marcus <marcus3v@hotmail.com>
Date: Mon, 8 Mar 2004 16:21:55 -0300
To: <www-html@w3c.org>, <www-dom@w3c.org>
Message-ID: <BAY7-DAV25oAfCQYBfn000324c4@hotmail.com>

I believe that the addition of an method similar to the innerHTML "DHTML"
property, that is implemented by some current browsers -- IE, Mozilla... --,
would be extremely useful, principally for script writers.
Such hypothetical method, the return of which would be a DocumentFrament
object, would look like this ( assume a ECMA262 enviroment ):


where "doc" is a object variable that implements the Document Interface and
"str" is a string variable that contains HTML markup, for instance:

'<div id="el0">xxx <span id="el1" class="xx">xx<\/span><\/div>'

( obs.: the reverse method, docFragTxt=doc.parseStr(docFrag) would,
likewise, exist ).

In spite of the incontestable robustness of the DOM, a implacable
hierarchization of objects and methods may seem a bit maddening for a script
writer, since he would, relatively, spend a lot of work for the creation of
simple and trivial pieces of HTML. In order to create the above fragment --
that is extraordinarily short -- with the currently existent DOM interfaces,
5 Elements ( 1 DIV, 2 SPAN and 2 Text ) must be generated, 3 properties must
be applied and, finally, 4 nestings ( appendChild(), or
insert[After||Before]()... ) must be executed. This would be done with only
1 line of friendly code, if the "parse[HTML||Str]()" method existed...
Received on Monday, 8 March 2004 14:22:42 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:06:08 UTC