On Mon, Jul 26, 2010 at 8:22 PM, Maciej Stachowiak <m...@apple.com> wrote:
>
> On Jul 26, 2010, at 4:25 PM, Eric Seidel wrote:
>
>> 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. :)
>
> That's easy to do, DRT could just force loading of the JS file that 
> implements dumpAsMarkup() (or whatever we end up calling it). But I'm not 
> sure that is better than including a JS file in the test explicitly. For one 
> thing, most of the logic to dumpAsMarkup() (other than forcing a text dump) 
> should work in any other browser, so it would make it easier to try our tests 
> in other browsers if the JS code implementing it is included explicitly 
> instead of magically. It would also make the tests more useful to try in a 
> WebKit-based browser like Safari or Chrome, for that matter - you wouldn't 
> need DRT to see the output.

Hmmm.... True.  This reminds me of my previous thoughts of making
DRT's controllers entirely a NPAPI plugin.   (Might make it possible
to run DRT-like tests in Safari or chrome renderers easier, and opens
the door for possible x-browser testing using expanded javascript
APIs.)  But that also has the same trouble of DRT being "too smart"
where explicit HTML is easier to run x-browser.

The idea behind auto-injecting JS appeals to me more for making
script-tests easier.

Then again it should be possible to re-write our script-test support
so that this is all you need to write:

<script src="script-tests.js"></script>
<script>
description("foo");
shouldBe("foo", "bar");
</script>
<script src="end-script-test.js"></script>

Instead of the current (cumbersome) templating system.  Should be
possible to even get rid of the final "end-script-test.js" tag if
we're smart.

-eric
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

Reply via email to