- From: Mike Samuel <notifications@github.com>
- Date: Sat, 04 May 2019 08:22:40 -0700
- To: w3c/webcomponents <webcomponents@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/webcomponents/issues/807/489336233@github.com>
@Lonniebiz
> hack that works without passing validation.
The below validates. Comment tokens are allowed before the doctype.
```html
<!-- --><!doctype html><html lang="en"><title>.</title><body><script>
console.log('Hello, World!');
//</script>
```
> Can you think of a way that a javascript file could formally acknowledge that it intends to
> generate an HTML document, in manner that would circumvent your CDN concerns?
I'm not sure I understand. Obviously we don't want to rely on the payload to tell us whether it's trustworthy.
Any response header that is not generated by existing web servers would suffice. Perhaps `Content-type: application/web+javascript` :)
> client-side generated html document
I still don't understand why it matters whether the HTMLDocument is created by outer ring JavaScript or by the browser, and I reread your stackoverflow question but found no clues there.
What would letting JavaScript creating the document enable given that it'd have to be via browser APIs that restrict at least some of the document's initial state?
There are parts of the document that cannot be left to outer ring code.
For example, `document.origin` has to be monotonically decreasing in privilege over the life of the document and the browser has to restrict its initial value.
If you want something about a document to be mutable to early running code that isn't presently, let's debate that.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/webcomponents/issues/807#issuecomment-489336233
Received on Saturday, 4 May 2019 15:23:03 UTC