Re: xdash name prefixes (was Re: Component Model Update)

[Roland Steiner]

On Wed, Aug 31, 2011 at 12:57 PM, Dominic Cooney wrote:

> I think for convenience registration probably should be carried around
> with the component, because:
>
> 1. It is convenient for the author using the component.
>
> 2. If the component library reuses its own abstractions, it probably
> expects them to have a specific element name. Putting registration in
> the hands of the author using the component jeopardizes that.
>

That is actually a good point.


Something declarative like module imports and exports, with scoped
> renaming, for registered tag names would be nice. This avoids these
> two problems, and is pretty convenient (particularly if import * gets
> you all of the exports by default.)
>

Wouldn't that be effectively namespaces by another name/mechanism? Also,
there's probably a limit to how far renaming can avoid clashes, e.g., if a
sub-components can also be utilized by a page's author.

In any case, until modules become a reality I think teaching component
authors to use "pseudo-namespaces" (e.g., "x-rogersoft-button" vs.
"x-delilahsoft-button") for stuff that might clash is not unreasonable.


Cheers,

- Roland

Re: xdash name prefixes (was Re: Component Model Update)

[Dominic Cooney]

I think for convenience registration probably should be carried around
with the component, because:

1. It is convenient for the author using the component.

2. If the component library reuses its own abstractions, it probably
expects them to have a specific element name. Putting registration in
the hands of the author using the component jeopardizes that.

However I don’t think the imperative API is right, or at least not
enough, for these reasons: (assuming you accept that registration
happens in the component library—the death before inconvenience
premise):

1. The imperative registration API is *not* OK for confined
components, because if you run script out of the library in your
context to do the registration, you are hosed.

2. There’s no way for the author to manage conflicts or namespace pollution.

Something declarative like module imports and exports, with scoped
renaming, for registered tag names would be nice. This avoids these
two problems, and is pretty convenient (particularly if import * gets
you all of the exports by default.)

Dominic

On Wed, Aug 31, 2011 at 10:54 AM, Roland Steiner
 wrote:
> On Fri, Aug 26, 2011 at 11:18 AM, Adam Barth  wrote:
>>
>> Doesn't it seem more likely that the third-party will do the
>> registration in whatever script you include that implements the Like
>> button, or whatever?
>
> That's just a matter of convention, no? I don't think it's unreasonable to
> frame it as "in order to use a component you need to load its source and
> register a suitable element name for it.".
> OTOH, there's nothing to prevent a package from doing the registering in one
> go. But if such a package then really leads to a clash, I'd prefer to first
> ask the authors to sort it out.
>
> Cheers,
> - Roland

Re: xdash name prefixes (was Re: Component Model Update)

[Roland Steiner]

On Fri, Aug 26, 2011 at 11:18 AM, Adam Barth  wrote:

> Doesn't it seem more likely that the third-party will do the
> registration in whatever script you include that implements the Like
> button, or whatever?


That's just a matter of convention, no? I don't think it's unreasonable to
frame it as "in order to use a component you need to load its source and
register a suitable element name for it.".

OTOH, there's nothing to prevent a package from doing the registering in one
go. But if such a package then really leads to a clash, I'd prefer to first
ask the authors to sort it out.


Cheers,

- Roland

Re: xdash name prefixes (was Re: Component Model Update)

[Adam Barth]

On Fri, Aug 26, 2011 at 1:07 AM, Roland Steiner
 wrote:
> On Thu, Aug 25, 2011 at 9:12 AM, Adam Barth  wrote:
>>
>> On the other hand, it seems likely that some of these xdash names will
>> come into multi-party use.  For example, the following use cases
>> involve xdash names chosen by one party and then used by another:
>>
>> http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Widget_Mix-and-Match
>> http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Contacts_Widget
>> http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Like.2F.2B1_Button
>
>
> Since the components that are used on a page are under the control of the
> page's author, it should be possible to avoid clashes by separating a
> component's definition (potentially pulled from third party) from its tag
> registration (done by page author), e.g.
> // Importing component definition for Facebook "Like" button
> // Importing component definition for Google+ "+1" button
> // ... later:
> Element.register("x-fb", Facebook.LikeButton)
> Element.register("x-gg", GooglePlus.PlusOneButton)

Doesn't it seem more likely that the third-party will do the
registration in whatever script you include that implements the Like
button, or whatever?

Adam


>> That's something like 40% of the use cases...
>>
>> I don't have much of a better suggestion.  You're running up against
>> all the usual distributed extensibility issues.
>
> We could use namespaces... *ducks and runs* :D
>
> Cheers,
> - Roland
>

Re: Component Model Update

[Dominic Cooney]

On Fri, Aug 26, 2011 at 12:42 AM, Roland Steiner
 wrote:
> On Thu, Aug 25, 2011 at 4:24 PM, Dominic Cooney  wrote:
>>
>> Here is a quick first cut:
>>
>> How about use cases like these:
>>
>> - Extension that wants to inspect  and warn you
>> when you are entering you password in an insecure form (from abarth
>> earlier in the thread.)
>> - Password manager that wants to find anything that looks like a login
>> panel and decorate it/fill it.
>> - Extension that removes formatting from a page to make it easier for
>> on-screen reading.
>> - Extension that finds phone numbers in a page and embosses them with
>> links to a crank call service.
>> - Extension that replaces all ads in a page with pictures of kittens.
>> Or an extension that detects pictures of kittens and monetizes them
>> with ads.
>> - Extension that on hover looks up
>> dictionary/thesaurus/translation/urban dictionary/wikipedia/etc.
>
> This is a great list!
> As for allowing extensions to inspect the shadow DOM: unless we want to
> break isolation/confinement again, I believe this should be handled by the
> relevant browser APIs for extensions, along the lines of "shadow =
> extensions.getShadowFor(element)". If the extension shouldn't be able to
> mess with shadows, it can be blocked at this point.

Yes, I think a separate function for doing the lookup is a good idea.
It keeps the set of attributes and methods on a given DOM object the
same for pages and extensions.

Dominic

Re: xdash name prefixes (was Re: Component Model Update)

[Roland Steiner]

On Thu, Aug 25, 2011 at 9:12 AM, Adam Barth  wrote:

> On the other hand, it seems likely that some of these xdash names will
> come into multi-party use.  For example, the following use cases
> involve xdash names chosen by one party and then used by another:
>
> http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Widget_Mix-and-Match
> http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Contacts_Widget
> http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Like.2F.2B1_Button
>

Since the components that are used on a page are under the control of the
page's author, it should be possible to avoid clashes by separating a
component's definition (potentially pulled from third party) from its tag
registration (done by page author), e.g.

// Importing component definition for Facebook "Like" button
// Importing component definition for Google+ "+1" button
// ... later:
Element.register("x-fb", Facebook.LikeButton)
Element.register("x-gg", GooglePlus.PlusOneButton)

That's something like 40% of the use cases...
>
> I don't have much of a better suggestion.  You're running up against
> all the usual distributed extensibility issues.
>

We could use namespaces... *ducks and runs* :D


Cheers,

- Roland

Re: Component Model Update

[Roland Steiner]

On Thu, Aug 25, 2011 at 4:24 PM, Dominic Cooney  wrote:

> Here is a quick first cut:
>
> How about use cases like these:
>
> - Extension that wants to inspect  and warn you
> when you are entering you password in an insecure form (from abarth
> earlier in the thread.)
> - Password manager that wants to find anything that looks like a login
> panel and decorate it/fill it.
> - Extension that removes formatting from a page to make it easier for
> on-screen reading.
> - Extension that finds phone numbers in a page and embosses them with
> links to a crank call service.
> - Extension that replaces all ads in a page with pictures of kittens.
> Or an extension that detects pictures of kittens and monetizes them
> with ads.
> - Extension that on hover looks up
> dictionary/thesaurus/translation/urban dictionary/wikipedia/etc.
>

This is a great list!

As for allowing extensions to inspect the shadow DOM: unless we want to
break isolation/confinement again, I believe this should be handled by the
relevant browser APIs for extensions, along the lines of "shadow =
extensions.getShadowFor(element)". If the extension shouldn't be able to
mess with shadows, it can be blocked at this point.

Re: xdash name prefixes (was Re: Component Model Update)

[Adam Barth]

On Wed, Aug 24, 2011 at 5:18 PM, Tab Atkins Jr.  wrote:
> On Wed, Aug 24, 2011 at 5:12 PM, Adam Barth  wrote:
>> On Wed, Aug 24, 2011 at 2:30 PM, Dominic Cooney  wrote:
>>> On Thu, Aug 25, 2011 at 2:03 AM, Dimitri Glazkov  
>>> wrote:
 On Tue, Aug 23, 2011 at 9:19 PM, Adam Barth  wrote:
> This section 
> says "When an unknown DOM element with an "x-"-prefixed tagName is
> encountered ...".  It seems unfortunate to special-case tag names that
> begin with "x-".  The IETF has a lot of experience with "x-" prefixes,
> and they're somewhat unhappy with them:
>
> http://tools.ietf.org/html/draft-saintandre-xdash

 I can't seem to draw a parallel between prefixing author-defined
 custom DOM elements and prefixing HTTP parameters -- other than the
 prefix itself, that is. There's a clear meaning of the prefix in the
 Component Model -- this element was defined by an author.
 Additionally, we are explicitly trying to avoid a registry-like
 situation, where one has to announce or qualify for the right to use a
 tag name. Can you help me understand what your concerns are?
>>>
>>> That RFC is interesting, but I didn’t find it a perfect parallel either.
>>>
>>> In protocol headers, clients and servers need to agree on the meaning
>>> of headers, and require migration from non-standard to standard
>>> headers with attendant interoperability issues. Components are
>>> different, because both the x-name and its definition are under
>>> control of the author. The intent is that if HTML standardizes an
>>> x-name, it will be christened with the un-prefixed name; the UA can
>>> continue supporting old x-names and definitions using the generic
>>> component mechanism.
>>>
>>> I guess we could get into interoperability difficulties if user agents
>>> start to rely on specific x-names and ignoring or augment their
>>> definitions. For example, if a crawler ignores the scripts that define
>>> components but interpret a common x-name a particular way. Or if a
>>> browser automatically augments the definition of a given x-name for
>>> better security or accessibility.
>>
>> Yeah, the parallel breaks down a bit because in HTTP the "X-" names
>> are used by two parties and here we're only talking about one party.
>> Maybe a better parallel is data attributes, which are also segmented
>> into their own namespace...
>
> Yes, the data-* attributes are the correct thing to draw parallels to here.
>
>
>> On the other hand, it seems likely that some of these xdash names will
>> come into multi-party use.  For example, the following use cases
>> involve xdash names chosen by one party and then used by another:
>>
>> http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Widget_Mix-and-Match
>> http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Contacts_Widget
>> http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Like.2F.2B1_Button
>>
>> That's something like 40% of the use cases...
>
> These are fine as well; the important case where prefixing causes
> problems is when one of the parties is the browser itself, where it
> will eventually want to change from recognizing the prefixed name to
> recognizing the unprefixed name.

That's a pretty narrow view.  :)

Adam

[Component Model] Declarative syntax for shadow DOM subtrees, was Re: Component Model Update

[Dimitri Glazkov]

On Thu, Aug 25, 2011 at 8:35 AM, Tab Atkins Jr.  wrote:
> On Thu, Aug 25, 2011 at 1:41 AM, Olli Pettay  wrote:
>> One thing missing is some kind of declarative way to define
>> shadow trees, similar to XBL1's .
>>
>> It would be rather strange if one needs to explicitly construct
>> shadow tree after the element is created.
>
> I know we plan to add a declarative syntax similar to XBL, but the
> scripted syntax gets into the details better, so it's better to focus
> on that first.  It's also easy, when you start from a declarative
> solution, to accidentally build in magic that's hard to replicate
> imperatively.  Starting from imperative has similar risks, but I think
> they're easier to manage.

Splitting into a fresh thread.

I also think being able to use markup to declare shadow DOM trees is
pretty cool, however I would strongly recommend coming up with a use
case that clearly illustrates the need for it. Now that we have a
fairly rigorous framework around this spec development
(http://wiki.whatwg.org/wiki/Component_Model_Methodology), we should
follow it.

So we have to answer this question first: Why and to Whom is it
important to have such a feature?

One notion I was toying with is productivity, since declarative markup
should be easier to read.

Another possible point is consistency: we can build DOM trees using
markup in a document, why not in shadow DOM?

I don't think performance quite cuts it anymore, since JS engines have
gotten to the point where I doubt you'll see a significant difference
between declarative and imperative tree instantiation.

:DG<

Re: Component Model Update

[Tab Atkins Jr.]

On Thu, Aug 25, 2011 at 1:41 AM, Olli Pettay  wrote:
> One thing missing is some kind of declarative way to define
> shadow trees, similar to XBL1's .
>
> It would be rather strange if one needs to explicitly construct
> shadow tree after the element is created.

I know we plan to add a declarative syntax similar to XBL, but the
scripted syntax gets into the details better, so it's better to focus
on that first.  It's also easy, when you start from a declarative
solution, to accidentally build in magic that's hard to replicate
imperatively.  Starting from imperative has similar risks, but I think
they're easier to manage.

~TJ

Re: Component Model Update

[John J Barton]

On Thu, Aug 25, 2011 at 1:41 AM, Olli Pettay wrote:

> One thing missing is some kind of declarative way to define
> shadow trees, similar to XBL1's .
>
> I think this omission is a big plus. XBL1  is mysterious.  If a
dev tool wants to add support for building Components from declarative
markup, awesome. But the bizarre combo of xml, .css, and .js in XBL one is
poorly supported by tooling and thus is just a mess. Create a great JS
solution then let tools build on that.

jjb

Re: Component Model Update

[Dominic Cooney]

On Thu, Aug 25, 2011 at 5:41 PM, Olli Pettay  wrote:
> On 08/23/2011 11:40 PM, Dimitri Glazkov wrote:
>>
>> All,
>>
>> Over the last few weeks, a few folks and myself have been working on
>> fleshing out the vision for the Component Model. Here's what we've
>> done so far:
>>
>> * Created a general overview document for behavior attachment problem
>> on the Web (http://wiki.whatwg.org/wiki/Behavior_Attachment);
>> * Wrote down the a set of guidelines on how we intend to tackle the
>> problem (http://wiki.whatwg.org/wiki/Component_Model_Methodology);
>> * Updated the list of use cases and desired properties for each case
>> (http://wiki.whatwg.org/wiki/Component_Model_Use_Cases);
>> * Captured the overall component model design and how it satisfies
>> each desired property (http://wiki.whatwg.org/wiki/Component_Model),
>> including a handy comparison with existing relevant specs and
>> implementations
>>
>> (http://wiki.whatwg.org/wiki/Component_Model#Comparison_With_Existing_Specs_and_Implementations).
>>
>> After of this iteration, the proposed shadow DOM API no longer
>> includes the .shadow accessor (see details here
>> http://dglazkov.github.com/component-model/dom.html). Instead, the
>> shadow DOM subtree association happens in ShadowRoot constructor:
>>
>> var element = document.createElement("div");
>> var shadow = new ShadowRoot(element); // {element} now has shadow DOM
>> subtree, and {shadow} is its root.
>> shadow.appendChild(document.createElement("p")).textContent = "weee!!';
>
>
> One thing missing is some kind of declarative way to define
> shadow trees, similar to XBL1's .
>
> It would be rather strange if one needs to explicitly construct
> shadow tree after the element is created.

Looking at the use cases, it looks like components need to run script
anyway, at least to hook up event listeners. So would it be fair to
rephrase this as: “There should be a concise way to get HTML into a
shadow tree.” ?

> (Component Model is getting closer and closer to XBL, and it is not
>  quite clear to me why XBL2 couldn't be used. It needs some
>  minor fixes, but should work otherwise.)

I feel like XBL2 doesn’t get the power-to-weight ratio right—it looks
hard to use and implement, and as this

summarizes XBL2 doesn’t mesh well with JavaScript, and doesn’t get
confinement. So this proposal looks like it made a good tradeoff…
eliminate a lot of what’s complex to use and implement in XBL2, and
focusses instead on useful capabilities like confinement.

Dimitri et al studied XBL2 in depth in designing the component model.
It is possible when you follow through with minor fixes to XBL2 you
will end up here anyway… it might be more productive to work on
fleshing out and fixing this proposal.

>> Keeping the accessor out allows for proper encapsulation and
>> confinement (better explanation of these new bits of terminology here:
>> https://plus.google.com/103035368214666982008/posts/AnGBpHZzQu6), and
>> also simplifies the API surface.
>>
>> Please review. Feedback is welcome!
>>
>> :DG<
>>
>>
>
>
>

Re: Component Model Update

[Olli Pettay]

On 08/23/2011 11:40 PM, Dimitri Glazkov wrote:

All,

Over the last few weeks, a few folks and myself have been working on
fleshing out the vision for the Component Model. Here's what we've
done so far:

* Created a general overview document for behavior attachment problem
on the Web (http://wiki.whatwg.org/wiki/Behavior_Attachment);
* Wrote down the a set of guidelines on how we intend to tackle the
problem (http://wiki.whatwg.org/wiki/Component_Model_Methodology);
* Updated the list of use cases and desired properties for each case
(http://wiki.whatwg.org/wiki/Component_Model_Use_Cases);
* Captured the overall component model design and how it satisfies
each desired property (http://wiki.whatwg.org/wiki/Component_Model),
including a handy comparison with existing relevant specs and
implementations
(http://wiki.whatwg.org/wiki/Component_Model#Comparison_With_Existing_Specs_and_Implementations).

After of this iteration, the proposed shadow DOM API no longer
includes the .shadow accessor (see details here
http://dglazkov.github.com/component-model/dom.html). Instead, the
shadow DOM subtree association happens in ShadowRoot constructor:

var element = document.createElement("div");
var shadow = new ShadowRoot(element); // {element} now has shadow DOM
subtree, and {shadow} is its root.
shadow.appendChild(document.createElement("p")).textContent = "weee!!';



One thing missing is some kind of declarative way to define
shadow trees, similar to XBL1's .

It would be rather strange if one needs to explicitly construct
shadow tree after the element is created.


(Component Model is getting closer and closer to XBL, and it is not
 quite clear to me why XBL2 couldn't be used. It needs some
 minor fixes, but should work otherwise.)




Keeping the accessor out allows for proper encapsulation and
confinement (better explanation of these new bits of terminology here:
https://plus.google.com/103035368214666982008/posts/AnGBpHZzQu6), and
also simplifies the API surface.

Please review. Feedback is welcome!

:DG<

Re: Component Model Update

[Dominic Cooney]

Here is a quick first cut:

How about use cases like these:

- Extension that wants to inspect  and warn you
when you are entering you password in an insecure form (from abarth
earlier in the thread.)
- Password manager that wants to find anything that looks like a login
panel and decorate it/fill it.
- Extension that removes formatting from a page to make it easier for
on-screen reading.
- Extension that finds phone numbers in a page and embosses them with
links to a crank call service.
- Extension that replaces all ads in a page with pictures of kittens.
Or an extension that detects pictures of kittens and monetizes them
with ads.
- Extension that on hover looks up
dictionary/thesaurus/translation/urban dictionary/wikipedia/etc.

How does it change desired properties? The desired properties are good
for the page. Extensions can typically exercise capabilities the page
has (right?) Extensions can additionally violate encapsulation.
However the UA may bless some encapsulation as inviolate (when the
implementation uses shadow and wants to rely on nobody—not even
extensions—messing with it.) Extensions sometimes have their own
notion of confinement. I think it is OK if extensions can’t violate
confinement. There is no deep reflective API for JavaScript, so it
would not be so useful anyway?

How does it change the primitives? Extensions can detect which
elements have shadow, get the shadow root, and get the host for a
given shadow root. (In addition to creating shadow roots and any other
typical DOM manipulations an extension can do.) Do any of the above
use cases need to access the "flattened" tree? If so, maybe there
should be an API for that, because computing it in script would be
tedious.

Dominic

On Thu, Aug 25, 2011 at 1:06 PM, Dimitri Glazkov  wrote:
> On Wed, Aug 24, 2011 at 8:23 PM, John J Barton
>  wrote:
>>
>>
>> On Wed, Aug 24, 2011 at 7:50 PM, Dimitri Glazkov 
>> wrote:
>>
>>>
>>> > Independent of our different point of view on control, shadow DOM needs
>>> > debug APIs. So much the better if these are available to extensions.
>>>
>>> Let me see if I can capture this into a feature: user scripts may have
>>> access to shadow DOM subtrees. In terms of WebKit, when run in user
>>> script worlds, the Element has an extra accessor to spelunk down the
>>> shadow DOM.
>>>
>>> Is this what you're suggesting?
>>
>> Yes. Encapsulation is good UI, not security. I want to ignore the subtree
>> "normally" but jump into the astral plane for special enlightenment.
>> XUL has such a mechanism, but I'd wish for less mystery. I spent many hours
>> trying to keep element inspection working on XUL. The API should aim to work
>> well with code designed for normal elements.
>> jjb
>
> Ok. Can you help me formulating a use case for this API, and how it
> affects desired properties, and building blocks?
>
> Anybody has an allergic reaction to something like this?
>
> :DG<
>
>>>
>>> :DG<
>>>
>>> >
>>> > jjb
>>> >
>>
>>
>

Re: Component Model Update

[Dominic Cooney]

On Thu, Aug 25, 2011 at 2:03 PM, John J Barton
 wrote:
> I'm still trying to digest this, but it seem pretty clear the 'confinement'
> is the "clear scope" thing I was asking about on es-discuss.  According to
> that discussion, this means needs to fit with the 'modules' thing on
> ecmascript. That seems to be where you are headed, but basing a new proposal
> on another new proposal is ... well I'll let you fill in the blank depending
> on how you are feeling.

Courageous?

> I guess the actual implementation of confined script evaluation would not be
> difficult (Firefox can do it now if you can get some one to explain it).
> Getting the entire 'modules' effort out? I'm thinking that could be hard.
>
> jjb

If we do the design so that good things are possible when modules
arrive, and the component model is useful for some use cases even
without hermetic confinement, then it sounds reasonable to work on
specing, implementing and getting experience with the other parts?

Re: Component Model Update

[John J Barton]

I'm still trying to digest this, but it seem pretty clear the 'confinement'
is the "clear scope" thing I was asking about on es-discuss.  According to
that discussion, this means needs to fit with the 'modules' thing on
ecmascript. That seems to be where you are headed, but basing a new proposal
on another new proposal is ... well I'll let you fill in the blank depending
on how you are feeling.

I guess the actual implementation of confined script evaluation would not be
difficult (Firefox can do it now if you can get some one to explain it).
Getting the entire 'modules' effort out? I'm thinking that could be hard.

jjb

Re: Component Model Update

[Dimitri Glazkov]

On Wed, Aug 24, 2011 at 8:23 PM, John J Barton
 wrote:
>
>
> On Wed, Aug 24, 2011 at 7:50 PM, Dimitri Glazkov 
> wrote:
>
>>
>> > Independent of our different point of view on control, shadow DOM needs
>> > debug APIs. So much the better if these are available to extensions.
>>
>> Let me see if I can capture this into a feature: user scripts may have
>> access to shadow DOM subtrees. In terms of WebKit, when run in user
>> script worlds, the Element has an extra accessor to spelunk down the
>> shadow DOM.
>>
>> Is this what you're suggesting?
>
> Yes. Encapsulation is good UI, not security. I want to ignore the subtree
> "normally" but jump into the astral plane for special enlightenment.
> XUL has such a mechanism, but I'd wish for less mystery. I spent many hours
> trying to keep element inspection working on XUL. The API should aim to work
> well with code designed for normal elements.
> jjb

Ok. Can you help me formulating a use case for this API, and how it
affects desired properties, and building blocks?

Anybody has an allergic reaction to something like this?

:DG<

>>
>> :DG<
>>
>> >
>> > jjb
>> >
>
>

Re: Component Model Update

[John J Barton]

On Wed, Aug 24, 2011 at 7:50 PM, Dimitri Glazkov wrote:


> > Independent of our different point of view on control, shadow DOM needs
> > debug APIs. So much the better if these are available to extensions.
>
> Let me see if I can capture this into a feature: user scripts may have
> access to shadow DOM subtrees. In terms of WebKit, when run in user
> script worlds, the Element has an extra accessor to spelunk down the
> shadow DOM.
>
> Is this what you're suggesting?
>

Yes. Encapsulation is good UI, not security. I want to ignore the subtree
"normally" but jump into the astral plane for special enlightenment.

XUL has such a mechanism, but I'd wish for less mystery. I spent many hours
trying to keep element inspection working on XUL. The API should aim to work
well with code designed for normal elements.

jjb


>
> :DG<
>
> >
> > jjb
> >
>

Re: Component Model Update

[Dimitri Glazkov]

On Wed, Aug 24, 2011 at 2:50 PM, John J Barton
 wrote:
>
>
> On Wed, Aug 24, 2011 at 2:30 PM, Dominic Cooney  wrote:
>>
>> On Thu, Aug 25, 2011 at 2:03 AM, Dimitri Glazkov 
>> wrote:
>> > Yes, shadow DOM gives the author an extra lever to control visibility
>> > and hackability of their code. It's up to them to use this lever
>> > wisely.
>
> Maybe I grew up on to much Web koolaid, but browsers should be giving all
> extra levers to users. In real life control in the hand of "authors" means
> control in the hands of suits and suits will always pick the "hide all"
> setting.
>
>>
>> This is not without precedent. Just like authors who choose to
>> > use canvas to build their entire applications are shutting the door
>> > (intentionally or not) on extensions, I bet we'll also see these
>> > extremes with the Component Model.
>
> In the case of canvas the reason is technical inferiority, the medium is
> write only. Component Model has not such technical limit.
>
>>
>> However, I am also sure that a lot
>> > of authors will see value in retaining composability for extensions.
>> > If anything, shadow DOM can help authors draw proper composability
>> > boundaries and thus inform extensions developers where tweaking is ok
>> > and where may cause explosions.
>
> Again, that's old school.
>
> Independent of our different point of view on control, shadow DOM needs
> debug APIs. So much the better if these are available to extensions.

Let me see if I can capture this into a feature: user scripts may have
access to shadow DOM subtrees. In terms of WebKit, when run in user
script worlds, the Element has an extra accessor to spelunk down the
shadow DOM.

Is this what you're suggesting?

:DG<

>
> jjb
>

Re: xdash name prefixes (was Re: Component Model Update)

[Tab Atkins Jr.]

On Wed, Aug 24, 2011 at 5:12 PM, Adam Barth  wrote:
> On Wed, Aug 24, 2011 at 2:30 PM, Dominic Cooney  wrote:
>> On Thu, Aug 25, 2011 at 2:03 AM, Dimitri Glazkov  
>> wrote:
>>> On Tue, Aug 23, 2011 at 9:19 PM, Adam Barth  wrote:
 This section 
 says "When an unknown DOM element with an "x-"-prefixed tagName is
 encountered ...".  It seems unfortunate to special-case tag names that
 begin with "x-".  The IETF has a lot of experience with "x-" prefixes,
 and they're somewhat unhappy with them:

 http://tools.ietf.org/html/draft-saintandre-xdash
>>>
>>> I can't seem to draw a parallel between prefixing author-defined
>>> custom DOM elements and prefixing HTTP parameters -- other than the
>>> prefix itself, that is. There's a clear meaning of the prefix in the
>>> Component Model -- this element was defined by an author.
>>> Additionally, we are explicitly trying to avoid a registry-like
>>> situation, where one has to announce or qualify for the right to use a
>>> tag name. Can you help me understand what your concerns are?
>>
>> That RFC is interesting, but I didn’t find it a perfect parallel either.
>>
>> In protocol headers, clients and servers need to agree on the meaning
>> of headers, and require migration from non-standard to standard
>> headers with attendant interoperability issues. Components are
>> different, because both the x-name and its definition are under
>> control of the author. The intent is that if HTML standardizes an
>> x-name, it will be christened with the un-prefixed name; the UA can
>> continue supporting old x-names and definitions using the generic
>> component mechanism.
>>
>> I guess we could get into interoperability difficulties if user agents
>> start to rely on specific x-names and ignoring or augment their
>> definitions. For example, if a crawler ignores the scripts that define
>> components but interpret a common x-name a particular way. Or if a
>> browser automatically augments the definition of a given x-name for
>> better security or accessibility.
>
> Yeah, the parallel breaks down a bit because in HTTP the "X-" names
> are used by two parties and here we're only talking about one party.
> Maybe a better parallel is data attributes, which are also segmented
> into their own namespace...

Yes, the data-* attributes are the correct thing to draw parallels to here.


> On the other hand, it seems likely that some of these xdash names will
> come into multi-party use.  For example, the following use cases
> involve xdash names chosen by one party and then used by another:
>
> http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Widget_Mix-and-Match
> http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Contacts_Widget
> http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Like.2F.2B1_Button
>
> That's something like 40% of the use cases...

These are fine as well; the important case where prefixing causes
problems is when one of the parties is the browser itself, where it
will eventually want to change from recognizing the prefixed name to
recognizing the unprefixed name.

~TJ

xdash name prefixes (was Re: Component Model Update)

[Adam Barth]

On Wed, Aug 24, 2011 at 2:30 PM, Dominic Cooney  wrote:
> On Thu, Aug 25, 2011 at 2:03 AM, Dimitri Glazkov  
> wrote:
>> On Tue, Aug 23, 2011 at 9:19 PM, Adam Barth  wrote:
>>> This section 
>>> says "When an unknown DOM element with an "x-"-prefixed tagName is
>>> encountered ...".  It seems unfortunate to special-case tag names that
>>> begin with "x-".  The IETF has a lot of experience with "x-" prefixes,
>>> and they're somewhat unhappy with them:
>>>
>>> http://tools.ietf.org/html/draft-saintandre-xdash
>>
>> I can't seem to draw a parallel between prefixing author-defined
>> custom DOM elements and prefixing HTTP parameters -- other than the
>> prefix itself, that is. There's a clear meaning of the prefix in the
>> Component Model -- this element was defined by an author.
>> Additionally, we are explicitly trying to avoid a registry-like
>> situation, where one has to announce or qualify for the right to use a
>> tag name. Can you help me understand what your concerns are?
>
> That RFC is interesting, but I didn’t find it a perfect parallel either.
>
> In protocol headers, clients and servers need to agree on the meaning
> of headers, and require migration from non-standard to standard
> headers with attendant interoperability issues. Components are
> different, because both the x-name and its definition are under
> control of the author. The intent is that if HTML standardizes an
> x-name, it will be christened with the un-prefixed name; the UA can
> continue supporting old x-names and definitions using the generic
> component mechanism.
>
> I guess we could get into interoperability difficulties if user agents
> start to rely on specific x-names and ignoring or augment their
> definitions. For example, if a crawler ignores the scripts that define
> components but interpret a common x-name a particular way. Or if a
> browser automatically augments the definition of a given x-name for
> better security or accessibility.

Yeah, the parallel breaks down a bit because in HTTP the "X-" names
are used by two parties and here we're only talking about one party.
Maybe a better parallel is data attributes, which are also segmented
into their own namespace...

On the other hand, it seems likely that some of these xdash names will
come into multi-party use.  For example, the following use cases
involve xdash names chosen by one party and then used by another:

http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Widget_Mix-and-Match
http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Contacts_Widget
http://wiki.whatwg.org/wiki/Component_Model_Use_Cases#Like.2F.2B1_Button

That's something like 40% of the use cases...

I don't have much of a better suggestion.  You're running up against
all the usual distributed extensibility issues.

Adam

Re: Component Model Update

[John J Barton]

On Wed, Aug 24, 2011 at 2:30 PM, Dominic Cooney  wrote:

> On Thu, Aug 25, 2011 at 2:03 AM, Dimitri Glazkov 
> wrote:
> > Yes, shadow DOM gives the author an extra lever to control visibility
> > and hackability of their code. It's up to them to use this lever
> > wisely.
>

Maybe I grew up on to much Web koolaid, but browsers should be giving all
extra levers to users. In real life control in the hand of "authors" means
control in the hands of suits and suits will always pick the "hide all"
setting.


> This is not without precedent. Just like authors who choose to
> > use canvas to build their entire applications are shutting the door
> > (intentionally or not) on extensions, I bet we'll also see these
> > extremes with the Component Model.
>

In the case of canvas the reason is technical inferiority, the medium is
write only. Component Model has not such technical limit.


> However, I am also sure that a lot
> > of authors will see value in retaining composability for extensions.
> > If anything, shadow DOM can help authors draw proper composability
> > boundaries and thus inform extensions developers where tweaking is ok
> > and where may cause explosions.
>

Again, that's old school.

Independent of our different point of view on control, shadow DOM needs
debug APIs. So much the better if these are available to extensions.

jjb

Re: Component Model Update

[Dominic Cooney]

On Thu, Aug 25, 2011 at 2:03 AM, Dimitri Glazkov  wrote:
> On Tue, Aug 23, 2011 at 9:19 PM, Adam Barth  wrote:
>> I feel somewhat like I'm walking into the middle of a movie, but I
>> have a couple questions.  Please forgive me if my questions have
>> already been answer in previous discussions.
>
> Welcome to the show!
>
>>
>> On Tue, Aug 23, 2011 at 1:40 PM, Dimitri Glazkov  
>> wrote:
>>> All,
>>>
>>> Over the last few weeks, a few folks and myself have been working on
>>> fleshing out the vision for the Component Model. Here's what we've
>>> done so far:
>>>
>>> * Created a general overview document for behavior attachment problem
>>> on the Web (http://wiki.whatwg.org/wiki/Behavior_Attachment);
>>> * Wrote down the a set of guidelines on how we intend to tackle the
>>> problem (http://wiki.whatwg.org/wiki/Component_Model_Methodology);
>>> * Updated the list of use cases and desired properties for each case
>>> (http://wiki.whatwg.org/wiki/Component_Model_Use_Cases);
>>> * Captured the overall component model design and how it satisfies
>>> each desired property (http://wiki.whatwg.org/wiki/Component_Model),
>>
>> This section 
>> seems to imply that components can override the traversal and
>> manipulation APIs defined by DOM Core.  Do you mean that they can
>> override the JavaScript APIs folks use for traversal and manipulation,
>> or can they override the traversal and manipulation APIs used by other
>> languages bound to the DOM and internally by specifications?
>
> I certainly didn't mean to convey either: the former as some new thing
> introduced by the Component Model, and the latter as something that is
> being attempted.
>
> All it says is that your components are DOM objects and inherit the
> DOM Core APIs. You can add your own properties and extend the API
> surface.
>
>>
>> For example, suppose we implemented the Component Model in WebKit and
>> a component overrided the nextSibling traversal API.  Would
>> Objective-C code interacting with the component (e.g., via Mac OS X's
>> Object-C API for interacting with the DOM) see the original API or the
>> override?  Similarly, for browsers such as Safari, Chrome, Firefox,
>> and Opera that provide a script-based extension mechanism, would
>> extensions interacting with these components (e.g., via isolated
>> worlds or XPCNativeWrappers) see the original API or the override?
>>
>> My sense is that you only mean that Components can shadow (and here I
>> mean shadow in the traditional Computer Science sense
>> ) the normal
>> traversal and manipulation, not that they can override it, per se.
>
> Just to reiterate, the Component Model doesn't add or change anything
> here that's not possible today.
>
> How can I make this more clear in the overview?
>
>>
>>
>> This section 
>> says "... and ensures that no information about the shadow DOM tree
>> crosses this boundary."  Surely that's an overstatement.  At a
>> minimum, I assume the shadow DOM participates in layout, so its height
>> and width is leaked.
>
> Oh you're right. I need to ratchet down the language. "Information" is
> a very heavy word.
>
>>
>>
>> ---8<---
>> var shadow2 = new ShadowRoot(this); // throws an exception.
>> --->8---
>>
>> I'm not sure I understand why that's the best design decision.  Maybe
>> this is explained elsewhere?  I link would help folks like me
>> understand better.  It looks like this design decision is tied up into
>> how http://wiki.whatwg.org/wiki/Component_Model#Composability works.
>
> Ah, good point. I need to expand on this. I'll start a thread to discuss.
>
>>
>>
>> This section 
>> says "... this also explains why you can't add shadow DOM subtrees to
>> input or details elements."  It seems unfortunate that some elements
>> will accept new ShadowRoots but others will not.  Is this an
>> implementation detail?  What's the list of elements that reject
>> ShadowRoots?
>
> As I mentioned in the section, any element that uses more than one CSS
> box and isn't specified in terms of CSS. The spec would need to have
> an explicit list.
>
>>
>> As an example, it seems entirely reasonable that you'd want to create
>> an autocomplete dropdown component for use with an input element.  It
>> seems like the natural thing to do would be to subclass the "input"
>> element and add an autocomplete dropdown as a shadow DOM.  This design
>> choice appears to preclude this use case.  Instead, I need to subclass
>> "div" or whatever and replicate the HTMLInputElement API, which seems
>> like the opposite of the "reuse existing mechanisms" design principle
>> .
>
> For what it's worth, this particular use case has grown into a list
> attribute on the input element:
> http://www.whatw

Re: Component Model Update

[Dimitri Glazkov]

Hi Olli!

On Wed, Aug 24, 2011 at 3:13 AM, Olli Pettay  wrote:
> On 08/23/2011 11:40 PM, Dimitri Glazkov wrote:
>>
>> All,
>>
>> Over the last few weeks, a few folks and myself have been working on
>> fleshing out the vision for the Component Model. Here's what we've
>> done so far:
>>
>> * Created a general overview document for behavior attachment problem
>> on the Web (http://wiki.whatwg.org/wiki/Behavior_Attachment);
>> * Wrote down the a set of guidelines on how we intend to tackle the
>> problem (http://wiki.whatwg.org/wiki/Component_Model_Methodology);
>> * Updated the list of use cases and desired properties for each case
>> (http://wiki.whatwg.org/wiki/Component_Model_Use_Cases);
>> * Captured the overall component model design and how it satisfies
>> each desired property (http://wiki.whatwg.org/wiki/Component_Model),
>> including a handy comparison with existing relevant specs and
>> implementations
>>
>> (http://wiki.whatwg.org/wiki/Component_Model#Comparison_With_Existing_Specs_and_Implementations).
>>
>> After of this iteration, the proposed shadow DOM API no longer
>> includes the .shadow accessor (see details here
>> http://dglazkov.github.com/component-model/dom.html). Instead, the
>> shadow DOM subtree association happens in ShadowRoot constructor:
>>
>> var element = document.createElement("div");
>> var shadow = new ShadowRoot(element); // {element} now has shadow DOM
>> subtree, and {shadow} is its root.
>> shadow.appendChild(document.createElement("p")).textContent = "weee!!';
>
>
> This is getting a bit better, more XBL2-like, but just with different syntax
> :)

I am glad you like it!

>
>
> Adam already sent comments about most of the things I had in mind
> and I'm especially interested to know about
> "This section 
> seems to imply that components can override the traversal and
> manipulation APIs defined by DOM Core." since that could have major effects
> to browser engine architecture. If all the APIs could be
> overridden, and browser engine is expected to call the JS implemented
> versions, the problems we have now with mutation events would be there
> with all the DOM methods.
>
>
>
> The wiki page doesn't mention at all how events are propagated.
> I assume mousemove events should be fired in the real dom, but also in
> shadow dom? mouseover/out should in some cases fire only in shadow dom,
> but in some cases both in shadow and real...etc.
> Is the idea to clone events like in XBL2, or propagate but
> re-target like in XBL1 or what?

The event propagation is already mostly spec'd out here:
http://dglazkov.github.com/component-model/events.html

Propagation through  element and handling evenets for the
confinement primitives isn't yet done.

:DG<

>
>
> -Olli
>
>
>>
>> Keeping the accessor out allows for proper encapsulation and
>> confinement (better explanation of these new bits of terminology here:
>> https://plus.google.com/103035368214666982008/posts/AnGBpHZzQu6), and
>> also simplifies the API surface.
>>
>> Please review. Feedback is welcome!
>>
>> :DG<
>>
>>
>
>

Re: Component Model Update

[Dimitri Glazkov]

On Tue, Aug 23, 2011 at 9:19 PM, Adam Barth  wrote:
> I feel somewhat like I'm walking into the middle of a movie, but I
> have a couple questions.  Please forgive me if my questions have
> already been answer in previous discussions.

Welcome to the show!

>
> On Tue, Aug 23, 2011 at 1:40 PM, Dimitri Glazkov  
> wrote:
>> All,
>>
>> Over the last few weeks, a few folks and myself have been working on
>> fleshing out the vision for the Component Model. Here's what we've
>> done so far:
>>
>> * Created a general overview document for behavior attachment problem
>> on the Web (http://wiki.whatwg.org/wiki/Behavior_Attachment);
>> * Wrote down the a set of guidelines on how we intend to tackle the
>> problem (http://wiki.whatwg.org/wiki/Component_Model_Methodology);
>> * Updated the list of use cases and desired properties for each case
>> (http://wiki.whatwg.org/wiki/Component_Model_Use_Cases);
>> * Captured the overall component model design and how it satisfies
>> each desired property (http://wiki.whatwg.org/wiki/Component_Model),
>
> This section 
> seems to imply that components can override the traversal and
> manipulation APIs defined by DOM Core.  Do you mean that they can
> override the JavaScript APIs folks use for traversal and manipulation,
> or can they override the traversal and manipulation APIs used by other
> languages bound to the DOM and internally by specifications?

I certainly didn't mean to convey either: the former as some new thing
introduced by the Component Model, and the latter as something that is
being attempted.

All it says is that your components are DOM objects and inherit the
DOM Core APIs. You can add your own properties and extend the API
surface.

>
> For example, suppose we implemented the Component Model in WebKit and
> a component overrided the nextSibling traversal API.  Would
> Objective-C code interacting with the component (e.g., via Mac OS X's
> Object-C API for interacting with the DOM) see the original API or the
> override?  Similarly, for browsers such as Safari, Chrome, Firefox,
> and Opera that provide a script-based extension mechanism, would
> extensions interacting with these components (e.g., via isolated
> worlds or XPCNativeWrappers) see the original API or the override?
>
> My sense is that you only mean that Components can shadow (and here I
> mean shadow in the traditional Computer Science sense
> ) the normal
> traversal and manipulation, not that they can override it, per se.

Just to reiterate, the Component Model doesn't add or change anything
here that's not possible today.

How can I make this more clear in the overview?

>
>
> This section 
> says "... and ensures that no information about the shadow DOM tree
> crosses this boundary."  Surely that's an overstatement.  At a
> minimum, I assume the shadow DOM participates in layout, so its height
> and width is leaked.

Oh you're right. I need to ratchet down the language. "Information" is
a very heavy word.

>
>
> ---8<---
> var shadow2 = new ShadowRoot(this); // throws an exception.
> --->8---
>
> I'm not sure I understand why that's the best design decision.  Maybe
> this is explained elsewhere?  I link would help folks like me
> understand better.  It looks like this design decision is tied up into
> how http://wiki.whatwg.org/wiki/Component_Model#Composability works.

Ah, good point. I need to expand on this. I'll start a thread to discuss.

>
>
> This section 
> says "... this also explains why you can't add shadow DOM subtrees to
> input or details elements."  It seems unfortunate that some elements
> will accept new ShadowRoots but others will not.  Is this an
> implementation detail?  What's the list of elements that reject
> ShadowRoots?

As I mentioned in the section, any element that uses more than one CSS
box and isn't specified in terms of CSS. The spec would need to have
an explicit list.

>
> As an example, it seems entirely reasonable that you'd want to create
> an autocomplete dropdown component for use with an input element.  It
> seems like the natural thing to do would be to subclass the "input"
> element and add an autocomplete dropdown as a shadow DOM.  This design
> choice appears to preclude this use case.  Instead, I need to subclass
> "div" or whatever and replicate the HTMLInputElement API, which seems
> like the opposite of the "reuse existing mechanisms" design principle
> .

For what it's worth, this particular use case has grown into a list
attribute on the input element:
http://www.whatwg.org/specs/web-apps/current-work/multipage/common-input-element-attributes.html#attr-input-list.
But more on the multiple shadow DOMs per element thread that's coming
up.

>
>
> This sec

Re: Component Model Update

[Olli Pettay]

On 08/23/2011 11:40 PM, Dimitri Glazkov wrote:

All,

Over the last few weeks, a few folks and myself have been working on
fleshing out the vision for the Component Model. Here's what we've
done so far:

* Created a general overview document for behavior attachment problem
on the Web (http://wiki.whatwg.org/wiki/Behavior_Attachment);
* Wrote down the a set of guidelines on how we intend to tackle the
problem (http://wiki.whatwg.org/wiki/Component_Model_Methodology);
* Updated the list of use cases and desired properties for each case
(http://wiki.whatwg.org/wiki/Component_Model_Use_Cases);
* Captured the overall component model design and how it satisfies
each desired property (http://wiki.whatwg.org/wiki/Component_Model),
including a handy comparison with existing relevant specs and
implementations
(http://wiki.whatwg.org/wiki/Component_Model#Comparison_With_Existing_Specs_and_Implementations).

After of this iteration, the proposed shadow DOM API no longer
includes the .shadow accessor (see details here
http://dglazkov.github.com/component-model/dom.html). Instead, the
shadow DOM subtree association happens in ShadowRoot constructor:

var element = document.createElement("div");
var shadow = new ShadowRoot(element); // {element} now has shadow DOM
subtree, and {shadow} is its root.
shadow.appendChild(document.createElement("p")).textContent = "weee!!';



This is getting a bit better, more XBL2-like, but just with different 
syntax :)



Adam already sent comments about most of the things I had in mind
and I'm especially interested to know about
"This section 
seems to imply that components can override the traversal and
manipulation APIs defined by DOM Core." since that could have major 
effects to browser engine architecture. If all the APIs could be

overridden, and browser engine is expected to call the JS implemented
versions, the problems we have now with mutation events would be there
with all the DOM methods.



The wiki page doesn't mention at all how events are propagated.
I assume mousemove events should be fired in the real dom, but also in
shadow dom? mouseover/out should in some cases fire only in shadow dom,
but in some cases both in shadow and real...etc.
Is the idea to clone events like in XBL2, or propagate but
re-target like in XBL1 or what?


-Olli




Keeping the accessor out allows for proper encapsulation and
confinement (better explanation of these new bits of terminology here:
https://plus.google.com/103035368214666982008/posts/AnGBpHZzQu6), and
also simplifies the API surface.

Please review. Feedback is welcome!

:DG<

Re: Component Model Update

[Adam Barth]

On Tue, Aug 23, 2011 at 9:19 PM, Adam Barth  wrote:
> I feel somewhat like I'm walking into the middle of a movie, but I
> have a couple questions.  Please forgive me if my questions have
> already been answer in previous discussions.
>
> On Tue, Aug 23, 2011 at 1:40 PM, Dimitri Glazkov  
> wrote:
>> All,
>>
>> Over the last few weeks, a few folks and myself have been working on
>> fleshing out the vision for the Component Model. Here's what we've
>> done so far:
>>
>> * Created a general overview document for behavior attachment problem
>> on the Web (http://wiki.whatwg.org/wiki/Behavior_Attachment);
>> * Wrote down the a set of guidelines on how we intend to tackle the
>> problem (http://wiki.whatwg.org/wiki/Component_Model_Methodology);
>> * Updated the list of use cases and desired properties for each case
>> (http://wiki.whatwg.org/wiki/Component_Model_Use_Cases);
>> * Captured the overall component model design and how it satisfies
>> each desired property (http://wiki.whatwg.org/wiki/Component_Model),
>
> This section 
> seems to imply that components can override the traversal and
> manipulation APIs defined by DOM Core.  Do you mean that they can
> override the JavaScript APIs folks use for traversal and manipulation,
> or can they override the traversal and manipulation APIs used by other
> languages bound to the DOM and internally by specifications?
>
> For example, suppose we implemented the Component Model in WebKit and
> a component overrided the nextSibling traversal API.  Would
> Objective-C code interacting with the component (e.g., via Mac OS X's
> Object-C API for interacting with the DOM) see the original API or the
> override?  Similarly, for browsers such as Safari, Chrome, Firefox,
> and Opera that provide a script-based extension mechanism, would
> extensions interacting with these components (e.g., via isolated
> worlds or XPCNativeWrappers) see the original API or the override?
>
> My sense is that you only mean that Components can shadow (and here I
> mean shadow in the traditional Computer Science sense
> ) the normal
> traversal and manipulation, not that they can override it, per se.
>
>
> This section 
> says "... and ensures that no information about the shadow DOM tree
> crosses this boundary."  Surely that's an overstatement.  At a
> minimum, I assume the shadow DOM participates in layout, so its height
> and width is leaked.
>
>
> ---8<---
> var shadow2 = new ShadowRoot(this); // throws an exception.
> --->8---
>
> I'm not sure I understand why that's the best design decision.  Maybe
> this is explained elsewhere?  I link would help folks like me
> understand better.  It looks like this design decision is tied up into
> how http://wiki.whatwg.org/wiki/Component_Model#Composability works.
>
>
> This section 
> says "... this also explains why you can't add shadow DOM subtrees to
> input or details elements."  It seems unfortunate that some elements
> will accept new ShadowRoots but others will not.  Is this an
> implementation detail?  What's the list of elements that reject
> ShadowRoots?
>
> As an example, it seems entirely reasonable that you'd want to create
> an autocomplete dropdown component for use with an input element.  It
> seems like the natural thing to do would be to subclass the "input"
> element and add an autocomplete dropdown as a shadow DOM.  This design
> choice appears to preclude this use case.  Instead, I need to subclass
> "div" or whatever and replicate the HTMLInputElement API, which seems
> like the opposite of the "reuse existing mechanisms" design principle
> .
>
>
> This section 
> says "When an unknown DOM element with an "x-"-prefixed tagName is
> encountered ...".  It seems unfortunate to special-case tag names that
> begin with "x-".  The IETF has a lot of experience with "x-" prefixes,
> and they're somewhat unhappy with them:
>
> http://tools.ietf.org/html/draft-saintandre-xdash
>
>
> This section 
> 
> seems somewhat half-baked at the moment.  It says as much, so I
> presume it's more of a work-in-progress.  Getting confinement right is
> pretty tricky.
>
>> including a handy comparison with existing relevant specs and
>> implementations
>> (http://wiki.whatwg.org/wiki/Component_Model#Comparison_With_Existing_Specs_and_Implementations).
>>
>> After of this iteration, the proposed shadow DOM API no longer
>> includes the .shadow accessor (see details here
>> http://dglazkov.github.com/component-model/dom.html). Instead, the
>> shadow DOM subtree association happens in ShadowRoot constructor:
>>
>> var element = document.cre

Re: Component Model Update

[Adam Barth]

I feel somewhat like I'm walking into the middle of a movie, but I
have a couple questions.  Please forgive me if my questions have
already been answer in previous discussions.

On Tue, Aug 23, 2011 at 1:40 PM, Dimitri Glazkov  wrote:
> All,
>
> Over the last few weeks, a few folks and myself have been working on
> fleshing out the vision for the Component Model. Here's what we've
> done so far:
>
> * Created a general overview document for behavior attachment problem
> on the Web (http://wiki.whatwg.org/wiki/Behavior_Attachment);
> * Wrote down the a set of guidelines on how we intend to tackle the
> problem (http://wiki.whatwg.org/wiki/Component_Model_Methodology);
> * Updated the list of use cases and desired properties for each case
> (http://wiki.whatwg.org/wiki/Component_Model_Use_Cases);
> * Captured the overall component model design and how it satisfies
> each desired property (http://wiki.whatwg.org/wiki/Component_Model),

This section 
seems to imply that components can override the traversal and
manipulation APIs defined by DOM Core.  Do you mean that they can
override the JavaScript APIs folks use for traversal and manipulation,
or can they override the traversal and manipulation APIs used by other
languages bound to the DOM and internally by specifications?

For example, suppose we implemented the Component Model in WebKit and
a component overrided the nextSibling traversal API.  Would
Objective-C code interacting with the component (e.g., via Mac OS X's
Object-C API for interacting with the DOM) see the original API or the
override?  Similarly, for browsers such as Safari, Chrome, Firefox,
and Opera that provide a script-based extension mechanism, would
extensions interacting with these components (e.g., via isolated
worlds or XPCNativeWrappers) see the original API or the override?

My sense is that you only mean that Components can shadow (and here I
mean shadow in the traditional Computer Science sense
) the normal
traversal and manipulation, not that they can override it, per se.


This section 
says "... and ensures that no information about the shadow DOM tree
crosses this boundary."  Surely that's an overstatement.  At a
minimum, I assume the shadow DOM participates in layout, so its height
and width is leaked.


---8<---
var shadow2 = new ShadowRoot(this); // throws an exception.
--->8---

I'm not sure I understand why that's the best design decision.  Maybe
this is explained elsewhere?  I link would help folks like me
understand better.  It looks like this design decision is tied up into
how http://wiki.whatwg.org/wiki/Component_Model#Composability works.


This section 
says "... this also explains why you can't add shadow DOM subtrees to
input or details elements."  It seems unfortunate that some elements
will accept new ShadowRoots but others will not.  Is this an
implementation detail?  What's the list of elements that reject
ShadowRoots?

As an example, it seems entirely reasonable that you'd want to create
an autocomplete dropdown component for use with an input element.  It
seems like the natural thing to do would be to subclass the "input"
element and add an autocomplete dropdown as a shadow DOM.  This design
choice appears to preclude this use case.  Instead, I need to subclass
"div" or whatever and replicate the HTMLInputElement API, which seems
like the opposite of the "reuse existing mechanisms" design principle
.


This section 
says "When an unknown DOM element with an "x-"-prefixed tagName is
encountered ...".  It seems unfortunate to special-case tag names that
begin with "x-".  The IETF has a lot of experience with "x-" prefixes,
and they're somewhat unhappy with them:

http://tools.ietf.org/html/draft-saintandre-xdash


This section 

seems somewhat half-baked at the moment.  It says as much, so I
presume it's more of a work-in-progress.  Getting confinement right is
pretty tricky.

> including a handy comparison with existing relevant specs and
> implementations
> (http://wiki.whatwg.org/wiki/Component_Model#Comparison_With_Existing_Specs_and_Implementations).
>
> After of this iteration, the proposed shadow DOM API no longer
> includes the .shadow accessor (see details here
> http://dglazkov.github.com/component-model/dom.html). Instead, the
> shadow DOM subtree association happens in ShadowRoot constructor:
>
> var element = document.createElement("div");
> var shadow = new ShadowRoot(element); // {element} now has shadow DOM
> subtree, and {shadow} is its root.
> shadow.appendChild(document.createElement("p")).textContent = "weee!!';

This looks l

Component Model Update

[Dimitri Glazkov]

All,

Over the last few weeks, a few folks and myself have been working on
fleshing out the vision for the Component Model. Here's what we've
done so far:

* Created a general overview document for behavior attachment problem
on the Web (http://wiki.whatwg.org/wiki/Behavior_Attachment);
* Wrote down the a set of guidelines on how we intend to tackle the
problem (http://wiki.whatwg.org/wiki/Component_Model_Methodology);
* Updated the list of use cases and desired properties for each case
(http://wiki.whatwg.org/wiki/Component_Model_Use_Cases);
* Captured the overall component model design and how it satisfies
each desired property (http://wiki.whatwg.org/wiki/Component_Model),
including a handy comparison with existing relevant specs and
implementations
(http://wiki.whatwg.org/wiki/Component_Model#Comparison_With_Existing_Specs_and_Implementations).

After of this iteration, the proposed shadow DOM API no longer
includes the .shadow accessor (see details here
http://dglazkov.github.com/component-model/dom.html). Instead, the
shadow DOM subtree association happens in ShadowRoot constructor:

var element = document.createElement("div");
var shadow = new ShadowRoot(element); // {element} now has shadow DOM
subtree, and {shadow} is its root.
shadow.appendChild(document.createElement("p")).textContent = "weee!!';

Keeping the accessor out allows for proper encapsulation and
confinement (better explanation of these new bits of terminology here:
https://plus.google.com/103035368214666982008/posts/AnGBpHZzQu6), and
also simplifies the API surface.

Please review. Feedback is welcome!

:DG<