Re: [webcomponents] HTML Imports

On Oct 7, 2013, at 12:24 PM, Rafael Weinstein <rafaelw@google.com> wrote:

> On Mon, Oct 7, 2013 at 3:24 AM, James Graham <james@hoppipolla.co.uk> wrote:
> On 06/10/13 17:25, Dimitri Glazkov wrote:
> 
>     And, if the script is executed against the global/window object of
>     the main document, can and should you be able to access the imported
>     document?
> 
> 
> You can and you should. HTML Imports are effectively #include for the Web.
> 
> Yes, that sounds like a good description of the problem :) It is rather noticable that no one making programming languages today replicates the #include mechanism, and I think html-imports has some of the same design flaws that makes #include unpopular. 
> 
> I think authors will find it very hard to write code in an environment where simple functions like document.getElementById don't actually work on the document containing the script, but on some other document that 
> they can't see. It also seems that the design requires you to be super careful about having side effects; if the author happens to have a non-idempotent action in a document that is imported, then things will break in the relatively 
> uncommon case where a single document is imported more than once. 
> 
> We have an orthogonal mechanism for preventing side-effects: The HTML Template Element. Imports do not prevent side-effects implicitly. This is Good. Authors have control over the semantics they need. Want to include some DOM -- use imports, need some fragment of that to not have side effects -- put it in a <template>.

I don't think template element solves that problem if we're talking about scripts that need to run as soon as the document is imported.


On Oct 9, 2013, at 10:42 AM, Scott Miles <sjmiles@google.com> wrote:

> On Mon, Oct 7, 2013 at 3:24 AM, James Graham <james@hoppipolla.co.uk> wrote:
> On 06/10/13 17:25, Dimitri Glazkov wrote:
> 
>     And, if the script is executed against the global/window object of
>     the main document, can and should you be able to access the imported
>     document?
> 
> 
> You can and you should. HTML Imports are effectively #include for the Web.
> 
> Yes, that sounds like a good description of the problem :) It is rather noticable that no one making programming languages today replicates the #include mechanism, and I think html-imports has some of the same design flaws that makes #include unpopular.
> 
> I think authors will find it very hard to write code in an environment where simple functions like document.getElementById don't actually work on the document containing the script, but on some other document that they can't see.
> 
> It's true we are introducing something new, but this actually one of The Good Parts. Imports are not the main document, they are satellite to the main document. The main document maintains primacy, but your imports can act on it. So far, we haven't really had any problems with developers on this point.

We should be asking this question to an average Web developer who has never heard of HTML imports before.


> It also seems that the design requires you to be super careful about having side effects; if the author happens to have a non-idempotent action in a document that is imported, then things will break in the relatively uncommon case where a single document is imported more than once.
> 
> Can you give an example of a non-idempotent, potentially breaking action? 

e.g. defining a global variable.

> Overall it feels like html imports has been designed as an over general mechanism to address certain narrow use cases and, in so doing, has handed authors a footgun.
> 
> I guess I would instead suggest that generality of HTML Imports is due to the group attempting to find a virtuous primitive, instead of a special case.
> 
> For just one issue, look how much HTML becomes embedded in strings, or hidden as comments, or other crazy hacks. We can import (relocatable!) CSS and JS, why can we not import our most basic content?

We can address that problem without executing scripts in the host document.  e.g.  If I'm importing foo.html, it wouldn't be the end of the world for all objects defined in foo.html to be under "window.foo".  We can let the imported document access the host document via ownerDocument or whatever to address the other use case but let's not introduce another footgun.

- R. Niwa