Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Tab Atkins Jr.]

On Mon, Mar 17, 2014 at 9:08 AM, Anne van Kesteren  wrote:
> On Thu, Feb 13, 2014 at 2:34 PM, Boris Zbarsky  wrote:
>> On 2/13/14 5:35 AM, Anne van Kesteren wrote:
>>>
>>> Also, Type 2 can be used for built-in elements
>>
>> Built-in elements need Type 4.
>
> Well, Chrome does not have Type 4, yet is implementing parts of the
> their elements using shadow DOM constructs. So clearly something is
> possible with the current design.

We enforce that through C++ magic right now.  There's a lot of details
to figure out before it's something that can be exposed to JS.

~TJ

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Boris Zbarsky]

On 3/17/14 12:08 PM, Anne van Kesteren wrote:

Well, Chrome does not have Type 4, yet is implementing parts of the
their elements using shadow DOM constructs.


What makes you say Chrome doesn't have Type 4?

They do in fact have it for the case in question, as far as I can tell 
(inaccessible .shadowRoot, separate worlds for the JS objects, etc). 
They just don't expose a way to do Type 4 to web pages.


-Boris

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Anne van Kesteren]

On Thu, Feb 13, 2014 at 2:34 PM, Boris Zbarsky  wrote:
> On 2/13/14 5:35 AM, Anne van Kesteren wrote:
>>
>> Also, Type 2 can be used for built-in elements
>
> Built-in elements need Type 4.

Well, Chrome does not have Type 4, yet is implementing parts of the
their elements using shadow DOM constructs. So clearly something is
possible with the current design.


-- 
http://annevankesteren.nl/

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Alex Russell]

On Sat, Feb 15, 2014 at 1:57 AM, Maciej Stachowiak  wrote:

>
> On Feb 14, 2014, at 9:00 AM, Erik Arvidsson  wrote:
>
>
>
>
> On Thu, Feb 13, 2014 at 9:00 PM, Maciej Stachowiak  wrote:
>
>>
>>  On Feb 13, 2014, at 4:01 PM, Alex Russell 
>> wrote:
>>
>> A closure is an iron-clad isolation mechanism for object ownership with
>> regards to the closing-over function object. There's absolutely no
>> iteration of the closed-over state of a function object; any such
>> enumeration would be a security hole (as with the old Mozilla
>> object-as-param-to-eval bug). You can't get the value of "foo" in this
>> example except with the consent of the returned function:
>>
>>
>> var maybeVendFoo = function() {
>>   var foo = 1;
>>   return function(willMaybeCall) {
>> if (/* some test */) { willMaybeCall(foo); }
>>   }
>> };
>>
>> Leakage via other methods can be locked down by the first code to run in
>> an environment (caja does this, and nothing prevents it from doing this for
>> SD as it can pre-process/filter scripts that might try to access internals).
>>
>>
>> Caja is effective for protecting a page from code it embeds, since the
>> page can have a guarantee that its code is the first to run. But it cannot
>> be used to protect embedded code from a page, so for example a JS library
>> cannot guarantee that objects it holds only in closure variables will not
>> leak to the surrounding page...
>>
>
> That is incorrect. It is definitely possible to write code that does not
> leak to the environment. It is painful to do because like Ryosuke wrote you
> cannot use any of the built in functions or objects. You can only use
> primitives and literals. But with a compile to JS language this can be made
> less painful and in the days of LLVM to JS compilers this seems like a
> trivial problem.
>
>
> Let's assume for the sake of argument that there was actually a practical
> way to do this for nontrivial code[*]. Even if that were the case, it would
> not be relevant to the way in which today's JS programs use closures. They
> find closures useful even without a transpiler to a primitives-only subset
> of the language. So one cannot claim the value of closures for
> encapsulation follows from this theoretical possibility.
>

This misses a good chunk of cultural JS practice (which, I should note,
still isn't a substitute for the previously requested use-cases and example
code): in many frameworks, closure-captured state is considered to be
"hostile" as it prevents monkey-patches and makes extension difficult.
Many, instead, lean on convention (some form of "_"-based prefix/suffix) to
denote semi-private state.

Closures most frequently find use in areas where JS's lexical binding
leaves much to be desired, (ab)using the function context as a way to
create new lexical bindings.

Arguing about them as a containment structure without this cultural context
isn't particularly enlightening.

Looking forward to hearing more about possible uses for the type of
encapsulation you're proposing.

Regards


> Regards,
> Maciej
>
>
> * - And really, it is not that practical. Many algorithms require a
> variable-sized data structure, or one that is indexable, or one that is
> associative - and you can't do any of that with only primitives and a fixed
> set of variable slots. And you can't do anything to a primitive that would
> potentially invoke a method call explicitly or implicitly, which includes
> such things as number-to-string conversion, using functions on the Math
> object on numbers, and the majority of things you would do to a string
> (such as converting to/from char codes). What remains is pretty narrow.
> This is setting aside that you would not be able to do anything useful to
> the outside world besides return a value. For reference, the LLVM-to-JS
> compilers that exist make major use of non-primitives, in particular
> Emscripten uses a giant typed array to represent memory.
>
>

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Maciej Stachowiak]

On Feb 14, 2014, at 7:16 PM, Boris Zbarsky  wrote:

> On 2/14/14 10:07 PM, Ryosuke Niwa wrote:
>> We most vigorously object to making the CSS style resolver depend on JS
>> DOM object properties.
> 
> Ryosuke, I think you misunderstood the proposal.  I'm pretty sure we all 
> object to having the CSS style resolver depend on anything that involves JS 
> properties.  But it's not necessarily a problem to have it depends on 
> internal node state that can be set via DOM APIs (e.g. it already depends on 
> DOM attribute values and whatnot).
> 
> So in implementation terms, an element would just have an internal boolean 
> and setting "this.shadowRoot = undefined" or whatnot would set that boolean; 
> the CSS machinery would read that boolean.  That seems fairly workable to me; 
> whether it's the sort of API we want is a separate issue that I have no 
> opinion on.

The API we currently have doesn't actually allow this:

readonly attribute ShadowRoot? shadowRoot;

Now, we could change this attribute to not be readonly. However, that makes me 
wonder - what happens if you assign something other than null? Would this 
become an API to replace the shadow root? That seems like a bad idea. On the 
whole, this choice seems like messier API change than a parameter to 
createShadowRoot indicating the mode (which I thought the WG had rough 
consensus on over a year ago).

Regards,
Maciej

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Bjoern Hoehrmann]

* Alex Russell wrote:
>So you've written off the massive coordination costs of adding a uniform to
>all code across all of Google and, on that basis, have suggested there
>isn't really a problem? ISTM that it would be a multi-month (year?) project
>to go patch every project in google3 and then wait for them to all deploy
>new code.
>
>Perhaps you can imagine a simpler/faster way to do it that doesn't include
>getting owners-LGTMs from nearly every part of google3 and submitting tests
>in nearly every part of the tree??

This is a vendor-neutral international standards development forum, not
some Google product development mailing list.
-- 
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Maciej Stachowiak]

On Feb 14, 2014, at 9:00 AM, Erik Arvidsson  wrote:

> 
> 
> 
> On Thu, Feb 13, 2014 at 9:00 PM, Maciej Stachowiak  wrote:
> 
> On Feb 13, 2014, at 4:01 PM, Alex Russell  wrote:
>> A closure is an iron-clad isolation mechanism for object ownership with 
>> regards to the closing-over function object. There's absolutely no iteration 
>> of the closed-over state of a function object; any such enumeration would be 
>> a security hole (as with the old Mozilla object-as-param-to-eval bug). You 
>> can't get the value of "foo" in this example except with the consent of the 
>> returned function:
> 
>> 
>> var maybeVendFoo = function() {
>>   var foo = 1;
>>   return function(willMaybeCall) {
>> if (/* some test */) { willMaybeCall(foo); }
>>   }
>> };
>> 
>> Leakage via other methods can be locked down by the first code to run in an 
>> environment (caja does this, and nothing prevents it from doing this for SD 
>> as it can pre-process/filter scripts that might try to access internals).
> 
> Caja is effective for protecting a page from code it embeds, since the page 
> can have a guarantee that its code is the first to run. But it cannot be used 
> to protect embedded code from a page, so for example a JS library cannot 
> guarantee that objects it holds only in closure variables will not leak to 
> the surrounding page...
> 
> That is incorrect. It is definitely possible to write code that does not leak 
> to the environment. It is painful to do because like Ryosuke wrote you cannot 
> use any of the built in functions or objects. You can only use primitives and 
> literals. But with a compile to JS language this can be made less painful and 
> in the days of LLVM to JS compilers this seems like a trivial problem.

Let's assume for the sake of argument that there was actually a practical way 
to do this for nontrivial code[*]. Even if that were the case, it would not be 
relevant to the way in which today's JS programs use closures. They find 
closures useful even without a transpiler to a primitives-only subset of the 
language. So one cannot claim the value of closures for encapsulation follows 
from this theoretical possibility.

Regards,
Maciej


* - And really, it is not that practical. Many algorithms require a 
variable-sized data structure, or one that is indexable, or one that is 
associative - and you can't do any of that with only primitives and a fixed set 
of variable slots. And you can't do anything to a primitive that would 
potentially invoke a method call explicitly or implicitly, which includes such 
things as number-to-string conversion, using functions on the Math object on 
numbers, and the majority of things you would do to a string (such as 
converting to/from char codes). What remains is pretty narrow. This is setting 
aside that you would not be able to do anything useful to the outside world 
besides return a value. For reference, the LLVM-to-JS compilers that exist make 
major use of non-primitives, in particular Emscripten uses a giant typed array 
to represent memory.

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Ryosuke Niwa]

On Feb 14, 2014, at 7:07 PM, Ryosuke Niwa  wrote:
> On Feb 14, 2014, at 6:12 PM, Daniel Freedman  wrote:
>>> Since you have preciously claimed that instantiating a template element may 
>>> not be a common pattern for custom elements / web components, I have a hard 
>>> time accepting the claim that you’re certain accessing shadow root is a 
>>> common coding pattern.
>>> 
>>> Surely as the person asking for the more restricted form, the onus falls to 
>>> you to make the argument that the added restrictions show their value. 
>> 
>> I don’t think it’s fair to say that we’re asking for the more restricted 
>> form since Apple has never agreed to support the more open form (Type I 
>> encapsulation) in the first place.
>> 
>> I don't understand this point, can you elaborate? It certainly seems like 
>> you are asking for a form of ShadowDOM encapsulation that is more 
>> restrictive than the already defined Type 1.
> 
> On Feb 14, 2014, at 6:55 PM, Alex Russell  wrote:
>> > I don’t think it’s fair to say that we’re asking for the more restricted 
>> > form since Apple has never agreed to support the more open form (Type I 
>> > encapsulation) in the first place.
>> 
>> Waitwhat? Either what you want *is* more restricted than Type 1 or it's 
>> not. If it is, the burden falls to you to outline use-cases and identify 
>> users (as type 1 proponents have).
>> 
> I’m saying that YOU are the one asking for Type I encapsulation on the basis 
> that we’ve never agreed that Type I encapsulation is necessary or desirable 
> for the level 1 specifications.  The only consensus we’ve had in this working 
> group so far was to add a switch between two modes since Google 
> representatives have insisted that they want Type I encapsulation and Apple 
> representatives have insisted that we want Type II encapsulation.  Neither 
> party has convinced each other that either type is desirable, let alone which 
> one is a better default, as far as I can tell.
> 
I’m not saying that only Type I encapsulation proponents bear the burden to 
make the case.  I’m simply stating that proponents of Type I and Type II 
encapsulations equally bear the burdens to make their case for each 
encapsulation model.

- R. Niwa

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Ryosuke Niwa]

On Feb 14, 2014, at 7:16 PM, Boris Zbarsky  wrote:
> On 2/14/14 10:07 PM, Ryosuke Niwa wrote:
>> We most vigorously object to making the CSS style resolver depend on JS
>> DOM object properties.
> 
> Ryosuke, I think you misunderstood the proposal.  I'm pretty sure we all 
> object to having the CSS style resolver depend on anything that involves JS 
> properties.  But it's not necessarily a problem to have it depends on 
> internal node state that can be set via DOM APIs (e.g. it already depends on 
> DOM attribute values and whatnot).
> 
> So in implementation terms, an element would just have an internal boolean 
> and setting "this.shadowRoot = undefined" or whatnot would set that boolean; 
> the CSS machinery would read that boolean.  That seems fairly workable to me; 
> whether it's the sort of API we want is a separate issue that I have no 
> opinion on.

I see. So we’re going to have some special setter that magically updates node’s 
internal state when being set on “undefined”.

That seems workable although I do agree that whether we want that sort of API 
is a separate issue.

- R. Niwa

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Boris Zbarsky]

On 2/14/14 10:07 PM, Ryosuke Niwa wrote:

We most vigorously object to making the CSS style resolver depend on JS
DOM object properties.


Ryosuke, I think you misunderstood the proposal.  I'm pretty sure we all 
object to having the CSS style resolver depend on anything that involves 
JS properties.  But it's not necessarily a problem to have it depends on 
internal node state that can be set via DOM APIs (e.g. it already 
depends on DOM attribute values and whatnot).


So in implementation terms, an element would just have an internal 
boolean and setting "this.shadowRoot = undefined" or whatnot would set 
that boolean; the CSS machinery would read that boolean.  That seems 
fairly workable to me; whether it's the sort of API we want is a 
separate issue that I have no opinion on.


-Boris

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Ryosuke Niwa]

On Feb 14, 2014, at 6:12 PM, Daniel Freedman  wrote:
> On Fri, Feb 14, 2014 at 5:39 PM, Ryosuke Niwa  wrote:
> On Feb 14, 2014, at 5:17 PM, Alex Russell  wrote:
> 
>> On Fri, Feb 14, 2014 at 3:56 PM, Ryosuke Niwa  wrote:
>> On Feb 14, 2014, at 2:50 PM, Elliott Sprehn  wrote:
>>> On Fri, Feb 14, 2014 at 2:39 PM, Boris Zbarsky  wrote:
>>> On 2/14/14 5:31 PM, Jonas Sicking wrote:
>>> Also, I think that the Type 2 encapsulation has the same
>>> characteristics. If the component author does things perfectly and
>>> doesn't depend on any outside code
>>> 
>>> And never invokes any DOM methods on the nodes in the component's anonymous 
>>> content.  Which is a pretty strong restriction; I'm having a bit of trouble 
>>> thinking of a useful component with this property.
>>> 
>>> 
>>> I think my biggest issue with Type-2 is that unlike the languages cited for 
>>> providing "private" it's trying to mimic it provides no backdoor for tools 
>>> and frameworks to get at private state and at the same time it doesn't add 
>>> any security benefits.
>> 
>> Except that JavaScript doesn’t have “private”.
>> 
>> Right, it only has the stronger form (closures)
> 
> I don’t think we have the stronger form in that using any builtin objects and 
> their functions would result in leaking information inside the closure.
> 
>>> Ruby, Python, Java, C# and almost all other modern languages that provide a 
>>> private facility for interfaces (as advocated by the Type-2 design) provide 
>>> a backdoor through reflection to get at the variables and methods anyway. 
>>> This allowed innovation like AOP, dependency injection, convention based 
>>> frameworks and more.
>>> 
>>> So if we provide Type-2 I'd argue we _must_ provide some kind of escape 
>>> hatch to still get into the ShadowRoot from script. I'm fine providing some 
>>> kind of "don't let CSS styles enter me" feature, but hiding the shadowRoot 
>>> property from the Element makes no sense.
>> 
>> I don’t see how the above two sentences lead to a consolation that we must 
>> provide an escape hatch to get shadow root from script given that such an 
>> escape hatch already exists if the component authors end up using builtin 
>> DOM functions.
>> 
>> It's the difference between using "legit" methods and "hacking around the 
>> platform". If it's desirable to allow continued access in these situations, 
>> why isn't .shadowRoot an acceptable speed bump?
> 
> The point is that it’s NOT ALWAYS desirable to allow continued access.  We 
> saying that components should have a choice.
> 
>> If it's not desirable, isn't the ability to get around the restriction at 
>> all a bug to be fixed (arguing, implicitly, that we should be investigating 
>> stronger primitives that Maciej and I were discussing to enable Type 4)?
> 
> Are you also arguing that we should “fix” closures so that you can safely 
> call builtin objects and their methods without leaking information?  If not, 
> I don’t see why we need to fix this problem only for web components.
> 
>>> We all agree it's not a security boundary and you can go through great 
>>> lengths to get into the ShadowRoot if you really wanted, all we've done by 
>>> not exposing it is make sure that users include some crazy 
>>> jquery-make-shadows-visible.js library so they can build tools like Google 
>>> Feedback or use a new framework or polyfill.
>> 
>> I don’t think Google Feedback is a compelling use case since all components 
>> on Google properties could simply expose “shadow” property themselves.
>> 
>> So you've written off the massive coordination costs of adding a uniform to 
>> all code across all of Google and, on that basis, have suggested there isn't 
>> really a problem? ISTM that it would be a multi-month (year?) project to go 
>> patch every project in google3 and then wait for them to all deploy new code.
> 
> On the other hand, Google representatives have previously argued that adding 
> template instantiation mechanism into browser isn’t helping anyone, because 
> framework authors would figure that out better than we can.
> 
> I have a hard time understanding why anyone would come to conclusion that 
> forcing every single web components that use template to have:
> 
> this.createShadowRoot().appendChild(document.importNode(template.contents));
> 
> I don't understand how this pertains to encapsulation. Could you elaborate?

See http://lists.w3.org/Archives/Public/public-webapps/2013OctDec/0855.html
"I don't see how pushing that one line down into the browser is helping anyone. 
Web components are part of the extensible web concept where we provide a 
minimal subset of features necessary for opinionated frameworks to build things 
on top. Supporting  in document.register is easily done in script, so 
I believe it's better left to developers as they're better at building 
frameworks than we are.”

which was an argument made against automatically instantiating shadow root for 
custom elements.  If you truly believe that Web d

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Alex Russell]

On 14 Feb 2014 17:39, "Ryosuke Niwa"  wrote:
>
> On Feb 14, 2014, at 5:17 PM, Alex Russell  wrote:
>
>> On Fri, Feb 14, 2014 at 3:56 PM, Ryosuke Niwa  wrote:
>>>
>>> On Feb 14, 2014, at 2:50 PM, Elliott Sprehn 
wrote:

 On Fri, Feb 14, 2014 at 2:39 PM, Boris Zbarsky  wrote:
>
> On 2/14/14 5:31 PM, Jonas Sicking wrote:
>>
>> Also, I think that the Type 2 encapsulation has the same
>> characteristics. If the component author does things perfectly and
>> doesn't depend on any outside code
>
>
> And never invokes any DOM methods on the nodes in the component's
anonymous content.  Which is a pretty strong restriction; I'm having a bit
of trouble thinking of a useful component with this property.
>

 I think my biggest issue with Type-2 is that unlike the languages
cited for providing "private" it's trying to mimic it provides no backdoor
for tools and frameworks to get at private state and at the same time it
doesn't add any security benefits.
>>>
>>>
>>> Except that JavaScript doesn’t have “private”.
>>
>>
>> Right, it only has the stronger form (closures)
>
>
> I don’t think we have the stronger form in that using any builtin objects
and their functions would result in leaking information inside the closure.
>
 Ruby, Python, Java, C# and almost all other modern languages that
provide a private facility for interfaces (as advocated by the Type-2
design) provide a backdoor through reflection to get at the variables and
methods anyway. This allowed innovation like AOP, dependency injection,
convention based frameworks and more.

 So if we provide Type-2 I'd argue we _must_ provide some kind of
escape hatch to still get into the ShadowRoot from script. I'm fine
providing some kind of "don't let CSS styles enter me" feature, but hiding
the shadowRoot property from the Element makes no sense.
>>>
>>>
>>> I don’t see how the above two sentences lead to a consolation that we
must provide an escape hatch to get shadow root from script given that such
an escape hatch already exists if the component authors end up using
builtin DOM functions.
>>
>>
>> It's the difference between using "legit" methods and "hacking around
the platform". If it's desirable to allow continued access in these
situations, why isn't .shadowRoot an acceptable speed bump?
>
>
> The point is that it’s NOT ALWAYS desirable to allow continued access.
 We saying that components should have a choice.
>
>> If it's not desirable, isn't the ability to get around the
restriction at all a bug to be fixed (arguing, implicitly, that we should
be investigating stronger primitives that Maciej and I were discussing to
enable Type 4)?
>
>
> Are you also arguing that we should “fix” closures so that you can safely
call builtin objects and their methods without leaking information?  If
not, I don’t see why we need to fix this problem only for web components.
>
 We all agree it's not a security boundary and you can go through great
lengths to get into the ShadowRoot if you really wanted, all we've done by
not exposing it is make sure that users include some crazy
jquery-make-shadows-visible.js library so they can build tools like Google
Feedback or use a new framework or polyfill.
>>>
>>>
>>> I don’t think Google Feedback is a compelling use case since all
components on Google properties could simply expose “shadow” property
themselves.
>>
>>
>> So you've written off the massive coordination costs of adding a uniform
to all code across all of Google and, on that basis, have suggested there
isn't really a problem? ISTM that it would be a multi-month (year?) project
to go patch every project in google3 and then wait for them to all deploy
new code.
>
>
> On the other hand, Google representatives have previously argued that
adding template instantiation mechanism into browser isn’t helping anyone,
because framework authors would figure that out better than we can.

This is non sequitur. One relates to a way of implementing a way to
generate something, another with the default access policy of related (but
not identical) things. They are different in kind.

> I have a hard time understanding why anyone would come to conclusion that
forcing every single web components that use template to have:
>
>
this.createShadowRoot().appendChild(document.importNode(template.contents));
>
> is any less desirable than having components that want to expose
shadowRoot to write:
>
> this.shadowRoot = createShadowRoot();
>
>>> Since you have preciously claimed that instantiating a template element
may not be a common pattern for custom elements / web components, I have a
hard time accepting the claim that you’re certain accessing shadow root is
a common coding pattern.
>>
>>
>> Surely as the person asking for the more restricted form, the onus falls
to you to make the argument that the added restrictions show their value.
>
>
> I don’t think it’s fair to say that we’re asking for the more restricted
form since Apple 

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Tab Atkins Jr.]

On Fri, Feb 14, 2014 at 6:12 PM, Daniel Freedman  wrote:
> The other hand of this argument is that components that wish to lock
> themselves down could write:
>
> this.shadowRoot = undefined;
>
> Of course, this does would not change the outcome of the Shadow Selector
> spec, which is why a flag for createShadowRoot or something would be
> necessary to configure the CSS engine (unless you're ok with having the
> existence of a property on some DOM object control CSS parsing rules).

There's nothing wrong with doing that, by the way.  The Selectors data
model is already based on DOM, for DOM-based documents.  I don't
currently specify how you know when an element in the selectors tree
has "shadow trees", but I can easily say that it's whatever's
reachable via the DOM properties in DOM-based documents.

~TJ

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Daniel Freedman]

On Fri, Feb 14, 2014 at 5:39 PM, Ryosuke Niwa  wrote:

> On Feb 14, 2014, at 5:17 PM, Alex Russell  wrote:
>
> On Fri, Feb 14, 2014 at 3:56 PM, Ryosuke Niwa  wrote:
>
>> On Feb 14, 2014, at 2:50 PM, Elliott Sprehn  wrote:
>>
>> On Fri, Feb 14, 2014 at 2:39 PM, Boris Zbarsky  wrote:
>>
>>> On 2/14/14 5:31 PM, Jonas Sicking wrote:
>>>
 Also, I think that the Type 2 encapsulation has the same
 characteristics. If the component author does things perfectly and
 doesn't depend on any outside code

>>>
>>> And never invokes any DOM methods on the nodes in the component's
>>> anonymous content.  Which is a pretty strong restriction; I'm having a bit
>>> of trouble thinking of a useful component with this property.
>>>
>>>
>> I think my biggest issue with Type-2 is that unlike the languages cited
>> for providing "private" it's trying to mimic it provides no backdoor for
>> tools and frameworks to get at private state and at the same time it
>> doesn't add any security benefits.
>>
>>
>> Except that JavaScript doesn’t have “private”.
>>
>
> Right, it only has the stronger form (closures)
>
>
> I don’t think we have the stronger form in that using any builtin objects
> and their functions would result in leaking information inside the closure.
>
>  Ruby, Python, Java, C# and almost all other modern languages that
>> provide a private facility for interfaces (as advocated by the Type-2
>> design) provide a backdoor through reflection to get at the variables and
>> methods anyway. This allowed innovation like AOP, dependency injection,
>> convention based frameworks and more.
>>
>> So if we provide Type-2 I'd argue we _must_ provide some kind of escape
>> hatch to still get into the ShadowRoot from script. I'm fine providing some
>> kind of "don't let CSS styles enter me" feature, but hiding the shadowRoot
>> property from the Element makes no sense.
>>
>>
>> I don’t see how the above two sentences lead to a consolation that we
>> must provide an escape hatch to get shadow root from script given that such
>> an escape hatch already exists if the component authors end up using
>> builtin DOM functions.
>>
>
> It's the difference between using "legit" methods and "hacking around the
> platform". If it's desirable to allow continued access in these situations,
> why isn't .shadowRoot an acceptable speed bump?
>
>
> The point is that it’s NOT ALWAYS desirable to allow continued access.  We
> saying that components should have a choice.
>
>  If it's not desirable, isn't the ability to get around the restriction *at
> all* a bug to be fixed (arguing, implicitly, that we should be
> investigating stronger primitives that Maciej and I were discussing to
> enable Type 4)?
>
>
> Are you also arguing that we should “fix” closures so that you can safely
> call builtin objects and their methods without leaking information?  If
> not, I don’t see why we need to fix this problem only for web components.
>
>  We all agree it's not a security boundary and you can go through great
>> lengths to get into the ShadowRoot if you really wanted, all we've done by
>> not exposing it is make sure that users include some crazy
>> jquery-make-shadows-visible.js library so they can build tools like Google
>> Feedback or use a new framework or polyfill.
>>
>>
>> I don’t think Google Feedback is a compelling use case since all
>> components on Google properties could simply expose “shadow” property
>> themselves.
>>
>
> So you've written off the massive coordination costs of adding a uniform
> to all code across all of Google and, on that basis, have suggested there
> isn't really a problem? ISTM that it would be a multi-month (year?) project
> to go patch every project in google3 and then wait for them to all deploy
> new code.
>
>
> On the other hand, Google representatives have previously argued that
> adding template instantiation mechanism into browser isn’t helping anyone,
> because framework authors would figure that out better than we can.
>
> I have a hard time understanding why anyone would come to conclusion that
> forcing every single web components that use template to have:
>
>
> this.createShadowRoot().appendChild(document.importNode(template.contents));
>

I don't understand how this pertains to encapsulation. Could you elaborate?


>
> is any less desirable than having components that want to expose
> shadowRoot to write:
>
> this.shadowRoot = createShadowRoot();
>

The other hand of this argument is that components that wish to lock
themselves down could write:

this.shadowRoot = undefined;

Of course, this does would not change the outcome of the Shadow Selector
spec, which is why a flag for createShadowRoot or something would be
necessary to configure the CSS engine (unless you're ok with having the
existence of a property on some DOM object control CSS parsing rules).

(Also your example would not handle multiple shadow roots correctly, here's
one that would)
var sr = this.shadowRoot;
var newSr = this.createSha

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Elliott Sprehn]

On Fri, Feb 14, 2014 at 5:17 PM, Alex Russell wrote:

> On Fri, Feb 14, 2014 at 3:56 PM, Ryosuke Niwa  wrote:
>
>> [...]

>  We all agree it's not a security boundary and you can go through great
>> lengths to get into the ShadowRoot if you really wanted, all we've done by
>> not exposing it is make sure that users include some crazy
>> jquery-make-shadows-visible.js library so they can build tools like Google
>> Feedback or use a new framework or polyfill.
>>
>>
>> I don’t think Google Feedback is a compelling use case since all
>> components on Google properties could simply expose “shadow” property
>> themselves.
>>
>
> So you've written off the massive coordination costs of adding a uniform
> to all code across all of Google and, on that basis, have suggested there
> isn't really a problem? ISTM that it would be a multi-month (year?) project
> to go patch every project in google3 and then wait for them to all deploy
> new code.
>
> Perhaps you can imagine a simpler/faster way to do it that doesn't include
> getting owners-LGTMs from nearly every part of google3 and submitting tests
> in nearly every part of the tree??
>
>

Please also note that Google Feedback's screenshot technology works fine on
many non-Google web pages and is used in situations that are not on Google
controlled properties. If we're going to ask the entire web to expose
".shadow" by convention so things like Google Feedback or Readability can
work we might as well just expose it in the platform.

- E

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Ryosuke Niwa]

On Feb 14, 2014, at 5:17 PM, Alex Russell  wrote:

> On Fri, Feb 14, 2014 at 3:56 PM, Ryosuke Niwa  wrote:
> On Feb 14, 2014, at 2:50 PM, Elliott Sprehn  wrote:
>> On Fri, Feb 14, 2014 at 2:39 PM, Boris Zbarsky  wrote:
>> On 2/14/14 5:31 PM, Jonas Sicking wrote:
>> Also, I think that the Type 2 encapsulation has the same
>> characteristics. If the component author does things perfectly and
>> doesn't depend on any outside code
>> 
>> And never invokes any DOM methods on the nodes in the component's anonymous 
>> content.  Which is a pretty strong restriction; I'm having a bit of trouble 
>> thinking of a useful component with this property.
>> 
>> 
>> I think my biggest issue with Type-2 is that unlike the languages cited for 
>> providing "private" it's trying to mimic it provides no backdoor for tools 
>> and frameworks to get at private state and at the same time it doesn't add 
>> any security benefits.
> 
> Except that JavaScript doesn’t have “private”.
> 
> Right, it only has the stronger form (closures)

I don’t think we have the stronger form in that using any builtin objects and 
their functions would result in leaking information inside the closure.

>> Ruby, Python, Java, C# and almost all other modern languages that provide a 
>> private facility for interfaces (as advocated by the Type-2 design) provide 
>> a backdoor through reflection to get at the variables and methods anyway. 
>> This allowed innovation like AOP, dependency injection, convention based 
>> frameworks and more.
>> 
>> So if we provide Type-2 I'd argue we _must_ provide some kind of escape 
>> hatch to still get into the ShadowRoot from script. I'm fine providing some 
>> kind of "don't let CSS styles enter me" feature, but hiding the shadowRoot 
>> property from the Element makes no sense.
> 
> I don’t see how the above two sentences lead to a consolation that we must 
> provide an escape hatch to get shadow root from script given that such an 
> escape hatch already exists if the component authors end up using builtin DOM 
> functions.
> 
> It's the difference between using "legit" methods and "hacking around the 
> platform". If it's desirable to allow continued access in these situations, 
> why isn't .shadowRoot an acceptable speed bump?

The point is that it’s NOT ALWAYS desirable to allow continued access.  We 
saying that components should have a choice.

> If it's not desirable, isn't the ability to get around the restriction at all 
> a bug to be fixed (arguing, implicitly, that we should be investigating 
> stronger primitives that Maciej and I were discussing to enable Type 4)?

Are you also arguing that we should “fix” closures so that you can safely call 
builtin objects and their methods without leaking information?  If not, I don’t 
see why we need to fix this problem only for web components.

>> We all agree it's not a security boundary and you can go through great 
>> lengths to get into the ShadowRoot if you really wanted, all we've done by 
>> not exposing it is make sure that users include some crazy 
>> jquery-make-shadows-visible.js library so they can build tools like Google 
>> Feedback or use a new framework or polyfill.
> 
> I don’t think Google Feedback is a compelling use case since all components 
> on Google properties could simply expose “shadow” property themselves.
> 
> So you've written off the massive coordination costs of adding a uniform to 
> all code across all of Google and, on that basis, have suggested there isn't 
> really a problem? ISTM that it would be a multi-month (year?) project to go 
> patch every project in google3 and then wait for them to all deploy new code.

On the other hand, Google representatives have previously argued that adding 
template instantiation mechanism into browser isn’t helping anyone, because 
framework authors would figure that out better than we can.

I have a hard time understanding why anyone would come to conclusion that 
forcing every single web components that use template to have:

this.createShadowRoot().appendChild(document.importNode(template.contents));

is any less desirable than having components that want to expose shadowRoot to 
write:

this.shadowRoot = createShadowRoot();

> Since you have preciously claimed that instantiating a template element may 
> not be a common pattern for custom elements / web components, I have a hard 
> time accepting the claim that you’re certain accessing shadow root is a 
> common coding pattern.
> 
> Surely as the person asking for the more restricted form, the onus falls to 
> you to make the argument that the added restrictions show their value. 

I don’t think it’s fair to say that we’re asking for the more restricted form 
since Apple has never agreed to support the more open form (Type I 
encapsulation) in the first place.

- R. Niwa

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Alex Russell]

On Fri, Feb 14, 2014 at 3:56 PM, Ryosuke Niwa  wrote:

> On Feb 14, 2014, at 2:50 PM, Elliott Sprehn  wrote:
>
> On Fri, Feb 14, 2014 at 2:39 PM, Boris Zbarsky  wrote:
>
>> On 2/14/14 5:31 PM, Jonas Sicking wrote:
>>
>>> Also, I think that the Type 2 encapsulation has the same
>>> characteristics. If the component author does things perfectly and
>>> doesn't depend on any outside code
>>>
>>
>> And never invokes any DOM methods on the nodes in the component's
>> anonymous content.  Which is a pretty strong restriction; I'm having a bit
>> of trouble thinking of a useful component with this property.
>>
>>
> I think my biggest issue with Type-2 is that unlike the languages cited
> for providing "private" it's trying to mimic it provides no backdoor for
> tools and frameworks to get at private state and at the same time it
> doesn't add any security benefits.
>
>
> Except that JavaScript doesn’t have “private”.
>

Right, it only has the stronger form (closures) and the weaker form ("_"
prefixing properties and marking them non-enumerable using defineProperty).
SD as currently defined is the second.

>  Ruby, Python, Java, C# and almost all other modern languages that
> provide a private facility for interfaces (as advocated by the Type-2
> design) provide a backdoor through reflection to get at the variables and
> methods anyway. This allowed innovation like AOP, dependency injection,
> convention based frameworks and more.
>
> So if we provide Type-2 I'd argue we _must_ provide some kind of escape
> hatch to still get into the ShadowRoot from script. I'm fine providing some
> kind of "don't let CSS styles enter me" feature, but hiding the shadowRoot
> property from the Element makes no sense.
>
>
> I don’t see how the above two sentences lead to a consolation that we must
> provide an escape hatch to get shadow root from script given that such an
> escape hatch already exists if the component authors end up using builtin
> DOM functions.
>

It's the difference between using "legit" methods and "hacking around the
platform". If it's desirable to allow continued access in these situations,
why isn't .shadowRoot an acceptable speed bump? If it's not desirable,
isn't the ability to get around the restriction *at all* a bug to be fixed
(arguing, implicitly, that we should be investigating stronger primitives
that Maciej and I were discussing to enable Type 4)?

> We all agree it's not a security boundary and you can go through great
> lengths to get into the ShadowRoot if you really wanted, all we've done by
> not exposing it is make sure that users include some crazy
> jquery-make-shadows-visible.js library so they can build tools like Google
> Feedback or use a new framework or polyfill.
>
>
> I don’t think Google Feedback is a compelling use case since all
> components on Google properties could simply expose “shadow” property
> themselves.
>

So you've written off the massive coordination costs of adding a uniform to
all code across all of Google and, on that basis, have suggested there
isn't really a problem? ISTM that it would be a multi-month (year?) project
to go patch every project in google3 and then wait for them to all deploy
new code.

Perhaps you can imagine a simpler/faster way to do it that doesn't include
getting owners-LGTMs from nearly every part of google3 and submitting tests
in nearly every part of the tree??


> Since you have preciously claimed that instantiating a template element
> may not be a common pattern for custom elements / web components, I have a
> hard time accepting the claim that you’re certain accessing shadow root is
> a common coding pattern.
>

Surely as the person asking for the more restricted form, the onus falls to
*you* to make the argument that the added restrictions show their value.

>  So given that we should have ShadowRoot.getPrivateType2Root(element) to
> provide a sensible modern api like other languages, is providing the
> shadowRoot property on the Element any different?
>
>
> We’re disagreeing on the premise that we should have
> ShadowRoot.getPrivateType2Root.
>
> I think we need to steer this conversation back to CSS's ability to style
> the ShadowRoot. There's no reason we can't provide a "no styles can enter
> me flag" while still having the shadowRoot property and the node
> distribution APIs.
>
>
> That might be an interesting topic to discuss but www-style discussion
> appears to indicate that we need to settle encapsulation discussion in
> public-webaps regardless.
>
> - R. Niwa
>
>

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Ryosuke Niwa]

On Feb 14, 2014, at 2:50 PM, Elliott Sprehn  wrote:
> On Fri, Feb 14, 2014 at 2:39 PM, Boris Zbarsky  wrote:
> On 2/14/14 5:31 PM, Jonas Sicking wrote:
> Also, I think that the Type 2 encapsulation has the same
> characteristics. If the component author does things perfectly and
> doesn't depend on any outside code
> 
> And never invokes any DOM methods on the nodes in the component's anonymous 
> content.  Which is a pretty strong restriction; I'm having a bit of trouble 
> thinking of a useful component with this property.
> 
> 
> I think my biggest issue with Type-2 is that unlike the languages cited for 
> providing "private" it's trying to mimic it provides no backdoor for tools 
> and frameworks to get at private state and at the same time it doesn't add 
> any security benefits.

Except that JavaScript doesn’t have “private”.

> Ruby, Python, Java, C# and almost all other modern languages that provide a 
> private facility for interfaces (as advocated by the Type-2 design) provide a 
> backdoor through reflection to get at the variables and methods anyway. This 
> allowed innovation like AOP, dependency injection, convention based 
> frameworks and more.
> 
> So if we provide Type-2 I'd argue we _must_ provide some kind of escape hatch 
> to still get into the ShadowRoot from script. I'm fine providing some kind of 
> "don't let CSS styles enter me" feature, but hiding the shadowRoot property 
> from the Element makes no sense.

I don’t see how the above two sentences lead to a consolation that we must 
provide an escape hatch to get shadow root from script given that such an 
escape hatch already exists if the component authors end up using builtin DOM 
functions.

> We all agree it's not a security boundary and you can go through great 
> lengths to get into the ShadowRoot if you really wanted, all we've done by 
> not exposing it is make sure that users include some crazy 
> jquery-make-shadows-visible.js library so they can build tools like Google 
> Feedback or use a new framework or polyfill.

I don’t think Google Feedback is a compelling use case since all components on 
Google properties could simply expose “shadow” property themselves.

Since you have preciously claimed that instantiating a template element may not 
be a common pattern for custom elements / web components, I have a hard time 
accepting the claim that you’re certain accessing shadow root is a common 
coding pattern.

> So given that we should have ShadowRoot.getPrivateType2Root(element) to 
> provide a sensible modern api like other languages, is providing the 
> shadowRoot property on the Element any different?

We’re disagreeing on the premise that we should have 
ShadowRoot.getPrivateType2Root.

> I think we need to steer this conversation back to CSS's ability to style the 
> ShadowRoot. There's no reason we can't provide a "no styles can enter me 
> flag" while still having the shadowRoot property and the node distribution 
> APIs.

That might be an interesting topic to discuss but www-style discussion appears 
to indicate that we need to settle encapsulation discussion in public-webaps 
regardless.

- R. Niwa

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Elliott Sprehn]

On Fri, Feb 14, 2014 at 2:39 PM, Boris Zbarsky  wrote:

> On 2/14/14 5:31 PM, Jonas Sicking wrote:
>
>> Also, I think that the Type 2 encapsulation has the same
>> characteristics. If the component author does things perfectly and
>> doesn't depend on any outside code
>>
>
> And never invokes any DOM methods on the nodes in the component's
> anonymous content.  Which is a pretty strong restriction; I'm having a bit
> of trouble thinking of a useful component with this property.
>
>
Indeed.

I think my biggest issue with Type-2 is that unlike the languages cited for
providing "private" it's trying to mimic it provides no backdoor for tools
and frameworks to get at private state and at the same time it doesn't add
any security benefits.

Ruby, Python, Java, C# and almost all other modern languages that provide a
private facility for interfaces (as advocated by the Type-2 design) provide
a backdoor through reflection to get at the variables and methods anyway.
This allowed innovation like AOP, dependency injection, convention based
frameworks and more.

So if we provide Type-2 I'd argue we _must_ provide some kind of escape
hatch to still get into the ShadowRoot from script. I'm fine providing some
kind of "don't let CSS styles enter me" feature, but hiding the shadowRoot
property from the Element makes no sense. We all agree it's not a security
boundary and you can go through great lengths to get into the ShadowRoot if
you really wanted, all we've done by not exposing it is make sure that
users include some crazy jquery-make-shadows-visible.js library so they can
build tools like Google Feedback or use a new framework or polyfill.

So given that we should have ShadowRoot.getPrivateType2Root(element) to
provide a sensible modern api like other languages, is providing the
shadowRoot property on the Element any different?

I think we need to steer this conversation back to CSS's ability to style
the ShadowRoot. There's no reason we can't provide a "no styles can enter
me flag" while still having the shadowRoot property and the node
distribution APIs.

- E

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Boris Zbarsky]

On 2/14/14 5:31 PM, Jonas Sicking wrote:

Also, I think that the Type 2 encapsulation has the same
characteristics. If the component author does things perfectly and
doesn't depend on any outside code


And never invokes any DOM methods on the nodes in the component's 
anonymous content.  Which is a pretty strong restriction; I'm having a 
bit of trouble thinking of a useful component with this property.


-Boris

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Jonas Sicking]

On Fri, Feb 14, 2014 at 2:02 PM, Ryosuke Niwa  wrote:
> On Feb 14, 2014, at 9:00 AM, Erik Arvidsson  wrote:
>
> On Thu, Feb 13, 2014 at 9:00 PM, Maciej Stachowiak  wrote:
>>
>> On Feb 13, 2014, at 4:01 PM, Alex Russell  wrote:
>>
>> A closure is an iron-clad isolation mechanism for object ownership with
>> regards to the closing-over function object. There's absolutely no iteration
>> of the closed-over state of a function object; any such enumeration would be
>> a security hole (as with the old Mozilla object-as-param-to-eval bug). You
>> can't get the value of "foo" in this example except with the consent of the
>> returned function:
>>
>>
>> var maybeVendFoo = function() {
>>   var foo = 1;
>>   return function(willMaybeCall) {
>> if (/* some test */) { willMaybeCall(foo); }
>>   }
>> };
>>
>> Leakage via other methods can be locked down by the first code to run in
>> an environment (caja does this, and nothing prevents it from doing this for
>> SD as it can pre-process/filter scripts that might try to access internals).
>>
>>
>> Caja is effective for protecting a page from code it embeds, since the
>> page can have a guarantee that its code is the first to run. But it cannot
>> be used to protect embedded code from a page, so for example a JS library
>> cannot guarantee that objects it holds only in closure variables will not
>> leak to the surrounding page...
>
>
> That is incorrect. It is definitely possible to write code that does not
> leak to the environment. It is painful to do because like Ryosuke wrote you
> cannot use any of the built in functions or objects. You can only use
> primitives and literals. But with a compile to JS language this can be made
> less painful and in the days of LLVM to JS compilers this seems like a
> trivial problem.
>
>
> While it's technically the case that one could write a Turing-complete
> closure that doesn't leak any information, I think we all agree it's so
> painful that nobody can do this successfully by hand without relying on
> heavily-weight tools such as Caja or a LLVM-to-JS compiler.
>
> Instead of accepting this is as a status quo, we should strive to improve
> the Web platform to provide better encapsulation.

Also, I think that the Type 2 encapsulation has the same
characteristics. If the component author does things perfectly and
doesn't depend on any outside code, a Type 2 encapsulation might very
well be equivalent to Type 4.

In practice, I'm not sure that this is an interesting debate though.
In practice everyone does depend on outside code. Even people using
closures. Trying to use closures to enforce security is too brittle.

/ Jonas

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Ryosuke Niwa]

On Feb 14, 2014, at 9:00 AM, Erik Arvidsson  wrote:
> On Thu, Feb 13, 2014 at 9:00 PM, Maciej Stachowiak  wrote:
> On Feb 13, 2014, at 4:01 PM, Alex Russell  wrote:
>> A closure is an iron-clad isolation mechanism for object ownership with 
>> regards to the closing-over function object. There's absolutely no iteration 
>> of the closed-over state of a function object; any such enumeration would be 
>> a security hole (as with the old Mozilla object-as-param-to-eval bug). You 
>> can't get the value of "foo" in this example except with the consent of the 
>> returned function:
> 
>> 
>> var maybeVendFoo = function() {
>>   var foo = 1;
>>   return function(willMaybeCall) {
>> if (/* some test */) { willMaybeCall(foo); }
>>   }
>> };
>> 
>> Leakage via other methods can be locked down by the first code to run in an 
>> environment (caja does this, and nothing prevents it from doing this for SD 
>> as it can pre-process/filter scripts that might try to access internals).
> 
> Caja is effective for protecting a page from code it embeds, since the page 
> can have a guarantee that its code is the first to run. But it cannot be used 
> to protect embedded code from a page, so for example a JS library cannot 
> guarantee that objects it holds only in closure variables will not leak to 
> the surrounding page...
> 
> That is incorrect. It is definitely possible to write code that does not leak 
> to the environment. It is painful to do because like Ryosuke wrote you cannot 
> use any of the built in functions or objects. You can only use primitives and 
> literals. But with a compile to JS language this can be made less painful and 
> in the days of LLVM to JS compilers this seems like a trivial problem.

While it’s technically the case that one could write a Turing-complete closure 
that doesn’t leak any information, I think we all agree it’s so painful that 
nobody can do this successfully by hand without relying on heavily-weight tools 
such as Caja or a LLVM-to-JS compiler.

Instead of accepting this is as a status quo, we should strive to improve the 
Web platform to provide better encapsulation.

- R. Niwa

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Erik Arvidsson]

On Thu, Feb 13, 2014 at 9:00 PM, Maciej Stachowiak  wrote:

>
> On Feb 13, 2014, at 4:01 PM, Alex Russell  wrote:
>
> A closure is an iron-clad isolation mechanism for object ownership with
> regards to the closing-over function object. There's absolutely no
> iteration of the closed-over state of a function object; any such
> enumeration would be a security hole (as with the old Mozilla
> object-as-param-to-eval bug). You can't get the value of "foo" in this
> example except with the consent of the returned function:
>
>
> var maybeVendFoo = function() {
>   var foo = 1;
>   return function(willMaybeCall) {
> if (/* some test */) { willMaybeCall(foo); }
>   }
> };
>
> Leakage via other methods can be locked down by the first code to run in
> an environment (caja does this, and nothing prevents it from doing this for
> SD as it can pre-process/filter scripts that might try to access internals).
>
>
> Caja is effective for protecting a page from code it embeds, since the
> page can have a guarantee that its code is the first to run. But it cannot
> be used to protect embedded code from a page, so for example a JS library
> cannot guarantee that objects it holds only in closure variables will not
> leak to the surrounding page...
>

That is incorrect. It is definitely possible to write code that does not
leak to the environment. It is painful to do because like Ryosuke wrote you
cannot use any of the built in functions or objects. You can only use
primitives and literals. But with a compile to JS language this can be made
less painful and in the days of LLVM to JS compilers this seems like a
trivial problem.

-- 
erik

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Ryosuke Niwa]

On Feb 13, 2014, at 4:01 PM, Alex Russell  wrote:

> On Thu, Feb 13, 2014 at 1:25 PM, Maciej Stachowiak  wrote:
> On Feb 12, 2014, at 4:04 PM, Alex Russell  wrote:
> It is meant to be an encapsulation mechanism. Let me give a comparison. Many 
> JavaScript programmers choose to use closures as a way to store private data 
> for objects. That is an encapsulation mechanism. It is not, in itself, a hard 
> security mechanism. If the caller can hook your global environment, and for 
> example modify commonly used Object methods, then they may force a leak of 
> your data.
> 
> A closure is an iron-clad isolation mechanism for object ownership with 
> regards to the closing-over function object. There's absolutely no iteration 
> of the closed-over state of a function object; any such enumeration would be 
> a security hole (as with the old Mozilla object-as-param-to-eval bug). You 
> can't get the value of "foo" in this example except with the consent of the 
> returned function:
> 
> var maybeVendFoo = function() {
>   var foo = 1;
>   return function(willMaybeCall) {
> if (/* some test */) { willMaybeCall(foo); }
>   }
> };

But what if maybeVendFoo called some builtin functions like Math.abs on foo?  
e.g.

var maybeVendFoo = function () {
var foo = 1;
var bar = Math.abs(foo);
…
return function (willMaybeCall) {
if (/* some test */) {willMaybeCall(foo);
}
}

The caller of maybeVendFoo could easily override Math.abs and observe the value 
of foo:

var foo;
var realAbs = Math.abs;
Math.abs = function (val) { foo = val; return realAbs(val); }
maybeVendFoo();
Math.abs = realAbs;

This is exactly the kind of leakage we would have in Type 2 encapsulation 
Maciej has been talking about.

- R. Niwa

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Maciej Stachowiak]

On Feb 13, 2014, at 4:01 PM, Alex Russell  wrote:

> On Thu, Feb 13, 2014 at 1:25 PM, Maciej Stachowiak  wrote:
> 
> On Feb 12, 2014, at 4:04 PM, Alex Russell  wrote:
> 
>> 
>> 
>> In discussion with Elliot and Erik, there appears to be an additional 
>> complication: any of the DOM manipulation methods that aren't locked down 
>> (marked non-configurable and filtered, ala caja) create avenues to get 
>> elements from the Shadow DOM and then inject styles. E.g., even with Arv's 
>> lockdown sketch: 
>> 
>>   https://gist.github.com/arv/8857167
>> 
>> You still have most of your work ahead of you. DocumentFragment provides 
>> tons of "ins", as will all incidentally composed APIs.
> 
> I'm not totally clear on what you're saying. I believe you're pointing out 
> that injecting hooks into the scripting environment a component runs in (such 
> as by replacing methods on global protototypes) can allow the shadow root to 
> be accessed even if no explicit access is given. I agree. This is not 
> addressed with simple forms of Type 2 encapsutation. It is a non-goal for 
> Type 2.
> 
> I'd like to understand what differentiates "simple forms of Type 2 
> encapsulation" from other potential forms that still meet the Type 2 
> criteria. Can you walk me through an example and show how they would be used 
> in a framework?

Type 4 encapsulation would also meet the Type 2 criteria, for example.

The difference is that with "simple" Type 2 you do not attempt to protect 
against a pre-poisoned scripting environment. I would be satisfied with Type 4 
(if it's usable) but it is much harder to spec as you need it to give rigorous 
security guarantees.

>  
>> This is fraught.
> 
> Calling something fraught is not an argument.
> 
> Good news! I provided an argument in the following sentence to help 
> contextualize my conclusion and, I had hoped, lead you to understand why I'd 
> said that.

Your argument seems to be based on an incorrect premise.

>  
>> To get real ocap-style denial of access to the shadow DOM, we likely need to 
>> intercept and check all DOM accesses. Is the system still usable at this 
>> point? It's difficult to know. In either case, a system like caja *can* 
>> exist without explicit supportwhich raises the question: what's the 
>> goal? Is "Type 2" defined by real denial of access? Or is the request for a 
>> fig-leaf (perception of security)?
> 
> Type 2 is not meant to be a security mechanism.
> 
> I'd like to see an example of Type 2 isolation before I agree to that.
>  
> It is meant to be an encapsulation mechanism. Let me give a comparison. Many 
> JavaScript programmers choose to use closures as a way to store private data 
> for objects. That is an encapsulation mechanism. It is not, in itself, a hard 
> security mechanism. If the caller can hook your global environment, and for 
> example modify commonly used Object methods, then they may force a leak of 
> your data.
> 
> A closure is an iron-clad isolation mechanism for object ownership with 
> regards to the closing-over function object. There's absolutely no iteration 
> of the closed-over state of a function object; any such enumeration would be 
> a security hole (as with the old Mozilla object-as-param-to-eval bug). You 
> can't get the value of "foo" in this example except with the consent of the 
> returned function:
> 
> var maybeVendFoo = function() {
>   var foo = 1;
>   return function(willMaybeCall) {
> if (/* some test */) { willMaybeCall(foo); }
>   }
> };
> 
> Leakage via other methods can be locked down by the first code to run in an 
> environment (caja does this, and nothing prevents it from doing this for SD 
> as it can pre-process/filter scripts that might try to access internals).

Caja is effective for protecting a page from code it embeds, since the page can 
have a guarantee that its code is the first to run. But it cannot be used to 
protect embedded code from a page, so for example a JS library cannot guarantee 
that objects it holds only in closure variables will not leak to the 
surrounding page. This is exactly analogous to shadow DOM leakage via DOM 
methods.

> 
> Getting to closure-strength encapsulation means neutering all potential 
> DOM/CSS access. Maybe I'm dense, but that seems stronger than the "simple 
> form of Type 2".

That seems like a false conclusion to me given the above.

> 
> If you're making the case that it might be helpful to folks trying to 
> implement Type 4 if the platform gave them a way to neuter access without so 
> much pre-processing/runtime-filtering, I could take that as an analog with 
> marking things non-configurable in ES. But it seems you think there's an 
> interim point that developers will use directly. I don't understand that and 
> would like to.

I don't believe Type 4 can be implemented on top of Type 1 with a 
pre-processing/runtime-filtering strategy. It would require additions to the 
platform. Filtering cannot create a two-way distrust boundary, only 

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Tab Atkins Jr.]

On Thu, Feb 13, 2014 at 4:07 PM, Charles McCathie Nevile
 wrote:
> On Thu, 13 Feb 2014 19:09:33 +0100, Tab Atkins Jr. 
> wrote:
>> On Thu, Feb 13, 2014 at 2:35 AM, Anne van Kesteren 
>>> On Thu, Feb 13, 2014 at 12:04 AM, Alex Russell 
 Until we can agree on this, Type 2 feels like an attractive nuisance
 and, onreflection, one that I think we should punt to compilers like

 caja in the interim. If toolkits need it, I'd like to understand those
 use-cases from experience.
>>>
>>> I think Maciej explains fairly well in
>>> http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1364.html
>>> why it's good to have. Also, Type 2 can be used for built-in elements,
>>> which I thought was one of the things we are trying to solve here.
>>
>> Stay after class and write 100 times on the board: "Type 2 is not a
>> security boundary".
>
> This is not appropriate on this email list.

Sorry, it was meant to be a playful response to Anne, and as I know
him personally and consider him a friend, I assumed he'd take it in
kind.  (Based on his reaction in IRC, I think he did.)

~TJ

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Charles McCathie Nevile]

Tab,

On Thu, 13 Feb 2014 19:09:33 +0100, Tab Atkins Jr.   
wrote:



On Thu, Feb 13, 2014 at 2:35 AM, Anne van Kesteren 

On Thu, Feb 13, 2014 at 12:04 AM, Alex Russell 
Until we can agree on this, Type 2 feels like an attractive nuisance  
and, onreflection, one that I think we should punt to compilers like

caja in the interim. If toolkits need it, I'd like to understand those
use-cases from experience.


I think Maciej explains fairly well in
http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1364.html
why it's good to have. Also, Type 2 can be used for built-in elements,
which I thought was one of the things we are trying to solve here.


Stay after class and write 100 times on the board: "Type 2 is not a
security boundary".


This is not appropriate on this email list.

cheers

Chaals

--
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
  cha...@yandex-team.ru Find more at http://yandex.com

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Alex Russell]

On Thu, Feb 13, 2014 at 1:25 PM, Maciej Stachowiak  wrote:

>
> On Feb 12, 2014, at 4:04 PM, Alex Russell  wrote:
>
>
>
> In discussion with Elliot and Erik, there appears to be an additional
> complication: any of the DOM manipulation methods that aren't locked down
> (marked non-configurable and filtered, ala caja) create avenues to get
> elements from the Shadow DOM and then inject styles. E.g., even with Arv's
> lockdown sketch:
>
>   https://gist.github.com/arv/8857167
>
> You still have most of your work ahead of you. DocumentFragment provides
> tons of "ins", as will all incidentally composed APIs.
>
>
> I'm not totally clear on what you're saying. I believe you're pointing out
> that injecting hooks into the scripting environment a component runs in
> (such as by replacing methods on global protototypes) can allow the shadow
> root to be accessed even if no explicit access is given. I agree. This is
> not addressed with simple forms of Type 2 encapsutation. It is a non-goal
> for Type 2.
>

I'd like to understand what differentiates "simple forms of Type 2
encapsulation" from other potential forms that still meet the Type 2
criteria. Can you walk me through an example and show how they would be
used in a framework?


>  This is fraught.
>
>
> Calling something fraught is not an argument.
>

Good news! I provided an argument in the following sentence to help
contextualize my conclusion and, I had hoped, lead you to understand why
I'd said that.


> To get real ocap-style denial of access to the shadow DOM, we likely need
> to intercept and check all DOM accesses. Is the system still usable at this
> point? It's difficult to know. In either case, a system like caja *can*
> exist without explicit supportwhich raises the question: what's the
> goal? Is "Type 2" defined by real denial of access? Or is the request for a
> fig-leaf (perception of security)?
>
>
> Type 2 is not meant to be a security mechanism.
>

I'd like to see an example of Type 2 isolation before I agree to that.


> It is meant to be an encapsulation mechanism. Let me give a comparison.
> Many JavaScript programmers choose to use closures as a way to store
> private data for objects. That is an encapsulation mechanism. It is not, in
> itself, a hard security mechanism. If the caller can hook your global
> environment, and for example modify commonly used Object methods, then they
> may force a leak of your data.
>

A closure is an iron-clad isolation mechanism for object ownership with
regards to the closing-over function object. There's absolutely no
iteration of the closed-over state of a function object; any such
enumeration would be a security hole (as with the old Mozilla
object-as-param-to-eval bug). You can't get the value of "foo" in this
example except with the consent of the returned function:

var maybeVendFoo = function() {
  var foo = 1;
  return function(willMaybeCall) {
if (/* some test */) { willMaybeCall(foo); }
  }
};

Leakage via other methods can be locked down by the first code to run in an
environment (caja does this, and nothing prevents it from doing this for SD
as it can pre-process/filter scripts that might try to access internals).

Getting to closure-strength encapsulation means neutering all potential
DOM/CSS access. Maybe I'm dense, but that seems stronger than the "simple
form of Type 2".

If you're making the case that it might be helpful to folks trying to
implement Type 4 if the platform gave them a way to neuter access without
so much pre-processing/runtime-filtering, I could take that as an analog
with marking things non-configurable in ES. But it seems you think there's
an interim point that developers will use directly. I don't understand that
and would like to.

But that does not mean using closers for data hiding is a "fig-leaf" or
> "attractive nuisance".
>

Agreed, but only because they're stronger than you imply by analogy. What
I'm arguing is that if closures are the right analogy for some variant of
Shadow DOM then they'd need to get MUCH stronger  (Type 4) to meet that
charge.


> It's simply taking access to internals out of the toolset of common and
> convenient things, thereby reducing the chance of a caller inadvertently
> coming to depend on implementation details. ES6 private symbols serve a
> similar role.
>

Sadly, private symbols don't look likely to make an appearance in ES6.


> The proposal is merely to provide the same level of protection for the
> shadow DOM.
>
>
> This is the struggle I have with Type 2. I can get my mind around Type 4
> and want it very badly. So badly, in fact, that I bore most people I talk
> to with the idea of creating primitives that explain x-origin iframes (some
> sort of "renderer worker", how are the graphics contexts allocated and
> protected? what does it mean to navigate? what sorts of constraints can we
> put on data-propagation approaches for flowed layouts that can keep us out
> of security hell?).
>
>
> (1) The form of Type 1 encapsu

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Bjoern Hoehrmann]

* Maciej Stachowiak wrote:
>Type 2 is not meant to be a security mechanism. It is meant to be an 
>encapsulation mechanism. Let me give a comparison. Many JavaScript 
>programmers choose to use closures as a way to store private data for 
>objects. That is an encapsulation mechanism. It is not, in itself, a 
>hard security mechanism. If the caller can hook your global environment, 
>and for example modify commonly used Object methods, then they may force 
>a leak of your data. But that does not mean using closers for data 
>hiding is a "fig-leaf" or "attractive nuisance". It's simply taking 
>access to internals out of the toolset of common and convenient things, 
>thereby reducing the chance of a caller inadvertently coming to depend 
>on implementation details.

An analogy for the above would be a programming environment where your
access to a private data member via `example.private_member` is denied
but you can still use the runtime environment's reflection API to get
to it. In a sense, marking a data member private then is just hard-to-
miss documentation of the API contract. I think that is sensible, but
it is also quite far away from your description of "Type 2"

  Encapsulation against deliberate access - no API is provided which
  lets code outside the component poke at the shadow DOM. Only internals
that the component chooses to expose are exposed."

since the reflection API is being provided in my analogous example, and
it leaves out mention of "common" and "convenient" which are central to
your description above. I can easily agree that "use classes maybe?" is
an insufficient answer to requests for this kinder, gentler version of
"Type 2".
-- 
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Maciej Stachowiak]

On Feb 12, 2014, at 4:04 PM, Alex Russell  wrote:

> 
> 
> In discussion with Elliot and Erik, there appears to be an additional 
> complication: any of the DOM manipulation methods that aren't locked down 
> (marked non-configurable and filtered, ala caja) create avenues to get 
> elements from the Shadow DOM and then inject styles. E.g., even with Arv's 
> lockdown sketch: 
> 
>   https://gist.github.com/arv/8857167
> 
> You still have most of your work ahead of you. DocumentFragment provides tons 
> of "ins", as will all incidentally composed APIs.

I'm not totally clear on what you're saying. I believe you're pointing out that 
injecting hooks into the scripting environment a component runs in (such as by 
replacing methods on global protototypes) can allow the shadow root to be 
accessed even if no explicit access is given. I agree. This is not addressed 
with simple forms of Type 2 encapsutation. It is a non-goal for Type 2.

> 
> This is fraught.

Calling something fraught is not an argument.

> To get real ocap-style denial of access to the shadow DOM, we likely need to 
> intercept and check all DOM accesses. Is the system still usable at this 
> point? It's difficult to know. In either case, a system like caja *can* exist 
> without explicit supportwhich raises the question: what's the goal? Is 
> "Type 2" defined by real denial of access? Or is the request for a fig-leaf 
> (perception of security)?

Type 2 is not meant to be a security mechanism. It is meant to be an 
encapsulation mechanism. Let me give a comparison. Many JavaScript programmers 
choose to use closures as a way to store private data for objects. That is an 
encapsulation mechanism. It is not, in itself, a hard security mechanism. If 
the caller can hook your global environment, and for example modify commonly 
used Object methods, then they may force a leak of your data. But that does not 
mean using closers for data hiding is a "fig-leaf" or "attractive nuisance". 
It's simply taking access to internals out of the toolset of common and 
convenient things, thereby reducing the chance of a caller inadvertently coming 
to depend on implementation details. ES6 private symbols serve a similar role. 
The proposal is merely to provide the same level of protection for the shadow 
DOM.

> 
> This is the struggle I have with Type 2. I can get my mind around Type 4 and 
> want it very badly. So badly, in fact, that I bore most people I talk to with 
> the idea of creating primitives that explain x-origin iframes (some sort of 
> "renderer worker", how are the graphics contexts allocated and protected? 
> what does it mean to navigate? what sorts of constraints can we put on 
> data-propagation approaches for flowed layouts that can keep us out of 
> security hell?).

(1) The form of Type 1 encapsulation offered by current Shadow DOM specs cannot 
explain *any* built-in element that has a compound structure. Because built-in 
elements do not expose their Shadow DOM. It would be nearly impossible to do 
that and code them safely. If you want explanatory power for built-ins, Type 1 
is not sufficient.

(2) Enabling iframes to be implemented as a custom element would be hard, and 
goes beyond the bare minimum of Type 4 requirements. That said, as far as I can 
tell there is no need whatsoever to expose the details of how graphics contexts 
are allocated to enable this. Why would you think that? As I understand it, 
iframes are primarily about providing a security boundary with some tiny 
narrowly scoped holes, not about management of graphics resources. You would 
not use canvas-level primitives to implement iframes. 

> What I don't understand is what daylight there can be, in practice, between 
> Type 2 and Type 4-by-other-means. Either we lean on convention (using class 
> names for styling) and see how it goes, potentially extracting something like 
> the previously-proposed "::part()" system, or we go down the caja-style 
> rabbit hole and try to lock down _all_ the things, and not just from 
> incidental access.
> 
> Where would you have us draw this line?

I would draw the line between simple, obvious explicit mechanisms whose 
intended common use amounts to free-form access to the Shadow DOM, and 
mechanisms that indirectly allow this access by injecting traps into the global 
environment. Providing a clean global environment is not a goal for Type 2. Nor 
is a secure membrane for method calls.

> 
> Until we can agree on this, Type 2 feels like an attractive nuisance

I think you are only calling it an "attractive nuisance" because you did not 
understand what it is meant to provide, and instead believe it is a broken 
version of a different feature. It is not. I have tried to explain. I hope my 
explanation was informative.

> and, on reflection, one that I think we should punt to compilers like caja in 
> the interim. If toolkits need it, I'd like to understand those use-cases from 
> experience.

Caja cannot solve the Type 2

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Bjoern Hoehrmann]

* Anne van Kesteren wrote:
>On Thu, Feb 13, 2014 at 12:04 AM, Alex Russell  wrote:
>> Until we can agree on this, Type 2 feels like an attractive nuisance and, on
>> reflection, one that I think we should punt to compilers like caja in the
>> interim. If toolkits need it, I'd like to understand those use-cases from
>> experience.
>
>I think Maciej explains fairly well in
>http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1364.html
>why it's good to have. Also, Type 2 can be used for built-in elements,
>which I thought was one of the things we are trying to solve here.

The desire to retrofit built-ins into cross-browser component technology
has not been very helpful to deliver component technology into the hands
of authors.

I also note that "Encapsulation against deliberate access" would make it
quite difficult to automate components for testing and other purposes;
in many cases you would be unable to make a reduced test case that shows
some defect in a third party component that others can load in their web
browser without difficulty; and automation tools would need a privileged
API to break the encapsulation.
-- 
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Alex Russell]

On Thu, Feb 13, 2014 at 2:35 AM, Anne van Kesteren  wrote:

> On Thu, Feb 13, 2014 at 12:04 AM, Alex Russell 
> wrote:
> > Until we can agree on this, Type 2 feels like an attractive nuisance
> and, on
> > reflection, one that I think we should punt to compilers like caja in the
> > interim. If toolkits need it, I'd like to understand those use-cases from
> > experience.
>
> I think Maciej explains fairly well in
> http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1364.html
> why it's good to have. Also, Type 2 can be used for built-in elements,
> which I thought was one of the things we are trying to solve here.


I encourage you to go through the exercise that arv has.

What does it mean, in practice, to *really* defend against "deliberate
access" (Maciej's Type 2). If you were to try to implement a built-in using
what, in your mind, is Type 2, would it work? Would you really be able to
hang privileged user access off that implementation?

Any time I consider the question, it leads me to want to lock down all
routes to access outside some (unspecified, and I fear unspecifiable until
we get *much* stronger primitives) relationship between a script execution
context and some subset of the DOM. This is painful because DOM makes
transport across "worlds" so trivial. Iframes, built-in-controls and caja
have all done this, but they do it by going for Type 4.

There is no spoon. Type 2 is a mirage.

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Tab Atkins Jr.]

On Thu, Feb 13, 2014 at 2:35 AM, Anne van Kesteren  wrote:
> On Thu, Feb 13, 2014 at 12:04 AM, Alex Russell  wrote:
>> Until we can agree on this, Type 2 feels like an attractive nuisance and, on
>> reflection, one that I think we should punt to compilers like caja in the
>> interim. If toolkits need it, I'd like to understand those use-cases from
>> experience.
>
> I think Maciej explains fairly well in
> http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1364.html
> why it's good to have. Also, Type 2 can be used for built-in elements,
> which I thought was one of the things we are trying to solve here.

Stay after class and write 100 times on the board: "Type 2 is not a
security boundary".

~TJ

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Boris Zbarsky]

On 2/13/14 5:35 AM, Anne van Kesteren wrote:

Also, Type 2 can be used for built-in elements


Built-in elements need Type 4.

-Boris

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Anne van Kesteren]

On Thu, Feb 13, 2014 at 12:04 AM, Alex Russell  wrote:
> Until we can agree on this, Type 2 feels like an attractive nuisance and, on
> reflection, one that I think we should punt to compilers like caja in the
> interim. If toolkits need it, I'd like to understand those use-cases from
> experience.

I think Maciej explains fairly well in
http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1364.html
why it's good to have. Also, Type 2 can be used for built-in elements,
which I thought was one of the things we are trying to solve here.


-- 
http://annevankesteren.nl/

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Alex Russell]

On Tue, Feb 11, 2014 at 5:16 PM, Maciej Stachowiak  wrote:

>
> On Feb 11, 2014, at 4:04 PM, Dimitri Glazkov 
> wrote:
>
> On Tue, Feb 11, 2014 at 3:50 PM, Maciej Stachowiak  wrote:
>
>>
>> On Feb 11, 2014, at 3:29 PM, Dimitri Glazkov 
>> wrote:
>>
>>
>>
>>> Dimitri, Maciej, Ryosuke - is there a mutually agreeable solution here?
>>>
>>
>> I am exactly sure what problem this thread hopes to raise and whether
>> there is a need for anything other than what is already planned.
>>
>>
>> In the email Ryosuke cited, Tab said something that sounded like a claim
>> that the WG had decided to do public mode only:
>>
>> 
>> Quoting Tab:
>>
>> The decision to do the JS side of Shadow DOM this way was made over a
>> year ago.  Here's the relevant thread for the decision:
>> <
>> http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/thread.html#msg312
>> >
>> (it's rather long) and a bug tracking it
>> .
>>
>>
>> I can't speak for Ryosuke but when I saw this claim, I was honestly
>> unsure whether there had been a formal WG decision on the matter that I'd
>> missed. I appreciate your clarification that you do not see it that way.
>>
>>
>> Quoting Dmitri again:
>>
>> The plan is, per thread I mentioned above, is to add a flag to
>> createShadowRoot that hides it from DOM traversal APIs and relevant CSS
>> selectors: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144.
>>
>>
>> That would be great. Can you please prioritize resolving this bug[1]? It
>> has been waiting for a year, and at the time the private/public change was
>> made, it sounded like this would be part of the package.
>>
>
> Can you help me understand why you feel this needs to be prioritized? I
> mean, I don't mind, but it would be great if I had an idea on what's the
> driving force behind the urgency?
>
>
> (1) It blocks the two dependent issues I mentioned.
> (2) As a commenter on a W3C spec and member of the relevant WG, I think I
> am entitled to a reasonably prompt level of response from a spec editor.
> This bug has been open since November 2012. I think I have waited long
> enough, and it is fair to ask for some priority now. If it continues to go
> on, then an outside observer might get the impression that failing to
> address this bug is deliberate stalling. Personally, I prefer to assume
> good faith, and I think you have just been super busy. But it would show
> good faith in return to address the bug soon.
>
> Note: as far as I know there is no technical issue or required feedback
> blocking bug 20144. However, if there is any technical input you need, or
> if you would find it helpful to have a spec diff provided to use as you see
> fit, I would be happy to provide such. Please let me know!
>
>
> It seems like there are a few controversies that are gated on having the
>> other mode defined:
>> - Which of the two modes should be the default (if any)?
>>
>
> This is re-opening the old year-old discussion, settled in
> http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/thread.html#msg800,
> right?
>
>
> I'm not sure what you mean by "settled". You had a private meeting and the
> people there agreed on what the default should be. That is fine. Even using
> that to make a provisional editing decision seems fine. However, I do not
> believe that makes it "settled" for purposes of the WG as a whole. In
> particular, I have chosen not to further debate which mode should be the
> default until both modes exist, something that I've been waiting on for a
> while. I don't think that means I lose my right to comment and to have my
> feedback addressed.
>
> In fact, my understanding of the process is this: the WG is required to
> address any and all feedback that comes in at any point in the process. And
> an issue is not even settled to the point of requiring explicit reopening
> unless there is a formal WG decision (as opposed to just an editor's
> decision based on their own read of input from the WG.)
>
>
>
>
>> - Should shadow DOM styling primitives be designed so that they can work
>> for private/closed components too?
>>
>
> Sure. The beauty of a hidden/closed mode is that it's a special case of
> the open mode, so we can simply say that if a shadow root is "closed", the
> selectors don't match anything in that tree. I left the comment to that
> effect on the bug.
>
>
> Right, but that leaves you with no styling mechanism that offers more
> fine-grained control, suitable for use with closed mode. Advocates of the
> current styling approach have said we need not consider closed mode at all,
> because the Web Apps WG has decided on open mode. If what we actually
> decided is to have both (and that is my understanding of the consensus),
> then I'd like the specs to reflect that, so the discussion in www-style can
> be based on facts.
>
> As a more basic point, mention of closed mode to exclude it from /shadow
> m

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Maciej Stachowiak]

On Feb 11, 2014, at 4:04 PM, Dimitri Glazkov  wrote:

> On Tue, Feb 11, 2014 at 3:50 PM, Maciej Stachowiak  wrote:
> 
> On Feb 11, 2014, at 3:29 PM, Dimitri Glazkov  wrote:
> 
>>  
>> Dimitri, Maciej, Ryosuke - is there a mutually agreeable solution here?
>> 
>> I am exactly sure what problem this thread hopes to raise and whether there 
>> is a need for anything other than what is already planned.
> 
> In the email Ryosuke cited, Tab said something that sounded like a claim that 
> the WG had decided to do public mode only:
> 
> 
> Quoting Tab:
>> The decision to do the JS side of Shadow DOM this way was made over a
>> year ago.  Here's the relevant thread for the decision:
>> 
>> (it's rather long) and a bug tracking it
>> .
> 
> I can't speak for Ryosuke but when I saw this claim, I was honestly unsure 
> whether there had been a formal WG decision on the matter that I'd missed. I 
> appreciate your clarification that you do not see it that way.
> 
> 
> Quoting Dmitri again:
>> The plan is, per thread I mentioned above, is to add a flag to 
>> createShadowRoot that hides it from DOM traversal APIs and relevant CSS 
>> selectors: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144.
> 
> That would be great. Can you please prioritize resolving this bug[1]? It has 
> been waiting for a year, and at the time the private/public change was made, 
> it sounded like this would be part of the package.
> 
> Can you help me understand why you feel this needs to be prioritized? I mean, 
> I don't mind, but it would be great if I had an idea on what's the driving 
> force behind the urgency?

(1) It blocks the two dependent issues I mentioned.
(2) As a commenter on a W3C spec and member of the relevant WG, I think I am 
entitled to a reasonably prompt level of response from a spec editor. This bug 
has been open since November 2012. I think I have waited long enough, and it is 
fair to ask for some priority now. If it continues to go on, then an outside 
observer might get the impression that failing to address this bug is 
deliberate stalling. Personally, I prefer to assume good faith, and I think you 
have just been super busy. But it would show good faith in return to address 
the bug soon.

Note: as far as I know there is no technical issue or required feedback 
blocking bug 20144. However, if there is any technical input you need, or if 
you would find it helpful to have a spec diff provided to use as you see fit, I 
would be happy to provide such. Please let me know!

> 
> It seems like there are a few controversies that are gated on having the 
> other mode defined:
> - Which of the two modes should be the default (if any)?
> 
> This is re-opening the old year-old discussion, settled in 
> http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/thread.html#msg800,
>  right? 

I'm not sure what you mean by "settled". You had a private meeting and the 
people there agreed on what the default should be. That is fine. Even using 
that to make a provisional editing decision seems fine. However, I do not 
believe that makes it "settled" for purposes of the WG as a whole. In 
particular, I have chosen not to further debate which mode should be the 
default until both modes exist, something that I've been waiting on for a 
while. I don't think that means I lose my right to comment and to have my 
feedback addressed. 

In fact, my understanding of the process is this: the WG is required to address 
any and all feedback that comes in at any point in the process. And an issue is 
not even settled to the point of requiring explicit reopening unless there is a 
formal WG decision (as opposed to just an editor's decision based on their own 
read of input from the WG.)


>  
> - Should shadow DOM styling primitives be designed so that they can work for 
> private/closed components too?
> 
> Sure. The beauty of a hidden/closed mode is that it's a special case of the 
> open mode, so we can simply say that if a shadow root is "closed", the 
> selectors don't match anything in that tree. I left the comment to that 
> effect on the bug.

Right, but that leaves you with no styling mechanism that offers more 
fine-grained control, suitable for use with closed mode. Advocates of the 
current styling approach have said we need not consider closed mode at all, 
because the Web Apps WG has decided on open mode. If what we actually decided 
is to have both (and that is my understanding of the consensus), then I'd like 
the specs to reflect that, so the discussion in www-style can be based on facts.

As a more basic point, mention of closed mode to exclude it from /shadow most 
likely has to exist in the shadow styling spec, not just the Shadow DOM spec. 
So there is a cross-spec dependency even if no new constructs are added.


T

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Ryosuke Niwa]

On Feb 11, 2014, at 3:36 PM, Dimitri Glazkov  wrote:
> Durrr. Forgot a NOT.
> 
> On Tue, Feb 11, 2014 at 3:29 PM, Dimitri Glazkov  
> wrote:
> 
> I am NOT exactly sure what problem this thread hopes to raise and whether 
> there is a need for anything other than what is already planned.

I was not hoping to raise any problem.

As Maciej mentioned earlier, we wanted to get a clarification on whether we’ve 
missed the part where the working group made a decision to focus on Type I 
encapsulation for the level 1 specifications per Tab’s email on www-style, 
which sounded like the WebApps WG has decided that.

- R. Niwa

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Dimitri Glazkov]

On Tue, Feb 11, 2014 at 3:50 PM, Maciej Stachowiak  wrote:

>
> On Feb 11, 2014, at 3:29 PM, Dimitri Glazkov 
> wrote:
>
>
>
>> Dimitri, Maciej, Ryosuke - is there a mutually agreeable solution here?
>>
>
> I am exactly sure what problem this thread hopes to raise and whether
> there is a need for anything other than what is already planned.
>
>
> In the email Ryosuke cited, Tab said something that sounded like a claim
> that the WG had decided to do public mode only:
>
> 
> Quoting Tab:
>
> The decision to do the JS side of Shadow DOM this way was made over a
> year ago.  Here's the relevant thread for the decision:
> <
> http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/thread.html#msg312
> >
> (it's rather long) and a bug tracking it
> .
>
>
> I can't speak for Ryosuke but when I saw this claim, I was honestly unsure
> whether there had been a formal WG decision on the matter that I'd missed.
> I appreciate your clarification that you do not see it that way.
>
>
> Quoting Dmitri again:
>
> The plan is, per thread I mentioned above, is to add a flag to
> createShadowRoot that hides it from DOM traversal APIs and relevant CSS
> selectors: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144.
>
>
> That would be great. Can you please prioritize resolving this bug[1]? It
> has been waiting for a year, and at the time the private/public change was
> made, it sounded like this would be part of the package.
>

Can you help me understand why you feel this needs to be prioritized? I
mean, I don't mind, but it would be great if I had an idea on what's the
driving force behind the urgency?


>
> It seems like there are a few controversies that are gated on having the
> other mode defined:
> - Which of the two modes should be the default (if any)?
>

This is re-opening the old year-old discussion, settled in
http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/thread.html#msg800,
right?


> - Should shadow DOM styling primitives be designed so that they can work
> for private/closed components too?
>

Sure. The beauty of a hidden/closed mode is that it's a special case of the
open mode, so we can simply say that if a shadow root is "closed", the
selectors don't match anything in that tree. I left the comment to that
effect on the bug.

:DG<

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Maciej Stachowiak]

On Feb 11, 2014, at 3:29 PM, Dimitri Glazkov  wrote:

>  
> Dimitri, Maciej, Ryosuke - is there a mutually agreeable solution here?
> 
> I am exactly sure what problem this thread hopes to raise and whether there 
> is a need for anything other than what is already planned.

In the email Ryosuke cited, Tab said something that sounded like a claim that 
the WG had decided to do public mode only:


Quoting Tab:
> The decision to do the JS side of Shadow DOM this way was made over a
> year ago.  Here's the relevant thread for the decision:
> 
> (it's rather long) and a bug tracking it
> .

I can't speak for Ryosuke but when I saw this claim, I was honestly unsure 
whether there had been a formal WG decision on the matter that I'd missed. I 
appreciate your clarification that you do not see it that way.


Quoting Dmitri again:
> The plan is, per thread I mentioned above, is to add a flag to 
> createShadowRoot that hides it from DOM traversal APIs and relevant CSS 
> selectors: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144.

That would be great. Can you please prioritize resolving this bug[1]? It has 
been waiting for a year, and at the time the private/public change was made, it 
sounded like this would be part of the package.

It seems like there are a few controversies that are gated on having the other 
mode defined:
- Which of the two modes should be the default (if any)?
- Should shadow DOM styling primitives be designed so that they can work for 
private/closed components too?

Regards,
Maciej

[1] Incidentally, if you find the word "private" problematic, we could call the 
two modes "open" and "closed", then someday the third mode can be "secure" or 
"sandboxed"

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Dimitri Glazkov]

Durrr. Forgot a NOT.

On Tue, Feb 11, 2014 at 3:29 PM, Dimitri Glazkov wrote:

I am NOT exactly sure what problem this thread hopes to raise and whether
> there is a need for anything other than what is already planned.
>

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Dimitri Glazkov]

On Mon, Feb 10, 2014 at 11:08 AM, Arthur Barstow wrote:

> On 2/6/14 9:06 PM, ext Ryosuke Niwa wrote:
>
>> Could chairs of the working group please clarify whether we have had a
>> reach of consensus on the default encapsulation level in shadow DOM?
>>
>
> As described in [WorkMode], WebApps' asynchronous participation and edit
> first "work modes" means group members must actively participate on the
> list and actively file bugs and participate in bug reports. We also expect
> both Editors and group participants to work toward obtaining broad
> consensus as described in the charter [Decisions].
>
>
>
>  More concretely, have we _decided_ that we only want Type 1 encapsulation
>> for the level 1 specifications of Web components instead of Type 2 or Type
>> 1 and Type 2 encapsulations as defined in Maciej's email sent out in June
>> 29th, 2011:
>> http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1364.html
>>
>> I don't recall any consensus being reached about this matter.
>>
>> In fact, http://lists.w3.org/Archives/Public/public-webapps/
>> 2012OctDec/thread.html#msg312
>> (referred by http://lists.w3.org/Archives/Public/www-style/2014Feb/0221.
>> html)
>> clearly shows the lack of consensus in my eyes as both Boris Zbarsky from
>> Mozilla and Maciej Stachowiak from Apple have voiced to prefer Type 2
>> encapsulation:
>>
>> http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0406.html
>> http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0421.html
>> http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0628.html
>>
>> while representatives of Google preferring Type 1 encapsulations.
>>
>
> I agree the threads started by Maciej at [1364.html] and Dimitri at
> [0312.html] do not appear to have reached broad consensus. (I am not
> subscribed to www-style so I haven't followed those discussions.)
>

FWIW, the story is not complete without
http://lists.w3.org/Archives/Public/public-webapps/2013JanMar/thread.html#msg800,
which indicates a higher degree of consensus. Right?



> Dimitri, Maciej, Ryosuke - is there a mutually agreeable solution here?
>

I am exactly sure what problem this thread hopes to raise and whether there
is a need for anything other than what is already planned.

The plan is, per thread I mentioned above, is to add a flag to
createShadowRoot that hides it from DOM traversal APIs and relevant CSS
selectors: https://www.w3.org/Bugs/Public/show_bug.cgi?id=20144.

:DG<

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Ryosuke Niwa]

Thanks for the clarifications, Arthur!

On Feb 10, 2014, at 11:08 AM, Arthur Barstow  wrote:

> On 2/6/14 9:06 PM, ext Ryosuke Niwa wrote:
>> Could chairs of the working group please clarify whether we have had a reach 
>> of consensus on the default encapsulation level in shadow DOM?
> 
> As described in [WorkMode], WebApps' asynchronous participation and edit 
> first "work modes" means group members must actively participate on the list 
> and actively file bugs and participate in bug reports. We also expect both 
> Editors and group participants to work toward obtaining broad consensus as 
> described in the charter [Decisions].

Thanks for remaining me, and in fact, we’re aware of this.   We were simply 
surprised that other participants of the working group thought there was a 
consensus on this matter because it wasn’t our understanding of the situation 
but we didn’t want to jump to any conclusion.

>> More concretely, have we _decided_ that we only want Type 1 encapsulation 
>> for the level 1 specifications of Web components instead of Type 2 or Type 1 
>> and Type 2 encapsulations as defined in Maciej's email sent out in June 
>> 29th, 2011:
>> http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1364.html
>> 
>> I don't recall any consensus being reached about this matter.
>> 
>> In fact, 
>> http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/thread.html#msg312
>> (referred by http://lists.w3.org/Archives/Public/www-style/2014Feb/0221.html)
>> clearly shows the lack of consensus in my eyes as both Boris Zbarsky from 
>> Mozilla and Maciej Stachowiak from Apple have voiced to prefer Type 2 
>> encapsulation:
>> 
>> http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0406.html
>> http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0421.html
>> http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0628.html
>> 
>> while representatives of Google preferring Type 1 encapsulations.
> 
> I agree the threads started by Maciej at [1364.html] and Dimitri at 
> [0312.html] do not appear to have reached broad consensus. (I am not 
> subscribed to www-style so I haven't followed those discussions.)

Great.  That is my understanding as well.

> Dimitri, Maciej, Ryosuke - is there a mutually agreeable solution here?

I think the contention here is about which types of encapsulations need to be 
supported in the level 1 specifications.  It would be great to sort it out 
somehow because it’s hard to discuss specifics unless we’ve agreed upon the use 
cases and requirements for them first.

- R. Niwa

Re: [webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Arthur Barstow]

On 2/6/14 9:06 PM, ext Ryosuke Niwa wrote:

Could chairs of the working group please clarify whether we have had a reach of 
consensus on the default encapsulation level in shadow DOM?


As described in [WorkMode], WebApps' asynchronous participation and edit 
first "work modes" means group members must actively participate on the 
list and actively file bugs and participate in bug reports. We also 
expect both Editors and group participants to work toward obtaining 
broad consensus as described in the charter [Decisions].




More concretely, have we _decided_ that we only want Type 1 encapsulation for 
the level 1 specifications of Web components instead of Type 2 or Type 1 and 
Type 2 encapsulations as defined in Maciej's email sent out in June 29th, 2011:
http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1364.html

I don't recall any consensus being reached about this matter.

In fact, 
http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/thread.html#msg312
(referred by http://lists.w3.org/Archives/Public/www-style/2014Feb/0221.html)
clearly shows the lack of consensus in my eyes as both Boris Zbarsky from 
Mozilla and Maciej Stachowiak from Apple have voiced to prefer Type 2 
encapsulation:

http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0406.html
http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0421.html
http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0628.html

while representatives of Google preferring Type 1 encapsulations.


I agree the threads started by Maciej at [1364.html] and Dimitri at 
[0312.html] do not appear to have reached broad consensus. (I am not 
subscribed to www-style so I haven't followed those discussions.)


Dimitri, Maciej, Ryosuke - is there a mutually agreeable solution here?

-Thanks, ArtB

[WorkMode] 
[Decisions] 
[1364.html] 

[0312.html] 

[webcomponents] Encapsulation and defaulting to open vs closed (was in www-style)

[Ryosuke Niwa]

Hi,

Could chairs of the working group please clarify whether we have had a reach of 
consensus on the default encapsulation level in shadow DOM?

More concretely, have we _decided_ that we only want Type 1 encapsulation for 
the level 1 specifications of Web components instead of Type 2 or Type 1 and 
Type 2 encapsulations as defined in Maciej's email sent out in June 29th, 2011:
http://lists.w3.org/Archives/Public/public-webapps/2011AprJun/1364.html

I don't recall any consensus being reached about this matter.

In fact, 
http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/thread.html#msg312
(referred by http://lists.w3.org/Archives/Public/www-style/2014Feb/0221.html)
clearly shows the lack of consensus in my eyes as both Boris Zbarsky from 
Mozilla and Maciej Stachowiak from Apple have voiced to prefer Type 2 
encapsulation:

http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0406.html
http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0421.html
http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0628.html

while representatives of Google preferring Type 1 encapsulations.

- R. Niwa