RE: Progress on Push API
On 30 abr 2014 at 00:13:14, Jonas Sicking wrote: On Tue, Apr 29, 2014 at 2:00 AM, EDUARDO FULLEA CARRERA e...@tid.es wrote: Hi all, Last week the Push API editors (ATT, 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
Re: [Gamepad] Liveness of Gamepad objects
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: Separating Transclusion Mechanisms for Inheritance and Data Binding
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 shadow 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 content insertion points inside shadow 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 shadow elements, but in the meantime are primarily concerned with seeing native Shadow DOM implementations across all browsers. –Jan
Re: [Gamepad] Liveness of Gamepad objects
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: [Gamepad] Liveness of Gamepad objects
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
[admin] putting Push API in W3C's Github repo [Was: Re: Progress on Push API]
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: [admin] putting Push API in W3C's Github repo [Was: Re: Progress on Push API]
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 https://github.com/w3c/push-api.
Re: [Gamepad] Liveness of Gamepad objects
On Wed, Apr 30, 2014 at 5:58 AM, Ted Mielczarek t...@mozilla.com 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 t...@mozilla.com 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]
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 https://github.com/w3c/push-api. 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
On Wed, Apr 30, 2014 at 12:21 AM, Glenn Maynard gl...@zewt.org wrote:
On Tue, Apr 29, 2014 at 8:25 PM, Ted Mielczarek t...@mozilla.com 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: doNotTrack API feedback
On Wed, Apr 30, 2014 at 11:11 PM, Adrian Bateman adria...@microsoft.com 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/
[Bug 25458] [Shadow]: The return type of Event.path should be EventTarget[], instead of NodeList
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25458 Hayato Ito hay...@chromium.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #19 from Hayato Ito hay...@chromium.org --- 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.
[Bug 25458] [Shadow]: The return type of Event.path should be EventTarget[], instead of NodeList
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25458 Boris Zbarsky bzbar...@mit.edu changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- -- You are receiving this mail because: You are on the CC list for the bug.
