W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2014

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

From: Dimitri Glazkov <dglazkov@chromium.org>
Date: Fri, 23 May 2014 10:42:59 -0700
Message-ID: <CADh5Ky1fA67YWWHjwGHgtV5mB8J5JOg7igNBGoLTwMrg9SnjnA@mail.gmail.com>
To: Brian Di Palma <offler@gmail.com>
Cc: Scott Miles <sjmiles@google.com>, Jonas Sicking <jonas@sicking.cc>, Webapps WG <public-webapps@w3.org>, Jan Miksovsky <jan@component.kitchen>
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 Friday, 23 May 2014 17:43:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:14:24 UTC