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

On Tue, Feb 11, 2014 at 5:16 PM, Maciej Stachowiak <mjs@apple.com> wrote:

>
> On Feb 11, 2014, at 4:04 PM, Dimitri Glazkov <dglazkov@chromium.org>
> wrote:
>
> On Tue, Feb 11, 2014 at 3:50 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>
>>
>> On Feb 11, 2014, at 3:29 PM, Dimitri Glazkov <dglazkov@chromium.org>
>> 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:
>>
>> <http://lists.w3.org/Archives/Public/www-style/2014Feb/0221.html>
>> 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
>> <https://www.w3.org/Bugs/Public/show_bug.cgi?id=19562>.
>>
>>
>> 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.
>

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.

This is fraught. 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 support....which 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)?

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?). 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?

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.

Regards