Specify the mapping of containing block to element

[hawkinsw]

With respect to the proposal to use "nearest containing block ancestor" as the way to aggregate text nodes:

The containing block is a rectangle, not an element, and the mapping between rectangles and elements is not trivial

1. a single element can map to multiple containing blocks,
2. a single containing block might not map to any specific element at all (e.g. this is what you get if a table-row cell contains several block-and-text children: you get an anonymous table-cell box which determines the containing block for those blocks-and-text, but that box does not correspond to any elements).

Can we specify the mapping from containing blocks to elements?

[npm1]

Thanks for the feedback! Interesting, anonymous layout objects are definitely a problem here. Any suggestions on how we can fix this? For example, could we consider the nearest element ancestor?

[bzbarsky]

Parent element (the parent of a textnode that's bound to the document tree is always an element) is easy enough to do. Would it produce the right behavior?

One thing to consider: how do textnodes fundamentally differ from inline elements (replaced or non-replaced), apart from not being elements?

[npm1]

Parent elements does not work like we'd like it to, for example consider the following paragraph: <p>See the <a href...>link</a>.</p> We want link to be grouped with p, hence why we used containing block (to attempt to visually group text elements).

One thing to consider: how do textnodes fundamentally differ from inline elements (replaced or non-replaced), apart from not being elements?

Not sure I understand the message here.

[bzbarsky]

Not sure I understand the message here.

I think that question was due to not really checking how the association of text to containing block is used. Looks like it's pretty text-specific....