[webcomponents] HTML Imports notes

[Hajime Morrita]

Hi,

Since last HTML Imports WD is published, I heard some feedback. Most of
them are about the loading order and its sync/async nature. Thanks for
sharing your thought!

At the same time, I found there are some confusion about how it works. As
it's hard for me to capture the underlying thinking in the standard
document, I thought that it might be helpful to informally sketch what's
behind the current design and what we're thinking. So here it is [1]. I
hope this clarifies some of your questions and/or concerns.

If you have any comments, let's talk at coming F2F.

Bests,

[1] https://gist.github.com/omo/9986103

-- 
morrita

Re: [webcomponents] HTML Imports

[Brian Kardell]

I've been putting off a response on this, but I have some things to add...
The topic on this thread was originally HTML Imports - it seems like some
of the concerns expressed extend beyond imports and are a little wider
ranging.  I am cross posting this comment to public-next...@w3.org as I
think it is related.

I share the concern about letting out an API too early, but I think my
concerns are different.  In the past we worked (meaning browsers, devs,
stds groups) in a model in which things were released into the wild -
prefixed or not - without a very wide feedback loop.  At that point, the
practical realities leave not many good options for course correction or
even for small, but significant tweaks.  I think a lot is happening to
change that model and, as we can see in the case of everything with Web
Components (esp imports and selectors perhaps) the wider we throw the net
the more feedback we get from real people trying to accomplish real things
with real concerns - not just theory.  Some of this experimentation is
happening in the native space, but it is behind a flag, so we are shielded
from the problems above - no public Web site is relying on those things.
 And some of that is happening in the prollyfill space - Github FTW - in
projects like x-tags and polymer.  When we really look down through things
it does feel like it starts to become clear where the pain points are and
where things start to feel more stable.  With this approach, we don't need
to "rush" standardization in the large scale - if we can reasonably do it
without that and there seems to be wide questioning - let's hold off a bit.

HTML Imports, for example, are generating an *awful* lot of discussion - it
feels like they aren't cooked to me.  But virtually every discussion
involves elements we know we'd need to experiment in that space - modules
would allow one kind of experimentation, promises seem necessary for other
kinds, and so on.  There is a danger of undercooking, yes - but there is
also a danger in overcooking in the standards space alone that I think is
less evident:  No matter how good or bad something is technically, it needs
uptake to succeed.  If you think that ES6 modules have absolutely nothing
to do with this, for example, but through experimentation in the community
that sort of approach turns out to be a winner - it is much more valuable
than theoretical debate.  Debate is really good - but the advantage I think
we need to help exploit is that folks like Steve Souders or James Burke and
W3C TAG can debate and make their cases with working code without pulling
the proverbial trigger if we prioritize the right things and tools to make
it possible.  And no ones code needs to break in the meantime - the
JS-based approach you use today will work just as well tomorrow - better
actually because the perf curve of the browser and speed of machines they
run on is always up.

I don't think that "perfect" imports is necessarily the lynch-pin to value
in Web Components - it needn't block other progress to slow down the
standard on this one.  Other things like document.register already feel a
lot more stable.  Finding a way to evolve the Web is tricky, but I think
doable and the Web would be a lot better for it if we can get it right.

Re: [webcomponents] HTML Imports

[Charles McCathie Nevile]

On Wed, 04 Dec 2013 18:58:10 +0100, Scott Miles  wrote:


seems a specification that seems really pushed/rushed


Since my team (Polymer) has been working with imports in practice for a
year-and-a-half (100% public and open-source, btw) this seems a strange
conclusion.


As Bjoern pointed out, this functionality is something we have been trying  
to get on the web for most of the history of the web. And I think it is  
fair to say that we have often pushed to get something accepted. We're  
still pushing - it would be useful to solve this longstanding problem.


I don't know if that equates to "rushed". This is discussed elsewhere, and  
I don't think it's a very fruitful discussion.



But this is only my perspective, I'm still a standards n00b I suppose.

In any case, I codified the concepts that our team has been espousing in  
a document here:


https://docs.google.com/document/d/14qJlCgda7GX2_KKxYhj1EULmY_hqNH35wjqDgGSkkOo/edit#

The aim of this document was to address some of the questions around
pragmatic operation of the spec as we see it.


Thanks. This is helpful. More perspectives from different kinds of people  
who have tried to use Web components may be important contribution in  
deciding whether we have it right enough.


cheers

Chaals


Scott

On Wed, Dec 4, 2013 at 4:32 AM, Anne van Kesteren   
wrote:



On Wed, Dec 4, 2013 at 9:21 AM, Brian Di Palma  wrote:
> I would say though that I get the feeling that Web Components seems a
> specification that seems really pushed/rushed and I worry that might
> lead to some poor design decisions whose side effects will be felt by
> developers in the future.

I very much share this sentiment.


--
http://annevankesteren.nl/




--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
  cha...@yandex-team.ru Find more at http://yandex.com

Re: [webcomponents] HTML Imports

[Bjoern Hoehrmann]

* Brian Di Palma wrote:
>Neither did I mean it to be taken to mean "This work is rushed". I said,
>
>"I get the feeling that Web Components seems a specification that
>seems really pushed/rushed",
>
>by that I meant it seemed as if the current spec is being pushed as
>fast as possible toward standardization.

As far as I can tell, the Web Components proponents have been very clear
in the past that they want something very soon, including that they are
willing to live with issues that cannot be solved soon. So, sure, they
are pushing this.

>I was not commenting on the amount of time put into making the spec
>but more the amount of time given to interested parties to digest,
>implement, and comment on it.

I believe the general sentiment in the Working Group is that feedback
coming from people developing applications running in web browsers is
extremely sought after. They do not, however, have much of an interest
in creating an environment where such people can easily and do gladly
provide such feedback when it would be most useful. Ordinarily there
would be mandatory procedures Working Groups and Working Group parti-
cipants are held to that should provide such an environment.

But as you can see in a nearby thread, it's already too much to ask of
the Chairs that they make sure Apple and Mozilla have finished their
final review of the "Custom Elements" draft and are satisfied that all
their comments have been addressed before considering it ready for Last
Call. That has destroyed Last Call as a synchronisation mechanism, you
cannot use it to prioritise reviews because you do not know whether any
given Last Call will have one, two, or six more following it. That re-
sults in "late" comments and late changes which make temporal planning
impossible. People get frustrated that things take so long, that they
cannot keep up with the pace, stuff falls through the cracks, and so on.
-- 
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: [webcomponents] HTML Imports

[Brian Di Palma]

I never meant my comments to be taken as a slight toward anyone
involved in the Web Components work.
Neither did I mean it to be taken to mean "This work is rushed". I said,

"I get the feeling that Web Components seems a specification that
seems really pushed/rushed",

by that I meant it seemed as if the current spec is being pushed as
fast as possible toward standardization.

I was not commenting on the amount of time put into making the spec
but more the amount of time given to interested parties to digest,
implement, and comment on it.
I believe Dimitri has responded to comments to this effect by
extending the time between spec transitions.

I'm very excited by the possibilities that Web Components open up.
I would love to see the representatives from all the implementers as
excited or convinced about the spec.

On Wed, Dec 4, 2013 at 7:30 PM, Rafael Weinstein  wrote:
> On Wed, Dec 4, 2013 at 10:37 AM, Dimitri Glazkov 
> wrote:
>>
>> On Wed, Dec 4, 2013 at 9:56 AM, Dimitri Glazkov 
>> wrote:
>>>
>>> On Wed, Dec 4, 2013 at 4:32 AM, Anne van Kesteren 
>>> wrote:

 On Wed, Dec 4, 2013 at 9:21 AM, Brian Di Palma  wrote:
 > I would say though that I get the feeling that Web Components seems a
 > specification that seems really pushed/rushed and I worry that might
 > lead to some poor design decisions whose side effects will be felt by
 > developers in the future.

 I very much share this sentiment.
>>>
>>>
>>> It's a very reasonable and normal worry to have. I lose sleep over this
>>> worry all the time. The trick that helps me is balancing it out with the
>>> sadness of the geological timescale that it takes for Web platform to
>>> advance.
>>
>>
>> Just to help visualize the geological timescale, the work on Web
>> Components began in late 2010
>> (http://wiki.whatwg.org/index.php?title=Component_Model_Use_Cases&oldid=5631),
>> and was chartered in this WG over 2 years ago
>> (http://www.w3.org/2008/webapps/wiki/CharterChanges#Additions_Agreed).
>>
>> To clarify my previous email: Web Components is an extremely hard problem
>> with lots of constraints, and a concern would be that we miss some bits is
>> totally fair. Qualifying this work as "pushed/rushed" probably ain't.
>
>
> I'd like to make an aside about having respect for one-another's work.
>
> Dimitri, Alex, Dominic, Scott, Elliot and many others have put massive time
> into this problem over the course of many years now, and my view is that the
> design has evolved and accommodated a dizzying number of challenges and
> constraints.
>
> "What this is attempting is big & scary" is fair. "I haven't had time to
> digest the design" is fair. "I have the following specific issues" is fair.
> "This work is rushed" is always understood as an indictment.
>
> I've seen too many talented people vote with their feet and decide life will
> be less frustrating working on a closed system. Let's remember we're all on
> the same team.
>
> AFAICT, evolving the web is fundamentally an exercise in not letting perfect
> be the enemy of good. I have no doubt Web Components is imperfect, but from
> what I can tell, it is *extremely* good.
>
> Also, go hug your mother.
>
>
>>
>>
>> :DG<
>
>

Re: [webcomponents] HTML Imports

[Rafael Weinstein]

On Wed, Dec 4, 2013 at 10:37 AM, Dimitri Glazkov wrote:

> On Wed, Dec 4, 2013 at 9:56 AM, Dimitri Glazkov wrote:
>
>> On Wed, Dec 4, 2013 at 4:32 AM, Anne van Kesteren wrote:
>>
>>> On Wed, Dec 4, 2013 at 9:21 AM, Brian Di Palma  wrote:
>>> > I would say though that I get the feeling that Web Components seems a
>>> > specification that seems really pushed/rushed and I worry that might
>>> > lead to some poor design decisions whose side effects will be felt by
>>> > developers in the future.
>>>
>>> I very much share this sentiment.
>>>
>>
>> It's a very reasonable and normal worry to have. I lose sleep over this
>> worry all the time. The trick that helps me is balancing it out with the
>> sadness of the geological timescale that it takes for Web platform to
>> advance.
>>
>
> Just to help visualize the geological timescale, the work on Web
> Components began in late 2010 (
> http://wiki.whatwg.org/index.php?title=Component_Model_Use_Cases&oldid=5631),
> and was chartered in this WG over 2 years ago (
> http://www.w3.org/2008/webapps/wiki/CharterChanges#Additions_Agreed).
>
> To clarify my previous email: Web Components is an extremely hard problem
> with lots of constraints, and a concern would be that we miss some bits is
> totally fair. Qualifying this work as "pushed/rushed" probably ain't.
>

I'd like to make an aside about having respect for one-another's work.

Dimitri, Alex, Dominic, Scott, Elliot and many others have put massive time
into this problem over the course of many years now, and my view is that
the design has evolved and accommodated a dizzying number of challenges and
constraints.

"What this is attempting is big & scary" is fair. "I haven't had time to
digest the design" is fair. "I have the following specific issues" is fair.
"This work is rushed" is always understood as an indictment.

I've seen too many talented people vote with their feet and decide life
will be less frustrating working on a closed system. Let's remember we're
all on the same team.

AFAICT, evolving the web is fundamentally an exercise in not letting
perfect be the enemy of good. I have no doubt Web Components is imperfect,
but from what I can tell, it is *extremely* good.

Also, go hug your mother.



>
> :DG<
>

Re: [webcomponents] HTML Imports

[Bjoern Hoehrmann]

* Anne van Kesteren wrote:
>On Wed, Dec 4, 2013 at 9:21 AM, Brian Di Palma  wrote:
>> I would say though that I get the feeling that Web Components seems a
>> specification that seems really pushed/rushed and I worry that might
>> lead to some poor design decisions whose side effects will be felt by
>> developers in the future.
>
>I very much share this sentiment.

"The growth of HTML with scripting as an application platform has
exploded recently. One limiting factor of this growth is that there is
no way to formalize the services that an HTML application can provide,
or to allow them to be reused as components in another HTML page or
application." -- http://www.w3.org/TR/NOTE-HTMLComponents

That was 15 years ago. You might be able to appreciate that this may be
a case where the past is a lot longer than the future and in another 15
years "Web Components" as they are being proposed currently have moved
to museums that exhibit them as important evolutionary step that finally
gave web developers some kind of robust re-usable component technology.
-- 
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: [webcomponents] HTML Imports

[Dimitri Glazkov]

On Wed, Dec 4, 2013 at 9:56 AM, Dimitri Glazkov wrote:

> On Wed, Dec 4, 2013 at 4:32 AM, Anne van Kesteren wrote:
>
>> On Wed, Dec 4, 2013 at 9:21 AM, Brian Di Palma  wrote:
>> > I would say though that I get the feeling that Web Components seems a
>> > specification that seems really pushed/rushed and I worry that might
>> > lead to some poor design decisions whose side effects will be felt by
>> > developers in the future.
>>
>> I very much share this sentiment.
>>
>
> It's a very reasonable and normal worry to have. I lose sleep over this
> worry all the time. The trick that helps me is balancing it out with the
> sadness of the geological timescale that it takes for Web platform to
> advance.
>

Just to help visualize the geological timescale, the work on Web Components
began in late 2010 (
http://wiki.whatwg.org/index.php?title=Component_Model_Use_Cases&oldid=5631),
and was chartered in this WG over 2 years ago (
http://www.w3.org/2008/webapps/wiki/CharterChanges#Additions_Agreed).

To clarify my previous email: Web Components is an extremely hard problem
with lots of constraints, and a concern would be that we miss some bits is
totally fair. Qualifying this work as "pushed/rushed" probably ain't.

:DG<

Re: [webcomponents] HTML Imports

[Scott Miles]

> seems a specification that seems really pushed/rushed

Since my team (Polymer) has been working with imports in practice for a
year-and-a-half (100% public and open-source, btw) this seems a strange
conclusion. But this is only my perspective, I'm still a standards n00b I
suppose.

In any case, I codified the concepts that our team has been espousing in a
document here:

https://docs.google.com/document/d/14qJlCgda7GX2_KKxYhj1EULmY_hqNH35wjqDgGSkkOo/edit#

The aim of this document was to address some of the questions around
pragmatic operation of the spec as we see it.

Scott

On Wed, Dec 4, 2013 at 4:32 AM, Anne van Kesteren  wrote:

> On Wed, Dec 4, 2013 at 9:21 AM, Brian Di Palma  wrote:
> > I would say though that I get the feeling that Web Components seems a
> > specification that seems really pushed/rushed and I worry that might
> > lead to some poor design decisions whose side effects will be felt by
> > developers in the future.
>
> I very much share this sentiment.
>
>
> --
> http://annevankesteren.nl/
>

Re: [webcomponents] HTML Imports

[Dimitri Glazkov]

On Wed, Dec 4, 2013 at 4:32 AM, Anne van Kesteren  wrote:

> On Wed, Dec 4, 2013 at 9:21 AM, Brian Di Palma  wrote:
> > I would say though that I get the feeling that Web Components seems a
> > specification that seems really pushed/rushed and I worry that might
> > lead to some poor design decisions whose side effects will be felt by
> > developers in the future.
>
> I very much share this sentiment.
>

It's a very reasonable and normal worry to have. I lose sleep over this
worry all the time. The trick that helps me is balancing it out with the
sadness of the geological timescale that it takes for Web platform to
advance.

:DG<

Re: [webcomponents] HTML Imports

[Anne van Kesteren]

On Wed, Dec 4, 2013 at 9:21 AM, Brian Di Palma  wrote:
> I would say though that I get the feeling that Web Components seems a
> specification that seems really pushed/rushed and I worry that might
> lead to some poor design decisions whose side effects will be felt by
> developers in the future.

I very much share this sentiment.


-- 
http://annevankesteren.nl/

Re: [webcomponents] HTML Imports

[Brian Di Palma]

To be fair though Web Components are bleeding edge and the vast
majority of developers have had no interaction with them at all.
I work in a company that should see huge benefits from Web Components
as we build large scale browser applications and not one developer has
had the time to investigate Web Components properly.

I have even heard our developers say that Web Components are only for
small widgets like buttons and aren't designed for anything large
scale, basically a glorified "button" element.

People are busy and have jobs to do, I'd love to provide good feedback
on Web Components but time is a constraint.

I would say though that I get the feeling that Web Components seems a
specification that seems really pushed/rushed and I worry that might
lead to some poor design decisions whose side effects will be felt by
developers in the future.

Are we sure #include is what the web wants/needs?

On Wed, Dec 4, 2013 at 4:02 AM, Eric Bidelman  wrote:
>
>
>
> On Tue, Dec 3, 2013 at 7:03 PM, Ryosuke Niwa  wrote:
>>
>> On Oct 7, 2013, at 12:24 PM, Rafael Weinstein  wrote:
>>
>> On Mon, Oct 7, 2013 at 3:24 AM, James Graham 
>> 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 .
>>
>>
>> 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  wrote:
>>
>> On Mon, Oct 7, 2013 at 3:24 AM, James Graham 
>> 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,

Re: [webcomponents] HTML Imports

[Ryosuke Niwa]

On Dec 3, 2013, at 8:02 PM, Eric Bidelman  wrote:
> On Tue, Dec 3, 2013 at 7:03 PM, Ryosuke Niwa  wrote:
> On Oct 9, 2013, at 10:42 AM, Scott Miles  wrote:
> 
>> On Mon, Oct 7, 2013 at 3:24 AM, James Graham  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/

One minute of googling gave me an article that talks about HTML rel=import and 
says this is "the complex part" and that "[t]he spec doesn't address this 
issue":
http://www.stevesouders.com/blog/2013/11/16/async-ads-with-html-imports/

The article then proceeds to mention that there are many 3rd party ads that use 
document.write and suggests to manually override document.write when the entire 
problem wouldn't exist if the "document" was the imported document as expected 
by authors as mentioned by the article.

- R. Niwa

Re: [webcomponents] HTML Imports

[Eric Bidelman]

On Tue, Dec 3, 2013 at 7:03 PM, Ryosuke Niwa  wrote:

> On Oct 7, 2013, at 12:24 PM, Rafael Weinstein  wrote:
>
> On Mon, Oct 7, 2013 at 3:24 AM, James Graham 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 .
>
>
> 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  wrote:
>
> On Mon, Oct 7, 2013 at 3:24 AM, James Graham 
>  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
>
>

Re: [webcomponents] HTML Imports

[Ryosuke Niwa]

On Oct 7, 2013, at 12:24 PM, Rafael Weinstein  wrote:

> On Mon, Oct 7, 2013 at 3:24 AM, James Graham  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 .

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

> On Mon, Oct 7, 2013 at 3:24 AM, James Graham  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.


> 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

Re: [webcomponents] HTML Imports

[Dimitri Glazkov]

I remember Adam raving about HTML Imports being awesome after he tried
them. Adam, can you provide color? :)

:DG<


On Fri, Oct 18, 2013 at 4:11 PM, Scott Miles  wrote:

> >> they'll have to use a closure to capture the document that the template
> lives in
>
> Yes, this is true. But stamping of templates tends to be something custom
> elements are really good at, so this paritcular use case doesn't come up
> very often.
>
>
> >> Out of curiosity, what have the Polymer guys been using imports for?
>
> 1. Bundling resources. Imports can contain or chain to JS, CSS, or
> additional HTML imports, so I have access to bundles in silos of
> functionality instead of syntax.
>
> 2. Obscuring production details. I can import "library.html" and get an
> entire dependency without knowing if it's an optimized build file or a
> dependency tree of imports.
>
> 3. Relocatability. I can import "elements.html" and that package can
> reference resources relative to itself.
>
> 4. Importing data as markup, where typically it's then the responsibility
> of the importer to consume the data, not the import itself.
>
> 5. We would like to use imports for preloading images, depending on the
> resolution of the 'view-in-import' discussion.
>
> [sidebar] we tend to declare self-organizing custom elements for data and
> then load them in imports. For example, many of our library elements has an
> associated `metadata.html` file that contains `` elements with
> various details. An interested object can make an blank x-meta element to
> access the database, and the details are are encapsulated inside the x-meta
> implementation.
>
> Scott
>
> On Fri, Oct 18, 2013 at 3:37 PM, Blake Kaplan  wrote:
>
>> On Sun, Oct 6, 2013 at 9:38 AM, Dimitri Glazkov 
>> wrote:
>> >> So you have  in meh.html and blah.html is:
>> >> 
>> >>  /* how do I get to #test? */ 
>> > document.currentScript.ownerDocument.querySelector("#test") :)
>>
>> This only works for code running directly in the script. The current
>> setup means that any time an author has something like:
>>
>> ...
>> 
>> function cloneFoo() { /* get foo and return it. */ }
>> 
>>
>> they'll have to use a closure to capture the document that the
>> template lives in, which is rather surprising to me. Also, storing the
>> document in a global variable is a footgun, because that global
>> variable would potentially collide with another import trying to do
>> the same thing. ES6 modules would help here, but there a way's off.
>>
>> > I think the greatest impact here will be on developers. They have to
>> start
>> > thinking in terms of multiple documents. We should ask Polymer people:
>> they
>> > wrote a ton of code with Imports now and I bet they have opinions.
>>
>> Out of curiosity, what have the Polymer guys been using imports for?
>> More than just declaring custom elements? I'm worried that we're
>> coming up with a very generic feature with odd semantics that only
>> make sense for one narrow use-case.
>> --
>> Blake Kaplan
>>
>
>

Re: [webcomponents] HTML Imports

[Scott Miles]

>> they'll have to use a closure to capture the document that the template
lives in

Yes, this is true. But stamping of templates tends to be something custom
elements are really good at, so this paritcular use case doesn't come up
very often.

>> Out of curiosity, what have the Polymer guys been using imports for?

1. Bundling resources. Imports can contain or chain to JS, CSS, or
additional HTML imports, so I have access to bundles in silos of
functionality instead of syntax.

2. Obscuring production details. I can import "library.html" and get an
entire dependency without knowing if it's an optimized build file or a
dependency tree of imports.

3. Relocatability. I can import "elements.html" and that package can
reference resources relative to itself.

4. Importing data as markup, where typically it's then the responsibility
of the importer to consume the data, not the import itself.

5. We would like to use imports for preloading images, depending on the
resolution of the 'view-in-import' discussion.

[sidebar] we tend to declare self-organizing custom elements for data and
then load them in imports. For example, many of our library elements has an
associated `metadata.html` file that contains `` elements with
various details. An interested object can make an blank x-meta element to
access the database, and the details are are encapsulated inside the x-meta
implementation.

Scott

On Fri, Oct 18, 2013 at 3:37 PM, Blake Kaplan  wrote:

> On Sun, Oct 6, 2013 at 9:38 AM, Dimitri Glazkov 
> wrote:
> >> So you have  in meh.html and blah.html is:
> >> 
> >>  /* how do I get to #test? */ 
> > document.currentScript.ownerDocument.querySelector("#test") :)
>
> This only works for code running directly in the script. The current
> setup means that any time an author has something like:
>
> ...
> 
> function cloneFoo() { /* get foo and return it. */ }
> 
>
> they'll have to use a closure to capture the document that the
> template lives in, which is rather surprising to me. Also, storing the
> document in a global variable is a footgun, because that global
> variable would potentially collide with another import trying to do
> the same thing. ES6 modules would help here, but there a way's off.
>
> > I think the greatest impact here will be on developers. They have to
> start
> > thinking in terms of multiple documents. We should ask Polymer people:
> they
> > wrote a ton of code with Imports now and I bet they have opinions.
>
> Out of curiosity, what have the Polymer guys been using imports for?
> More than just declaring custom elements? I'm worried that we're
> coming up with a very generic feature with odd semantics that only
> make sense for one narrow use-case.
> --
> Blake Kaplan
>

Re: [webcomponents] HTML Imports

[Blake Kaplan]

On Sun, Oct 6, 2013 at 9:38 AM, Dimitri Glazkov  wrote:
>> So you have  in meh.html and blah.html is:
>> 
>>  /* how do I get to #test? */ 
> document.currentScript.ownerDocument.querySelector("#test") :)

This only works for code running directly in the script. The current
setup means that any time an author has something like:

...

function cloneFoo() { /* get foo and return it. */ }


they'll have to use a closure to capture the document that the
template lives in, which is rather surprising to me. Also, storing the
document in a global variable is a footgun, because that global
variable would potentially collide with another import trying to do
the same thing. ES6 modules would help here, but there a way's off.

> I think the greatest impact here will be on developers. They have to start
> thinking in terms of multiple documents. We should ask Polymer people: they
> wrote a ton of code with Imports now and I bet they have opinions.

Out of curiosity, what have the Polymer guys been using imports for?
More than just declaring custom elements? I'm worried that we're
coming up with a very generic feature with odd semantics that only
make sense for one narrow use-case.
-- 
Blake Kaplan

Re: [webcomponents] HTML Imports

[Dominic Cooney]

On Thu, Oct 10, 2013 at 2:42 AM, Scott Miles  wrote:

> On Mon, Oct 7, 2013 at 3:24 AM, James Graham 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
>
>


-- 

Re: [webcomponents] HTML Imports

[Scott Miles]

On Mon, Oct 7, 2013 at 3:24 AM, James Graham  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

Re: [webcomponents] HTML Imports

[Rafael Weinstein]

On Mon, Oct 7, 2013 at 3:24 AM, James Graham  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 .


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

Re: [webcomponents] HTML Imports

[James Graham]

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.


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.

Re: [webcomponents] HTML Imports

[Scott Miles]

> We should ask Polymer people: they wrote a ton of code with Imports now
and I bet they have opinions.

The Polymer team has successfully adopted/evolved the modality Dimitri
describes. Imported documents work roughly as #includes, and
`currentScript.ownerDocument` is interrogated if one needs to locate their
containing import from (non custom-element) script.

> I sincerely hope that when we get back to declarative form, we will be
able to write declarative custom element syntax as a custom element itself.
:)

Of course, this is exactly , and because it is itself an
element it has easy access to the import tree.



On Sun, Oct 6, 2013 at 9:38 AM, Dimitri Glazkov wrote:

>
>
>
> On Sun, Oct 6, 2013 at 9:21 AM, Anne van Kesteren wrote:
>
>> On Sun, Oct 6, 2013 at 5:25 PM, Dimitri Glazkov 
>> wrote:
>> > On Sun, Oct 6, 2013 at 6:26 AM, Angelina Fabbro <
>> angelinafab...@gmail.com>
>> > 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.
>>
>> So you have  in meh.html and blah.html is:
>>
>> 
>>  /* how do I get to #test? */ 
>>
>
> document.currentScript.ownerDocument.querySelector("#test") :)
>
>
>> Having thought a bit more about how declarative custom elements would
>> work that might not actually be much of a problem (assuming we go with
>> Allen's model), but it seems somewhat worrying that the document the
>>  elements are inserted in is not actually the one the scripts
>> operate on.
>>
>
> I think the greatest impact here will be on developers. They have to start
> thinking in terms of multiple documents. We should ask Polymer people: they
> wrote a ton of code with Imports now and I bet they have opinions.
>
>
>>
>> (The way I expect we'll do declarative custom elements is > constructor=X> combined with