[Bug 25458] [Shadow]: The return type of Event.path should be EventTarget[], instead of NodeList

[bugzilla]

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

Boris Zbarsky  changed:

   What|Removed |Added

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

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

[Bug 25458] [Shadow]: The return type of Event.path should be EventTarget[], instead of NodeList

[bugzilla]

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

Hayato Ito  changed:

   What|Removed |Added

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

--- Comment #19 from Hayato Ito  ---
Thank you. 2 looks a reasonable option here.

I updated the spec at
https://github.com/w3c/webcomponents/commit/6f296e4bb73238a15baab805a0079c16f9dfac7f

I appreciate any feedbacks for that.

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

Re: doNotTrack API feedback

[Anne van Kesteren]

On Wed, Apr 30, 2014 at 11:11 PM, Adrian Bateman  wrote:
> My understanding was that attributes on navigator returned values that
> were expected to be consistent for the browser. Are you proposing a
> navigator attribute that varies based on the document origin? I didn't
> realise we'd changed this. This was why the group moved this away from
> the original location on navigator.

It seems cookieEnabled and several plugin-related properties can
already differ. If we can still change how we expose DNT, we should
strongly consider making it asynchronous.


-- 
http://annevankesteren.nl/

RE: doNotTrack API feedback

[Adrian Bateman]

On Wednesday, April 30, 2014 2:53 PM, Anne van Kesteren wrote:
> In a private thread with one of the editors I suggested the following
> as replacement for the current API:
> 
> 
> enum DNTValues { "unspecified", "0", "1" };
> 
> [NoInterfaceObject, Exposed=Window,Worker]
> interface NavigatorDNT {
>   readonly attribute DNTValues doNotTrack;
> };
> Navigator implements NavigatorDNT
> WorkerNavigator implements NavigatorDNT
> 
> 
> I think this more closely matches what we want here.
> 
> It's probably still not completely ideal as per Peter permission
> exposure is ideally asynchronous due to crossing process boundaries,
> but I suspect it might be too late to turn this into a promise.

My understanding was that attributes on navigator returned values that
were expected to be consistent for the browser. Are you proposing a
navigator attribute that varies based on the document origin? I didn't
realise we'd changed this. This was why the group moved this away from
the original location on navigator.

Thanks,

Adrian

Re: doNotTrack API feedback

[Anne van Kesteren]

On Wed, Apr 30, 2014 at 10:44 PM, Marcos  wrote:
> On April 29, 2014 at 8:36:20 AM, Anne van Kesteren (ann...@annevk.nl) wrote:
>> 4. It should be exposed in workers.
>
> See: http://heycam.github.io/webidl/#Exposed for the details of how to do 
> that. Contains an example.

In a private thread with one of the editors I suggested the following
as replacement for the current API:


enum DNTValues { "unspecified", "0", "1" };

[NoInterfaceObject, Exposed=Window,Worker]
interface NavigatorDNT {
  readonly attribute DNTValues doNotTrack;
};
Navigator implements NavigatorDNT
WorkerNavigator implements NavigatorDNT


I think this more closely matches what we want here.

It's probably still not completely ideal as per Peter permission
exposure is ideally asynchronous due to crossing process boundaries,
but I suspect it might be too late to turn this into a promise.


-- 
http://annevankesteren.nl/

Re: doNotTrack API feedback

[Marcos]

On April 29, 2014 at 8:36:20 AM, Anne van Kesteren (ann...@annevk.nl) wrote:
> 4. It should be exposed in workers.

See: http://heycam.github.io/webidl/#Exposed for the details of how to do that. 
Contains an example.  

Re: [admin] putting Push API in W3C's Github repo [Was: Re: Progress on Push API]

[Mounir Lamouri]

On Thu, 1 May 2014, at 1:50, EDUARDO FULLEA CARRERA wrote:
> On 30 abr 2014 at 16:52:49, Arthur Barstow wrote:
> > On 4/30/14 10:44 AM, Arthur Barstow wrote:
> >> I'll work with Mike/Robin to create a new "push-api" project, unless
> >> you request otherwise. OK?
> >
> > Eduardo - Mike created this project .
> 
> Thanks! Once we deal with open pull requests in current repo will migrate
> to the new one.
> A question, who has permission to accept pull requests? At least the
> editors should have.

I believe this will be the WebApps team including Marcos and I for the
moment:
https://github.com/orgs/w3c/teams/webapps

-- Mounir

RE: [Gamepad] Liveness of Gamepad objects

[Domenic Denicola]

From: Rick Waldron 

> Another argument for "live" objects is that it should be possible to reason 
>about gamepad objects as instances of a Gamepad constructor. The "snapshot" 
>design destroys any notion of object identity that could be associated with a 
>gamepad object. 

This seems relevant to a related concern I have, which is that if something is 
to be a class (WebIDL interface) instead of a normal JS object (WebIDL 
dictionary), it should have both data and behavior. Snapshots don't seem to 
have any behavior.

I'm not suggesting changing anything in the spec at this stage (two 
mostly-interoperable implementations sounds great to me!), but this makes me 
lean more toward live objects, since then they would have behavior (viz. 
properties that change values over time).

Re: [Gamepad] Liveness of Gamepad objects

[Rick Waldron]

On Wed, Apr 30, 2014 at 7:11 AM, Ted Mielczarek  wrote:

> On 4/29/2014 10:39 AM, Ted Mielczarek wrote:
> > The only major issue that needs to be fixed in the Gamepad API spec
> > currently is the liveness of Gamepad objects[1].
> After reading through the discussion here I'm leaning towards specifying
> the snapshot behavior that Chrome implements. Regardless of whether we
> spec an event-based update mechanism in the future, being able to refer
> to a snapshot of Gamepad state seems useful, and there's not much
> overhead in calling navigator.getGamepads()[i] instead of referring
> directly to a saved Gamepad object.
>
> My only reservation is that if Gamepad becomes a snapshot instead of a
> live object, it feels weird to suggest adding output methods to it (like
> adding vibration support). Perhaps I'm overthinking it, though.
>
> Any other thoughts here?
>

I agree with this concern.


Another argument for "live" objects is that it should be possible to reason
about gamepad objects as instances of a Gamepad constructor. The "snapshot"
design destroys any notion of object identity that could be associated with
a gamepad object.

Consider the case where a WeakMap is used to store some side table of
information:

// Live object use...
var wm = new WeakMap();
var gamepad = navigator.getGamepads()[0];

// store some foo counter state
wm.set(gamepad, { foo: 1 });

// later access the foo count (some other aspect of the program has been
updating it)
wm.get(gamepad).foo;


There is no analog in the snapshot case because "gamepad" will be a new
snapshot object every rAF turn, since the reference is lost the WeakMap
will dispose of the key/val pair and the side-table state disposed along
with it.

Rick

Re: [Gamepad] Liveness of Gamepad objects

[Rick Waldron]

On Wed, Apr 30, 2014 at 12:21 AM, Glenn Maynard  wrote:

> On Tue, Apr 29, 2014 at 8:25 PM, Ted Mielczarek  wrote:
>
>>  On 4/29/2014 7:28 PM, Glenn Maynard wrote:
>>
>>   Gamepad objects should definitely be a snapshot.  Otherwise, change
>> events could only expose the most recent state of the gamepad.  For
>> example, if the user presses a button and then releases it very quickly
>> (before the down press gets handled by script), and you fire two change
>> events, the script would never see the buttons as pressed.
>>
>>
>> This is a good point--if we have live objects then if we do implement
>> change events we'd need to store the state elsewhere. Firefox has
>> gamepadbutton{press,release} events and gamepadaxismove events[1][2]
>> (behind a pref), they actually do this already but it's not fantastic.
>>
>
> There should simply be a "change" event, which is fired when any property
> changes.  (Some rate clamping might be needed for analog inputs, which
> could change very quickly, but that's an implementation detail.)
>
>  My original prototype provided the events mentioned above. The feedback I
>> received was overwhelmingly in favor of a polling API instead[3]. I decided
>> to go ahead with that (actually Scott beat me to the punch and implemented
>> that in Chrome first), figuring we could always spec events in a future
>> revision.
>>
>
> (Please try to direct conversations here or to the whatwg list, so
> everyone has a chance to participate...)
>
> Supporting polling is a separate issue from whether the Gamepad interface
> is live or a snapshot.  You definitely want to be able to retrieve a
> snapshot of the current state, and as long as you can do that you
> automatically support polling.
>
> That is, users can either use polling:
>
> onRequestAnimationFrame = function() {
> // Once we create this, it never changes, so we can compare it the
> next time around when it becomes lastGamepadState.
> var gamepadState = navigator.getGamepads();
>
> // Find differences between lastGamepadState and gamepadState and act
> on them:
> for(var i = 0; i < gamepadState.length; ++i)
> processInput(gamepadState[i], lastGamepadState[i]);
>
> // Save the current state, for comparison during the next frame.
> lastGamepadState = gamepadState;
> }
>
> or events:
>
> navigator.onGamepadChange = function(e) {
> var gamepadState = e.state;
> processInput(e.gamepadIndex, gamepadState, lastGamepadState);
> lastGamepadState[e.gamepadIndex] = gamepadState;
> }
>
>
This is exactly the semantics I described here
http://lists.w3.org/Archives/Public/public-webapps/2014AprJun/0266.html,
with the exception that the Gamepad object is live and the change event
states are "snapshots".


Something else to consider: how does a Gamepad object behave with
Object.observe?

var gamepads = navigator.getGamepads();

Object.observe(gamepads[0], function(changeRecords) {
  ...
});


Presumably the "live" object design will work as expected, invoking the
observe handler at the end of each processing turn "microtask"
(changeRecords will always include the previous and current values), and
the "snapshot" does not.


Rick

RE: [admin] putting Push API in W3C's Github repo [Was: Re: Progress on Push API]

[EDUARDO FULLEA CARRERA]

On 30 abr 2014 at 16:52:49, Arthur Barstow wrote:
> On 4/30/14 10:44 AM, Arthur Barstow wrote:
>> I'll work with Mike/Robin to create a new "push-api" project, unless
>> you request otherwise. OK?
>
> Eduardo - Mike created this project .

Thanks! Once we deal with open pull requests in current repo will migrate to 
the new one.
A question, who has permission to accept pull requests? At least the editors 
should have.



Este mensaje se dirige exclusivamente a su destinatario. Puede consultar 
nuestra política de envío y recepción de correo electrónico en el enlace 
situado más abajo.
This message is intended exclusively for its addressee. We only send and 
receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx

Re: [Gamepad] Liveness of Gamepad objects

[Glenn Maynard]

On Wed, Apr 30, 2014 at 5:58 AM, Ted Mielczarek  wrote:

> Yes, it's true. In any event, this is going a bit afield. We're not going
> to spec events for the first version of the spec.
>

Examining the features that each design would make easier or harder isn't
afield.

On Wed, Apr 30, 2014 at 6:11 AM, Ted Mielczarek  wrote:

> My only reservation is that if Gamepad becomes a snapshot instead of a
> live object, it feels weird to suggest adding output methods to it (like
> adding vibration support). Perhaps I'm overthinking it, though.
>

I cut out a comment about that for length, actually.  It would be better to
have separate objects for the gamepad itself and where output methods live,
and another interface holding a snapshot of an input state.  Then, you'd
just call gamepad.getState() to read the state for that device.  It's also
a natural place for an event interface to live, and for input state that
doesn't change, like the device's ID.

I definitely wouldn't make Gamepad live just to avoid doing that, though.
 It could always be added later, by adding a GamepadDevice interface, eg:

gamepadDevices = navigator.getGamepadDevices();
gamepad = gamepads[0];
state = gamepad.getState();

equivalent to navigator.getGamepads()[0].

--
Glenn Maynard

Re: [admin] putting Push API in W3C's Github repo [Was: Re: Progress on Push API]

[Arthur Barstow]

On 4/30/14 10:44 AM, Arthur Barstow wrote:
I'll work with Mike/Robin to create a new "push-api" project, unless 
you request otherwise. OK?


Eduardo - Mike created this project .

[admin] putting Push API in W3C's Github repo [Was: Re: Progress on Push API]

[Arthur Barstow]

On 4/30/14 3:25 AM, EDUARDO FULLEA CARRERA wrote:

We developing the new version at [1], though not yet updated with the changes 
in my previous email.

But if may be a good idea to migrate is to the W3C GitHub official repo.


Hi Eduardo,

WebApps already has a few specs using github.org/W3C so the Push API can 
be added.



What is the process to open the project there? Can anyone help?


I'll work with Mike/Robin to create a new "push-api" project, unless you 
request otherwise. OK?


-Thanks, ArtB

Re: [Gamepad] Liveness of Gamepad objects

[Ted Mielczarek]

On 4/29/2014 10:39 AM, Ted Mielczarek wrote:
> The only major issue that needs to be fixed in the Gamepad API spec
> currently is the liveness of Gamepad objects[1].
After reading through the discussion here I'm leaning towards specifying
the snapshot behavior that Chrome implements. Regardless of whether we
spec an event-based update mechanism in the future, being able to refer
to a snapshot of Gamepad state seems useful, and there's not much
overhead in calling navigator.getGamepads()[i] instead of referring
directly to a saved Gamepad object.

My only reservation is that if Gamepad becomes a snapshot instead of a
live object, it feels weird to suggest adding output methods to it (like
adding vibration support). Perhaps I'm overthinking it, though.

Any other thoughts here?

-Ted

Re: [Gamepad] Liveness of Gamepad objects

[Ted Mielczarek]

On 4/30/2014 12:21 AM, Glenn Maynard wrote:
>
> My original prototype provided the events mentioned above. The
> feedback I received was overwhelmingly in favor of a polling API
> instead[3]. I decided to go ahead with that (actually Scott beat
> me to the punch and implemented that in Chrome first), figuring we
> could always spec events in a future revision.
>
>
> (Please try to direct conversations here or to the whatwg list, so
> everyone has a chance to participate...)
If you note the dates you can see that this was well before
standardization work started. This was just feedback on a prototype.

>
> Supporting polling is a separate issue from whether the Gamepad
> interface is live or a snapshot.  You definitely want to be able to
> retrieve a snapshot of the current state, and as long as you can do
> that you automatically support polling.
>

Yes, it's true. In any event, this is going a bit afield. We're not
going to spec events for the first version of the spec. We have two
mostly-compatible implementations shipping in Firefox and Chrome
supporting polling, I'd just like to nail down the remaining uncertain
bits of the spec (like the topic at hand) so others can ship compatible
implementations. Once that's done we can certainly discuss features for
a next revision, there's already a wiki page[1] to gather ideas.

> (Aside: I'm not sure if the top one is correct.  Does
> getGamepads()[n].index == n, so that gamepadState[i] always
> corresponds to lastGamepadState[i]?  The spec suggests that with
> "index of the gamepad in the Navigator", but I'm not sure.  If so,
> what is getGamepads()[1] if controller index 1 is disconnected, since
> you can't reorder the later items?  undefined?)
Yes, Gamepad.index is the index into the list returned by
navigator.getGamepads(), so that holds true. If the latter portion isn't
answered in the spec I can add some text to clarify: there are allowed
to be holes in the array where controllers were removed. I'm not sure
what they are in current practice, but null or undefined both seem like
legitimate values.

-Ted

1. https://www.w3.org/wiki/Webapps/GamepadFeatures

Re: Separating Transclusion Mechanisms for Inheritance and Data Binding

[Jan Miksovsky]

I just saw Dimitri's reference to my “Filling slots in shadow” blog posts from 
a while back, so I thought I’d follow up with the experiences I’ve had I wrote 
it.

First, I remain convinced that it will be very helpful for Shadow DOM to 
provide a feature like this that allows for parent and child classes to 
cooperatively contribute elements to the same component. This is a key feature 
that enables well-factored user interface components. I started a company 
earlier this year that is building a site entirely on web components, and we’ve 
already hit the limitations of what’s possible without this feature.

Second, my colleagues and I found the pre-existing proposal to let authors 
reproject content into  to be an elegant solution to this problem. 
During the brief window when this feature was available in Chrome Canary, we 
quickly made use of it. It felt like a very natural extension of the Shadow DOM 
tree composition concepts we had already learned. That is, in our experience, 
the conceptual load introduced by this feature was low. To the extent the 
developer experience weighs in any decision here, we were completely fine with 
the approach of placing  insertion points inside  elements.

Third, we feel a modest amount of impatience to see this feature implemented in 
Chrome again, and for other browsers to adopt this feature as it existed in 
Chrome. It was meeting our needs, and seeing it (even temporarily) removed felt 
like a step backwards. We’re concerned that lack of a solution here will 
discourage people from applying subclassing as a means to factor user interface 
behavior into parent/child component class relationships.

Finally, even given all the above, we view it as more important that all the 
mainstream browsers implement the more fundamental aspects of Shadow DOM with 
all due speed. Our company and its customers are entirely dependent upon web 
components that use Shadow DOM, and while we can rely upon the Polymer library 
for cross-browser compatibility, there is a considerable different in 
performance between native and polyfilled Shadow DOM features. We test on a 
variety of browsers and devices, and while we can run on Mobile Safari or IE, 
performance on those platforms is barely acceptable. We would rather see the 
basics of Shadow DOM be native now, and live without defined semantics for 
parent/child contributions to shadow trees, than wait indefinitely for that 
feature before seeing native implementations of the basics.

I feel like something of an industry outsider in discussions related to web 
standards, and appreciate the range of scenarios those working on standards 
must consider as they debate proposals for changes. I trust the smart folks at 
Apple, Google, and elsewhere to make the right decision here. All I can offer 
here is my company's own practical experience in this domain. For our part, we 
would be very happy to see a solution adopted in the standard that follows the 
general lines of allowing reprojection of content into  elements, but 
in the meantime are primarily concerned with seeing native Shadow DOM 
implementations across all browsers.

–Jan

Re: [Gamepad] Liveness of Gamepad objects

[Florian Bösch]

There's two aspects that should not be overlooked.

   1. Some events only make sense in unison. For instance the input of a
   2-axis knob. On many OS implementations, change events for each axis arrive
   separately in short succession. However to an application programmer,
   getting first the X axis change, and then the Y axis change may not make
   sense. A common result of doing this would be that instead of getting a
   diagonal movement, a stepped movement is displayed. The technique employed
   by many native application programmers to this kind of problem is to
   coalesce events they deem to belong together into one event.
   2. Input -> Output latency is a significant concern for input devices
   used to produce an output. One way to minimize the latency is called "time
   warp" in which most of the frames tasks that are not directly influenced by
   the input are completed. Then the program idles till nearly the end of the
   frame, polls the input (which should arrive fresh) and then completes the
   rest of the (ideally constant time) tasks just before the frame runs out.

RE: Progress on Push API

[EDUARDO FULLEA CARRERA]

On 30 abr 2014 at 00:13:14, Jonas Sicking wrote:
> On Tue, Apr 29, 2014 at 2:00 AM, EDUARDO FULLEA CARRERA 
> wrote:
>> Hi all,
>>
>> Last week the Push API editors (AT&T, Telefónica) and other interested
> parties (Mozilla, Google) met to progress this specification. It was a very
> productive meeting in which great support was shown to this piece of work and
> consensus was reached around many topics under discussion. This is a summary
> of these points, which will be incorporated into a new editor's draft 
> shortly. Of
> course feel free to provide any feedback:
>

We developing the new version at [1], though not yet updated with the changes 
in my previous email.

But if may be a good idea to migrate is to the W3C GitHub official repo. What 
is the process to open the project there? Can anyone help?

Thanks.
Eduardo.

[1] https://github.com/telefonicaid/WebAPISpecs/tree/develop/Push



Este mensaje se dirige exclusivamente a su destinatario. Puede consultar 
nuestra política de envío y recepción de correo electrónico en el enlace 
situado más abajo.
This message is intended exclusively for its addressee. We only send and 
receive email on the basis of the terms set out at:
http://www.tid.es/ES/PAGINAS/disclaimer.aspx