Re: [webcomponents] HTML Imports

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


>
> 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. Whilst I don't doubt it is usable by the highly
> competent people who are working at the bleeding edge on polyfilling
> components, the rest of the population can't be expected to understand the
> implemetation details that seem to have led the design in this direction. I
> think it would be useful to go right back to use cases here and work out if
> we can't design something better.
>
>