[Bug 24629] New: [Explainer]: attachedCallback / detachedCallback are now enteredView and leftView

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24629

Bug ID: 24629
   Summary: [Explainer]: attachedCallback / detachedCallback are
now enteredView and leftView
   Product: WebAppsWG
   Version: unspecified
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Component Model
  Assignee: dglaz...@chromium.org
  Reporter: mr.a...@gmail.com
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
Blocks: 14949

In the lifecycle explanation it says "attachedCallback, which is called after a
custom element is inserted into a document with a default view;
detachedCallback" but according to the latest custom element spec those have
been renamed into "enteredView" and "leftView", see
http://w3c.github.io/webcomponents/spec/custom/index.html#types-of-callbacks
for details.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: Extending Mutation Observers to address use cases of

[Ryosuke Niwa]

On Feb 11, 2014, at 8:41 PM, Joshua Peek  wrote:
> Are you proposing new mutation record type? I think that could handle
> most of the enter/leave requirements.

Not really.  I’m mostly talking about new timing at which mutation records are 
delivered.

Apparently we need to deliver records more “eagerly” for custom elements. 

> If MutationObservers are an open topic for extension, I'd love to see
> generic css selector support.
> 
>  observer.observe(target, { selector: 'foo' });
>  observer.observe(target, { selector: '.foo' });
> 
> That'd cover element name "enter" and "leaves" as well.

enteredView and exitedView are custom element callbacks and not elements 
themselves.
http://w3c.github.io/webcomponents/spec/custom/#types-of-callbacks

There has been some discussions to extend mutation observers to support better 
filtering.

We can probably support simple selector: 
http://dev.w3.org/csswg/selectors4/#simple

I don’t think we can support any arbitrary selector (e.g. descendent selector) 
for performance reasons since doing so requires tree traversal, and checking 
that condition on every DOM mutation is too expensive.

- R. Niwa

Re: Extending Mutation Observers to address use cases of

[Joshua Peek]

Are you proposing new mutation record type? I think that could handle
most of the enter/leave requirements.

  observer.observe(target, { element: 'x-foo' });

If MutationObservers are an open topic for extension, I'd love to see
generic css selector support.

  observer.observe(target, { selector: 'foo' });
  observer.observe(target, { selector: '.foo' });

That'd cover element name "enter" and "leaves" as well.

On Tue, Feb 11, 2014 at 7:41 PM, Ryosuke Niwa  wrote:
> Hi,
>
> I’m bringing this up out of:
>
> [Custom]: enteredView and leftView callbacks are still confusing
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=24314
>
> Could someone clarify exactly why mutation observers can’t satisfy use cases 
> for custom elements?
>
> I strongly believe that we should extend mutation observers (e.g. add some 
> flag to fire more eagerly) so that we could *explain* these callbacks in 
> terms of mutation observers.
>
> - R. Niwa
>
>

[Bug 24628] New: spec has (almost) no style (or scripts)

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24628

Bug ID: 24628
   Summary: spec has (almost) no style (or scripts)
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
   URL: https://dvcs.w3.org/hg/editing/raw-file/tip/editing.ht
ml
OS: Windows XP
Status: NEW
  Severity: normal
  Priority: P2
 Component: HTML Editing APIs
  Assignee: a...@aryeh.name
  Reporter: naes...@gmail.com
QA Contact: sideshowbarker+html-editing-...@gmail.com
CC: m...@w3.org, public-webapps@w3.org

I'm using "Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Firefox/24.0
ID:20140131092626 CSet: d06a17a96fa2" (actually version 24.3.0), and when I try
to view the spec (from the link on
), I get a very
understyled page.

The problem becomes (reasonably) clear if we look at "Developer Tools: Web
Console":

[21:56:19.480] GET
https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#selections [HTTP/1.1
200 Script output follows 641ms]
[21:56:19.878] Blocked loading mixed active content
"http://www.whatwg.org/style/specification"; @
https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#selections
[21:56:20.381] Blocked loading mixed active content
"http://www.whatwg.org/specs/web-apps/current-work/dfn.js"; @
https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html#selections
[... skipped irrelevant deprecation warning caused by some extension ...]
[21:56:23.642] GET http://www.w3.org/Icons/w3c_home [HTTP/1.1 200 OK 16ms]
[21:56:23.653] The Web Console logging API (console.log, console.info,
console.warn, console.error) has been disabled by a script on this page.

(Actually, this pasted text is clearer than what was on the screen ...)

So, it seems Firefox decided that it's had enough of people trying to use
"http://"; resources from an "https://"; document and finally put its foot down.

Unfortunately, the obvious workaround (delete the "s") does not work because
that redirects back to the https:// address :-(.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug 24627] [Shadow]: Support disconnected nodes

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24627

Hayato Ito  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Hayato Ito  ---
I've updated the spec:

https://github.com/w3c/webcomponents/commit/bc9e62c9e6c13229f6944f4c798f603ad98b7697

Thanks to the concept of trees of trees, updating the spec is not so hard than
I expected.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: Extending Mutation Observers to address use cases of

[Ryosuke Niwa]

On Feb 11, 2014, at 6:27 PM, Ryosuke Niwa  wrote:

> 
>> On Feb 11, 2014, at 6:06 PM, Bjoern Hoehrmann  wrote:
>> 
>> * Olli Pettay wrote:
>>> We could add some scheduling thing to mutation observers. By default 
>>> we'd use microtask, since that tends to be good for various performance 
>>> reasons, but normal tasks or nanotasks could be possible too.
> 
> Right, we need some sort of a switch.  I'm not certain if we want to add it 
> as a per-observation option or a global switch when we create an observer. My 
> guy feeling is that we want the latter.  It would be weird for some mutation 
> records to be delivered earlier than others to the same observer.

s/guy/gut/.  Also by “a global switch”, I mean per-MutationObserver object.  
Not some global switch on window/document.

- R. Niwa

Re: Extending Mutation Observers to address use cases of

[Ryosuke Niwa]

> On Feb 11, 2014, at 6:06 PM, Bjoern Hoehrmann  wrote:
> 
> * Olli Pettay wrote:
>> We could add some scheduling thing to mutation observers. By default 
>> we'd use microtask, since that tends to be good for various performance 
>> reasons, but normal tasks or nanotasks could be possible too.

Right, we need some sort of a switch.  I'm not certain if we want to add it as 
a per-observation option or a global switch when we create an observer. My guy 
feeling is that we want the latter.  It would be weird for some mutation 
records to be delivered earlier than others to the same observer.

I'd like to know exact semantics requirements before start jumping into details 
though.

> This sounds like adding a switch that would dynamically invalidate
> assumptions mutation observers might make, which sounds like a bad idea. 
> Could you elaborate?

I don't really follow what the problem is. Could you elaborate on what you see 
as a problem?

- R. Niwa

Re: Extending Mutation Observers to address use cases of

[Bjoern Hoehrmann]

* Olli Pettay wrote:
>We could add some scheduling thing to mutation observers. By default 
>we'd use microtask, since that tends to be good for various performance 
>reasons, but normal tasks or nanotasks could be possible too.

This sounds like adding a switch that would dynamically invalidate
assumptions mutation observers might make, which sounds like a bad
idea. Could you elaborate?
-- 
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: Extending Mutation Observers to address use cases of

[Olli Pettay]

On 02/12/2014 03:41 AM, Ryosuke Niwa wrote:

Hi,

I’m bringing this up out of:

[Custom]: enteredView and leftView callbacks are still confusing
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24314

Could someone clarify exactly why mutation observers can’t satisfy use cases 
for custom elements?

I strongly believe that we should extend mutation observers (e.g. add some flag 
to fire more eagerly) so that we could *explain* these callbacks in terms of 
mutation observers.

- R. Niwa





Doesn't the web component stuff want to be notified way before mutation 
observer callbacks are called (end of microtask)
This new stuff would be called right before some dom method call returns (I 
think someone mentioned 'nanotask').


We could add some scheduling thing to mutation observers. By default we'd use 
microtask, since that tends to be good
for various performance reasons, but normal tasks or nanotasks could be 
possible too.



-Olli

Extending Mutation Observers to address use cases of

[Ryosuke Niwa]

Hi,

I’m bringing this up out of:

[Custom]: enteredView and leftView callbacks are still confusing
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24314

Could someone clarify exactly why mutation observers can’t satisfy use cases 
for custom elements?

I strongly believe that we should extend mutation observers (e.g. add some flag 
to fire more eagerly) so that we could *explain* these callbacks in terms of 
mutation observers.

- R. Niwa

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

[Bug 24627] New: [Shadow]: Support disconnected nodes

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24627

Bug ID: 24627
   Summary: [Shadow]: Support disconnected nodes
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Component Model
  Assignee: dglaz...@chromium.org
  Reporter: hay...@chromium.org
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
Blocks: 14978

The relevant background is:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24421

-- 
You are receiving this mail because:
You are on the CC list for the bug.

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

[Bug 24421] [Shadow]: Clarify that Shadow DOM spec takes care of nodes which are *inDocument*.

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24421

Hayato Ito  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from Hayato Ito  ---
Let me close this bug and file another bug to support disconnected nodes in the
spec.

The point is that the most of Shadow DOM spec has been written so that it only
supports connected nodes. This motivation of this bug 24421 is make this fact
clear so that there is no ambiguous parts in the current specification.

There has been a lot of ambiguous parts if we should consider connected nodes.
The current spec is not ready to accept disconnected nodes.
Let me work on this non-trivial task as another issue.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: [webcomponents] Async Registration of Custom Elements

[Ryosuke Niwa]

On Feb 11, 2014, at 3:42 PM, Dimitri Glazkov  wrote:
> On Thu, Jan 30, 2014 at 3:03 PM, Ryosuke Niwa  wrote:
> Could someone clarify why we want to allow out-of-order registration of 
> custom elements?  Can we also have (a pointer to) concrete use cases for this 
> feature?
> 
> 
> The thing is if an author wants to replace or customize a placeholder element 
> using a script that loads later, that’s pretty easy to achieve in the script 
> itself:
> 
> // Placeholder elements already exist in the document.
> 
> document.registerElement(…); // This line of code is present no matter what.
> 
> // Four more lines of code finish the job.
> var placeholders = document.querySelectorAll(…);
> for (var placeholder of placeholders)
> placeholder.parentNode.replaceChild(…);
> 
> techcrunch.com does this for all of its  buttons, for example — 
> although they do the replacement on hover, and not on load.
> 
> There’s very little upside to building replacement behavior into the browser 
> engine when it’s so easy to achieve in script — and the script had to run 
> anyway in order to document.registerElement().   In fact, it may be actively 
> harmful in preventing developers from implementing potentially desirable 
> patterns (e.g. Techcrunch’s on demand replacement, which may be advantageous 
> if the components are expensive).
> 
> 
> But... there is no replacement behavior? The spec was carefully design to 
> explicitly avoid that. In itself, the "upgrade" is a process of setting 
> prototype: http://w3c.github.io/webcomponents/spec/custom/#dfn-set-prototype

Sorry, I guess my explanation wasn’t clear here.

The “replacement” behavior we’re talking about here isn’t about element or its 
prototype objects in JS.  We’re talking about elements’  transition from 
“unresolved” state to “resolved” / “instantiated” state.

Since the right behavior (e.g. reserve blank space, not showing them at all, 
etc…) is different for each use case, let’s not bake one into the browser 
engines.  If authors wanted to define customs elements asynchronously, they 
could do so and explicitly replace “unresolved” elements as they wish with a 
few lines of scripts.

- 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] Async Registration of Custom Elements

[Dimitri Glazkov]

On Thu, Feb 6, 2014 at 9:15 PM, Ryosuke Niwa  wrote:

> I'll also note that none of builtin HTML elements have "resolved" state.
>

Sure, because HTML elements are added to the registry before the main
document is loaded.

: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] Async Registration of Custom Elements

[Dimitri Glazkov]

On Thu, Jan 30, 2014 at 3:03 PM, Ryosuke Niwa  wrote:

> Hi,
>
> Could someone clarify why we want to allow out-of-order registration of
> custom elements?  Can we also have (a pointer to) concrete use cases for
> this feature?
>
>
> The thing is if an author wants to replace or customize a placeholder
> element using a script that loads later, that’s pretty easy to achieve in
> the script itself:
>
> // Placeholder elements already exist in the document.
>
> document.registerElement(…); // This line of code is present no matter
> what.
>
> // Four more lines of code finish the job.
> var placeholders = document.querySelectorAll(…);
> for (var placeholder of placeholders)
> placeholder.parentNode.replaceChild(…);
>
> techcrunch.com does this for all of its  buttons, for example —
> although they do the replacement on hover, and not on load.
>
> There’s very little upside to building replacement behavior into the
> browser engine when it’s so easy to achieve in script — and the script had
> to run anyway in order to document.registerElement().   In fact, it may be
> actively harmful in preventing developers from implementing potentially
> desirable patterns (e.g. Techcrunch’s on demand replacement, which may be
> advantageous if the components are expensive).
>
>
But... there is no replacement behavior? The spec was carefully design to
explicitly avoid that. In itself, the "upgrade" is a process of setting
prototype: http://w3c.github.io/webcomponents/spec/custom/#dfn-set-prototype

:DG<

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

[Bug 24106] FKA: No defined way to get keyboard focus into and out of a shadow DOM component

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24106

Ian 'Hixie' Hickson  changed:

   What|Removed |Added

 CC||public-webapps@w3.org
  Component|HTML|Component Model
   Assignee|i...@hixie.ch|dglaz...@chromium.org
Product|WHATWG  |WebAppsWG
   Target Milestone|Unsorted|---
 QA Contact|contribu...@whatwg.org  |public-webapps-bugzilla@w3.
   ||org

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Re: [webcomponents] PubStatus reorg; Plans and Expectations

[Dimitri Glazkov]

Just a quick update: working on an update, will post here as soon as I have
all of the ducks in a row.

:DG<


On Thu, Jan 9, 2014 at 9:29 AM, Dimitri Glazkov wrote:

>
>
>
> On Thu, Jan 9, 2014 at 5:17 AM, Arthur Barstow wrote:
>
>> Hi Dimitri All,
>>
>> FYI, yesterday I moved all of the Web Components specs in PubStatus to
>> its own table [PubStatus-WC] to help address the "so, what is the status of
>> Web Components standardization in WebApps" use case (as well as to be
>> consistent with the way PubStatus organizes the Widgets spec suite).
>>
>> Although PubStatus provides current data about the state of WebApps'
>> specs, other than the Plans data (which is typically quite terse or empty),
>> PubStatus doesn't facilitate Editors documenting more "forward looking"
>> information such as roadmaps, longer term expectations, etc. Given this,
>> and the broad interest in Web Components, I think it would be useful if
>> there was some type of "state of Web Components standardization" that
>> included things like:
>>
>> * Expectations for the specs by EoY 2014
>>
>> * Status and plans of Web Component native implementations (f.ex.
>> information beyond what is available in CanIUse.com and
>> ChromeStatus.com/features)
>>
>> * Status and plans of Web Component polyfills
>>
>> * Key open issues, dependencies
>>
>> * Testing status and plans
>>
>> * Deployment status
>>
>> Thus, when someone asks "so, what do we expect for the state of Web
>> Components standardization by the end of 2014?", we have a document/thread
>> we can point to (and that document could be a reply to this email, a blog,
>> etc.). WDYT?
>>
>
> I think it's reasonable. I've been away from the keyboard for a little bit
> and am still digging out from the email backlog, so please be patient with
> me :)
>
>
>>
>> (BTW, I'm not picking on Dimitri here (who has done exemplary work,
>> especially regarding professional community engagement). I wold be
>> *delighted* if other Editors would provide similar information for their
>> specs.)
>>
>
> Yay, I love being delightful!
>
>
>>
>> -Thanks, ArtB
>>
>> [PubStatus-WC] > Components_Specifications>
>>
>>
>

RfC: LCWD of Vibration API; deadline March 4

[Arthur Barstow]

This is a Request for Comments for the Device API WG's February 11 LCWD 
of the Vibration API:


  <http://www.w3.org/TR/2014/WD-vibration-20140211/>

Individual WG members are encouraged to provide individual feedback.

If anyone in WebApps wants to propose an official WG response, please do 
so ASAP, in reply to this e-mail so the WG can discuss it.


Comments should be sent to public-device-apis @ w3.org, with a subject 
prefix of [vibration] by March 4.


-Thanks, AB

On 2/11/14 12:00 PM, Hirsch Frederick (Nokia-CTO/Boston) wrote:

The Device API Working Group [1] has published  a third Last Call working draft of the 
"Vibration API" specification  today, 11 February 2014 [2] and requests review 
comments from your groups (Web Applications WG, HTML WG). We are also interested in 
comments from others.

The changes, based on review feedback during CR, are noted in the status 
section (with links to diffs) and include allowing  implementations to truncate 
long vibrations,  specifying how  concurrent invocations in different browsing 
contexts are handled and clarifying the processing vibration patterns algorithm.

The draft is available at  http://www.w3.org/TR/2014/WD-vibration-20140211/

The Last Call period ends 4 March 2014 (3 weeks) - please send comments to the DAP public 
mailing list with "[vibration]" at the start of the Subject line. Indications 
of support for the changes are welcome.

Thanks

regards, Frederick

Frederick Hirsch, Nokia
Chair, W3C DAP Working Group

[1] http://www.w3.org/2009/dap/

[2]  http://www.w3.org/blog/news/archives/3653

FYI: Navigation Error Logging

[Philippe Le Hegaret]

This specification defines an interface to store and retrieve error data
related to the previous navigations of a document:
  http://www.w3.org/TR/2014/WD-navigation-error-logging-20140211/

As usual, we welcome all feedback on public-web-p...@w3.org

Thank you,

Philippe

[Bug 24042] [imports]: document.write() in imports should do nothing.

[bugzilla]

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24042

Anne  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||ann...@annevk.nl
 Resolution|FIXED   |---

--- Comment #6 from Anne  ---
Please file bugs
https://www.w3.org/Bugs/Public/enter_bug.cgi?product=WHATWG&component=HTML to
make sure this gets properly integrated and reviewed by the editor of the HTML
specification. Monkey patching without actually involving Ian is not the right
way to go about this.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[admin] Headsup: f2f meeting April 10-11 in San Jose

[Arthur Barstow]

Hi All - as mentioned last month, we are organizing a f2f meeting for 
this coming Spring and the dates are April 10-11 in San Jose CA US. 
WebApps' Thurs/Friday meeting will follow an April 8-9 meeting of the 
HTMLWG at the same location.


If April 10-11 causes any major and non-resolvable issue, please speak 
up immediately.


-Thanks, Art, Chaals, Yves and Cindy