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

[HTML Imports] What is the imagined work flow?

From: Jonas Sicking <jonas@sicking.cc>
Date: Tue, 20 May 2014 22:08:40 -0700
Message-ID: <CA+c2ei-T8n9DHp319Mqm4id5wKawn=qsFBETKMou8wNp5c8Q4w@mail.gmail.com>
To: Webapps WG <public-webapps@w3.org>
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 Wednesday, 21 May 2014 05:09:37 UTC

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