Re: [webcomponents] HTML Imports

On Tue, Dec 3, 2013 at 7:03 PM, Ryosuke Niwa <rniwa@apple.com> wrote:

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

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