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


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


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


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


We created polyfills not as an end-in-itself, but as a way of making it
possible to test these concepts in the real world. The fact is, that one of
my team's mandates is to (try to) ensure that what comes out if this
process is actually useful for end-users. We're certainly open to criticism
on this point (or any point!), but it's basically upside-down to assume we
are focused on the technology more than the usability.


> I think it would be useful to go right back to use cases here and work out
> if we can't design something better.
>

Welcome to the discussion, we are grateful for your participation! Let's
keep up the discussion. In particular, it would be very helpful if you
could fill in some details on the foot-gun as described above.

Thanks again,
Scott