W3C home > Mailing lists > Public > public-webapps@w3.org > October to December 2011

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

From: Roland Steiner <rolandsteiner@google.com>
Date: Tue, 4 Oct 2011 16:12:24 +0900
Message-ID: <CACFPSpjEDr9VQ=AK_6y5WVkfpVBvcFatPvwRiHHAp9Pymue1CA@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: Dominic Cooney <dominicc@google.com>, Brian Kardell <bkardell@gmail.com>, "Tab Atkins Jr." <jackalmage@gmail.com>, "Edward O'Connor" <eoconnor@apple.com>, public-webapps@w3.org
On Tue, Oct 4, 2011 at 12:38 PM, Ian Hickson <ian@hixie.ch> wrote:

>  * Any case of taking an element with existing semantics (e.g. a <select>
>   showing a list of countries) and replacing its presentation with
>   something completely different (e.g. a map selector), where the exact
>   binding could depend based on media queries (e.g. different UIs for
>   tablets vs TVs) or alternative style sheet selections (e.g. the user
>   picking a high-contrast view rather than a custom "cool" one).

Well for one we already have HTML elements that do more or less the same
(<select> vs. <input type=radio>, <button> vs. <input type=button>), so it
doesn't seem such a stretch to me to allow <select> vs. <select

On a second note, what you essentially seem to demand is swapping out entire
HTML sub-branches based on presentation. It is IMHO not entirely a given
that it's components who have to fulfill this mechanism. IOW, components
could be seen as a neat, simple wrapping of a complex DOM structure under a
single element name (or binding attribute), and the task of switching out
different HTML trees (whether containing components or not) could be handled
by another, yet-to-be-specified mechanism. This incidentally would also
solve the security issue you mentioned in conjunction with CSS bindings.

On Mon, 3 Oct 2011, Roland Steiner wrote:
> >
> >
> > Pros:
> > - element name is inherently immutable
> > - can provide arbitrary API, can (but does not have to) derive from
> >   arbitrary HTML element
> > - best performance (in instantiation, CSS selector matching)
> I don't see why it would be more performant, can you elaborate on that?

Instantiation: for <button is=mywidget> I assumed there is a gap during
parsing when a <button> is instantiated, then later is expanded/replaced
when the "is" attribute is read. This may or may not be the case, though. In
any case, <x-mywidget> does not suffer from this.

CSS Selector matching: WebKit at least has a fast path for element names,
but not for attribute matches. So "button[is="mywidget"] { color: red; }"
would be slower than "x-mywidget { color: red; }". (The former also requires
up to 2 comparisons - attribute value and element name - besides.)

> <button IS=MYWIDGET>
> >
> > Pros:
> > - fallback behavior as per HTML element
> > - accessibility as per HTML element + shadow tree contents
> > - binding only at creation, or immediately thereafter
> > - API is that of host element, +alpha
> > Cons:
> > - add'l APIs ignored for accessibility
> I'm not sure what this means. I would have thought the with-binding
> accessibility would be at least as good as the <x-foo> case; better if you
> bind to an element that already has some semantics and just augment them.

That's what I meant to say under "Pros". It's the augmentations that are
ignored. But that's the case in all scenarios, so I shouldn't have singled
it out here.

> button { BINDING: MYWIDGET; }
> > Pros:
> > - fallback behavior as if un-styled
> > - accessibility
> > - mutability depending on medium, etc.
> > - host element stays unchanged
> > Cons:
> > - dynamic binding is hard to implement
> It doesn't have to be. In particular, now that we have the event loop
> specified we can just specify how this works asynchronously.
> > - shadow DOM dependent on rendering tree (something we explicitly wanted
> > to avoid)
> It's dependent on the style resolution, not the rendering tree.

Right, but the point still stands: We'd have a DOM tree "hanging off" (be
dependent on) something that isn't the DOM. This was the case previously in
WebKit before we started with the whole shadow DOM approach, and caused a
lot of headaches.

> - unclear what happens if a HTML element with (intrinsic or explicit)
>  > shadow DOM is assigned a CSS binding as well
> It doesn't have to be unclear, it just has to be defined. There are two
> obvious options: replace it, or augment it. XBL2 supported both.

TBH, XBL2's answer to multiple bindings felt rather hand-wavey to me - it
assumed that an arbitrary intrinsic order would work in all circumstances,
and that the various bindings wouldn't end up clobbering each other on

Specifics aside, it's also a fundamental question how to address multiple
applicable CSS bindings that may be mutually exclusive - e.g., a layout
manager component gets both a "vertical" and "horizontal" layout binding
from different rules. For these reasons I would argue that replacing or
ignoring additional bindings is the only feasible way to go, but that OTOH
will easily lead to arbitrary results.


- Roland
Received on Tuesday, 4 October 2011 07:13:08 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:36 UTC