W3C home > Mailing lists > Public > public-css-testsuite@w3.org > November 2012

Comments on 'line-height'-related tests for Quirks Mode

From: Kang-Hao (Kenny) Lu <kanghaol@oupeng.com>
Date: Fri, 23 Nov 2012 10:21:39 +0800
Message-ID: <50AEDDB3.70007@oupeng.com>
To: Simon Pieters <simonp@opera.com>
CC: W3C CSS Test Suite <public-css-testsuite@w3.org>
Hello Simon,


While preparing a talk for advanced CSS topics, I have a chance to
review some of the tests and here are my comments:

== 3.1 The line height calculation quirk ==

  # <div id=test><img src="{png}"> <img src="{png}"></div>
  # <div id=ref>x</div><div id=s_ref>x</div>

The 5th test duplicates the second, as the test itself already warns you
at the beginning.


  # span { padding:1px 0 }
  # <div id=test><span></span></div>
  # <div id=ref></div><div id=s_ref></div>

This is a bit puzzling, in particular about "<div id=s_ref></div>". I
think what this test runs into is this part of CSS 2.1 9.4.2:

  # Line boxes are created as needed to hold inline-level content
  # within an inline formatting context. Line boxes that contain no
  # text, no preserved white space, no inline elements with non-zero
  # margins, padding, or borders, and no other in-flow content (such as
  # images, inline blocks or inline tables), and do not end with a
  # preserved newline must be treated as zero-height line boxes for the
  # purposes of determining the positions of any elements inside of
  # them, and must be treated as not existing for any other purpose.

While the condition "no inline elements with non-zero margins, padding,
or borders" probably has quirks-mode difference too (and should be
specced), if you are testing the current prose to see if the above
<span> contributes to line height, I'd suggest the test be written in
this way:

  | div { line-height: 0} span { padding:1px 0; line-height: normal }
  | <div id=test>x<span></span></div><div id=ref>x</div>
  | <div id=s_ref>x<span>x</span></div>

The 'x' at the beginning ensures that the tests don't go into the
"zero-height line boxes" situation.

Ditto for all others.


  # span { display:inline-block; height:1px }
  # <div id=test><i><span></span> </i></div>
  # <span id=ref></span><div id=s_ref>x</div>

Browsers behave differently for this sort of situation so I think there
should be more tests like this. For example, we should write tests for
when <span> is 'inline-table' 'inline-flex' or replaced elements.


If you agree with the above comments, I can send you a patch.


Some relevant comments for the spec:

  # In quirks mode and almost standards mode, an inline box that
  # matches the following conditions, must, for the purpose of line
  # height calculation, act as if the box had a height of zero.

I think you meant to say "the box had a 'line-height' of zero" instead,
as the content height of an inline box never affects the line height,
the "line-height box" does. This is what CSS 2.1 10.8 says

  # The height of each inline-level box in the line box is calculated.
  # For replaced elements, inline-block elements, and inline-table
  # elements, this is the height of their margin box; for inline boxes,
  # this is their 'line-height'. (See "Calculating heights and margins"
  # and the height of inline boxes in "Leading and half-leading".)

(What 'window.getComputedStyle' would return for 'height' is sort of a
parallel, although also interesting, question.)


  # <div id=test><img src="{png}" border=1></div>
  # <img id=ref src="{png}" height=3><div id=s_ref>x</div>

This (and the following three), as well as the starting 6 tests seem to
belong to "3.2 The blocks ignore line-height quirk" instead of this set,
but you should just consider combining these two, I guess.


== 3.2 The blocks ignore line-height quirk ==

The test seems fine, but for the spec prose,

  # In quirks mode and almost standards mode, a block container element
  # whose content is composed of inline-level elements, the element's
  # 'line-height' must be ignored for the purpose of calculating the
  # minimal height of line boxes within the element.

s/a block/for a block/ ?

, I am wondering if it's easier to understand if the spec just sas the
"struts"[1] don't exist. But I am not an expert in inline formatting...
Also, you might consider "a block container element establishing inline
formatting context" in place of the current wording.

[1] http://www.w3.org/TR/CSS21/visudet.html#strut



Cheers,
Kenny
-- 
Web Specialist, Oupeng Browser, Beijing
Try Oupeng: http://www.oupeng.com/
Received on Friday, 23 November 2012 02:22:12 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 23 November 2012 02:22:12 GMT