[webkit-reviews] review granted: [Bug 84167] CSS 2.1 failure: inline-table-001 fails : [Attachment 140767] Patch

[bugzilla-daemon at webkit.org]

Julien Chaffraix <jchaffraix at webkit.org> has granted Robert Hogan
<robert at webkit.org>'s request for review:
Bug 84167: CSS 2.1 failure: inline-table-001 fails
https://bugs.webkit.org/show_bug.cgi?id=84167

Attachment 140767: Patch
https://bugs.webkit.org/attachment.cgi?id=140767&action=review

------- Additional Comments from Julien Chaffraix <jchaffraix at webkit.org>
View in context: https://bugs.webkit.org/attachment.cgi?id=140767&action=review


r+ assuming you update the confusing test, add the missing expectations and get
a green EWS before landing :)

Please consider making the space changes too.

>>> LayoutTests/fast/inline-block/001.html:-5
>>> -USED.
>> 
>> If we don't expect this test to ever pass, I wonder if we just shouldn't
remove it (assuming it is correctly super-seeded by the new CSS 2.1 tests). As
it is now, the output is confusing as the test says "This text should be on the
same line." (and it's not).
>> 
>> Looking again at the test itself, it doesn't strike me as obvious why we
don't expect it to pass as I would expect the inline-table to share the same
baseline (all their structure being equal).
> 
> I think the answer to this is in the spec (very bottom of
http://www.w3.org/TR/CSS21/visudet.html#leading):
> 
> "The baseline of an 'inline-table' is the baseline of the first row of the
table.
> 
> The baseline of an 'inline-block' is the baseline of its last line box in the
normal flow, unless it has either no in-flow line boxes or if its 'overflow'
property has a computed value other than 'visible', in which case the baseline
is the bottom margin edge."
> 
> The result is that for an adjacent inline-block and inline-table,  the first
row of the inline table will align roughly with the last line of the inline
block. This much makes sense to me - though I'm not entirely sure why the first
line/row of the table and the last line of the block do no line up exactly. I
don't think that's a bug (FF and Opera render it the same) - just a gap in my
understanding.

As discussed, the explanation makes sense. The output is confusing so it would
need to be updated to explain that the author's assumptions are incorrect.