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

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Peter Sorotokin

Correct me if I am wrong, but CSS 2.1 does not define the height of the line box and thus does not define the position of the horizontal border of inline elements. Yet, this test

 

http://www.w3.org/Style/CSS/Test/CSS2.1/current/t100801-c42-ibx-ht-00-d-a.xht

 

relies on that position being defined. Either a spec or a test should be fixed.

 

Peter

Reply | Threaded
Open this post in threaded view
|

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

L. David Baron
On Monday 2006-09-25 00:09 -0700, Peter Sorotokin wrote:
> Correct me if I am wrong, but CSS 2.1 does not define the height of the
> line box and thus does not define the position of the horizontal border
> of inline elements. Yet, this test

It does define the height of the line box (10.8 and 9.4.2).

It's true that the visual height of inline elements is defined in a
slightly vague way -- 10.6.1 allows something unspecified based on the
font -- but I think the Ahem font has metrics such that every reasonable
thing based on the font should lead to the same result.  Perhaps the
spec should limit the options to a set of choices.

-David

--
L. David Baron                                <URL: http://dbaron.org/ >
           Technical Lead, Layout & CSS, Mozilla Corporation

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Peter Sorotokin

David,

It does define the height of the *line box*, but borders are supposed to
be around the element's *content area* (if there are no padding), not
the line box (so that, for example, when line-height property is
modified, the position of the borders does not change relative to the
text). It seems that this is how it is implemented in Mozilla and Opera
(but not IE) and I think there are tests for that in the suite. The CSS
spec could have been more explicit on how that works.

The height of the content area is explicitly undefined in section 10.6.1
(as you pointed out). What browsers seem to do is to define the content
area height (and position) being the same as *default* line height
(which is quite reasonable). Following the spec *suggestions* and
defining content area height in terms of the em box of the font or
ascender/descender (which is the same thing for Ahem) does not seem to
work for this test.

Peter

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of L. David Baron
Sent: Monday, September 25, 2006 12:25 AM
To: [hidden email]
Subject: Re: possible bug in t100801-c42-ibx-ht-00-d-a.xht

On Monday 2006-09-25 00:09 -0700, Peter Sorotokin wrote:
> Correct me if I am wrong, but CSS 2.1 does not define the height of
the
> line box and thus does not define the position of the horizontal
border
> of inline elements. Yet, this test

It does define the height of the line box (10.8 and 9.4.2).

It's true that the visual height of inline elements is defined in a
slightly vague way -- 10.6.1 allows something unspecified based on the
font -- but I think the Ahem font has metrics such that every reasonable
thing based on the font should lead to the same result.  Perhaps the
spec should limit the options to a set of choices.

-David

--
L. David Baron                                <URL: http://dbaron.org/ >
           Technical Lead, Layout & CSS, Mozilla Corporation

Reply | Threaded
Open this post in threaded view
|

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

L. David Baron
On Monday 2006-09-25 00:49 -0700, Peter Sorotokin wrote:
> It does define the height of the *line box*, but borders are supposed to
> be around the element's *content area* (if there are no padding), not
> the line box (so that, for example, when line-height property is
> modified, the position of the borders does not change relative to the
> text). It seems that this is how it is implemented in Mozilla and Opera
> (but not IE) and I think there are tests for that in the suite. The CSS
> spec could have been more explicit on how that works.

Right.  Inline boxes have two different heights:  one that is used for
border and padding, and the other that is used for some types of
vertical alignment and to determine the height of the line box.

> The height of the content area is explicitly undefined in section 10.6.1
> (as you pointed out). What browsers seem to do is to define the content
> area height (and position) being the same as *default* line height
> (which is quite reasonable). Following the spec *suggestions* and
> defining content area height in terms of the em box of the font or
> ascender/descender (which is the same thing for Ahem) does not seem to
> work for this test.

For Ahem, these should both be exactly the same as the font-size.  Is
that not what the test is testing?

-David

--
L. David Baron                                <URL: http://dbaron.org/ >
           Technical Lead, Layout & CSS, Mozilla Corporation

attachment0 (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Peter Sorotokin



> From: [hidden email]
[mailto:[hidden email]] On Behalf Of L. David Baron
> Sent: Monday, September 25, 2006 1:23 AM
> To: [hidden email]
> Subject: Re: possible bug in t100801-c42-ibx-ht-00-d-a.xht
>
> [snip]
>
> > The height of the content area is explicitly undefined in section
10.6.1
> > (as you pointed out). What browsers seem to do is to define the
content
> > area height (and position) being the same as *default* line height
> > (which is quite reasonable). Following the spec *suggestions* and
> > defining content area height in terms of the em box of the font or
> > ascender/descender (which is the same thing for Ahem) does not seem
to
> > work for this test.
>
> For Ahem, these should both be exactly the same as the font-size.  Is
> that not what the test is testing?
>

Correct me, if my reasoning is wrong. This is what CSS default for
line-height is (section 10.8.1):

normal - Tells user agents to set the used value to a "reasonable" value
based on the font of the element. The value has the same meaning as
<number>. We recommend a used value for 'normal' between 1.0 to 1.2.

So default line box height is about 1.2*fontSize and em box is, of
course, just fontSize high.

Peter

>
> -David
>
> --
> L. David Baron                                <URL: http://dbaron.org/
>
>            Technical Lead, Layout & CSS, Mozilla Corporation
>

Reply | Threaded
Open this post in threaded view
|

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

Ian Hickson

On Mon, 25 Sep 2006, Peter Sorotokin wrote:
>
> Correct me, if my reasoning is wrong. This is what CSS default for
> line-height is (section 10.8.1):

The test doesn't use the default value for line-height; on the <div>
element's anonymous inline box children the line-height value is 12px, on
the <em> element inline boxes the line-height is 10px, and on the <span>
element inline boxes the line-height is 12px.

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

Reply | Threaded
Open this post in threaded view
|

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

Peter Sorotokin
In reply to this post by Peter Sorotokin


> From: [hidden email]
[mailto:[hidden email]] On Behalf Of Peter
Sorotokin
> Sent: Monday, September 25, 2006 12:50 AM
> To: [hidden email]
> Subject: RE: possible bug in t100801-c42-ibx-ht-00-d-a.xht
>
>
> David,
>
> It does define the height of the *line box*, but borders are supposed
to
> be around the element's *content area* (if there are no padding), not
> the line box (so that, for example, when line-height property is
> modified, the position of the borders does not change relative to the
> text). It seems that this is how it is implemented in Mozilla and
Opera
> (but not IE) and I think there are tests for that in the suite. The
CSS
> spec could have been more explicit on how that works.
>
> The height of the content area is explicitly undefined in section
10.6.1
> (as you pointed out). What browsers seem to do is to define the
content
> area height (and position) being the same as *default* line height
> (which is quite reasonable). Following the spec *suggestions* and
> defining content area height in terms of the em box of the font or
> ascender/descender (which is the same thing for Ahem) does not seem to
> work for this test.

After more testing I can see that browsers actually do use em box or
ascent/descent (which is the same thing for Ahem). The test is still
incorrect, I think, because CSS does not tell how inline box height is
calculated - these two alternatives are just suggestions, not normative
definition. Either the spec should be amended (probably a better option)
or the test should be removed (or fixed somehow).

Peter

>
> Peter
>

Reply | Threaded
Open this post in threaded view
|

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

Peter Sorotokin
In reply to this post by Ian Hickson

Ian,

Line-height is really quite irrelevant here (well, it is relevant for
the test, but I do not question line-height calculations in this test -
they *are* correct). What is incorrect in this test is that it makes an
assumption on where the border of the inline element should occur (it
relies on the border exactly overlapping red characters in the previous
line). Border location in the vertical direction depends on the
dimensions of the content area of the element and the height of the
inline element content area is explicitly left undefined in the current
draft of CSS 2.1 (section 10.6.1).

Peter

-----Original Message-----
From: Ian Hickson [mailto:[hidden email]]
Sent: Monday, September 25, 2006 10:14 AM
To: Peter Sorotokin
Cc: [hidden email]
Subject: RE: possible bug in t100801-c42-ibx-ht-00-d-a.xht

On Mon, 25 Sep 2006, Peter Sorotokin wrote:
>
> Correct me, if my reasoning is wrong. This is what CSS default for
> line-height is (section 10.8.1):

The test doesn't use the default value for line-height; on the <div>
element's anonymous inline box children the line-height value is 12px,
on
the <em> element inline boxes the line-height is 10px, and on the <span>

element inline boxes the line-height is 12px.

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

Reply | Threaded
Open this post in threaded view
|

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

Ian Hickson

On Mon, 25 Sep 2006, Peter Sorotokin wrote:
>
> What is incorrect in this test is that it makes an assumption on where
> the border of the inline element should occur (it relies on the border
> exactly overlapping red characters in the previous line). Border
> location in the vertical direction depends on the dimensions of the
> content area of the element and the height of the inline element content
> area is explicitly left undefined in the current draft of CSS 2.1
> (section 10.6.1).

Ah, yes, indeed.

As noted in one of the other threads, the tests make several assumptions
(like this one) in order to test certain hard-to-test aspects of CSS.
Is the assumption here one that is inconsistent with your implementation?

I can look into the feasibility of marking tests that make assumptions of
this nature, if you think that would help.

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

Reply | Threaded
Open this post in threaded view
|

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

Peter Sorotokin


>
> -----Original Message-----
> From: Ian Hickson [mailto:[hidden email]]
> Sent: Monday, September 25, 2006 10:44 AM
> To: Peter Sorotokin
> Cc: [hidden email]
> Subject: RE: possible bug in t100801-c42-ibx-ht-00-d-a.xht
>
> On Mon, 25 Sep 2006, Peter Sorotokin wrote:
> >
> > What is incorrect in this test is that it makes an assumption on
where
> > the border of the inline element should occur (it relies on the
border
> > exactly overlapping red characters in the previous line). Border
> > location in the vertical direction depends on the dimensions of the
> > content area of the element and the height of the inline element
content
> > area is explicitly left undefined in the current draft of CSS 2.1
> > (section 10.6.1).
>
> Ah, yes, indeed.
>
> As noted in one of the other threads, the tests make several
assumptions
> (like this one) in order to test certain hard-to-test aspects of CSS.

Ian,

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.
When a test makes non-obvious assumptions about environment or
implementations, it should be noted in the test, otherwise users and QA
engineers assume that there is a bug in the implementation without
looking any further. In this case the test relies on the specifically
undefined part of CSS spec. It does not say that anywhere. I think this
is very misleading.

> Is the assumption here one that is inconsistent with your
implementation?

The assumptions are OK and my implementation actually passes this test,
it is just that the assumptions are quite nontrivial in this case. Also,
in this specific case, I think it would have been much better to just
define the height of the inline box in the spec.

> 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.

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.

Peter

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

Reply | Threaded
Open this post in threaded view
|

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

Ian Hickson

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.


> Also, in this specific case, I think it would have been much better to
> just define the height of the inline box in the spec.

I agree, but consensus couldn't be reached when this was last discussed,
hence the way it is not defined.


> > 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. 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.)


> 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.

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

Reply | Threaded
Open this post in threaded view
|

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

Peter Sorotokin

> -----Original Message-----
> From: Ian Hickson [mailto:[hidden email]]
> Sent: Monday, September 25, 2006 11:31 AM
> To: Peter Sorotokin
> Cc: [hidden email]
> 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.
`._.-(,_..'--(,_..'`-.;.'
>

Reply | Threaded
Open this post in threaded view
|

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

Ian Hickson

On Mon, 25 Sep 2006, Peter Sorotokin wrote:
>
> 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?

No need, I'll correct the tests when I merge them into the test suite.
Thanks for submitting the tests!


> 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.

The e-mails to which I haven't replied are currently sitting in my TODO
pile for things to work on when I next work on the CSS 2.1 test suite. At
the moment CSS is not currently my main job and I basically only get to
work on CSS in my spare time, so I can't guarentee a timely response to
those reports, but they will be dealt with in due course.

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