Re: [webcomponents] How about let's go with slots?

[Scott Miles]

>> How does it work for redistribution

We've done some investigation and think it can work.

>> and the other downsides that have been brought up?

We have to tackle these deliberately, but mostly we think there is room for
consensus.

>> You're okay with the "required to plaster content-slot='foo' all
over your page" requirement?

Me personally, this is the least palatable part of the `slot` proposal. But
if after all the discussion is over, if the consensus is that the pros
outweigh the cons, then yeah it's not blocking from my perspective. For
sure, I'd at least like a shorter attribute name than `content-slot`, but
seems like that bikeshedding can wait until later. ;)

Scott

On Fri, May 15, 2015 at 5:24 PM, Tab Atkins Jr. 
wrote:

> On Fri, May 15, 2015 at 4:58 PM, Scott Miles  wrote:
> > Polymer really wants Shadow DOM natively, and we think the `slot`
> proposal
> > can work, so maybe let's avoid blocking on design of an imperative API
> > (which we still should make in the long run).
>
> How does it work for redistribution, and the other downsides that have
> been brought up?  Are you saying that those cases just aren't
> important enough to be blocking at the moment?
>
> You're okay with the "required to plaster content-slot='foo' all over
> your page" requirement?
>
> ~TJ
>

[webcomponents] How about let's go with slots?

[Scott Miles]

Polymer really wants Shadow DOM natively, and we think the `slot` proposal
can work, so maybe let's avoid blocking on design of an imperative API
(which we still should make in the long run).

As our entire stack is built on Web Components, the Polymer team is highly
motivated to assist browser implementers come to agreement on a Shadow DOM
specification. Specifically, as authors of the `webcomponents-js`
polyfills, and more than one Shadow DOM shim, we are keenly aware of how
difficult Shadow DOM is to simulate without true native support.

I believe we are in general agreement with the implementers that an
imperative API, especially one that cleanly explains platform behavior, is
an ideal end point for Shadow DOM distribution. However, as has been
discussed at length, it’s likely that a proper imperative API is blocked on
other still-to-mature technologies. For this reason, we would like for the
working group to focus on writing the spec for the declarative `slot`
proposal [1]. We're happy to participate in the process.

[1]:
https://github.com/w3c/webcomponents/blob/gh-pages/proposals/Proposal-for-changes-to-manage-Shadow-DOM-content-distribution.md#proposal-part-1-syntax-for-named-insertion-points

Re: [Imports]: Styleshet cascading order clarification

[Scott Miles]

I know this is probably the wrong place/time to say this, but fwiw, a
primary use case for imports is replacing:








Having the imported stylesheets apply to the main document is a big part of
the value here. If the stylesheets are for some other purpose, it's easy to
put them in a , but the reverse is not true.

I realize implementation difficulty may trump ergonomics, but I wanted to
make sure this part was heard.

Scott


On Mon, Nov 3, 2014 at 10:12 AM, Tab Atkins Jr. 
wrote:

> On Mon, Nov 3, 2014 at 7:28 AM, Gabor  Krizsanits
>  wrote:
> > During our last meeting we all seemed to agree on that
> defining/implementing
> > order for style-sheets is imports is super hard (if possible) and will
> bring more
> > pain than it's worth for the web (aka. let's not make an already
> over-complicated
> > system twice as complicated for very little benefits). And the consensus
> was that we
> > should just not allow global styles in imports.
> >
> > Some months has passed but I still don't see any update on the spec. in
> this regard,
> > so I'm just double checking that we still planning to do this or if
> anything changed
> > since then.
>
> Out of curiosity, why is it hard?  Without much background in the
> implementation matters, it doesn't seem that a  that
> contains a  should be any different than a  rel=stylesheet> that contains an @import rule.
>
> ~TJ
>
>

Re: Relative URLs in Web Components

[Scott Miles]

> The URL is parsed again? That seems like something that should not
> happen. Are you copying the node perhaps?

There is no explicit copying, but I don't know if there is something
implicit happening when the element goes trans-document.

Sample code (assume index.html that imports import/import.html).







  // node above in this import
  var img = document.currentScript.ownerDocument.querySelector('img');

  console.log(img.src, img.getAttribute('src'));
  // > 'import/beaker.jpg', 'beaker.jpg'

  // do this to freeze the src
  //img.src = img.src;

  // move node to window.document
  document.body.appendChild(img);

  console.log(img.src, img.getAttribute('src'));
  // > 'beaker.jpg', 'beaker.jpg'

  // img.src is 404




Live version at http://sjmiles.github.io/import-beaker/ (needs Chrome for
HTMLImports).

> neither of these solves the case for a script in an
> imported document
> [that would] require usage of the URL API to properly resolve base URLs
first which
> not likely something you would think about.

Very true. For Polymer we took this hit and gave every element a
`resolvePath` fixup method. As you say, you'd never consider this without
documentation, and some lose a toe. Otoh, it may be a survivable
compromise. Anecdotally, it hasn't come up with heinous frequency, and the
solution seems to appease those who find it.

> The lack of encapsulation is major hassle.

I'm not sure what you mean, can you elaborate? If this is the root cause,
maybe we attack it there.

Thanks,
Scott

On Sun, Oct 5, 2014 at 1:09 AM, Anne van Kesteren  wrote:

> On Sat, Oct 4, 2014 at 7:00 PM, Scott Miles  wrote:
> > An issue is that a relative URL is only correct as long as the `img` (for
> > example) is owned by the import. If you migrate the element to the main
> > document, the path is now relative to the wrong base, and users are
> > confused. One can do `img.src = img.src;` before migrating the node, and
> > that will freeze the resolved path, but this is somewhat arcane.
>
> The URL is parsed again? That seems like something that should not
> happen. Are you copying the node perhaps?
>
>
> > As Anne points out, this issue is worse when you start using templates.
> The
> > `img` in the template isn't live and never has a resolved `src` property.
> >
> > If the use cases are:
> >
> > - migrating a sub-tree from an import to another document
> > - migrating a sub-tree from a template to another document
> >
> > In both cases, users frequently want migrated elements to retain a base
> URL
> > from the original document (except when they don't, for example when they
> > are using anchor links, href="#foo" =/).
>
> This problem stems directly from components not having proper
> encapsulation.
>
> There's two ways this can be solved and neither seems particularly
> attractive:
>
> 1) We parse imported documents in a special way. Either having
> elements parse their URLs at an earlier point or actually storing the
> parsed URL in the tree. Note that this would also require a special
> parsing mode for CSS and that we would have to parse CSS (not apply)
> even in .
>
> 2) Rather than document-scoped, we make base URLs node-scoped and
> provide a way to move a node around while preserving its base URL
> (node because at least Element and DocumentFragment would need this).
> The implications here at that URL parsing for every node becomes a
> more expensive operation due to tree traversal.
>
> And again, neither of these solves the case for a script in an
> imported document setting innerHTML, or fetching something. They would
> require usage of the URL API to properly resolve base URLs first which
> is not likely something you would think about.
>
> The lack of encapsulation is major hassle.
>
>
> --
> https://annevankesteren.nl/
>

Re: Relative URLs in Web Components

[Scott Miles]

An issue is that a relative URL is only correct as long as the `img` (for
example) is owned by the import. If you migrate the element to the main
document, the path is now relative to the wrong base, and users are
confused. One can do `img.src = img.src;` before migrating the node, and
that will freeze the resolved path, but this is somewhat arcane.

As Anne points out, this issue is worse when you start using templates. The
`img` in the template isn't live and never has a resolved `src` property.

If the use cases are:

- migrating a sub-tree from an import to another document
- migrating a sub-tree from a template to another document

In both cases, users frequently want migrated elements to retain a base URL
from the original document (except when they don't, for example when they
are using anchor links, href="#foo" =/).

I've hand-waved definitions of 'migrating', 'base URL', and 'original
document', but I'm only trying to frame the (as Anne said, hard) problem.

Scott

On Sat, Oct 4, 2014 at 6:27 AM, Anne van Kesteren  wrote:

> On Thu, Oct 2, 2014 at 3:09 PM, Anne van Kesteren 
> wrote:
> > This is a hard problem:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20976#c8
>
> I saw you commented on the bug, but I prefer keeping that bug focused
> on several other problems around base URLs so let's continue here. You
> gave this example:
>
> # Consider this document, located at
> # https://example.com/some-component/import-me.html:
> #
> #   
> #
> # It would be nice if the import process would *somehow*
> # turn that into…
> #
> #   https://example.com/some-component/foo>
> #
> # …before inserting it into the parent document.
>
> As far as I can tell this particular example should already work. The
> base URL for that  element will be that of the document it is in,
> which is the import (at least per the algorithms in HTML Imports).
> What makes you think it would not work?
>
> The problem is with  as that isolates elements which will
> therefore not be processed and their associated URLs will therefore
> not parse, etc. Now we could perhaps add a special
> in--processing model for all elements that can have one or
> more associated URLs, or something along those lines, but it's not
> clear that's worth it.
>
>
> --
> https://annevankesteren.nl/
>
>

Re: [HTML Imports] What is the imagined work flow?

[Scott Miles]

Sorry, but just a bit of follow up.

One may notice that the Web Components spec is imperative and assume that
declarative support is not important. But as it turns out, the notion of
using custom-elements to bootstrap declarative syntaxes allows various
parties to experiment in the real-world, as opposed to a working group
trying to resolve the trade-offs in an a-priori spec.

I mention this, because although I used Polymer as an example (it's my
project after all), the fact is we hope people will use web-components like
this:


...


Is  implemented via Polymer? X-tags? Vanilla JavaScript? User
doesn't need to know to use the resource.

Ideally, best-of-breed technology emerges and the option to standardize is
still available.



On Tue, May 20, 2014 at 11:56 PM, Scott Miles  wrote:

> Some of the ways Polymer team uses imports are as follows:
>
> - aggregating 

Re: [HTML Imports] What is the imagined work flow?

[Scott Miles]

Some of the ways Polymer team uses imports are as follows:

- aggregating 

Re: [Custom Elements] attributeChanged not sufficient?

[Scott Miles]

I certainly support some kind of per-element media query, or resize event,
if the well-known performance issues around these ideas can be resolved,
but otherwise Custom Elements don't have a lot to say about this problem.

>> Typically, when using a plain JS API (and not a custom declarative
markup), users are used to call a size synchronization routine, shall the
map viewport change.

This notion hasn't changed. In the absence of native resize signals,
applications or frameworks will need to manage this information themselves,
and broadcast custom signals (e.g. 'call a size synchronization routine').

Fwiw, I believe this question is orthogonal to `attributeChanged` (or
attributes in general).

Scott


On Mon, Mar 31, 2014 at 4:20 AM, Ondřej Žára wrote:

> Hi,
>
> let me introduce my Custom Element scenario: an interactive map element,
> powered by one of the well-known JS APIs (such as Google Maps API or so).
>
> Typically, the markup will be like
>
> 
>
> However, the underlying JS needs to know when this element's rendered size
> changes; the viewport needs to be filled with new map tiles and other geo
> data.
>
> Typically, when using a plain JS API (and not a custom declarative
> markup), users are used to call a size synchronization routine, shall the
> map viewport change. This is no longer the case when a Custom Element is
> introduced (and scripting is replaced by declarative HTML).
>
> A user may insert a map element anywhere in the page (see
> http://api4.mapy.cz/ for reference), including a variable-width box in a
> sidebar or so. This means that the  element itself cannot determine
> when its own (rendered) size changes, as the attributeChanged callback only
> applies to own attributes.
>
> Is there some recommended way of dealing with this?
>
>
> Sincerely,
> Ondrej Zara
>
>
>
> --
> *RNDr. Ondřej Žára*
> Programátor UI senior
>
> https://twitter.com/0ndras
> ondrej.z...@firma.seznam.cz 
> http://www.seznam.cz/
>
> Seznam.cz, a.s., Radlická 3294/10, 150 00 Praha 5 
>
>
>
>

Re: [custom-elements] :unresolved and :psych

[Scott Miles]

Yes, I agree with what R. Niwa says.

I believe there are many variations on what should happen during element
lifecycle, and the element itself is best positioned to make those choices.

`:unresolved` is special because it exists a-priori to the element having
any control.

Scott


On Wed, Mar 26, 2014 at 12:26 PM, Ryosuke Niwa  wrote:

> Maybe the problem comes from not distinguishing elements being created and
> ready for API access versus elements is ready for interactions?
>
> I’d also imagine that the exact appearance of a custom element between the
> time the element is created and the time it is ready for interaction will
> depend on what the element does.   e.g. img behaves more or less like
> display:none at least until the dimension is available, and then updates
> the screen as the image is loaded.  iframe on the other hand will occupy
> the fixed size in accordance to its style from the beginning, and simply
> updates its content.
>
> Given that, I’m not certain adding another pseudo element in UA is the
> right approach here.  I suspect there could be multiple states between the
> time element is created and it’s ready for user interaction for some custom
> elements.  Custom pseudo, for example, seems like a more appealing solution
> in that regard.
>
> - R. Niwa
>
> On Mar 25, 2014, at 2:31 PM, Brian Kardell  wrote:
>
> I'm working with several individuals of varying skillsets on using/making
> custom elements - we are using a way cut-back subset of what we think are
> the really stable just to get started but I had an observation/thought that
> I wanted to share with the list based on feedback/experience so far...
>
> It turns out that we have a lot of what I am going to call "async
> components" - things that involve calling 1 or more services during their
> creation in order to actually draw something useful on the screen.  These
> range from something simple like an RSS element (which, of course, has to
> fetch the feed) to complex wizards which have to consult a service to
> determine which view/step they are even on and then potentially additional
> request(s) to display that view in a good way.  In both of these cases I've
> seen confusion over the :unresolved pseudo-class.  Essentially, the created
> callback has happened so from the currently defined lifecycle state it's
> ":resolved", but still not useful.  This can easily be messed up at both
> ends (assuming that the thing sticking markup in a page and the CSS that
> styles it are two ends) such that we get FOUC garbage between the time
> something is ":resolved" and when it is actually conceptually "ready".  I
> realize that there are a number of ways to work around this and maybe do it
> "properly" such that this doesn't happen, but there are an infinitely
> greater number of ways to barf unhappy content into the screen before its
> time.  To everyone who I see look at this, it seems they conceptually
> associate :resolved with "ok it's ready," and my thought is "that isn't
> necessarily an insensible thing to think since there is clearly a
> pseudo-class about 'non-readiness' of some kind and nothing else that seems
> to address this".
>
> I see a few options, I think all of them can be seen as enhancements, not
> necessary to a v1 spec if it is going to hold up something important.   The
> first would be to let the created callback optionally return a promise - if
> returned we can delay :resolved until the promise is fulfilled.  The other
> is to introduce another pseudo like ":loaded" and let the author
> participate in that somehow, perhaps the same way (optionally return a
> promise from created).  Either way, it seems to me that if we had that, my
> folks would use that over the current definition of :resolved in a lot of
> cases.
>
>
>
> --
> Brian Kardell :: @briankardell :: hitchjs.com
>
>
>

Re: [HTML imports]: Imports and Content Security Policy

[Scott Miles]

I'm hoping there are some constraints we can impose on imports to allow
them to contain inline scripts to exist under CSP.

Failing that, we already have a tool ('vulcanizer') which can separate
scripts out of imports (and to the reverse as well).

Whether an import uses inline or external scripts is invisible to the
importer.


On Wed, Jan 29, 2014 at 5:47 PM, Gabor Krizsanits
wrote:

> One more thing that little bit worries me, that the most common request
> when it comes to CSP is banning inline scripts. If all the imports obey the
> CSP of the master, which I think the only way to go, that also probably
> means that in most cases we can only use imports those do not have any
> inline scripting either... I think this should be mentioned in the spec.
> Since if you develop some huge library let's say, based on imports, and
> then no costumer can use it who also want to have CSP, because it's full of
> inline scripts, that would be quite annoying.
>
>
>

Re: [webcomponents] Auto-creating shadow DOM for custom elements

[Scott Miles]

You cannot pass the shadow root to the constructor, because each class in
the chain can have it's own shadow root. This is the core of the problem.



On Fri, Dec 13, 2013 at 1:16 AM, Maciej Stachowiak  wrote:

>
> On Dec 9, 2013, at 11:13 AM, Scott Miles  wrote:
>
> Domenic Denicola a few messages back gave a highly cogent explanation of
> the exact line of thinking arrived at last time we went through all this
> material.
>
> I'm not wont to try to summarize it here, since he said it already better
> there. Perhaps the short version is: nobody knows what the 'standard use
> case' is yet.
>
> In previous adjudications, the straw that broke that camel's back was with
> respect to handling auto-generation with inheritance. Shadow-roots may need
> to be generated for each entry in the inheritance chain. Having the system
> perform this task takes it out of the control of the user's code, which
> otherwise has ability to modulate calls to super-class methods and manage
> this process.
>
> class XFoo {
>  constructor_or_createdCallback: function() {
> // my shadowRoot was auto-generated
>this.doUsefulStuffLikeDatabinding(this.shadowRoot);
>  }
> }
>
> class XBar extends XFoo {
>  constructor_or_createdCallback: function() {
>super(); // uh-oh, super call operates on wrong shadowRoot
>  }
> }
>
>
> If the shadow root is optionally automatically generated, it should
> probably be passed to the createdCallback (or constructor) rather than made
> a property named "shadowRoot". That makes it possible to pass a different
> shadow root to the base class than to the derived class, thus solving the
> problem.
>
> Using an object property named "shadowRoot" would be a bad idea in any
> case since it automatically breaks encapsulation. There needs to be a
> private way to store the shadow root, either using ES6 symbols, or some new
> mechanism specific to custom elements. As it is, there's no way for ES5
> custom elements to have private storage, which seems like a problem. They
> can't even use the closure approach, because the constructor is not called
> and the methods are expected to be on the prototype. (I guess you could
> create per-instance copies of the methods closing over the private data in
> the created callback, but that would preclude prototype monkeypatching of
> the sort built-in HTML elements allow.)
>
> Regards,
> Maciej
>
>
>

Re: [custom elements] Improving the name of document.register()

[Scott Miles]

I also agree with Ted.

I prefer 'registerElement' because I'm used to the concept of registration
wrt custom elements, but I'm not ginding any axe.

Scott


On Wed, Dec 11, 2013 at 6:46 PM, Dominic Cooney  wrote:

> On Thu, Dec 12, 2013 at 5:17 AM, pira...@gmail.com wrote:
>
>> I have seen registerProtocolHandler() and it's being discused
>> registerServiceWorker(). I believe registerElementDefinition() or
>> registerCustomElement() could help to keep going on this path.
>>
>> Send from my Samsung Galaxy Note II
>> El 11/12/2013 21:10, "Edward O'Connor"  escribió:
>>
>> Hi,
>>>
>>> The name "register" is very generic and could mean practically anything.
>>> We need to adopt a name for document.register() that makes its purpose
>>> clear to authors looking to use custom elements or those reading someone
>>> else's code that makes use of custom elements.
>>>
>>
> I support this proposal.
>
>
>>  Here are some ideas:
>>>
>>> document.defineElement()
>>> document.declareElement()
>>> document.registerElementDefinition()
>>> document.defineCustomElement()
>>> document.declareCustomElement()
>>> document.registerCustomElementDefinition()
>>>
>>> I like document.defineCustomElement() the most, but
>>> document.defineElement() also works for me if people think
>>> document.defineCustomElement() is too long.
>>>
>>>
> I think the method should be called registerElement, for these reasons:
>
> - It's more descriptive about the purpose of the method than just
> "register."
> - It's not too verbose; it doesn't have any redundant part.
> - It's nicely parallel to registerProtocolHandler.
>
> If I had to pick from the list Ted suggested, I think defineElement is the
> best of that bunch and also an improvement over just "register". It doesn't
> line up with registerProtocolHandler, but there's some poetry to
> defineElement/createElement.
>
>
>>> Ted
>>>
>>> P.S. Sorry for the bikeshedding. I really believe we can improve the
>>> name of this function to make its purpose clear.
>>
>>
> I searched for bugs on this and found none; I expect this was discussed
> but I can't find a mail thread about it. The naming of register is
> something that's been on my mind so thanks for bringing it up.
>
> Dominic
>

Re: [webcomponents] Auto-creating shadow DOM for custom elements

[Scott Miles]

Domenic Denicola a few messages back gave a highly cogent explanation of
the exact line of thinking arrived at last time we went through all this
material.

I'm not wont to try to summarize it here, since he said it already better
there. Perhaps the short version is: nobody knows what the 'standard use
case' is yet.

In previous adjudications, the straw that broke that camel's back was with
respect to handling auto-generation with inheritance. Shadow-roots may need
to be generated for each entry in the inheritance chain. Having the system
perform this task takes it out of the control of the user's code, which
otherwise has ability to modulate calls to super-class methods and manage
this process.

class XFoo {

 constructor_or_createdCallback: function() {

// my shadowRoot was auto-generated

   this.doUsefulStuffLikeDatabinding(this.shadowRoot);

 }
}

class XBar extends XFoo {

 constructor_or_createdCallback: function() {

   super(); // uh-oh, super call operates on wrong shadowRoot

 }
}

Scott


On Mon, Dec 9, 2013 at 7:20 AM, Brian Kardell  wrote:

> +public-nextweb _ i encourage folks there to check out
> public-webapps@w3.org as this conversation is deep and multi-forked and I
> am late to the party.
>
> On Dec 7, 2013 4:44 PM, "Brendan Eich"  wrote:
> >
> > What does polymer do? Cows are already treading paths.
> >
> > I still smell a chance to do better out of the gate (gave, thanks
> autospellcheck! lol). Call me picky. Knee-jerking about scenario solving (I
> think I taught Yehuda that one) doesn't help. Particular response, please.
> >
> > /be
> >
>
> I think the most important part is to first ensure that we -can- explain
> the magic with core apis even if they are initially saltier than we'd all
> like.  When reasonable opportunities present themselves to improve
> developer ergonomics, we should take them - it doesn't preclude other
> opportunities for better flowers to bloom.
>
> The issues in this specific case in my mind surround the observation that
> it feels like it is attempting to bind several layers together which are in
> various states of "done" and conceptually what we have is more like a
> squirrel path than a cow path on this piece.  Without bindings or some kind
> of  pattern for solving those use cases, template is a less thing - and i
> think we are far from that.Templates aren't necessary for a useful
> document.register().  Shadow DOM isn't either but it's more obvious where
> the connections are and it seems considerably more stable.  There also
> isn't necessarily a 1:1 relationship of component to template, so we have
> to be careful there lest we add confusion.  Is this really a ShadowHost?
>
> I am not actually sure that the initial message in this thread really
> needs to have anything particular to the template element though, it looks
> like the optional third argument could be any Node - and that does actually
> seem to describe a useful and common pattern which we could easily explain
> in existing terms and it might be fruitful to think about that.
>

Re: [webcomponents] Decoupling Custom Elements and Shadow DOM (Was Proposal for Cross Origin Use Case and Declarative Syntax)

[Scott Miles]

>> We don't think decoupling custom elements and shadow DOM completely is
useful given that most important and natural use cases of custom elements
involve the use of shadow DOM.

Separating concerns is always useful, especially when it involves
contentious standards.

I also would like to point out that Mozilla's X-Tags/Brick custom elements
library is built entirely without Shadow DOM.

>> creating shadow DOM when an optional parameter is specified will give us
a way to constrain the scope of shadow DOM

As Dimitri mentioned, we very much wanted to use this approach ourselves,
but we determined it was naive given: (1) the complexities it introduces
for inheritance and (2) the flexibility end-users required for manipulating
templates and shadow roots.

Scott

On Thu, Dec 5, 2013 at 7:14 PM, Ryosuke Niwa  wrote:

> On Nov 12, 2013, at 12:45 AM, Ryosuke Niwa  wrote:
>
> On Nov 12, 2013, at 8:12 AM, Dimitri Glazkov 
> wrote:
>
> 2) It couples templates, shadow DOM, and custom elements in a way that's
> highly opinionated and inflexible. Throughout this year, we've tried many
> various ways to get this right, and failed [2]. I highly recommend that we
> avoid putting this into a specification now. Instead, we should let the
> best practices evolve and build on the cowpaths.
>
>
> We don't think decoupling custom elements and shadow DOM completely is
> useful given that most important and natural use cases of custom elements
> involve the use of shadow DOM.
>
> As I mentioned on other thread titled "auto-creating shadow DOM for custom
> elements", creating shadow DOM when an optional parameter is specified will
> give us a way to constrain the scope of shadow DOM to custom elements and
> move the shadow DOM specification forward without having to resolve all
> issues associated with attaching shadow DOMs to builtin elements.
>
> - R. Niwa
>
>

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: [HTML Imports]: Sync, async, -ish?

[Scott Miles]

I believe the primary issue here is 'synchronous with respect to
rendering'. Seems like you ignored this issue. See Brian's post.

Scott


On Mon, Nov 18, 2013 at 5:47 PM, John J Barton
wrote:

>
>
>
> On Mon, Nov 18, 2013 at 3:06 PM, Scott Miles  wrote:
>
>> >> I'll assert that the primary use case for JS interacting with HTML
>> components ought to be 'works well with JS modules'.
>>
>> You can happily define modules in your imports, those two systems are
>> friends as far as I can tell. I've said this before, I've yet to hear the
>> counter argument.
>>
>
> Yes indeed. Dimitri was asking for a better solution, but I agree that
> both are feasible and compatible.
>
>
>>
>> >> But if you believe in modularity for Web Components then you should
>> believe in modularity for JS
>>
>> Polymer team relies on Custom Elements for JS modularity. But again, this
>> is not mutually exclusive with JS modules, so I don't see the problem.
>>
>
> Steve's example concerns synchrony between 

Re: [HTML Imports]: what scope to run in

[Scott Miles]

I've made similar comments on various threads, so sorry if you've heard
this song before, but here are some basic comments:

The HTMLImports we've been working with so far is not primarily about JS,
it's about HTML.
There are already various ways to modularize JS, including requirejs, other
libs, and of course, ES6 modules.
Isolation of globals has definite use cases, but it also has costs, and is
more intervention than is required for first-party use cases. It's been
argued (convincingly, from my perspective) that isolation can be
successfully implemented via a separate opt-in mechanism.

There are the principles that guide the design as it is now. You have lots
of interesting ideas there, but it feels like re-scoping the problem into a
declarative form of JS modules. I suggest that keeping HTMLImports as
primitive as possible is a virtue on almost all fronts.

Scott



On Mon, Nov 18, 2013 at 4:14 PM, Jonas Sicking  wrote:

> Hi All,
>
> Largely independently from the thread that Dimitri just started on the
> sync/async/-ish nature of HTML imports I have a problem with how
> script execution in the imported document works.
>
> Right now it's defined that any 

Re: [HTML Imports]: Sync, async, -ish?

[Scott Miles]

>> Scott, is that because of what I said above (why polymer has the exact
opposite desire)?

Yes. Plus some salt from the KISS principle.

>>  I feel like it is maybe valuable to think that we should worry about
how you express [dependencies] in JS

I guess I thought ES6 modules already went through all these issues. I'm
happy to let modules be The Way for handling JS dependencies. Imports can
provide an entree to modules *and* be a vehicle for my other stuff.

Scott

On Mon, Nov 18, 2013 at 3:56 PM, Brian Kardell  wrote:

> Mixed response here...
>
> >> I love the idea of making HTML imports *not* block rendering as the
> default behavior
> In terms of custom elements, this creates as a standard, the dreaded FOUC
> problem about which a whole different group of people will be blogging and
> tweeting... Right?  I don't know that the current solution is entirely
> awesome, I'm just making sure we are discussing the same fact.  Also, links
> in the head and links in the body both "work" though the spec disallows the
> later it is defacto - the former blocks, the later doesn't I think.
>  This creates some interesting situations for people that use something
> like a CMS where they don't get to own the head upfront.
>
> > So, for what it's worth, the Polymer team has the exact opposite
> desire. I of course acknowledge use cases
> > where imports are being used to enhance existing pages, but the
> assertion that this is the primary use case is > at least arguable.
>
> Scott, is that because of what I said above (why polymer has the exact
> opposite desire)?
>
> >  if we allow "Expressing the dependency in JS" then why doesn't 'async'
> (or 'sync') get us both what we want?
>
> Just to kind of flip this on its head a bit - I feel like it is maybe
> valuable to think that we should worry about how you express it in JS
> *first* and worry about declarative sugar for one or more of those cases
> after.  I know it seems the boat has sailed on that just a little with
> imports, but nothing is really final else I think we wouldnt be having this
> conversation in the first place.  Is it plausible to excavate an
> explantation for the imports magic and define a JS API and then see how we
> tweak that to solve all the things?
>
>
>

Re: [HTML Imports]: Sync, async, -ish?

[Scott Miles]

>> I'll assert that the primary use case for JS interacting with HTML
components ought to be 'works well with JS modules'.

You can happily define modules in your imports, those two systems are
friends as far as I can tell. I've said this before, I've yet to hear the
counter argument.

>> But if you believe in modularity for Web Components then you should
believe in modularity for JS

Polymer team relies on Custom Elements for JS modularity. But again, this
is not mutually exclusive with JS modules, so I don't see the problem.

>> Dimitri's proposal makes the async case much more difficult: you need
both the link tag with async attribute then again you need to express the
dependency with the clunky onload busines

I believe you are making assumptions about the nature of link and async.
There are ways of avoiding this problem, but it begs the question, which
is: if we allow "Expressing the dependency in JS" then why doesn't 'async'
(or 'sync') get us both what we want?

Scott

On Mon, Nov 18, 2013 at 2:58 PM, John J Barton
wrote:

>
>
>
> On Mon, Nov 18, 2013 at 2:33 PM, Scott Miles  wrote:
>
>> >> I love the idea of making HTML imports *not* block rendering as the
>> default behavior
>>
>> So, for what it's worth, the Polymer team has the exact opposite
>> desire. I of course acknowledge use cases where imports are being used to
>> enhance existing pages, but the assertion that this is the primary use case
>> is at least arguable.
>>
>
> I'll assert that the primary use case for JS interacting with HTML
> components ought to be 'works well with JS modules'. Today, in the current
> state of HTML Import and JS modules, this sounds too hard. But if you
> believe in modularity for Web Components then you should believe in
> modularity for JS (or look at the Node ecosystem) and gee they ought to
> work great together.
>
>
>>
>>
>> >>  It would be the web dev's responsibility to confirm that the import
>> was done loading
>>
>> Our use cases almost always rely on imports to make our pages sane.
>> Requiring extra code to manage import readiness is a headache.
>>
>
> I think your app would be overall even more sane if the dependencies were
> expressed directly where they are needed. Rather than loading components
> A,B,C,D then some JS that uses B,C,F, just load the JS and let it pull B,
> C, F.  No more checking back to the list of  to compare to the JS
> needs.
>
>
>>
>> Dimitri's proposal above tries to be inclusive to both world views, which
>> I strongly support as both use-cases are valid.
>>
>
> Dimitri's proposal makes the async case much more difficult: you need both
> the link tag with async attribute then again you need to express the
> dependency with the clunky onload business. Expressing the dependency in JS
> avoids both of these issues.
>
> Just to point out: System.component()-ish need not be blocked by
> completing ES module details and my arguments only apply for JS dependent
> upon Web Components.
>
>
>>
>>
>> Scott
>>
>> On Mon, Nov 18, 2013 at 2:25 PM, Steve Souders wrote:
>>
>>> I love the idea of making HTML imports *not* block rendering as the
>>> default behavior. I believe this is what JJB is saying: make >> rel=import> NOT block 

Re: [HTML Imports]: Sync, async, -ish?

[Scott Miles]

>> I love the idea of making HTML imports *not* block rendering as the
default behavior

So, for what it's worth, the Polymer team has the exact opposite desire. I
of course acknowledge use cases where imports are being used to enhance
existing pages, but the assertion that this is the primary use case is at
least arguable.

>>  It would be the web dev's responsibility to confirm that the import was
done loading

Our use cases almost always rely on imports to make our pages sane.
Requiring extra code to manage import readiness is a headache.

Dimitri's proposal above tries to be inclusive to both world views, which I
strongly support as both use-cases are valid.

Scott

On Mon, Nov 18, 2013 at 2:25 PM, Steve Souders  wrote:

> I love the idea of making HTML imports *not* block rendering as the
> default behavior. I believe this is what JJB is saying: make  rel=import> NOT block 

Re: [webcomponents] Proposal for Cross Origin Use Case and Declarative Syntax

[Scott Miles]

> pollute the window object with $, with ES6 modules around the corner

The $ was just an example, the import could also happily define one or more
modules. This concept allows us to decouple scoping from imports.

Now, the import is only a vehicle, but it advances the state of the art by
also delivering canonical HTML and CSS (instead of requiring JavaScript to
load or encode additional resources). We right away have an efficient
method for draining some of the existing resource management swamp.

>From there I can see paths to supporting opt-in isolation models, either
directly, or by delegating to an agent like DOMWorker.


On Tue, Nov 12, 2013 at 3:21 PM, Brian Di Palma  wrote:

> I'm not sure I would want jQuery UI to pollute the window object with
> $, with ES6 modules around the corner it seems like a step backwards
> for imports to start polluting window objects with their libraries...
>
> On Tue, Nov 12, 2013 at 9:01 PM, Elliott Sprehn  wrote:
> >
> > On Tue, Nov 12, 2013 at 12:45 AM, Ryosuke Niwa  wrote:
> >>
> >> [...]
> >>
> >> Script in the import is executed in the context of the window that
> >> contains the importingdocument. So window.document refers to the main
> page
> >> document. This has two useful corollaries:
> >>
> >> functions defined in an import end up on window.
> >> you don't have to do anything crazy like append the import's 

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

[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

[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