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

7 tests assume non-compliant step-order in foreign content #173

Open
not-my-profile opened this issue Sep 26, 2023 · 2 comments · May be fixed by whatwg/html#9809
Open

7 tests assume non-compliant step-order in foreign content #173

not-my-profile opened this issue Sep 26, 2023 · 2 comments · May be fixed by whatwg/html#9809

Comments

@not-my-profile
Copy link

The rules for parsing tokens in foreign content currently say:

↪ Any other end tag
Run these steps:

  1. Initialize node to be the current node (the bottommost node of the stack).
  2. If node's tag name, converted to ASCII lowercase, is not the same as the tag name of the token, then this is a parse error.
  3. Loop: If node is the topmost element in the stack of open elements, then return. (fragment case)
  4. If node's tag name, converted to ASCII lowercase, is the same as the tag name of the token, pop elements from the stack of open elements until node has been popped from the stack, and then return.
  5. Set node to the previous entry in the stack of open elements.
  6. If node is not an element in the HTML namespace, return to the step labeled loop.
  7. Otherwise, process the token according to the rules given in the section corresponding to the current insertion mode in HTML content.

However if you actually implement that 7 tree-construction test cases of this repository fail:

  • foreign-fragment-3
  • math-5
  • math-6
  • math-7
  • svg-5
  • svg-6
  • svg-7

Apparently the test cases assume that the 7th step is performed as step 4.
@not-my-profile not-my-profile changed the title tree construction tests assume different "Any other end tag" step-order for foreign content than spec 7 tests assume non-compliant step-order in foreign content Sep 26, 2023
@annevk
Copy link
Contributor

annevk commented Sep 27, 2023

Assuming all browsers pass these tests, this is probably best reported as a bug against the standard at this point.

@not-my-profile
Copy link
Author

not-my-profile commented Sep 29, 2023 •
edited
Loading

Oh yeah ... I should have noted that the only thing that changes if you do it in the order described as in the spec you get one parser error more ... I'll make a PR to the spec.

not-my-profile added a commit to not-my-profile/html that referenced this issue Sep 29, 2023
@not-my-profile
Stop reporting redundant fragment parser error in foreign content
761b28e 
I have tested this change against the test cases from html5lib-tests.

In document parsing this doesn't change any test results.

In fragment parsing this fixes 7 test cases by reporting one parser
error less. (That is all existing HTML parsers that pass html5lib-tests
must have already implemented these steps in the order they are changed
to by this commit.)

The test cases where one error is reported less fall in two categories:

* fragment parsing e.g. `<svg></table>` with a `tbody` HTML element as
  the context element => one "unexpected end tag" error is reported less

* fragment parsing e.g. `<g></path>` with a `path` SVG element as the
  context element => one "found special tag while closing generic tag"
  error is no longer reported

Fixes html5lib/html5lib-tests#173.
@not-my-profile not-my-profile linked a pull request Sep 29, 2023 that will close this issue
Open
not-my-profile added a commit to not-my-profile/html that referenced this issue Sep 29, 2023
@not-my-profile
Stop reporting redundant fragment parser error in foreign content
d119c56 
I have tested this change against the test cases from html5lib-tests.

In document parsing this doesn't change any test results.

In fragment parsing this fixes 7 test cases by reporting one parser
error less. (That is all existing HTML parsers that pass html5lib-tests
must have already implemented these steps in the order they are changed
to by this commit.)

The test cases where one error is reported less fall in two categories:

* fragment parsing e.g. `<svg></table>` with a `tbody` HTML element as
  the context element => one "unexpected end tag" error is reported less
  (previously it was reported twice)

* fragment parsing e.g. `<g></path>` with a `path` SVG element as the
  context element => one "found special tag while closing generic tag"
  error is no longer reported

Fixes html5lib/html5lib-tests#173.
not-my-profile added a commit to not-my-profile/html that referenced this issue Sep 29, 2023
@not-my-profile
Stop reporting redundant fragment parser error in foreign content
d04ee3d 
I have tested this change against the test cases from html5lib-tests.

In document parsing this doesn't change any test results.

In fragment parsing this fixes 7 test cases by reporting one parser
error less. (That is all existing HTML parsers that pass html5lib-tests
must have already implemented these steps in the order they are changed
to by this commit.)

The test cases where one error is reported less fall in two categories:

* fragment parsing e.g. `<svg></table>` with a `tbody` HTML element as
  the context element => one "unexpected end tag" error is reported less
  (previously it was reported twice)

* fragment parsing e.g. `<g></path>` with a `path` SVG element as the
  context element => one "found special tag while closing generic tag"
  error is no longer reported

Fixes html5lib/html5lib-tests#173.
not-my-profile added a commit to not-my-profile/html that referenced this issue Sep 29, 2023
@not-my-profile
Stop reporting redundant fragment parser error in foreign content
1d479e3 
I have tested this change against the test cases from html5lib-tests.

In document parsing this doesn't change any test results.

In fragment parsing this fixes 7 test cases by reporting one parser
error less. (That is all existing HTML parsers that pass html5lib-tests
must have already implemented these steps in the order they are changed
to by this commit.)

The test cases where one error is reported less fall in two categories:

* fragment parsing e.g. `<svg></table>` with a `tbody` HTML element as
  the context element => one "unexpected end tag" error is reported less
  (previously it was reported twice)

* fragment parsing e.g. `<g></path>` with a `path` SVG element as the
  context element => one "found special tag while closing generic tag"
  error is no longer reported

Fixes html5lib/html5lib-tests#173.
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
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Stop reporting redundant fragment parser error in foreign content not-my-profile/html
2 participants
@annevk @not-my-profile