Re: Multiple baseline question

On 24/07/2012 18:01, Julien Chaffraix wrote:
> On Mon, Jul 23, 2012 at 11:57 PM, Anton Prowse <prowse@moonhenge.net> wrote:
>> On 24/07/2012 02:27, L. David Baron wrote:
>>>
>>> On Monday 2012-07-23 17:11 -0700, L. David Baron wrote:
>>>>
>>>> On Monday 2012-07-23 16:32 -0700, Julien Chaffraix wrote:
>>>>>
>>>>> I have a question about the attached test-case. This is question
>>>>> related to a recent change in WebKit where we aligned our table
>>>>> baseline computation with CSS 2.1 but changed the output of the test.
>>>>> Longer context can be found here:
>>>>> https://bugs.webkit.org/show_bug.cgi?id=91137
>>>>>
>>>>> Browsers don't agree on the exact behavior in this case:
>>>>> * WebKit (after the change) / Opera don't horizontally align the 2
>>>>> rectangles.
>>>>> * WebKit (before the change) / FF and IE align them.
>>>>>
>>>>> The current line of thoughts is that the 2 inline-blocks shouldn't be
>>>>> vertically aligned:
>>>>> * We align the 2 inline-blocks along their baseline as vertical-align
>>>>> defaults to 'baseline'.
>>>>> * "The baseline of an 'inline-block' is the baseline of its last line
>>>>> box in the normal flow", which means that the inline-block baseline is
>>>>> the anonymous inline-table's.
>>>>> * "The baseline of an 'inline-table' is the baseline of the first row
>>>>> of the table."
>>>>> * "If a row has no cell box aligned to its baseline, the baseline of
>>>>> that row is the bottom content edge of the lowest cell in the row.",
>>>>> the only table cell's has vertical-align: middle so the baseline of
>>>>> the row is the bottom of the content edge.
>>
>>
>>> The flaw in your reasoning above is that there is an 'inline-table'
>>> at all.  The anonymous box generation algorithm should produce a
>>> 'table' since the parent is not display:inline.
>
> Ah, good catch. I misread the spec and thought we would need to
> generate an 'inline-table' wrapper in any inline formatting context.

Ah, nice twist!  When a block container box contains *only* a 
"misparented" box type which is fixed up in such a way that the 
principal anonymous box of the result of the fix-up may either be 
inline-level or block-level (a situation which, in CSS21, can only arise 
with an internal table element or a table caption) then we are indeed 
left in the dark about what to do unless the spec explicitly explains 
how to make that choice.  Should the block container establish an inline 
formatting context, or should it contain block-level boxes?

I think that, all other things being equal, the preference should be to 
fix up using a block-level principal anonymous box instead of an 
inline-level one.  After all, the primary use case for inline-level 
atomic boxes is to allow them to play nicely with real inline boxes, so 
when there are no such real boxes it seems a little perverse to choose 
inline-level over block-level.

I would suggest that the rule of thumb should be – in any situation 
where a principal anonymous box resulting from some sort of fix-up could 
be either inline-level or block-level – something like the following:

   | The box is block-level or inline-level depending on the formatting
   | context in which it participates.  If the type or identity of the
   | formatting context would depend on whether the box is block-level
   | or inline-level, then the box is block-level.

...and I was about to propose something concrete for the CSS21 table 
case only to find, when I looked up how table fix-up is defined in 
CSS21, that the folks who were involved in greatly improving that 
section prior to CSS21 going to Rec were already a step ahead!  17.2.1 
already says, as the last step in the fix-up:

   # For each proper table child C in a sequence of consecutive proper
   # table children, if C is misparented then generate an anonymous
   # 'table' or 'inline-table' box T around C and all consecutive
   # siblings of C that are proper table children. (If C's parent is an
   # 'inline' box, then T must be an 'inline-table' box; otherwise it
   # must be a 'table' box.)

Although the talk of 'table' box and 'inline-table' box seems a little 
muddled (since what should actually be generated is a block-level table 
box as defined in in 17.4 plus a block-level or inline-level table 
wrapper box), we get the idea, and it's clear that the intention is that 
the table wrapper box be block-level unless the parent of C is 
inline-level.  [Which is stricter than my hypothetical proposal, since a 
table-cell child of an inline-block would be fixed up into a block-level 
table even if it had inline-level siblings.]

So there's no issue in this case; the spec is clear that the generated 
table is block-level in the example you give.

Still, the issue is something to bear in mind when spec'ing future 
layout models, I guess.


>>> That said, I'm not sure what the baseline of an inline-block
>>> containing only a table is supposed to be.
>>
>> ... which is related to (and possibly a sub-problem of) the problem that we
>> don't know what the baseline of a table is.  The flexbox spec now contains
>> the following Note:
>>
>>    # CSS 2.1 did not define the baseline of block or table boxes. It is
>>    # expected that they will be defined consistent with those of table
>>    # cells, as follows:
>>    #
>>    # [...]
>>    #
>>    # ‘table’
>>    #     The inline-axis baseline of a table box is the baseline of its
>>    #     first row.
>
> I don't know what the baseline of a table would be either but authors
> seem to be expecting that the 2 blocks are aligned (ie we would align
> the cell's first line boxes) [1]. This doesn't match what the flexbox
> spec is saying as it would align the cell's bottom content edge in the
> example due to the vertical-align: middle property on the table cell.

Yes, that's right.  In the simple example given, it's easy for authors 
to say that they want a certain alignment.  But it becomes easier to see 
why the baseline for a table row (and from there, table box) was defined 
like that when you consider the case of a top-aligned table cell, a tall 
middle-aligned cell and a bottom-aligned table cell all in the same row. 
  With nothing much else to go on, keying into the lowest cell's bottom 
content edge seems like a reasonable choice.

Cheers,
Anton Prowse
http://dev.moonhenge.net

Received on Tuesday, 24 July 2012 21:58:41 UTC