On Jun 4, 2013, at 18:59 , "Robert O'Callahan" <rob...@ocallahan.org> wrote:
> On Wed, Jun 5, 2013 at 1:48 PM, Patrick Walton <pwal...@mozilla.com> wrote: > >> We're trying to figure out what to do when an inline RenderBox of an >> inline flow becomes non-inline. This is a vexing issue, as it violates the >> invariant that a flow's descendants and the flow itself are the only flows >> that need to be reconstructed from scratch when a box's style changes. This >> is because the adjacent inlines turn into anonymous block flows. This invariant seems too strong to me, since adding/removing boxes from a flow will cause some relayout, and possibly add sibling flows (which need to be constructed and positioned). > In Gecko those inlines don't turn into anonymous boxes, because we don't > currently implement the CSS setup directly --- we allow a block's direct > children to be a mixture of inline and block-level boxes. However, my guess > is that your current approach is better, so stick with it. In Servo, the flow tree allows similar mixes (block flow can have mix of block and inline flow children). The spec uses an anonymous block box as an adapter between formatting contexts to preserve the "block's children = single inline, or >=1 blocks". The flow tree encodes this by grouping all boxes in an inline formatting context into an inline flow, and only laying out flows according to the block formatting context. (on second thought that's a mouthful. we need some diagrams.) > Are you handling the case yet where there's a display:block element inside > a display:inline? That's closely related to your problem. AFAIK, last fall I stubbed out the function to restructure the different tree configurations for this situation. It would be a good test to add. _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
