[LayoutNG] Remove LayoutInline post block fragment painting. |
|||||
Issue description
LayoutInline::Split* methods shouldn't be needed in a post-LayoutNG world.
For example:
<span>text<div></div>text</span>
Today we split the LayoutInline to:
(anon)
LayoutInline
LayoutText
(anon)
LayoutBlockFlow
(anon)
LayoutInline
LayoutText
Post LayoutNG fragment painting we should:
LayoutNGBlockFlow (used to be a LayoutInline)
LayoutText
LayoutNGBlockFlow
LayoutText
As we can use LayoutNG fragmentation capabilities to produce the following fragment tree:
NGFragment (represents the <span>)
NGTextFragment ("text") -> NGBreakToken - with style state.
NGFragment (represents the <div>)
NGTextFragment ("text") -> Created from break token above.
NGInlineNode::CollectInlines will have to insert replacement characters for any block level divs it encounters to fragment in this way.
,
May 1 2017
This is what the spec defines to create anonymous blocks, correct? https://drafts.csswg.org/css2/visuren.html#anonymous-block-level I tend to agree that the anonymous blocks and line continuation is a complexity and great if we can avoid them, but I don't have full understanding if/how the layout results could differ or the same by not creating anonymous blocks. +cbiesinger since he mentioned Gecko handles this without creating anonymous blocks, in case he has any insights. Oh, or are you saying, we can create anonymous NGLayoutInputNodes to perform layout but optimize NGPhysicalFragment?
,
May 1 2017
The problem with the current implementation is that it just gives incorrect results a lot of the time. (hyatt was landing some patches over the past 2+ years to try and fix a bunch of the issues). I.e. we currently do the following wrong as we have the wrong tree structure. <span style="position: relative"> text text <div><div style="position: absolute; width: 20px; top: 0; bottom: 0;"></div></div> text text </span> That part of the spec is very vague. I can try and write up a document for what I think we want the structure to be, but this is post painting/hit-testing fragments unfortunately.
,
May 1 2017
Oh, sorry, confused with the case where the most outer box is a block. Is SplitFlow() incorrect too?
,
May 2 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 2 2018
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by ikilpatrick@chromium.org
, Apr 30 2017