[notriddle]

Opening a document with 512 <i> tags in Firefox, as found in the included test case, shows the same DOM, including the correct text nesting and two <i> tags at the tip of the pyramid.

Fixes #788

Results of running the test are given below.

Before

<div>     n=  4000  bytes=  44001    51.818ms
<div>     n= 16000  bytes= 176001   459.037ms
<div>     n= 64000  bytes= 704001      7.551s
<ul><li>  n=  4000  bytes=  32001   115.165ms
<ul><li>  n= 16000  bytes= 128001      1.845s
<ul><li>  n= 64000  bytes= 512001     35.355s
<b>       n=  4000  bytes=  12001   814.333µs
<b>       n= 16000  bytes=  48001     2.981ms
<b>       n= 64000  bytes= 192001    12.490ms

After

<div>     n=  4000  bytes=  44001     8.136ms
<div>     n= 16000  bytes= 176001    33.434ms
<div>     n= 64000  bytes= 704001   134.578ms
<ul><li>  n=  4000  bytes=  32001    15.342ms
<ul><li>  n= 16000  bytes= 128001    62.561ms
<ul><li>  n= 64000  bytes= 512001   253.616ms
<b>       n=  4000  bytes=  12001   727.458µs
<b>       n= 16000  bytes=  48001     2.664ms
<b>       n= 64000  bytes= 192001    10.497ms

[mrobinson]

Nit: It might make sense to describe how the nesting limit is enforced in the rustdoc. Do other browsers take the same approach other than sharing a nesting limit? Maybe it makes sense to call this something like "pop_elements_until_nesting_limit_reached" as well, just to make it very clear what it does.

[notriddle]

I did some more investigation and found a spot where this disagrees with Firefox.

Instead of popping elements until the nesting limit is reached, I've copied Gecko implementation more closely, as described in whatwg/html#3732 (comment).