I've doen some calculations myself.

Here is is the state when first entering the AAA with  token:

Stack of Open Elements	Active Formatting Elements
html, body, b, em, foo, foo, foo, aside	b, em

In the outer loop we get the following:

Formatting Element	Furthest Block	Common Ancestor	Bookmark
b	aside	body	0

Now the inner loop.

Blink and WebKit limit the inner loop counter to 3. This is also true for the html5lib-python implementation. However, the current spec doesn't state this explicitly, at least not explicitly enough as it is the case for the outer loop Outer loop: If outer loop counter is greater than or equal to eight, then abort these steps.

So in this case the  wouldn't be removed via the following step If inner loop counter is greater than three and node is in the list of active formatting elements, then remove node from the list of active formatting elements

So the state directly after the inner loop is as follows:

Stack of Open Elements	Active Formatting Elements
html, body, b, em, aside	b, em

and the DOM tree is untouched.

Now the furthest block <aside> gets inserted into the common ancestor <body>
A new element for the token, i.e. , is appended to <aside>
 is removed from the active formatting elements and reinserted at bookmark, which is 0, so this stays as it is
 is removed from the stack of open elements and is reinserted after the <aside>
The second iteration of the outer loops breaks because there is no furthest block and we end up with:

Stack of Open Elements	Active Formatting Elements
html, body, em, aside	em

with the following tree:

| <html>
|   <head>
|   <body>
|     <b>
|       <em>
|         <foo>
|           <foo>
|             <foo>
|     <aside>
|       <b>

The outer loop of the AAA for the  token is almost the same:

Formatting Element	Furthest Block	Common Ancestor	Bookmark
em	aside	body	0

The inner loop however is left immediately, since the element directly above the <aside> in the stack of pen elements is the formatting element.
A new element for the token  is created and it gets all child nodes from <aside>, as described: Take all of the child nodes of furthest block and append them to the element created in the last step.
The  is then appended to <aside>
The second iteration of the outer loops breaks because there is no furthest block and we end up with:

Stack of Open Elements	Active Formatting Elements
html, body, aside

with the following tree:

| <html>
|   <head>
|   <body>
|     <b>
|       <em>
|         <foo>
|           <foo>
|             <foo>
|     <aside>
|       <em>
|         <b>

Notice the ordering of  and  under <aside>. My initial assumption was wrong, however the test expectation is still incorrect.

I have also tested the HTML snippet in Chrome, Safari & Firefox, all three produce this tree, i.e. aside, em, b.

As I see it, the spec is ambiguous when it comes to the inner loop handling.

Incorrect expectations in tree-construction webkit02 tests #78

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions