Re: Fallout of non-encapsulated shadow trees

[Adam Barth]

On Tue, Jul 1, 2014 at 8:52 PM, Boris Zbarsky bzbar...@mit.edu wrote:
 On 7/1/14, 9:13 PM, Brendan Eich wrote:
 Are you sure? Because Gecko has used XBL (1) to implement, e.g., input
 type=file, or so my aging memory says.

 We use XBL to implement marquee.

I'm working on using web components to implement marquee in Blink:

https://github.com/abarth/marquee

I've studied the XBL implementation of marquee in Gecko, and it does
leak some implementation details.  As a simple example,
alert(document.createElement('marquee')) in Firefox says [object
HTMLDivElement] because the XBL implementation uses a div.

The approach I'm using is roughly the one outlined by Maciej in [1].
The most challenging aspect by far is isolating the script interface
inside and outside the component.

If you ignore script isolation, we already know that the current
design of shadow DOM can provide isolation by twiddling some internal
bits because we use shadow DOM in the engine to implement details,
keygen, video, progress, and several other elements.  We could
expose an API to authors that would let them twiddle those same bits,
but I'm not sure we should do that without providing script isolation
of some form.

My sense from following this discussion is that there's been a lot of
talking about this subject and not very much coding.  Hopefully I'll
learn something interesting by writing code that I can report back to
this group.

Kindly,
Adam

[1] http://lists.w3.org/Archives/Public/public-webapps/2014JulSep/0024.html

Re: Fallout of non-encapsulated shadow trees

[Boris Zbarsky]

On 7/2/14, 11:07 AM, Adam Barth wrote:

I've studied the XBL implementation of marquee in Gecko, and it does
leak some implementation details.


Absolutely.  The point of the XBL implementation was to provide the 
functionality (back before there was a spec for it, note) at minimal 
cost and core complexity.  It's not even close to what hixie has specced 
for marquee right now.



As a simple example,
alert(document.createElement('marquee')) in Firefox says [object
HTMLDivElement] because the XBL implementation uses a div.


It's because XBL doesn't have a way to affect the sort of JS object 
that's created for the element and we explicitly map the marquee tag 
name to creating an HTMLDivElement C++ object because we didn't really 
have any better sort of C++ object for it to create.


Web components can help solve parts of this what sort of JS object to 
create?, I agree.


-Boris

Re: Fallout of non-encapsulated shadow trees

[Ryosuke Niwa]

On Jul 2, 2014, at 8:07 AM, Adam Barth w...@adambarth.com wrote:

 On Tue, Jul 1, 2014 at 8:52 PM, Boris Zbarsky bzbar...@mit.edu wrote:
 On 7/1/14, 9:13 PM, Brendan Eich wrote:
 Are you sure? Because Gecko has used XBL (1) to implement, e.g., input
 type=file, or so my aging memory says.
 
 We use XBL to implement marquee.
 
 I'm working on using web components to implement marquee in Blink:
 
 https://github.com/abarth/marquee
 
 I've studied the XBL implementation of marquee in Gecko, and it does
 leak some implementation details.  As a simple example,
 alert(document.createElement('marquee')) in Firefox says [object
 HTMLDivElement] because the XBL implementation uses a div.
 
 The approach I'm using is roughly the one outlined by Maciej in [1].
 The most challenging aspect by far is isolating the script interface
 inside and outside the component.
 
 If you ignore script isolation, we already know that the current
 design of shadow DOM can provide isolation by twiddling some internal
 bits because we use shadow DOM in the engine to implement details,
 keygen, video, progress, and several other elements.  We could
 expose an API to authors that would let them twiddle those same bits,
 but I'm not sure we should do that without providing script isolation
 of some form.

By twiddling some internal bits, not exposing the said shadow roots on the 
element?

 My sense from following this discussion is that there's been a lot of
 talking about this subject and not very much coding.  Hopefully I'll
 learn something interesting by writing code that I can report back to
 this group.

I don't think we necessarily have to code anything in order to have a 
discussion in this mailing list.  Correct me if I'm wrong but neither WebApps 
WG nor W3C has any sort of policy to mandate that we need to create a polyfill 
or prototype in order to write a working draft for example as far as I know.

Having said that, gaining implementation experience is definitely valuable, and 
I look forward to hearing what you find out with your work.

- R. Niwa

Re: Fallout of non-encapsulated shadow trees

[Adam Barth]

On Wed, Jul 2, 2014 at 8:15 AM, Ryosuke Niwa rn...@apple.com wrote:
 On Jul 2, 2014, at 8:07 AM, Adam Barth w...@adambarth.com wrote:
 On Tue, Jul 1, 2014 at 8:52 PM, Boris Zbarsky bzbar...@mit.edu wrote:
 On 7/1/14, 9:13 PM, Brendan Eich wrote:
 Are you sure? Because Gecko has used XBL (1) to implement, e.g., input
 type=file, or so my aging memory says.

 We use XBL to implement marquee.

 I'm working on using web components to implement marquee in Blink:

 https://github.com/abarth/marquee

 I've studied the XBL implementation of marquee in Gecko, and it does
 leak some implementation details.  As a simple example,
 alert(document.createElement('marquee')) in Firefox says [object
 HTMLDivElement] because the XBL implementation uses a div.

 The approach I'm using is roughly the one outlined by Maciej in [1].
 The most challenging aspect by far is isolating the script interface
 inside and outside the component.

 If you ignore script isolation, we already know that the current
 design of shadow DOM can provide isolation by twiddling some internal
 bits because we use shadow DOM in the engine to implement details,
 keygen, video, progress, and several other elements.  We could
 expose an API to authors that would let them twiddle those same bits,
 but I'm not sure we should do that without providing script isolation
 of some form.

 By twiddling some internal bits, not exposing the said shadow roots on the 
 element?

That's the general idea, but there are some more details.  Take a look
at how UserAgentShadowRoot is used in Blink if you want to get some
idea of what's required:

https://code.google.com/p/chromium/codesearch#search/q=UserAgentShadowRootsq=package:chromiumtype=cs

 My sense from following this discussion is that there's been a lot of
 talking about this subject and not very much coding.  Hopefully I'll
 learn something interesting by writing code that I can report back to
 this group.

 I don't think we necessarily have to code anything in order to have a 
 discussion in this mailing list.

Yes, the hundreds of messages on this topic demonstrates that's the case.  :)

 Correct me if I'm wrong but neither WebApps WG nor W3C has any sort of policy 
 to mandate that we need to create a polyfill or prototype in order to write a 
 working draft for example as far as I know.

W3C culture doesn't place as much emphasis on running code as IETF
culture does, for example, but, for topics, the best way to understand
them is to try writing some code.

 Having said that, gaining implementation experience is definitely valuable, 
 and I look forward to hearing what you find out with your work.

Thanks!

Adam

RE: Fallout of non-encapsulated shadow trees

[Domenic Denicola]

From: Maciej Stachowiak m...@apple.com

 Web Components as currently designed cannot explain the behavior of any 
 built-in elements (except maybe those which can be explained with CSS alone).

Unfortunately this is a hard problem that nobody has even sketched a solution 
to.

From what I remember, you were arguing for some kind of soft encapsulation, 
which could be broken by e.g. overwriting Object.getOwnPropertyDescriptor, 
window.Number, Node.prototype.getAttribute, or anything else potentially 
useful that someone would use in implementing their elements. (I think it was 
called type X encapsulation in various discussions; I do not remember what X 
was.) But soft encapsulation is just as useless for explaining the platform as 
no encapsulation at all.

True encapsulation, wherein each element gets some kind of isolated world in 
which to implement itself, is much harder. Blink-in-JS [1] accomplishes 
something along these lines, but does not leverage custom elements, shadow DOM, 
or the like, and essentially works by redirecting through a WebIDL binding 
layer. Perhaps we can draw inspiration from there.

[1]: 
https://docs.google.com/a/google.com/presentation/d/1XvZdAF29Fgn19GCjDhHhlsECJAfOR49tpUFWrbtQAwU/edit

Re: Fallout of non-encapsulated shadow trees

[Brendan Eich]

Domenic Denicola wrote:

True encapsulation, wherein each element gets some kind of isolated world in 
which to implement itself, is much harder. Blink-in-JS [1] accomplishes 
something along these lines, but does not leverage custom elements, shadow DOM, 
or the like, and essentially works by redirecting through a WebIDL binding 
layer. Perhaps we can draw inspiration from there.

[1]:https://docs.google.com/a/google.com/presentation/d/1XvZdAF29Fgn19GCjDhHhlsECJAfOR49tpUFWrbtQAwU/edit


Mozilla did XUL and XBL what, 15 years ago? JS implementing IDL (XPIDL, 
whatever) interfaces, interoperating with C++, XBL bindings to compose 
elements out of other elements. It's doable, especially if you avoid the 
temptation to seek perfectection (true encapsulation). Enemy of the 
good, and all that.


I'm not saying WebComponents aren't good enough, note well. Sounds like 
they're pretty good and can be evolved and built upon to be even better 
in later iterations. If they can't be minimized much for the first 
interoperable spec, then full speed ahead -- but beware premature 
standardization. Need more implementations coming up in parallel. Who is 
implementing for real right now?


/be

Re: Fallout of non-encapsulated shadow trees

[Edward O'Connor]

Hi,

Maciej said:

 I agree with the need for encapsulation in Web Components and have
 been arguing for it for a long time. Currently, despite agreement
 dating back several years, it doesn’t even offer a mode with better
 encapsulation. Now that the non-encapsulation version has shipped in
 Chrome, it may be hard to change other than by renaming everything.

 Web Components as currently designed cannot explain the behavior of
 any built-in elements (except maybe those which can be explained with
 CSS alone).

Domenic replied:

 From what I remember, you were arguing for some kind of soft
 encapsulation, which could be broken by e.g. overwriting
 Object.getOwnPropertyDescriptor [etc…]

Type 2 encapsulation (Encapsulation against deliberate access in
Maciej's original email[1]) isn't a security boundary protecting the
component from the containing page. Type 2 is simply the idea that we
should not provide API for outside code to poke into the component's
shadow DOM without some kind of explicit buy-in (exporting, etc.) by the
component's author. Page authors could hack around it and get at the
internals if they really, really wanted to. But their code to do this
would look bad and they should feel bad for writing it. :)

Exposing the shadow DOM of an element to everyone with API means that
the entire contour of that DOM is now API. That's bad. Half the point of
having a component model is to allow component authors to hide their
implementation details so they can change them without breaking people
using their component.

 But soft encapsulation is just as useless for explaining the platform
 as no encapsulation at all.

I think just as useless overstates your case. Type 2 allows you to
hide implementation details of your component from authors better than
Type 1 does. Yes, it's not isolation for security purposes, so it
doesn't get you the whole way, but like Brendan said, we shouldn't let
the perfect be the enemy of the good.


Ted

1. http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1364.html

Re: Fallout of non-encapsulated shadow trees

[Brendan Eich]

I meant Shadow DOM below, where I wrote Web Components.

IIRC Mozilla second, Google first, are implementing. Anyone else?

/be

Brendan Eich wrote:
I'm not saying WebComponents aren't good enough, note well. Sounds 
like they're pretty good and can be evolved and built upon to be even 
better in later iterations. If they can't be minimized much for the 
first interoperable spec, then full speed ahead -- but beware 
premature standardization. Need more implementations coming up in 
parallel. Who is implementing for real right now? 

RE: Fallout of non-encapsulated shadow trees

[Domenic Denicola]

From: Edward O'Connor [mailto:eocon...@apple.com] 

 But soft encapsulation is just as useless for explaining the platform 
 as no encapsulation at all.

 I think just as useless overstates your case. Type 2 allows you to hide 
 implementation details of your component from authors better than Type 1 
 does. Yes, it's not isolation for security purposes, so it doesn't get you 
 the whole way, but like Brendan said, we shouldn't let the perfect be the 
 enemy of the good.

Well, but *for explaining the platform* it is just as useless. It may be useful 
independently for authors who wish to protect against interference by people 
who are afraid of feeling bad, but it is not useful for explaining the platform.

My personal perspective is that it is already a shame we are on track to have 
two versions (in some sense) of web components: the existing one, and one that 
explains the platform. It would be a shame to have a third in between those 
two, that is unlike the existing one but also does not explain the platform. So 
I guess along this axis I would strongly prefer perfect to good, I suppose 
because I think what we have already is good.

Re: Fallout of non-encapsulated shadow trees

[Brendan Eich]

Domenic Denicola wrote:

Well, but*for explaining the platform*  it is just as useless.


That is a false idol if it means no intermediate steps that explain some 
but not all of the platform.



  It may be useful independently for authors who wish to protect against 
interference by people who are afraid of feeling bad, but it is not useful for 
explaining the platform.

My personal perspective is that it is already a shame we are on track to have two versions (in some sense) of 
web components: the existing one, and one that explains the platform. It would be a shame to have a third in 
between those two, that is unlike the existing one but also does not explain the platform. So I guess along 
this axis I would strongly prefer perfect to good, I suppose because I think what we 
have already is good.


Sorry, I'm confused. What do we have now, already, among top browsers 
that is good? Or do you mean prospective stuff? Because among 
interoperating browsers, AFAIK we do not have any XBL2 or Shadow DOM or 
other such, after all these years.


Could you enumerate the three versions (in any sense) of web components 
in the worst case you cite above?


/be

RE: Fallout of non-encapsulated shadow trees

[Domenic Denicola]

From: Brendan Eich [mailto:bren...@secure.meer.net] 

 That is a false idol if it means no intermediate steps that explain some but 
 not all of the platform.

Sure. But I don't think the proposed type 2 encapsulation explains any of the 
platform at all. (Just as per Maciej's email from Monday, the existing shadow 
DOM spec doesn't explain any of the platform either.)

 Sorry, I'm confused. What do we have now, already, among top browsers that is 
 good? Or do you mean prospective stuff? Because among interoperating 
 browsers, AFAIK we do not have any XBL2 or Shadow DOM or other such, after 
 all these years.

I am not sure of your definition of prospective and top browsers, but according 
to https://jonrimmer.github.io/are-we-componentized-yet/ and linked issues, 
Chrome/Opera is shipping and Firefox is shipping behind a flag. And by 
shipping, I mean shipping the current shadow DOM spec, which I consider good.

(Although, 
https://bugzilla.mozilla.org/showdependencytree.cgi?id=811542hide_resolved=1 
shows that Firefox has lots of outstanding bugs, so I can't really say how 
close they are to unflagging.)

 Could you enumerate the three versions (in any sense) of web components in 
 the worst case you cite above?

Sure. They would be:

1. What is being shipped now/the current shadow DOM spec
2. A version of it that gives soft encapsulation
3. A version of it that gives true encapsulation, suitable for implementing 
built-ins

The relative badness of having 1+2+3 vs. just 1+3 is largely a function of what 
version ends up meaning. If it is a small additional flag, no big deal. If it 
is three separate conceptual models and APIs, bad news.

Re: Fallout of non-encapsulated shadow trees

[Brendan Eich]

Domenic Denicola wrote:

From: Brendan Eich [mailto:bren...@secure.meer.net]

  That is a false idol if it means no intermediate steps that explain some but 
not all of the platform.


Sure. But I don't think the proposed type 2 encapsulation explains any of the 
platform at all.


Are you sure? Because Gecko has used XBL (1) to implement, e.g., input 
type=file, or so my aging memory says. That's good enough and it has 
shipped for years, unless I'm mistaken.



  Sorry, I'm confused. What do we have now, already, among top browsers that is 
good? Or do you mean prospective stuff? Because among interoperating browsers, 
AFAIK we do not have any XBL2 or Shadow DOM or other such, after all these years.


I am not sure of your definition of prospective and top browsers, but according 
tohttps://jonrimmer.github.io/are-we-componentized-yet/  and linked issues, Chrome/Opera 
is shipping and Firefox is shipping behind a flag. And by shipping, I mean shipping the 
current shadow DOM spec, which I consider good.

(Although,https://bugzilla.mozilla.org/showdependencytree.cgi?id=811542hide_resolved=1
  shows that Firefox has lots of outstanding bugs, so I can't really say how close 
they are to unflagging.)


I meant all by top browsers. Otherwise we (developers) don't 
really have now any cross-browser web component to stand on and resist 
2nd or 3rd variations.



  Could you enumerate the three versions (in any sense) of web components in 
the worst case you cite above?


Sure. They would be:

1. What is being shipped now/the current shadow DOM spec


You're getting ahead of your own terms of debate here. Any we who 
have WC in this list, or another standards body list, must be 
developers dealing with all top browsers, at least.



2. A version of it that gives soft encapsulation
3. A version of it that gives true encapsulation, suitable for implementing 
built-ins


See above about input type=file. Boris should weigh in.

I don't even know what 3 means. Is it well defined, or just some utopia? 
I didn't see anyone seriously propose it.



The relative badness of having 1+2+3 vs. just 1+3 is largely a function of what 
version ends up meaning. If it is a small additional flag, no big deal. If it 
is three separate conceptual models and APIs, bad news.


You do seem to be making some perfect over good choices, but perfect is 
no-place -- it doesn't exist.


Let's work on 1 first, then get to 2, and declare victory. If Maciej is 
loath to implement 1 before 2, because widget APIs will leak 
implementation details, perhaps we shouldn't standardize in a hurry. I 
still see value in multiple implementors tracking a draft standard spec.


/be

Re: Fallout of non-encapsulated shadow trees

[Ryosuke Niwa]

On Jul 1, 2014, at 5:34 PM, Domenic Denicola dome...@domenicdenicola.com 
wrote:

 From: Edward O'Connor [mailto:eocon...@apple.com] 
 
 But soft encapsulation is just as useless for explaining the platform 
 as no encapsulation at all.
 
 I think just as useless overstates your case. Type 2 allows you to hide 
 implementation details of your component from authors better than Type 1 
 does. Yes, it's not isolation for security purposes, so it doesn't get you 
 the whole way, but like Brendan said, we shouldn't let the perfect be the 
 enemy of the good.
 
 Well, but *for explaining the platform* it is just as useless. It may be 
 useful independently for authors who wish to protect against interference by 
 people who are afraid of feeling bad, but it is not useful for explaining the 
 platform.
 
 My personal perspective is that it is already a shame we are on track to have 
 two versions (in some sense) of web components: the existing one, and one 
 that explains the platform. It would be a shame to have a third in between 
 those two, that is unlike the existing one but also does not explain the 
 platform. So I guess along this axis I would strongly prefer perfect to 
 good, I suppose because I think what we have already is good.


I don't understand.  We're not on track to have any versions of Web Components 
as is.  We haven't even agreed upon which types of encapsulation should be used 
by default.


On Jul 1, 2014, at 6:05 PM, Domenic Denicola dome...@domenicdenicola.com 
wrote:

 From: Brendan Eich [mailto:bren...@secure.meer.net] 
 
 Sorry, I'm confused. What do we have now, already, among top browsers that 
 is good? Or do you mean prospective stuff? Because among interoperating 
 browsers, AFAIK we do not have any XBL2 or Shadow DOM or other such, after 
 all these years.
 
 I am not sure of your definition of prospective and top browsers, but 
 according to https://jonrimmer.github.io/are-we-componentized-yet/ and linked 
 issues, Chrome/Opera is shipping and Firefox is shipping behind a flag. And 
 by shipping, I mean shipping the current shadow DOM spec, which I consider 
 good.


Obviously, I'm not in a position to speak for Mozilla but I'm not certain 
Firefox is shipping behind a flag accurately reflects their position given 
the following post made by Boris on blink-dev:
https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/ay9tVGRa8Rg/YEALsZv1dF4J

I would love to hear from Mozillians if they have gotten enough developer 
feedbacks to change their position on the matter or not.

- R. Niwa

RE: Fallout of non-encapsulated shadow trees

[Domenic Denicola]

From: Brendan Eich [mailto:bren...@secure.meer.net] 

 I don't even know what 3 means. Is it well defined, or just some utopia?

I think it is as well defined as 2 is. Both are really in terms of vague 
requirements:

2. Widget libraries should be implementable without leaking implementation 
details to non-determined consumers.
3. Widget libraries should be implementable without leaking implementation 
details to determined consumers.

 Let's work on 1 first, then get to 2, and declare victory.

I think the crux of my argument is that this would be a mistake.

 If Maciej is loath to implement 1 before 2, because widget APIs will leak 
 implementation details, perhaps we shouldn't standardize in a hurry. I still 
 see value in multiple implementors tracking a draft standard spec.

I fully agree with this, however.

Re: Fallout of non-encapsulated shadow trees

[Tab Atkins Jr.]

On Tue, Jul 1, 2014 at 6:13 PM, Brendan Eich bren...@secure.meer.net wrote:
 Domenic Denicola wrote:

 From: Brendan Eich [mailto:bren...@secure.meer.net]

   That is a false idol if it means no intermediate steps that explain
  some but not all of the platform.


 Sure. But I don't think the proposed type 2 encapsulation explains any of
 the platform at all.


 Are you sure? Because Gecko has used XBL (1) to implement, e.g., input
 type=file, or so my aging memory says. That's good enough and it has
 shipped for years, unless I'm mistaken.

XBL is either type 3, or it's type 2 but weak/magical enough that it
doesn't actually expose anything.  Gecko does *not* today leak any
internal details of input type=file, in the way that type 2 web
components would leak; that would be a major security breach.
(Leaking other elements would be something between a bug and a
security breach, depending on the element.)

~TJ

Re: Fallout of non-encapsulated shadow trees

[Brendan Eich]

Domenic Denicola wrote:

From: Brendan Eich [mailto:bren...@secure.meer.net]


  I don't even know what 3 means. Is it well defined, or just some utopia?


I think it is as well defined as 2 is. Both are really in terms of vague 
requirements:

2. Widget libraries should be implementable without leaking implementation 
details to non-determined consumers.


This is what input type=file relies on in Gecko, IINM, so there's an 
existence proof and practical (if single-implementation) definition.


You did not reply to my point that we have (2) and it's not 
unexplained, nor does a spec for it explain nothing. It may be 
overspecified by the one implementation in Gecko, but it's along the 
lines of what Maciej and Ted presented.



3. Widget libraries should be implementable without leaking implementation 
details to determined consumers.


Sounds like some evolution of Shadow DOM to use Google Caja = SES, etc. 
Where SES is not a utopia, but not widely used either; considered 
burdensome (fairly or not).



  Let's work on 1 first, then get to 2, and declare victory.


I think the crux of my argument is that this would be a mistake.


What this? You want to stand on (1) till (3) is figured out and made 
practical? You have to account for (2) sufficing in Firefox still, and 
justify making perfect enemy of good (always a mistake in my book).



  If Maciej is loath to implement 1 before 2, because widget APIs will leak 
implementation details, perhaps we shouldn't standardize in a hurry. I still see 
value in multiple implementors tracking a draft standard spec.


I fully agree with this, however.


Pronoun trouble again. If by this you mean multiple implementors 
tracking a draft standard spec, then we shouldn't have any vendor 
arguing shipped it, set the standard, spec is frozen. Right?


/be

Re: Fallout of non-encapsulated shadow trees

[Maciej Stachowiak]

 On Jul 1, 2014, at 3:26 PM, Domenic Denicola dome...@domenicdenicola.com 
 wrote:
 
 From: Maciej Stachowiak m...@apple.com
 
 Web Components as currently designed cannot explain the behavior of any 
 built-in elements (except maybe those which can be explained with CSS alone).
 
 Unfortunately this is a hard problem that nobody has even sketched a solution 
 to.

I have sketched a solution to it (including publicly in the last Web Apps WG 
meeting). I believe the following set of primitives would be sufficient for 
implementing built-in elements or their close equivalents:

(1) “closed” or “Type 2 Encapsulation” mode for the Shadow DOM as I have 
advocated it (i.e. no access to get into or style the Shadow DOM when in this 
mode).
(2) Ability to have the script associated with the component run in a separate 
“world”
(3) A two-way membrane at the API layer between a component and a script; 
approximately, this would be the Structured Clone algorithm, but extended to 
also translate references to DOM objects between the worlds.
(4) An import mechanism that loads some script to run in a separate world, and 
allows importing custom element definitions from it.
(5) Custom elements with the ability to work with the membrane from (3) and the 
script world from (2).

With this in place, the only “magic” of built-in elements would be access to 
platform capabilities that some built-in elements have (which could be exported 
as lower-level specific APIs, e.g. participation in form submission for form 
controls), and the fact that they come pre-imported.

Unfortunately, Shadow DOM doesn’t provide (1) and HTML Imports doesn’t provide 
(4). Thus, merely adding (2) and (3) won’t be enough; we’ll need to create 
parallels to API that Google has already shipped and frozen without addressing 
this problem.

Thus, when you say the following:

On Jul 1, 2014, at 5:34 PM, Domenic Denicola dome...@domenicdenicola.com 
wrote:

 From: Edward O'Connor [mailto:eocon...@apple.com] 
 
 But soft encapsulation is just as useless for explaining the platform 
 as no encapsulation at all.
 
 I think just as useless overstates your case. Type 2 allows you to hide 
 implementation details of your component from authors better than Type 1 
 does. Yes, it's not isolation for security purposes, so it doesn't get you 
 the whole way, but like Brendan said, we shouldn't let the perfect be the 
 enemy of the good.
 
 Well, but *for explaining the platform* it is just as useless. It may be 
 useful independently for authors who wish to protect against interference by 
 people who are afraid of feeling bad, but it is not useful for explaining the 
 platform.
 
 My personal perspective is that it is already a shame we are on track to have 
 two versions (in some sense) of web components: the existing one, and one 
 that explains the platform. It would be a shame to have a third in between 
 those two, that is unlike the existing one but also does not explain the 
 platform. So I guess along this axis I would strongly prefer perfect to 
 good, I suppose because I think what we have already is good.

I believe you are wrong. DOM-level encapsulation can be used as-is in 
combination with scripting encapsulation to provide a secure platform for 
untrusted components, and a way to explain built-in elements. Shadow DOM 
without DOM-level encapsulation cannot be used in combination with other 
primitives.

Thus, if we’d built Shadow DOM with DOM-level encapsulation in the first place, 
we could add the right other primitives to it and be able to explain built-in 
elements. But the way it was actually done can’t explain anything built-in.


I would really like to build a system that can provide security for mutually 
distrusting components and embedders, and that can explain the platform. 
However, I feel that my efforts to give feedback, both to nudge in this 
direction and otherwise, have been rejected and stonewalled. With Google 
controlling editorship of all the Web Components specs, shipping the only 
implementation so far -- unprefixed, freezing said implementation, and not 
being very open to non-Google input, and making all decisions in private via 
“consensus within Google”, it is hard to see how to meaningfully participate. 
If there is any possibility of some of those factors changing, I think it’s not 
too late to end up with a better component model and I’d be interested in 
helping.

Regards,
Maciej

P.S. Due to the factors stated in the last paragraph, I’m going to try to limit 
my participation in this thread as much as possible for the sake of my own 
mental equilibrium.

Re: Fallout of non-encapsulated shadow trees

[Brian Kardell]

[snip]
On Jul 1, 2014 10:07 PM, Maciej Stachowiak m...@apple.com wrote:

 (3) A two-way membrane at the API layer between a component and a script;
approximately, this would be the Structured Clone algorithm, but extended
to also translate references to DOM objects between the worlds.

Has this all been spelled out somewhere in more detail and i missed it? In
minutes maybe?  I'm very curious about it, references between worlds could
help in a whole number of ways beyond just this.  If it can be uncovered to
explain the existing platform (or provide a possible explanation) I'd like
to hear more.

Re: Fallout of non-encapsulated shadow trees

[Boris Zbarsky]

On 7/1/14, 9:16 PM, Ryosuke Niwa wrote:

I would love to hear from Mozillians if they have gotten enough developer 
feedbacks


Our implementation is currently at a stage that can best be described as 
not usable yet, which is most of the feedback we've gotten thus far.  ;)


-Boris

Re: Fallout of non-encapsulated shadow trees

[Boris Zbarsky]

On 7/1/14, 9:13 PM, Brendan Eich wrote:

Are you sure? Because Gecko has used XBL (1) to implement, e.g., input
type=file, or so my aging memory says.


We use XBL to implement marquee.

We do not use XBL to implement input type=file, though there was 
once a project to do that sort of thing.


-Boris

Re: Fallout of non-encapsulated shadow trees

[Boris Zbarsky]

On 7/1/14, 11:20 PM, Brendan Eich wrote:

XBL can expose anonymous content via special API:

https://developer.mozilla.org/en-US/docs/XBL/XBL_1.0_Reference/DOM_Interfaces#getAnonymousNodes

https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XUL/Tutorial/XBL_Example
https://developer.mozilla.org/en-US/docs/XBL/XBL_1.0_Reference/Anonymous_Content

I'm rusty on this stuff; bz should correct anything amiss here.


A few things:

1)  The XBL implementation has not been static over time.  At one point, 
XBL ran in the same global (Realm, whatever you want to call it) as the 
document it was bound to.  This caused obvious encapsulation issues.  We 
attempted to change it to run in a separate global, but ran into compat 
problems with Firefox UI and extensions that depended on the old 
behavior.  At the moment, XBL runs in the same global as the document 
when the document is part of the browser UI, but runs in a separate 
global when the document is untrusted.  This means we can use XBL to 
implement things like marquee or the controls of video elements 
without worrying about the XBL scripts being affected by whatever the 
web page is doing to its global.


2)  The document.getAnonymousNodes API does exist, but is only exposed 
to trusted globals and the XBL globals associated to untrusted web 
pages.  In other words, you can only use getAnonymousNodes() if you are 
same-global with the XBL code already.



   Gecko does*not*  today  leak any
internal details of input type=file, in the way that type 2 web
components would leak; that would be a major security breach.


Right you are -- native anonymous content is special this way. But ES6
proxies are used (albeit by C++ APIs):


In fact, we place the JS reflections for the innards of the file input 
in the same global as XBL bound to the page, if I recall correctly. 
Though there is no exposed API to get at it, of course.



So I question whether membranes *and* structured clones are required.
SES uses membranes without cloning (wrapping, not cloning). This all
seems doable in-JS with enough care and testing, including
capability-leak detection. Proxies are awesome!


Membranes are definitely doable, but there's a lot of details to get right.

-Boris

Re: Fallout of non-encapsulated shadow trees

[Brendan Eich]

Boris Zbarsky wrote:

On 7/1/14, 9:13 PM, Brendan Eich wrote:

Are you sure? Because Gecko has used XBL (1) to implement, e.g., input
type=file, or so my aging memory says.


We use XBL to implement marquee.


Also video playback controls, per your next message.

We do not use XBL to implement input type=file, though there was 
once a project to do that sort of thing.


Thanks.

There's a lot of prior art here to inform this discussion and (I hope it 
already did inform) shadow DOM. But it seems like not everyone knows or 
remembers the full story, definitely including me.


To get to the promised land, we need to share the same bible. Who is the 
Shadow DOM / WebComponents Moses?


/be

Re: Fallout of non-encapsulated shadow trees

[Boris Zbarsky]

On 7/2/14, 12:15 AM, Brendan Eich wrote:

Boris Zbarsky wrote:

On 7/1/14, 9:13 PM, Brendan Eich wrote:

Are you sure? Because Gecko has used XBL (1) to implement, e.g., input
type=file, or so my aging memory says.


We use XBL to implement marquee.


Also video playback controls, per your next message.


That's correct, but that's a slightly different situation because the 
XBL in that case is bound to an element that is internal anonymous 
content (in the same way that the button inside an input type=file 
is internal anonymous content) that the web page shouldn't have any 
access to anyway.  The marquee case is interesting because the element 
the XBL is attached to is in fact visible to the web page.


-Boris

Re: Fallout of non-encapsulated shadow trees

[Ryosuke Niwa]

On May 15, 2014, at 6:17 AM, Anne van Kesteren ann...@annevk.nl wrote:

 I'm still trying to grasp the philosophy behind shadow trees.
 Sometimes it's explained as exposing the primitives but the more I
 learn (rather slowly, this time at BlinkOn) the more it looks like a
 bunch of new primitives.
 
 We cannot explain input still, but since we allow going inside the
 shadow tree we now see the need for a composed tree walker (a way to
 iterate over a tree including its non-encapsulated interleaved shadow
 trees). In addition we see the need for a composed range of sorts, so
 selection across boundaries makes sense. Neither of these are really
 needed to explain bits of the existing platform.

I would really like get a grasp on everyone's perspective here as well (please 
be as concise as possible).

I feel that a lot of contention about shadow DOM and other aspects of Web 
Components comes from the fact everyone has his/her own definition of Web 
Components.

It would be of great use to state clearly what problem each party is 
trying/hoping to resolve with Web Components, or more specifically with shadow 
DOM in this thread.

- R. Niwa

Re: Fallout of non-encapsulated shadow trees

[Maciej Stachowiak]

 On May 15, 2014, at 6:17 AM, Anne van Kesteren ann...@annevk.nl wrote:
 
 I'm still trying to grasp the philosophy behind shadow trees.
 Sometimes it's explained as exposing the primitives but the more I
 learn (rather slowly, this time at BlinkOn) the more it looks like a
 bunch of new primitives.
 
 We cannot explain input still, but since we allow going inside the
 shadow tree we now see the need for a composed tree walker (a way to
 iterate over a tree including its non-encapsulated interleaved shadow
 trees). In addition we see the need for a composed range of sorts, so
 selection across boundaries makes sense. Neither of these are really
 needed to explain bits of the existing platform.

I agree with the need for encapsulation in Web Components and have been arguing 
for it for a long time. Currently, despite agreement dating back several years, 
it doesn’t even offer a mode with better encapsulation. Now that the 
non-encapsulation version has shipped in Chrome, it may be hard to change other 
than by renaming everything.

Web Components as currently designed cannot explain the behavior of any 
built-in elements (except maybe those which can be explained with CSS alone).

Regards,
Maciej

Fallout of non-encapsulated shadow trees

[Anne van Kesteren]

I'm still trying to grasp the philosophy behind shadow trees.
Sometimes it's explained as exposing the primitives but the more I
learn (rather slowly, this time at BlinkOn) the more it looks like a
bunch of new primitives.

We cannot explain input still, but since we allow going inside the
shadow tree we now see the need for a composed tree walker (a way to
iterate over a tree including its non-encapsulated interleaved shadow
trees). In addition we see the need for a composed range of sorts, so
selection across boundaries makes sense. Neither of these are really
needed to explain bits of the existing platform.


-- 
http://annevankesteren.nl/