Re: [css3-flexbox] splitting inline children around blocks, inside a flexbox

As a data point, Tab said in [1]

[[
For clarity, I have currently specified that table-fixup occurs
*before* flexbox does its thing, but block-in-inline fixup occurs
*after*.  This appears to be consistent with how these two fixup steps
occur in block layout, based on the limited testing I've done so far.
]]

, and I agree that the current spec is not yet as clear as it can be.

(12/03/23 2:04), Daniel Holbert wrote:
> This is according to the inline/block interaction rules in CSS 2.1 section
> 9.2.1.1 [2]:
> [[
> "When an inline box contains an in-flow block-level box, the inline box
> ...[is] broken around the block-level box... The line boxes before the
> break and after the break are enclosed in anonymous block boxes, and the
> block-level box becomes a sibling of those anonymous boxes
> ]]
> 
> In other words: if we follow CSS2.1 on how blocks behave inside of an
> inline, then the box for "not-an-item7.3" becomes an immediate child of
> the flexbox, which means the Flexbox spec says it should get its own
> flexbox item, contrary to what the example says.

9.2.1.1 arguably only happens in a block container ('block',
'inline-block', 'list-item', 'table-cell') because it also says

  # In other words: if a block container box (such as that generated
  # for the DIV above) has a block-level box inside it (such as the P
  # above), then we force it to have only block-level boxes inside it.

, and my mental model doesn't categorize 'flexbox' as a block container.

(CHECKPOINT: should '::first-letter'/'::first-line', which apply to
block container elements accoarding to CSS 2.1, apply to 'display:
flexbox'?)

> I think this needs clarification in the flexbox spec.  Maybe we need to
> use the element hierarchy instead of the box hierarchy for determining
> flexbox item eligibility?  I'm not sure if that makes sense.

My first impression about using the element hierarchy is "It is going to
be a fun exercise to work out the element-tree equivalent of the
anonymous box-tree fixup for table elements", but after thinking about
this more, I think it's probably just one more criterion in the list of
criteria to be a flexbox item (when translated to be in terms of
elements instead of boxes):

  | 4. Contiguous run of internal table elements and 'table-caption'
  | elements potentially with inter-element whitespace[2].

(12/03/23 2:09), Boris Zbarsky wrote:
> The other option, if the behavior of the example is desired, is to
> explicitly include blocks that split a non-replaced inline in the
> "runs of inlines" case and explicitly exclude them from the "block
> child" case.

Having said above, I prefer this partly because I am not confident about
the addition above and partly because referencing the term "inter-elment
whiatespace" might lead to another WHATWG HTML LS vs. W3C HTML5 drama.

(12/03/23 2:17), Daniel Holbert wrote:
> I realized after mailing that perhaps I should've filed a spec bug on
> this, so I did: https://www.w3.org/Bugs/Public/show_bug.cgi?id=16483
>
> Apologies if the combination of spec bug & email were overkill. :)

I'll prefer mailing list in this case as that's where other non-trivial
issues of css3-flexbox are raised. The Apple specs seem to have a
different culture though.

[1] http://lists.w3.org/Archives/Public/www-style/2012Jan/1154
[2]
http://www.whatwg.org/specs/web-apps/current-work/multipage/elements.html#inter-element-whitespace


Cheers,
Kenny

Received on Thursday, 22 March 2012 22:28:19 UTC