Re: HTMLElement.register--giving components tag names

On Sat, Sep 3, 2011 at 12:04 PM, Ian Hickson <ian@hixie.ch> wrote:
> On Tue, 30 Aug 2011, Dominic Cooney wrote:
>>
>> I'm proposing we add something that lets script extend the set of tag
>> names, so there is less of a bright line between elements defined in the
>> HTML spec and elements defined in script. Something like:
>>
>> HTMLElement.register('x-contacts', ContactPicker);
>
> What's the fallback behaviour for when script is disabled?

The fallback behavior is basically that you’ll author your markup
either progressively enhance. If you want to support script being
disabled, I guess you’re going to use postbacks.

Progressive enhancement:

<div becomes="x-contacts-picker">
  <form action="contacts.cgi" method="post">
    <label for="name">Name:</name>
    <input type="text" name="name">
    <input type="submit" value="Search">
  </form>
</div>

Fallback:

<x-contacts-picker>
  … form same as before …
</x-contacts-picker>

In this case when the x-contacts-picker is available, it suppresses
the fallback form with shadow DOM, or even by yanking it out of the
DOM.

Since registration is imperative, components imply running script.
There’s no story yet for when you have components but no script.
Looking at the use cases, they mostly (ie except for "panel" layout
manager) want to wire up event listeners for interactivity. I think
"has components, but doesn’t have script" will not be something people
design for.

Declarative would be nice for initializing the shadow DOM in a more
succinct way, though.

One thing that isn’t worked out is that sometimes you want to write
components that present their children, but if those children don’t
coincide with your fallback content you’re SOL. I expect one pattern
that might emerge is nested subcomponents, and have CSS handle
switching:

<x-spectacle>
  <x-rockin>
    <!-- 11" stonehenge, dwarves -->
    …
  </x-rockin>
  <img src="puppetshow.gif">
</x-spectacle>

x-rockin {
  display: none;
}

x-rockin:bound {
  display: block;
}

Shadow DOM would select and output the subcomponent to flip the switch
on the fallback content.

> I think the XBL approach is far superior here -- have authors use existing
> elements, and use XBL to augment them. For example, if you want the user
> to select a country from a map, you can use a <select> with a list of
> countries in <option> elements in the markup, but then use CSS/XBL to bind
> that <select> to a "component" that instead makes the <select> look like a
> map, with all the interactivity that implies.

That sounds appealing, but it looks really hard to implement from
where we right now. Wearing my WebKit hat, one nice property of the
above is that we either have an element we’re going to rip out of the
DOM and replace:

<div becomes="x-contact-picker"> (gets replaced somewhat like renameNode)

Or one that isn’t particularly rich to begin with:

<x-contact-picker> (is HTMLUnknownElement until registered; perfect
tabula rasa for a component)

Whereas in the general case we’d be fighting with suppressing parts of
the nature of the element being bound.

Similarly, one thing that simplifies shadow DOM is that it affects the
rendering of the child content of an element, but the element (as a
block or whatever) is still there. This is relatively simple to
implement because we can just switch from one list of child content to
another when shadow DOM is present. But making the replacement happen
outside the box is more complicated, because there are many more
places that would need to be aware of this switch—many things that are
data would need to be behavior/logic. It is hard to be confident that
they interact well.

There are a few other things that I like about this compared to XBL.
However I don’t want to reject every idea in XBL out of hand—parts of
it are appealing, some parts look hard, but in total it is staggering.
Some ways in which this proposal is much simpler than XBL:

inheritance—there is none. You might layer behavioral changes in a
kind of inheritance of prototype chains in JavaScript, but one bespoke
prototype is just as onerous as many from the browser’s point of view.

multiple bindings—no, only a single binding.

unbinding—there is no "unregister". (Not stated but I am guessing
re-registering the same element name does something simple—throws, or
the last one wins.) There’s no way to remove a shadow root, either.

complexity of selectors—you just get to match on the element name. So
it is very simple and static.

Dominic

> --
> Ian Hickson               U+1047E                )\._.,--....,'``.    fL
> http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
> Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
>

Received on Saturday, 3 September 2011 23:57:57 UTC