Re: [w3c/webcomponents] Make JavaScript Files a Valid Entry Point to a Web Page (#807)

> 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.

I'm ok with the browser taking part in the HTMLDocument creation, but I'd like the ability to initiate that creation with client-side javascript in the same manner it gets created using server-side html.

What I wish was possible, is the ability to create a web application without ever leaving my javascript file. I want the ability to write and save a single javascript file, serve it from a web server, and have the web-browser run that file, which then programmaticaly generates the html and css.

Right now, using javascript, on the client-side, you can programmatically generate all the HTML and CSS on a web page **except for the HTML wrapper itself** . Right now, the only way to create an HTMLDocument is to feed the web browser server-side-html.

So, the closest I can come to achieving my goal, is to hand the web browser a meaninglessly empty html file (to satisfy its 1994 expectations) that either encapsulates or links to my single javascript file.

The whole purpose of my intent is to skip this meaningless middle man: **the empty HTML file**. If my intent is to generate the HTML using client-side javascript exclusively, then javascript would be the most convenient file encapsulation (not some almost-empty html file designed to satisfy 1994 browser-expectations).

I don't understand all the details of all your concerns, but conceptually it seems likely that many concerns might be handled transparently if the browser would simply treat client-side-generated-html just like it currently treats server-side-generated-html. So, what ever assumptions a browser makes about server-side-html, regarding `document.origin`, it should make those same assumption about client-side-html that's generated by client-side javascript.

-- 
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-489539631