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

Re: Fwd: XBL2: First Thoughts and Use Cases

From: Dimitri Glazkov <dglazkov@google.com>
Date: Wed, 15 Dec 2010 11:29:08 -0800
Message-ID: <AANLkTinzwCWryH=MeUgCCY_fzyzV=kNFcVs_pgSzbhYK@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: "Tab Atkins Jr." <jackalmage@gmail.com>, public-webapps <public-webapps@w3.org>
On Wed, Dec 15, 2010 at 11:14 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> On 12/15/10 10:51 AM, Tab Atkins Jr. wrote:
>> Yes, output ports can be moved.  I don't have any particular use-case
>> for it, but under the current conceptual model for how output ports
>> work, it's simpler to allow it than to disallow it, because output
>> ports are just elements.
> It significantly complicates implementation; when an output port is moved
> you have to find all the elements in the flattened tree that came "through"
> the output port and move them to different places (note that they don't all
> end up in the same place, in general).
>> I think that having output ports be elements is a good and simple
>> answer, because we want output ports to be insertion points, not
>> containers.
> Sure.  But them being insertion points can happen without being elements.
>  For example, an insertion point can be tracked conceptually as a collapsed
> range (e.g. similar to the way a caret works in text controls; that too is
> an insertion point).
>>> At least in Gecko's case, we still use XBL1 in this way, and those design
>>> goals would apply to XBL2 from our point of view.  It sounds like you
>>> have
>>> entirely different design goals, right?
>> Sounds like it.
> OK, so given contradictory design goals, where do we go from here?

I don't understand how the goals are contradictory -- and to be
honest, I can't see how anyone could understand this without a set of
use cases. Can we instead focus on use cases and then decide? :)

>> Under this model, existing components already expose all their DOM
>> separately every time, as real live DOM nodes in the document, so
>> instantiating fresh shadow for each instance of a component is no
>> worse.
> Sure.  And Gecko instantiates a fresh shadow tree copy for each instance.
>  However you're suggesting also instantiating a fresh copy of various
> metadata, whose size can easily dwarf the size of the shadow tree itself.

That seems like an implementation detail. Metadata can be shared and
cloned as needed, just like styles in CSS.

> -Boris
Received on Wednesday, 15 December 2010 19:29:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:14 UTC