You can see many more examples of dom2string in the non-html5 results (where there are a zillion failure cases): http://trac.webkit.org/browser/trunk/LayoutTests/html5lib/runner-expected.txt
dom2string.js came from http://code.google.com/p/html5lib I thought, but I couldn't find the source for it there. I'm not wedded in any way to dom2string. But I do like the output it produces slightly more than the current dumpAsMarkup. I agree, standardization might be nice. dom2string uses " for <#text> and </#text>. newlines return you to the start of the line as you would expect. (see the runner-expected.txt above). -eric p.s. Would be nice if we could just inject certain javascript into every page. Sorta like how v8 allows you to define engine-level functions in javascript. Would be nice to just make dumpAsMarkup() part of DRT, but write it in javascript. :) On Mon, Jul 26, 2010 at 7:15 PM, Ojan Vafai <[email protected]> wrote: > I like the idea of standardizing the dump output and the dumping code for > that matter. If we can resolve the below, then we can make sure all the > dumping logic in dom2string gets moved into dump-as-markup and standardize > on that. As best I can tell, there's only 2 uses of dom2string. > >> There is another DOM dump format which the html5lib tests use: >> >> http://trac.webkit.org/browser/trunk/LayoutTests/html5lib/runner-expected-html5.txt >> Note, it's a DOM Dump, not a Markup dump, but it serves a similar >> purpose. > > I'm not really sure what distinction you're drawing here. They both just > dump the DOM. When this came up before, people preferred the name > dump-as-markup to dum-as-dom. > >> I I think I like the html5lib format better for a few reasons: >> 2. The DOM tree indent is nice. > > What does the indenting do with linebreaks? For example, "foo\nbar\nbaz". In > dump-as-markup, that gets printed as: > <#text>foo > bar > baz</text> > > I guess I'd be OK with indenting, but having anything after a newline not > indent. > >> 3. <#text> is takes less space. > > Meh. I find the quotes confusing, e.g. if there are quotes in the text node: > "And then I said, "wot?"" > > But I guess that's not too bad and it is a bit easier on the eyes overall. > I'm ok with changing this if that's what others think is better. > >> I suggest adding # signs to the selection pseudo-elements, >> just to avoid the tiny risk of conflicting with an actual element in a >> test. Also, perhaps it would be better to show tag names in lowercase - >> that can be achieved by using localName instead of nodeName or tagName. > > Both of these make sense. > > Filed https://bugs.webkit.org/show_bug.cgi?id=43015. > > Ojan > > _______________________________________________ > webkit-dev mailing list > [email protected] > http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev > > _______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
