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

On Fri, Sep 30, 2011 at 12:36 PM, Ian Hickson <ian@hixie.ch> wrote:

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


I understand that the parsing of x-foo and div are different, but is it an
issue? The model we proposed would just use the existing parsing algorithm,
but instantiate a different kind of element for x-foo instead of
HTMLUnknownElement.

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.


If I get this right, you are trading off letting the binding add API for
letting the bindings change dynamically? What use case is served by the
binding changing dynamically?


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


I like this part—particularly the permanent aspect. What’s the _one_ datum
that is always present in every mode of element creation—parsing,
document.createElement, etc.? We should make binding application hinge on
that. Preferably that datum would not be mutable via DOM like the element,
so authors aren’t confused about why a particular binding is applied to an
element when they inspect that 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.
>

Can you elaborate on the security reason? An attacker can hijack the page
through CSS+binding injection and lie in wait for an event?


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

We definitely need declarative and imperative to be harmonized in this way.


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

I think it will be confusing for authors to have one binding (eg mywidget)
than can be applied three ways, and one of the three ways has very different
effects (CSS-specified bindings are dynamic, the other two are static; CSS
bindings can’t touch API, the other two can.)


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

I think it is reasonable. The choices here are FOUC or blocking, or both
(let the author decide.) I guess blocking is the lesser evil? It is simpler
for UA implementors, more predictable for authors, visually less distracting
(although slower) for users.


> 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 04:48:51 UTC