- From: Geoffrey Sneddon <gsneddon@opera.com>
- Date: Tue, 14 Sep 2010 21:46:21 +0100
- To: css21testsuite@gtalbot.org
- CC: "public-css-testsuite@w3.org" <public-css-testsuite@w3.org>, Řyvind Stenhaug <oyvinds@opera.com>
On 13/09/10 23:04, "Gérard Talbot" wrote: > Such problem, which has been corroborated by another poster in > www-style, may have caused you to say "I've almost never seen them > actually all get rendered on the same line". I've not actually tried to run any of the CSS 2.1 tests on Windows myself, so no. :) Our regression tracking system takes screenshots at 1600x1200 (by default), which is wide enough as to make D appear split between lines. My local browser ends up (after all the chrome around it) with a viewport of 902x643, which is narrow enough to make B appear split between lines. As far as I can tell, there are only a few ranges of width where it will actually end up with the big/small coloured boxes on the same line as each other. For <http://www.gtalbot.org/BrowserBugsSection/css21testsuite/c414-flt-ln-002-draft.htm>, I wonder if it is worthwhile setting an explicit width on the div and using Ahem so that it is predicable exactly where the lines will break. I dislike, "You can resize the window to change respective position of boxes and you can increase/decrease the font size to verify", as it is impossible to do within any regression tracking system pretty much. Given a screenshot, you can't just increase/decrease font size to verify. It's also pretty much impossible to change such a test into a reftest. In general, having a TC that's pretty much impossible to automate seems bad. -- Geoffrey Sneddon — Opera Software <http://gsnedders.com> <http://opera.com>
Received on Tuesday, 14 September 2010 20:47:04 UTC