- From: David Carlisle <davidc@nag.co.uk>
- Date: Mon, 29 Nov 2010 23:49:37 +0000
- 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