w3c / w3c/DOM-Parsing

fragment parsing algorithm appears to be wrong when invoked from innerHTML setter of template element

Open
#61 2 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
HTML
Stars
28
Forks
14
Avg merge
3h 10m
Merged PRs (30d)
1

Description

It's possible there's some other piece here that I'm missing, but it looks like https://w3c.github.io/DOM-Parsing/#dfn-fragment-parsing-algorithm tells us to make a document fragment on the node document of the context element, and then append nodes to it. This has the potential to enqueue upgrade reactions on those nodes if they match custom element definitions.

However, if we're setting the innerHTML of a template, we want to stay away from the node document of that template element, using the associated inert template document instead and not enqueuing upgrade reactions.

https://w3c.github.io/DOM-Parsing/#dom-innerhtml distinguishes the template as a special case, but only after it's already done calling the fragment parsing algorithm; the upgrade reactions have already been queued before we check if the context object is a template.

The second case of this WPT test checks when upgrades happen in this situation, and browsers are passing it, which implies the specification isn't matching browser behavior: https://github.com/web-platform-tests/wpt/blob/master/custom-elements/reactions/Document.html

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the DOM Parsing fragment parsing algorithm and the innerHTML definition, then review the second case in web-platform-tests/custom-elements/reactions/Document.html. Confirm how template elements and their associated inert template documents are handled, and update the specification so its stated behavior matches the passing browser test.

Written by the indexing model from the issue text.

Assessment

Tech stack
html
Domain
web-dev
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.