Skip to content
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.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Foster parenting doesn't happen for HTML elements in foreign content #6808

Closed
stevecheckoway opened this issue Jun 26, 2021 · 3 comments
Closed

Foster parenting doesn't happen for HTML elements in foreign content #6808

stevecheckoway opened this issue Jun 26, 2021 · 3 comments

Comments

@stevecheckoway
Copy link

https://html.spec.whatwg.org/multipage/parsing.html#parsing-main-inforeign

A start tag whose tag name is one of:​ "b", "big", "blockquote", "body", "br", "center", "code", "dd", "div", "dl", "dt", "em", "embed", "h1", "h2", "h3", "h4", "h5", "h6", "head", "hr", "i", "img", "li", "listing", "menu", "meta", "nobr", "ol", "p", "pre", "ruby", "s", "small", "span", "strong", "strike", "sub", "sup", "table", "tt", "u", "ul", "var"
A start tag whose tag name is "font", if the token has any attributes named "color", "face", or "size"
An end tag whose tag name is "br", "p"

Parse error\.

While the current node is not a MathML text integration point, an HTML integration point, or an element in the HTML namespace, pop elements from the stack of open elements\.

Process the token using the rules for the "in body" insertion mode\.

I think that processing the token using the rules for "in body" isn't correct here. Consider the following HTML.

<!DOCTYPE html><body><table><svg><p>X</table>

My understanding of the spec is that the <svg> tag should cause the svg element to be foster parented before the table element from the anything else rule in the in table insertion mode. The <p> tag is processed according to the rule quoted above. That's going to pop the svg element off the stack of open elements which then consists of html > body > table.

At this point, I think the following should happen:

  • the <p> tag is processed according to the in table insertion mode which foster parents the p element before the table;
  • the X is processed according to the in table insertion mode which foster parents the text node but since the target is the p element, foster parenting does nothing; and
  • the </table> tag closes the table element.
    This would result in the following DOM.
<!DOCTYPE html>
<html>
  <head>
  <body>
    <svg:svg>
    <p>
      "X"
    <table>

Firefox, Chrome, and Safari agree with this interpretation.

However, the following is what I think the spec says happens:

  • the <p> tag is processed according to the in body insertion mode which inserts a p element as a child of the table;
  • the X is processed according to the in table insertion mode (because nothing has changed the tree construction's insertion mode) which foster parents the text node but places it in the p element as normal; and
  • the </table> tag closes the table element.
    This results in the following DOM.
<!DOCTYPE html>
<html>
  <head>
  <body>
  <svg:svg>
  <table>
    <p>
      "X"

Maybe all that needs to happen is after popping the stack of open elements until the current node is a MathML text integration point, HTML integration point, or an HTML element, the token should be processed using the rules for the current insertion mode in HTML content, similar to the last step of the any other end tag in foreign content.
stevecheckoway added a commit to sparklemotion/nokogiri that referenced this issue Jun 29, 2021
@stevecheckoway
Update HTML tests
e4b29a4 
Update to the latest version of html5lib-tests. The spec currently has a
[bug](whatwg/html#6808) so the parser does not
conform to the spec, but it does match Safari, Firefox, Chrome, and the
html5lib-tests tests.
@TRowbotham
Copy link
Contributor

I believe #6455 fixes this, but it hasn't been accepted yet.

@stevecheckoway
Copy link
Author

@TRowbotham, thanks! I agree that would fix it.

@annevk
Copy link
Member

annevk commented Jul 19, 2021

Let's dupe this into #6439.

@annevk annevk closed this as completed Jul 19, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@stevecheckoway @annevk @TRowbotham