Skip to content

HTML parser: handle </br> and </p> in SVG#6736

Merged
domenic merged 1 commit intomainfrom
bocoup/svg-br-p-end-tag
Jun 23, 2021
Merged

HTML parser: handle </br> and </p> in SVG#6736
domenic merged 1 commit intomainfrom
bocoup/svg-br-p-end-tag

Conversation

@zcorpan
Copy link
Copy Markdown
Member

@zcorpan zcorpan commented Jun 4, 2021

zcorpan added a commit to html5lib/html5lib-tests that referenced this pull request Jun 4, 2021
@zcorpan
Copy link
Copy Markdown
Member Author

zcorpan commented Jun 4, 2021

Together with #6455, I believe this matches current Chromium. @mfreed7 can you confirm?

@mfreed7
Copy link
Copy Markdown
Collaborator

mfreed7 commented Jun 4, 2021

I think that's right. In Chromium, <table><math><p>foo gives me <math><p><table> in DOM. That's the correct check, right?

@zcorpan
Copy link
Copy Markdown
Member Author

zcorpan commented Jun 4, 2021

For #6455, yes. This PR is about these cases:

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/9362

<svg></p><foo>

should produce:

  • html html
    • html head
    • html body
      • svg svg
      • html p
      • html foo

and

<svg></br><foo>

should produce:

  • html html
    • html head
    • html body
      • svg svg
      • html br
      • html foo

@mfreed7
Copy link
Copy Markdown
Collaborator

mfreed7 commented Jun 7, 2021

Thanks. I can confirm that behavior in Chromium also. 😄

@zcorpan
Copy link
Copy Markdown
Member Author

zcorpan commented Jun 7, 2021

This matches Gecko as well for the non-fragment case. (The fragment case is different because Gecko doesn't yet implement #6399 + #6455.) cc @hsivonen

@gsnedders does this comment #5113 (comment) indicate implementer interest for WebKit?

Ms2ger pushed a commit to html5lib/html5lib-tests that referenced this pull request Jun 11, 2021
@domenic domenic added compat Standard is not web compatible or proprietary feature needs standardizing interop Implementations are not interoperable with each other normative change topic: parser labels Jun 14, 2021
@bathos bathos mentioned this pull request Jun 19, 2021
Copy link
Copy Markdown
Member

@domenic domenic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Simon, should we merge this? Aligning the spec with 2/3 implementations seems good!

@zcorpan
Copy link
Copy Markdown
Member Author

zcorpan commented Jun 23, 2021

I think it's good to merge, yeah

@domenic domenic merged commit 681c884 into main Jun 23, 2021
@domenic domenic deleted the bocoup/svg-br-p-end-tag branch June 23, 2021 23:09
fb55 added a commit to inikulin/parse5 that referenced this pull request Mar 13, 2022
The behaviour for parsing foreign content was updated in whatwg/html#6455 and whatwg/html#6736. This catches us up to the current specced behaviour.
syjer added a commit to digitalfondue/jfiveparse that referenced this pull request Mar 13, 2022
syjer added a commit to digitalfondue/jfiveparse that referenced this pull request Mar 13, 2022
* initial work for updating parser to latest test: fix search
* update to spec whatwg/html#6736
* fix .dat parsing logic
* test against lts
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

compat Standard is not web compatible or proprietary feature needs standardizing interop Implementations are not interoperable with each other normative change topic: parser

Development

Successfully merging this pull request may close these issues.

Unmatched </p> or </br> inside foreign context needs a special parser rule

3 participants