W3C home > Mailing lists > Public > public-html-testsuite@w3.org > November 2010

Re: choice of javascript DOM methods suitable for use in tests

From: David Carlisle <davidc@nag.co.uk>
Date: Mon, 29 Nov 2010 23:49:37 +0000
Message-ID: <4CF43C11.9090908@nag.co.uk>
To: Maciej Stachowiak <mjs@apple.com>
CC: "public-html-testsuite@w3.org" <public-html-testsuite@w3.org>
On 29/11/2010 23:17, Maciej Stachowiak wrote:

 > Although offsetWidth is implemented in all popular browsers, it
 > doesn't always behave exactly the same, and the attempt to specify an
 > interoperable behavior for it is not yet very mature, so I would
 > recommend against it.

yes I suspected as much, which is one reason I used fairly big entries 
in the numerator/denominator, single character entries show lots of 
atrifacts due to font size and different padding but if the two children 
are large enough, then (hopefully) a fraction will always be less wide 
than the spans (or I could have measured height) no matter if the 
padding and fonts are different.
 >
 > Also this particular test seems rather indirect. I think a reftest
 > would be a better way to test layout.

Well fine as I mentioned this morning, getting input on the test format 
was the main point or the exercise. But the current test guidelines 
don't say you can make a reftest (or what a reftest is, or how to submit 
one). My (partial) understanding of the reftest system was that to test 
mfrac a b you'd have to supply something else that rendered the same way 
as mfrac a b without using mfrac and then the test would be checking 
that the two things rendered the same. I'm not sure how to do that for 
mfrac, but since you aren't the first to suggest reftest would be 
better, I think I must be missing something.

  There are many ways a browser
 > with the wrong rendering could pass the test, for example by failing
 > to render<math>  at all, or by using a different font for math that
 > happens to result in a narrower width. This isn't a very thorough
 > test that stacking actually occurred.

well it's not particularly thorough, but as I say I did try to mitigate 
against font differences by choosing a sufficiently large input, and 
while it is not thorough, it does, with just that one test, accurately 
distinguish which of opera/gecko/ie/safari/chrome (using whichever 
alpha/beta/nightly releases I had to hand) do render MathML in 
text/html, so it is not without use even as it is. I'd make it more 
thorough, and use more robust dom methods, if people said doing that
was a good idea, but if everyone is going to say use this reftest thing, 
I'll instead spend the time working out what that means...
 >
 >>
 >> Implementations of MathML are strongly encouraged to also use the
 >> MathML test suite at
 >>
 >> http://www.w3.org/Math/testsuite/
 >>
 >> which is a large collection of mainly visual tests against
 >> reference images, but it seems best to keep that separate at this
 >> stage.
 >
 > Perhaps it would be useful to make versions of these tests embedded
 > in HTML (and also XHTML?).

the tests themselves are (almost all) just self standing mathml files.
But the test runner linked from the above exposes them as 
mathml-in-xhtml (because this web thing is quite useful for controlling 
interaction:-)

It's all generated from the base sources, so generating an html5 version 
of the mathml testsuite would be essentially trivial
(just a couple of tweaks to the serialisation options of the controlling 
xslt and jelly scripts. We did plan do do that at some stage, could do 
it now if that would be useful)
 >
 > Another alternative that would test the parsing but not rendering
 > aspects is to make sure MathML elements end up in the proper
 > namespace, rather than directly testing their rendering.
 >

yes the first test I submitted math-parse01.html tests that (amongst 
other things) that just tests the normative requirements from the 
parsing stage. I agree that testing (to any extent) the rendering 
behaviour as in math-render01.html is different and probably should be 
in a different part of the testsuite, but the questions are;

where should it be located in the test suite tree?

and should it use some form of dom measurement (even if not offsetWidth) 
or should it use the reftest mechanism (in which case I may need a hint 
as to what to do)

 > Regards, Maciej
 >

Sorry to be a pain with so many questions but I suspect that there 
haven't been too many submissions from outside of the initial core 
group, and other newcomers will have similar questions I expect, so I 
may as well ask them now:-)

David
Received on Monday, 29 November 2010 23:50:05 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:49:37 UTC