RE: Publish as W3C Notes

[Travis Leithead]

Publish as note and Incubate +1

-Original Message-
From: Léonie Watson [mailto:t...@tink.uk] 
Sent: Tuesday, April 26, 2016 11:06 AM
To: public-webapps@w3.org
Subject: CFC: Publish as W3C Notes

Hello,

At the AC meeting in March 2016 the WP co-chairs indicated that the following 
two specifications would benefit from further incubation before continuing 
along the Recommendation track:

Quota Management API [1]
Input Method Editor API [2]

This is a CFC to publish each of these specifications as a W3C note, under the 
Software and Document License. Anyone wishing to take these ideas further is 
then welcome to use the notes to seed incubation within WICG or elsewhere.

If the CFC passes, the transition of each specification to note status will be 
done within the current WP WG charter.

If you have comments or concerns about this CFC, please send them to 
public-webapps@w3.org no later than Wednesday 4th May 2016. Positive responses 
are preferred and encouraged, and silence will be considered as agreement with 
the proposal.

Léonie on behalf of the WP chairs and team.
[1] https://w3c.github.io/quota-api/
[2] https://w3c.github.io/ime-api/
--
@LeonieWatson tink.uk Carpe diem

RE: New Web Components editor

[Léonie Watson]

> From: Domenic Denicola [mailto:d...@domenic.me]
> Sent: 26 April 2016 19:06
> Thanks Léonie. One correction:
> 
> From: Léonie Watson [mailto:t...@tink.uk]
> 
> 
> > The WP co-chairs and team are happy to announce that Domenic Denicola
> > will be the new editor of the Custom Elements and Shadow DOM
> > specifications at W3C.
> 
> Custom Elements only; Shadow DOM remains in Hayato's capable hands.

Sorry about that. I've corrected Pub Status accordingly [1]. Thanks.

Léonie.
[1] https://www.w3.org/WebPlatform/WG/PubStatus 

-- 
@LeonieWatson tink.uk Carpe diem

CFC: Publish as W3C Notes

[Léonie Watson]

Hello,

At the AC meeting in March 2016 the WP co-chairs indicated that the
following two specifications would benefit from further incubation before
continuing along the Recommendation track:

Quota Management API [1]
Input Method Editor API [2]

This is a CFC to publish each of these specifications as a W3C note, under
the Software and Document License. Anyone wishing to take these ideas
further is then welcome to use the notes to seed incubation within WICG or
elsewhere.

If the CFC passes, the transition of each specification to note status will
be done within the current WP WG charter.

If you have comments or concerns about this CFC, please send them to
public-webapps@w3.org no later than Wednesday 4th May 2016. Positive
responses are preferred and encouraged, and silence will be considered as
agreement with the proposal.

Léonie on behalf of the WP chairs and team.
[1] https://w3c.github.io/quota-api/
[2] https://w3c.github.io/ime-api/
-- 
@LeonieWatson tink.uk Carpe diem

New Web Components editor

[Léonie Watson]

Hello,

The WP co-chairs and team are happy to announce that Domenic Denicola will
be the new editor of the Custom Elements and Shadow DOM specifications at
W3C.

With thanks to Google for their time and support, we're looking forward to
working with Domenic - and to the continued evolution of these
specifications.

Léonie on behalf of the WP chairs and team.

-- 
@LeonieWatson tink.uk Carpe diem

Re: [gamepad] New feature proposals: pose, touchpad, vibration

[Kostiainen, Anssi]

Hi Brandon,

> On 22 Apr 2016, at 08:14, Brandon Jones  wrote:

[...]

> Finally, I'd like to propose that we add gamepad vibration controls. This has 
> been talked about in the past as well, and the thinking has typically been 
> that the Gamepad API may want to try and use the Vibration API somehow 
> instead of exposing a new interface. However that API doesn't currently have 
> a way to target anything other than the device's default motor (usually for a 
> phone), and I don't see there being much interest in extending it to do so. 
> Still, I don't see much sense in re-inventing this wheel so I suggest 
> exposing the same interface on the Gamepad object.
> 
> partial interface Gampad {
> boolean vibrate (VibratePattern pattern);
> };

If you have suggestions for improvements you'd like to see in the Vibration 
API, please feel free to open issues in GitHub:

https://github.com/w3c/vibration

Some specs already reuse parts of the Vibration API. For example, the 
Notifications API reuses and references the vibration pattern, and its 
'validate and normalize' and 'perform vibration' algorithms. We actually added 
some hooks to the Vibration API spec to make that integration possible.

> This is pretty basic as far as gamepad haptics go, but it's also provides a 
> lowest common denominator interface that should be supportable by anything 
> with a motor in it. It gives up some granularity (For example, it doesn't 
> allow developers to trigger the two motors in an Xbox controller 
> individually), but it provides a clean, universal interface that's easy to 
> use and mimics existing features on the web platform.

At the time the spec was crafted, we evaluated devices that were widely 
available and took an intersection of the feature set. That said, we should 
re-evaluate the feature set from time to time and make sure it matches the 
capabilities of the today's devices.

Thanks,

-Anssi (the Vibration API editor)

Re: [XHR] null response prop in case of invalid JSON

[Anne van Kesteren]

On Mon, Apr 25, 2016 at 8:10 PM, Kirill Dmitrenko  wrote:
> I've found in the spec of XHR Level 2 that if a malformed JSON's received 
> from a server, the response property would be set to null. But null is a 
> valid JSON, so, if I understand correctly, there is no way to distinct a 
> malformed JSON response from a response containing only 'null', which is, 
> again, a valid JSON:
>
> $ node -p -e 'JSON.parse("null")'
> null
> $

Use the fetch() API instead. It'll rethrow the exception for this
case: https://fetch.spec.whatwg.org/#fetch-api. Also, "XHR Level 2" is
no longer maintained. You want to look at https://xhr.spec.whatwg.org/
instead (though for this specific case it'll say the same thing).


-- 
https://annevankesteren.nl/

[XHR] null response prop in case of invalid JSON

[Kirill Dmitrenko]

Hi!

I've found in the spec of XHR Level 2 that if a malformed JSON's received from 
a server, the response property would be set to null. But null is a valid JSON, 
so, if I understand correctly, there is no way to distinct a malformed JSON 
response from a response containing only 'null', which is, again, a valid JSON:

$ node -p -e 'JSON.parse("null")'
null
$

-- 
Kirill Dmitrenko
Yandex Maps Team