Re: [webcomponents] HTML Imports

On Thu, Oct 10, 2013 at 2: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.
>
>
>> 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.
>
>
Multiple imports of the same resource don't run scripts multiple times.
Perhaps this assuages your concern?


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


-- 
<http://goto.google.com/dc-email-sla>