RE: possible bug in t100801-c42-ibx-ht-00-d-a.xht

> -----Original Message-----
> From: Ian Hickson [mailto:ian@hixie.ch] 
> Sent: Monday, September 25, 2006 11:31 AM
> To: Peter Sorotokin
> Cc: public-css-testsuite@w3.org
> Subject: RE: possible bug in t100801-c42-ibx-ht-00-d-a.xht
> 
> On Mon, 25 Sep 2006, Peter Sorotokin wrote:
> > 
> > As I understand the purpose of the test suite, it is designed to
help 
> > users (who are not necessarily CSS experts) to quickly see the level
of 
> > compliance for any implementation and to help implementers to find
bugs.
> 
> Oh, no, it's neither of these. The purpose of the test suite is to
help 
> the CSS working group gauge what level of interoperability we have so
we 
> know which parts of the spec to drop so we can move from CR to PR.
> 

I see. That makes this suite much less interesting from my perspective.

[snip]

> 
> > > I can look into the feasibility of marking tests that make
assumptions 
> > > of this nature, if you think that would help.
> > 
> > That would certainly help - especially if it would mention the 
> > assumptions in the prose of the test (like "your screen must be
96dpi" 
> > or "your user agent must calculate content area height according to 
> > non-normative language in section 10.6.1)". Suffix alone just would
not 
> > cut it - people would still just ignore it and submit bug reports.
> 
> Well, in both of those cases I think the bug reports would be likely 
> welcome anyway since you basically have to implement things that way
to be 
> compatible with existing content.

If we are speaking about existing content, it is the CSS spec itself
that is not compatible with it. Existing content that has troubles in
this area assumes that 1 inch is exactly 96 CSS pixels, *irrespective of
the display resolution* (which is quite ridiculous "rule", of course).
The only case where CSS spec and this existing content "rule" give the
same result is when display resolution is exactly 96dpi. If I follow the
existing content "rule", my implementation won't be compatible with the
spec anymore. So, no, I do not want these bug reports, just like I would
not want a bug report that "street" HTML does not parse correctly.

> But I will look into what can be done. 
> (As a general rule I don't think adding prose to a test helps since it

> would increase the time the test would take to check.)
> 

I see that we certainly have different goals here.

> 
> > Do you want a list of files that make 96dpi screen assumption? For 
> > those, actually, it would have been better to split each of them in
two: 
> > one that makes the assumption and the other one that does not.
> 
> If you have the list that would be great, yeah.
> 
> Making new tests would also be great, but I won't have the bandwidth
to do 
> this myself. If you have such tests, you can submit them using the
system 
> described here:
> 
>
http://lists.w3.org/Archives/Public/public-css-testsuite/2006Aug/0000
> 
> Use the "comments" column to mention that this is a
resolution-independent 
> variant of one of the other tests.

I have submitted several tests, to see what happens, but apparently I
have used wrong colors. Should I just submit them again once I fix the
colors?

I have to evaluate what to do here. It's not like a have a lot of
bandwidth to work on that either (and I am not even involved in CSS WG)
and cooperation only pays off when you get something in return. So far
all my reports on the problems with the tests were either ignored or
rejected for the reasons that I don't consider valid.

Peter

> 
> Cheers,
> -- 
> Ian Hickson               U+1047E                )\._.,--....,'``.
fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._
,.
> Things that are impossible just take longer.
`._.-(,_..'--(,_..'`-.;.'
>

Received on Monday, 25 September 2006 19:21:43 UTC