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

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