W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2014

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

From: Maciej Stachowiak <mjs@apple.com>
Date: Tue, 11 Feb 2014 17:16:42 -0800
Cc: Arthur Barstow <art.barstow@nokia.com>, "public-webapps@w3.org WG" <public-webapps@w3.org>
Message-id: <4D8AACB7-AF67-4188-9520-EEC58215328C@apple.com>
To: Dimitri Glazkov <dglazkov@chromium.org>

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.

Thank you for your consideration,

Received on Wednesday, 12 February 2014 01:17:13 UTC

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