Display: Flex Prototype

Creating a merge request just to showcase the ideas + prototype. So you'll see stretches of comments I've left myself as I tried to familiarize myself with the library, commented out code, things of that nature.

Visual step by step of ideal algorithm with these changes - Public_for_Paged_-Step_by_step__2.pdf

To summarize: Enhancing breakTokens to understand 'why' overflow occurred, and use that information in rebuildAncestors(), as well as refactoring to work with an array of breaktokens as opposed to just one.

Modifications showcased

• When searching for overflow, we additionally track flex boundaries. When flex begins, and each of its flex columns
• Then, when overflow is located, that information is tacked on too (to the breakToken). We also continue searching for more overflows, adding to a list
• During this, when we hit ‘leaf nodes,’ we mark them as done rendering on the source DOM
• When build a page, we have multiple overflows and thus, multiple breakTokens. RebuildAncestors() should rebuild differently based on “why” the overflow occurred
• If it’s because of flex, then we also must rebuild the flexSiblings, and the flexSiblings ancestors
• RenderTo() starts at the first breakToken, but we must 1) not reappend elements already present on the page and 2) not append elements that are ‘done’ on previous pages.

Issues known and Ideas

• Very flex focused, but similar idea can be leveraged for table. E.g. detect that a table has begun, and track elements that would need to be rebuilt (tr th, previous tds) in the breakToken for rebuildAncestors()
• Only works for simple example, and 'context' can nest (table in flex, flex in flex, etc). An idea I had for that was tracking nesting contexts in the breakToken as a queue. Then when it comes to rebuilding ancestors, you would start at the top/first, rebuild what’s necessary for that context, and then dequeue, continuing until all contexts have been dealt with
• renderTo() walks the original DOM, even if there’s content way off the page. Could we also check the wrapper here, and try to intelligently stop?