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

Dimitri,

Thank you for your excellent reply.

As you mention the dependency resolution properties are also available
in ES6 modules.
I feel there is a case to be made for ES6 modules being used for any
resource type loading.

e.g.

https://github.com/briandipalma/spa-2014-app/blob/master/src/SpaApplicationElement.js

This Custom Element is able to load in it's dependent styling and
template information.
Albeit it requires extensions to the ES6 module loader they are not
exceptionally complex.

My preference for a ES6 module solution is biased by the fact I spend
most of my time in JS code.
I can imagine people who want to drop in some some broadly reusable
functionality (social widgets etc) would prefer a HTML Import.
If it's just a matter of adding a tag and either works then I'd
question the use of two broadly similar specs.

It might be easier to add native CSS and HTML loading to ES6 modules
then to add HTMLImports to the platform.

B.

On Fri, May 23, 2014 at 6:42 PM, Dimitri Glazkov <dglazkov@chromium.org> wrote:
> Brian,
>
> I believe Scott enumerated all these in his initial reply, but here's
> my take (I wrote parts of this in another email, my apologies to that
> email's recipient for repeating myself :)
>
> HTML Imports are primarily about dependency resolution. They allow the
> web developer to think locally in terms of their dependencies. Then,
> the underlying machinery builds a global dependency graph and turns it
> into a tree to ensure consistent processing order.
>
> Scripts in the imports are evaluated in this order. In addition, HTML
> Imports load/apply styles to the document in the same order, which
> enables a much saner way to reason about components and their effects.
>
> For example, in Jan Miksovsky's presentation at SFHTML5 event, he shows
> something very interesting
> (https://www.youtube.com/watch?feature=player_detailpage&v=mN7IAaRdi_k#t=8608).
>
> He pastes
>
> <link rel="import"
> href="http://component.kitchen/packages/sample/basic-autosize-textarea/basic-autosize-textarea.html">
>
> in a jsbin and instantly gets his custom element work (modulo the
> platform.js polyfill, which will eventually not be necessary). This is
> super important. A typical way to do this prior to imports is:
>
> 1) Add the <script src> reference to the library that was used to
> develop this component
> 2) Add the link to the stylesheets that will be used by the component
> 3) Add the <script src> reference to the component itself.
> 4) In the script of the component, there will probably be some strings
> that are turned into DOM.
> 5) More than likely, there will be more links to other scripts or some
> machinery to munge all these scripts into one large one.
>
> Effectively, since there isn't a way to manage dependencies, this work
> would be relegated to build tools.
>
> With HTML Imports, Jan is able to do something for more elegant -- a
> single-line solution.
>
> This works, because HTML Imports carefully resolve the dependency tree
> for him. And this dependency tree is actually non-trivial (you can
> trace it with me by viewing source of
> http://component.kitchen/packages/sample/basic-autosize-textarea/basic-autosize-textarea.html):
>
> 1) The basic-autosize-textarea.html states that it has
> basic-element/basic-element.html as a dependent import
> 2) The basic-element.html has another dependent import, polymer.html
> 3) polymer.html depends on polymer.js and polymer-body.html
>
> Now that the dependency tree is understood, the HTML Imports plumbing
> evaluates the scripts, according to the tree:
>
> 1) polymer.js, which among other things, defines the <polymer-element>
> custom element
> 2) polymer-body.html
> 3) basic-element.html, which uses <polymer-element> to define a new
> <basic-element> element
> 4) basic-autosize-textarea.html, which uses <polymer-element> to
> extend <basic-element> to actually create the
> <basic-autosize-textarea> that we will need.
>
> All of this work is done on Jan's behalf without him needing to worry
> about it. He simply states dependencies -- locally. What's even cooler
> is that if anyone uses other components that rely on <basic-element>
> or <polymer-element> elsewhere in the document (or its imports), the
> respective imports will not be loaded twice -- the dependency
> management system takes care of that.
>
> The light bulb moment for me was realizing that I no longer need to
> state up front things like "I am using jquery" or "I am using
> framework/library X" at the beginning of your document. Instead, the
> import lists it as a local, explicit dependency -- which (especially
> with good inspector/devtools support) is a lot easier to reason about.
>
> I think you mentioned ES6 modules vs. HTML imports. They are not in an
> adversarial relationship. If anything, ES6 modules can be viewed as
> one of the bedrock technologies on which the HTML imports are built --
> namely the underlying underlying loading/dependency resolution
> machinery. That's where we're going
> (https://www.w3.org/Bugs/Public/show_bug.cgi?id=25715).
>
> Once we figure out how to implement <script type="module">
> (https://github.com/dherman/web-modules/tree/master/module-tag), it
> will fit nicely into the imports story as well -- it's just one of
> dependencies.
>
> :DG<
>
> On Fri, May 23, 2014 at 9:35 AM, Brian Di Palma <offler@gmail.com> wrote:
>> HTML Imports seems the least crucial of the Web Components specs.
>>
>> Consider that all but the most trivial of Web Components will require JS.
>> JS is now getting a module system which can be used to load other
>> resources ( e.g. https://github.com/systemjs/systemjs/#plugins ).
>> The JS module system seems much more flexible then loading via URLs.
>>
>> I think it's fair to question if HTML Imports is even necessary.
>> Are any of the current HTML Import use cases impossible to implement
>> using JS modules?
>>
>> On Wed, May 21, 2014 at 8:13 AM, Scott Miles <sjmiles@google.com> wrote:
>>> 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:
>>>
>>> <link rel="import" href="sweet-button.html">
>>> ...
>>> <sweet-button></sweet-button>
>>>
>>> Is <sweet-button> 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 <sjmiles@google.com> wrote:
>>>>
>>>> Some of the ways Polymer team uses imports are as follows:
>>>>
>>>> - aggregating <script src> and/or <link rel="stylesheet> elements into
>>>> functional units
>>>> - aggregating imports themselves into units
>>>> - expressing dependencies (N modules can each import jquery2-import.html
>>>> and I only get one copy of jquery)
>>>> - importing self-organizing databases via custom elements (e.g.
>>>> <core-meta> elements describe/provide metadata using monostate pattern)
>>>>
>>>> Also, one of the first things Polymer does is register a custom-element
>>>> which itself provides a declarative interface to the custom element
>>>> machinery. Most other Polymer elements are then structured declaratively (as
>>>> HTML) which makes using imports highly convenient.
>>>>
>>>> >> would stick a <style> element in the imported document
>>>>
>>>> You can do that, reference an external stylesheet, or place a (scoped)
>>>> style tag directly in the shadow-root.
>>>>
>>>> E.g. using Polymer idiom
>>>>
>>>> <polymer-element name="my-button" noscript>
>>>> <template>
>>>> <style>
>>>>   :host > div.someclass {
>>>>     color: "aliceblue";
>>>>   }
>>>> </style>
>>>> <div class="someclass">my-button</div>
>>>> </template>
>>>> </polymer-element>
>>>>
>>>>
>>>> On Tue, May 20, 2014 at 10:08 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>>>>
>>>>> Hi All,
>>>>>
>>>>> Over here at mozilla we've been trying to understand how the HTML
>>>>> Imports spec is intended to be used.
>>>>>
>>>>> We have so far received descriptions of how the spec works. I.e. what
>>>>> happens when the various import related attributes are added to an
>>>>> <link rel=import>.
>>>>>
>>>>> However I'm curious to understand the expected developer work flows.
>>>>>
>>>>> Let me make a few guesses to clarify the type of description I'm looking
>>>>> for.
>>>>>
>>>>> Clearly imports are expected to be used together with web components.
>>>>> However so far web components are mainly an imperative API, and not a
>>>>> declarative thing. Any element registrations needs to be created
>>>>> through JS calls, and all the shadow DOM inside a custom element needs
>>>>> to be created using JS calls and then inserted into the shadow root
>>>>> using script.
>>>>>
>>>>> At first glance it seems like a simple <script src=...> would then
>>>>> provide all that you need?
>>>>>
>>>>> However it might be tedious to create all elements using createElement
>>>>> and appendChild calls. A better work flow is to stick a <script> in a
>>>>> <link rel=import>ed document together with some <template> elements.
>>>>> Then clone the of those templates from the constructors of the custom
>>>>> elements.
>>>>>
>>>>> And in order to style the custom elements, you would stick a <style>
>>>>> element in the imported document which would have rules like
>>>>>
>>>>> my-button::shadow > div.someclass {
>>>>>   color: "aliceblue";
>>>>> }
>>>>>
>>>>> Is this an accurate description? Are there other reasons to stick
>>>>> non-<script> content in the HTML? Are there any examples out there of
>>>>> how HTML imports are intended to be used?
>>>>>
>>>>> / Jonas
>>>>>
>>>>
>>>
>>

Received on Thursday, 5 June 2014 13:07:52 UTC