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

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
is="mapselect">.

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:
> >
> > <X-MYWIDGET>
> >
> > 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
application.

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.


Cheers,

- Roland