W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

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

From: Ian Hickson <ian@hixie.ch>
Date: Fri, 30 Sep 2011 03:36:44 +0000 (UTC)
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: Dominic Cooney <dominicc@google.com>, Edward O'Connor <eoconnor@apple.com>, public-webapps@w3.org
Message-ID: <Pine.LNX.4.64.1109300325430.29849@ps20323.dreamhostps.com>
On Thu, 29 Sep 2011, Tab Atkins Jr. wrote:
> On Thu, Sep 29, 2011 at 7:05 PM, Dominic Cooney <dominicc@google.com> wrote:
> > OK.
> >
> > I understand <div> and <x-foo> are different in the respect of
> > automatically closing p-s.
> >
> > Is this a serious problem? It seems like if you want the p to be
> > closed, you can write </p>; if you insist on getting the parser to
> > close it, you can use <div becomes="x-foo">.
> 
> I agree that it's not a serious problem, and that it's trivial to fix
> for yourself.  There's no legacy pain, either.

My point was just that the parsing differences have nothing to do with 
whether you're creating a component that inherits from HTMLElement. There 
are parsing issues regardless of where in the DOM you are. Parsing issues 
which disappear entirely if we simply require authors to declare the 
bindings using a content attribute at creation time rather than allowing 
authors to invent new tag names.

What I'm proposing based on the feedback on this thread is that we have 
two binding mechanisms. The first is via 'binding' in CSS, and that 
binding mechanism only binds a shadow tree, style sheet, and event 
handlers. The second is via an attribute that must be set during element 
creation, and that one can bind a shadow tree, style sheet, event 
handlers, and a new API; such a binding is permanent for the lifetime of 
the element. Plus, for security reasons, any bindings attached via CSS 
must be explicitly mentioned in the document's <head> somehow before they 
will be allowed to run script.

For brevity, the attribute could be "is". So:

   <binding id="mywidget"> <!-- or however you define a binding inline -->
    ...
   </binding>
   ...
   <ul>
    <li is="mywidget">...</li> <!-- parse-time instantiation -->
   </ul>

   <script>
    var w = Element.create('li', { is: 'mywidget' });
    // run-time instantiation, using the new element creation API
   </script>

   <style scoped>
    /* a style-time instantiation; can't define a new API */
    li { binding: mywidget; }
   </style>

This model still suffers from the problem of stalling page loads while 
binding files are fetched, but if we're going to require that bindings 
apply at page load, I really don't see a way around that.

   <link rel=bindings href=...> <!-- import bindings; blocks -->

As far as I can tell this has all the advantages of what Dimitri is 
proposing, and addresses all his use cases, while still addressing almost 
all the problems that I and others have raised on this thread.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 30 September 2011 03:39:57 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:47 GMT