- Notifications
You must be signed in to change notification settings - Fork62
Added new tests for foster parenting in template, after after frameset a...#26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
base:master
Are you sure you want to change the base?
Uh oh!
There was an error while loading.Please reload this page.
Conversation
hoppipolla-critic-bot commentedNov 18, 2013
Critic review:https://critic.hoppipolla.co.uk/r/431 This is an external review system which you may optionally use for the code review of your pull request. |
| | content | ||
| | <template> | ||
| | content | ||
| | <div> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others.Learn more.
I'm having trouble following this one. Thediv element is inserted targeting thetable element with foster parenting enabled. For thediv to end up before thetable, we needthe following:
Iflast table has a parent element, then letadjusted insertion location be insidelast table's parent element, immediately beforelast table, and abort these sub steps.
must be true.
If theadjusted insertion location is inside a
templateelement, let it instead be inside thetemplateelement's template contents, after its last child (if any).must be false.
So from 1 thelast table has a parent element, thetemplate, and theadjusted insertion location is inside that parent element.
But from 2 theadjusted insertion location is not inside atemplate element. This contradicts 1 above.
By my reading, the error is in 2, and thediv should instead go after thetable.
That's a good catch. The new foster parenting algorithm behaves differently from the stand alone spec for templates and I'm not sure if this outcome is intentional. In Blink and Gecko, the adjusted insertion location in inside the template before the table, but as you mentioned, the new spec indicates that it should be after. This also means the previous test in template.dat is now incorrect as well. I'll raise a spec bug about this if you haven't already. |
I think the test with the "foo" character tokens is fine. It gets to
which is where the characters were inserted in the test. I have not yet filed a bug against the spec, so by all means go ahead! |
I was referring to the test that we already have in template.dat I'm going to email Hixie to see if the behavior change was intentional. If so, I'll update both tests. |
Oh, yep, that test is also affected. Good call. |
@revite: Any news on this? (Is the email public, or is there a bug on the spec? If so, a link would be nice!) |
@gsnedders: Sorry for the late reply. Hixie got back to me and he has updated the spec so that the submitted tests are correct and the spec behavior matches the current browser behaviour. In particular, sub-step 5 was reworded to "If last table has a parent node, then let adjusted insertion location be inside last table's parent node, immediately before last table, and abort these substeps." The key difference is changing the word "element" to "node". The parser appends children of the template element into the template content document fragment instead of the element. The parent of the table in this case is a node, not a template element, thus it does not get readjusted by step 3. |
This pull request now include another commit with tests covering changes relating to form pointer and template contents.http://html5.org/tools/web-apps-tracker?from=8330&to=8331 |
…t and parsing fragment in html context.
…k of open elements when they are not being recreated.
…t of active formatting elements.
...nd parsing fragment in html context.