On Tue, Dec 3, 2013 at 7:03 PM, Ryosuke Niwa <[email protected]> wrote:
> On Oct 7, 2013, at 12:24 PM, Rafael Weinstein <[email protected]> wrote: > > On Mon, Oct 7, 2013 at 3:24 AM, James Graham <[email protected]>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 <[email protected]> wrote: > > On Mon, Oct 7, 2013 at 3:24 AM, James Graham <[email protected]> > 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. > I speak with web developers on a regular basis. Most are agreeable with distinction and generally positive about the possibilities it opens up. http://robdodson.me/blog/2013/08/20/exploring-html-imports/ > > > 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 > >
