WICG / WICG/declarative-partial-updates

`marker`s for declarative partial updates

Open
#111 7 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Bikeshed
Stars
135
Forks
13
Avg merge
12m
Merged PRs (30d)
3

Description

A previous version of the declarative partial updates explainer had a concept of marker attributes that allowed nested content to be targetted by templates that did not share a root with the targetted content. This feature was a removed as a mitigation against possible mXSS attacks. I have a use case for this feature and I'd like to propose we bring it back while preserving the mXSS mitigation.

In our case we are streaming HTML that is generated on the fly. This HTML may have content that changes after it has been materialized in the DOM. For example, we may stream down a placeholder element that is later populated with data from an async fetch on the server. As concrete example this may look like:

<!-- 
  Imagine this is a streaming message, with multiple updates.
  
  The content is being streamed as it is generated. 
  
  We may need to replace previously streamed and materialized
  content in the middle of the stream. This may happen in an
  "open tail" situation where a DOM element is not closed (an
  opening <p> without the corresponding </p>) and is deeply 
  nested relative to the content to be replaced.
-->
<div marker="foo">
  <!-- this is the first update -->
  <div>
    <p>
      <?start name="another-placeholder">
        Initial content
      <?end>
      <!-- this is the second update -->
      <div>
        <!-- this is the third update -->
        <p>Here i am deep in nesting for</p>
          <!-- 
            We need to revise previous content! 
            Alternatively we may have fetched data on the server
            and the result resolved at this point.
          -->
          <template for="another-placeholder">
            Revised update for initial contennt
          </template>    
        </p>

We may also have multiple placeholders for things like status updates:

<div marker="root">
  <div id="status">
   <?start name="status-message><?end>
  </div>
  
  <div id="content">
   <!-- above example here -->

In either case, when we get the template we may be in an "open tail" situation. That is deeply nested HTML without closing tags:

<div>
  <p>
    content here
    <template for="foo">...</template>

In this scenario we cannot wait for the stream to get back to the common ancestor node because we do not know what is coming next in the stream. Maybe we get the closing tags that get us back to the common ancestor, maybe we get a lot more content. The prior marker syntax (root#child) solved this problem.

I'll propose that nonce may be used here to allow the marker syntax in a safe way. This could look like:

<div marker="my-marker" nonce="abc-123">
  <?start name="content-to-replace">
    I will be replaced
  <?end>  
  <!-- content here, nesting, etc -->
     <template for="my-marker#content-to-replace" nonce="abc-123">
       new content
     </template>

If the template and marker have matching nonces, we can expand the scope. If not, we enforce the current rules.

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 previous declarative partial updates explainer linked in commit 665e7f5ccec69a58609a09ef0bcb1a3e423ee2c and compare its removed marker syntax with the current rules. Evaluate the nonce-matching proposal against the open-tail examples, with done meaning an agreed design that supports nested targets without weakening the mXSS mitigation.

Written by the indexing model from the issue text.

Assessment

Tech stack
html
Domain
web-dev
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.