Behavior Attachment Redux, was Re: HTML element content models vs. components

> The way to solve this is not to change the content models, it's to use an
> actual <li> and bind it to the component. We should not have authors
> inventing new elements. It doesn't have fallback behaviour, it doesn't
> have semantics that can be interpreted by search engines and accessibility
> tools, it doesn't have default renderings, it doesn't allow for validation
> to catch authoring mistakes, it simply isn't a good design.

Hi Ian! :)

I already enumerated and hopefully addressed most of your concerns in
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1156.html
and http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1187.html,
but I am open to other ideas.

At this point, custom tags seems to be the most straightforward way of
conveying how things should work. XBL2 doesn't offer any better ideas,
as explained below.

Per our use cases
(http://wiki.whatwg.org/wiki/Component_Model_Use_Cases), we need a way
to allow attached behaviors to change element's API surface by adding
new (or shadowing existing) members.

To recap http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/1204.html,
the API surface (and thus the behavior) should be something an element
is born with. In other words, we need element behavior attachment
(http://wiki.whatwg.org/wiki/Behavior_Attachment).

Let's look at the behavior attachment options that XBL2 provides:
1) Attachment using <binding>
2) Attachment using CSS
3) Attachment using the DOM (ElementXBL.addBinding)

Clearly, CSS-based behavior attachment is transient. Additionally,
security experts tell us that CSS-based behavior attachment is a Bad
Idea (http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0699.html).
So we should nix that.

Similarly, we can't use selectors with <binding>, since they imply
that an element only has behavior when in the document tree, which
makes it transient. This limits <binding>'s "element" attribute to
only refer to tag names, since they are the only non-transient
identifying property of a DOM element, and such all-or-nothing knob is
way too large to be useful.

We can't use ElementXBL.addBinding either, since it clearly treats
behavior as something you can add and remove.

Alrighty. Now that we ran out of ways to attach behaviors to elements
using XBL2, let's step outside the box.

In abstract, we need a mechanism to bestow some properties on a DOM
element before it emerges from the construction site. That seems easy
-- just do something like this:

var elementWithBehavior = document.createElement('div',
newBehaviorImplementation); // HTMLDivElement +
"newBehaviorImplementation" => baby

Unfortunately, the parser has no clue about this secret sauce and the
behavior is easily lost in markup roundtrips (or while cloning):

var someOtherDiv = document.createElement('div');
someOtherDiv.appendChild(elementWithBehavior);
document.body.innerHTML = someOtherDiv.innerHTML;
var ohNoesJustAnOrdinaryDivAgain = document.body.firstChild;

So, we need a way to express in markup that a particular element is to
be created with a particular behavior. Since the tagName is the only
identifying property of a DOM element that can't be changed, this
brings us to... custom tag names.

:DG<

P.S. As an experiment for myself, I hacked together a poor-man's
extensible DOM prototype
(http://trac.webkit.org/browser/trunk/Tools/BuildSlaveSupport/build.webkit.org-config/public_html/TestFailures/scripts/base.js#L351),
then used it to build a non-trivial Web application (a WebKit
infrastructure project). In the process, I found the notion of
extending DOM objects extremely addictive (see
http://trac.webkit.org/browser/trunk/Tools/BuildSlaveSupport/build.webkit.org-config/public_html/TestFailures/scripts/ui/notifications.js
to get your first dose of the drug). This new world _feels_ right and
I refuse going back to the old one.

Received on Wednesday, 28 September 2011 18:09:02 UTC