W3C home > Mailing lists > Public > public-css-testsuite@w3.org > September 2006

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

From: Peter Sorotokin <psorotok@adobe.com>
Date: Mon, 25 Sep 2006 10:14:15 -0700
Message-ID: <40CE68F1F8CAFB48B998C328517EA92AFCB205@namail2.corp.adobe.com>
To: <public-css-testsuite@w3.org>

> From: public-css-testsuite-request@w3.org
[mailto:public-css-testsuite-request@w3.org] On Behalf Of Peter
> Sent: Monday, September 25, 2006 12:50 AM
> To: public-css-testsuite@w3.org
> 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
> 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
> (but not IE) and I think there are tests for that in the suite. The
> spec could have been more explicit on how that works. 
> The height of the content area is explicitly undefined in section
> (as you pointed out). What browsers seem to do is to define the
> 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
Received on Monday, 25 September 2006 17:14:34 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:13:16 UTC