Re: Screen Orientation API Spec (from phrasing confusion)

[Bruno Racineux]

>On 3/13/14 10:59 AM, "Mounir Lamouri"  wrote:
>
>>I recently landed a usage counter for window.orientation. It will take
>>some time to roll to Chrome Android stable but hopefully we will find
>>out if window.orientation is actually used a lot. If that's the case and
>>other UA want to implement it, we could incorporate that into this
>>specification. In any case, I would like to add this feature but not as
>>|window.orientation|.
>>
>>
>>Your use case will be taken care of, see this bug:
>>https://www.w3.org/Bugs/Public/show_bug.cgi?id=24698
>
>You could alternatively just have a 'natural' orientation boolean flag,
>to help assessing the angle at the initial rotation level
>(without having to first rotate to find out).
>
>The flag would also add the ability to lock to the "natural" orientation.
>
>My main rebuttal of the orientation values is not the lack of angle, but
>rather the lack of instant identification of this 'natural' orientation
>state. We can figure out the mapping to angles with such a flag.
>
>So should it a better or easier implementation option, perhaps avoiding
>redundancy, that would work too, and the only thing needed to address my
>case.

If you are going to leave it up to the UA. As per the recent change:
--- Comment #1 from Mounir Lamouri  ---
*-primary and *-secondary is now entirely up to the UA:
https://dvcs.w3.org/hg/screen-orientation/rev/5397f6ae4528

Ignore my previous/above comment. A flag won't work anymore.

The notion of left and right is lost under this new spec change,
with the concept of orientation being very different from what it was.
I have to scrap mapping to angles, that change deprecates my code.

I'll wait until we have angles, or for Mozilla and IE to implement
window.orientation for mobile.

Re: On starting WebWorkers with blob: URLs...

[Ian Hickson]

On Fri, 14 Mar 2014, Arun Ranganathan wrote:
> On Mar 12, 2014, at 6:54 PM, Ian Hickson wrote:
> >> 
> >> For blob: URLs we agreed to make this pretty explicit: 
> >> http://dev.w3.org/2006/webapi/FileAPI/#originOfBlobURL
> > 
> > Unfortunately, scripts don't have origins these days, so this 
> > definition doesn't really work.
> 
> It didn't work since it wasn't formally specific about effective script 
> origin according to the script setting object, but I've fixed that so 
> hopefully this definition should work:
> 
> http://dev.w3.org/2006/webapi/FileAPI/#originOfBlobURL

LGTM. Assuming that UAs implement this, that makes Workers automatically 
support blob: URLs, too.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

[Bug 25061] New: [Shadow]: Minor grammatical quibble

[bugzilla]

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

Bug ID: 25061
   Summary: [Shadow]: Minor grammatical quibble
   Product: WebAppsWG
   Version: unspecified
  Hardware: PC
OS: All
Status: NEW
  Severity: trivial
  Priority: P2
 Component: Component Model
  Assignee: dglaz...@chromium.org
  Reporter: arth...@chromium.org
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org
Blocks: 14978

"is no nodes" should be "are no nodes"

This phrase occurs twice.

Or alternately

"If there is no nodes distributed" =>  "If no nodes are distributed"

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

Re: On starting WebWorkers with blob: URLs...

[Arun Ranganathan]

On Mar 12, 2014, at 6:54 PM, Ian Hickson wrote:

>> For blob: URLs we agreed to make this pretty explicit: 
>> http://dev.w3.org/2006/webapi/FileAPI/#originOfBlobURL
> 
> Unfortunately, scripts don't have origins these days, so this definition 
> doesn't really work.



It didn't work since it wasn't formally specific about effective script origin 
according to the script setting object, but I've fixed that so hopefully this 
definition should work:

http://dev.w3.org/2006/webapi/FileAPI/#originOfBlobURL

-- A*

Re: [screen-orientation] Remove the ability to lock to multiple orientations?

[Mounir Lamouri]

Great. I applied those changes to the current ED. It might lack a bit of
clarity but I will integrate Promises soon so I will likely revisit the
language later.

-- Mounir

On Sat, 15 Mar 2014, at 5:36, Jonas Sicking wrote:
> Agreed. "any" sounds the most descriptive.
> 
> / Jonas
> 
> On Fri, Mar 14, 2014 at 7:01 AM, Marcos Caceres  wrote:
> >
> > On March 14, 2014 at 9:58:59 AM, Mounir Lamouri (mou...@lamouri.fr) wrote:
> >> On Fri, 14 Mar 2014, at 16:09, Jonas Sicking wrote:
> >> > However it does mean that we need to also have a way to define that
> >> > orientation should be completely unlocked. This is needed since the
> >> > manifest spec allows overriding the default unlocked orientation. I.e.
> >> > it should be possible to use the manifest to say that an app should be
> >> > in portrait mode, but then allow a page to temporarily override that
> >> > to allow any orientation.
> >>
> >> Good point. I meant to mention that in the email but obviously forgot. I
> >> was wondering between 'any', 'all' or 'sensor' (or 'sensor-all'? :)).
> >
> > `any` should be fine.
> >
> >
> >
> >
> 

[Bug 24702] Apply Anne's comments sent in public-webapps

[bugzilla]

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

Mounir Lamouri  changed:

   What|Removed |Added

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

--- Comment #3 from Mounir Lamouri  ---
This is done/other bugs are filed.

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

[Bug 25054] New: Should the API be exposed to non-Mobile?

[bugzilla]

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

Bug ID: 25054
   Summary: Should the API be exposed to non-Mobile?
   Product: WebAppsWG
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Screen Orientation
  Assignee: mou...@lamouri.fr
  Reporter: mou...@lamouri.fr
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org

I think the API should probably not be exposed if the device do not allow
orientation changes. There isn't much value in reading the orientation if the
orientation can't change. If it is only a presentation problem, CSS solves that
already with media queries.

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

[Bug 25053] New: Specify clear security requirements

[bugzilla]

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

Bug ID: 25053
   Summary: Specify clear security requirements
   Product: WebAppsWG
   Version: unspecified
  Hardware: All
OS: All
Status: NEW
  Severity: normal
  Priority: P2
 Component: Screen Orientation
  Assignee: mou...@lamouri.fr
  Reporter: mou...@lamouri.fr
QA Contact: public-webapps-bugzi...@w3.org
CC: m...@w3.org, public-webapps@w3.org

What if the call is made from a browser tab that in not fullscreen? if
fullscreen? in an iframe? etc.

It would be great if the specification could allow some freedom in
implementation here depending on security model but still make it clear to the
developers what's happening and how to solve it. For example, a Promise could
fail with "FullscreenRequired" or "SecurityError" depending on the actual
problem. The former being solvable (going fullscreen), the later being not
solvable in the current context (being an iframe or not at all allowed).

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

[Bug 24699] Reconsider -primary and -secondary orientations

[bugzilla]

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

Mounir Lamouri  changed:

   What|Removed |Added

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

--- Comment #1 from Mounir Lamouri  ---
*-primary and *-secondary is now entirely up to the UA:
https://dvcs.w3.org/hg/screen-orientation/rev/5397f6ae4528

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

[Bug 24700] Should 'foo' be entirely equivalent to [ 'foo-primary', 'foo-secondary' ]

[bugzilla]

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

Mounir Lamouri  changed:

   What|Removed |Added

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

--- Comment #1 from Mounir Lamouri  ---
Fixed by:
https://dvcs.w3.org/hg/screen-orientation/rev/fb358986c6c9
https://dvcs.w3.org/hg/screen-orientation/rev/5397f6ae4528

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

[Bug 24695] Allowed orientations should be an enum

[bugzilla]

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

Mounir Lamouri  changed:

   What|Removed |Added

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

--- Comment #1 from Mounir Lamouri  ---
https://dvcs.w3.org/hg/screen-orientation/rev/5397f6ae4528

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

[Bug 24703] No easy way to lock to a set of accepted orientations if one UA doesnt support one of them

[bugzilla]

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

Mounir Lamouri  changed:

   What|Removed |Added

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

--- Comment #2 from Mounir Lamouri  ---
Fixed by:
https://dvcs.w3.org/hg/screen-orientation/rev/fb358986c6c9
https://dvcs.w3.org/hg/screen-orientation/rev/5397f6ae4528

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

Re: [Editing] Splitting Selection API Into a Separate Specification

[Ryosuke Niwa]

On Mar 14, 2014, at 5:58 AM, Arthur Barstow  wrote:

> On 3/13/14 7:43 PM, ext Ryosuke Niwa wrote:
>> Hi,
>> 
>> It appears that there is a lot of new features such as CSS regions and 
>> shadow DOM that have significant implications on selection API, and we 
>> really need a spec. for selection API these specifications can refer to.
>> 
>> Thankfully, Aryeh has done a great work writing the spec. for selection API 
>> as a part of HTML Editing APIs specification [1] but no browser vendor has 
>> been able to give meaningful feedback or has implemented the spec due to the 
>> inherent complexity in HTML editing.  As a result, the specification hasn't 
>> made much progress towards reaching Last Call or CR.
>> 
>> Given the situation, I think it's valuable to extract the parts of the spec 
>> that defines selection API into its own specification and move it forward in 
>> the standards process so that we can make it more interoperable between 
>> browsers, and let CSS regions, shadow DOM, and other specifications refer to 
>> the specification.
>> 
>> Any thoughts and opinions?
> 
> When we last discussed this spec vis-à-vis the Editing CG and WebApps [1], 
> the CG's position was the spec was not ready for "Recommendation track work". 
> As such, I would like to hear from Aryeh and/or the Editing CG re Ryosuke's 
> proposal.

I think the selection API is ready for recommendation track work.  It's mostly 
interoperable between non-Gecko browsers.

> One factor to consider re WebApps formally working on this spec is whether 
> there we have sufficient resource commitment(s) re editing, testing, etc. Do 
> we have such commitment(s)?

For testing, Aryeh has written a very comprehensive test suite for the entire 
editing, so we should be able to extract the parts for selection API.

And I'm more than happy to volunteer as an editor for the spec.

- R. Niwa

Re: [screen-orientation] Remove the ability to lock to multiple orientations?

[Jonas Sicking]

Agreed. "any" sounds the most descriptive.

/ Jonas

On Fri, Mar 14, 2014 at 7:01 AM, Marcos Caceres  wrote:
>
> On March 14, 2014 at 9:58:59 AM, Mounir Lamouri (mou...@lamouri.fr) wrote:
>> On Fri, 14 Mar 2014, at 16:09, Jonas Sicking wrote:
>> > However it does mean that we need to also have a way to define that
>> > orientation should be completely unlocked. This is needed since the
>> > manifest spec allows overriding the default unlocked orientation. I.e.
>> > it should be possible to use the manifest to say that an app should be
>> > in portrait mode, but then allow a page to temporarily override that
>> > to allow any orientation.
>>
>> Good point. I meant to mention that in the email but obviously forgot. I
>> was wondering between 'any', 'all' or 'sensor' (or 'sensor-all'? :)).
>
> `any` should be fine.
>
>
>
>

Re: indexedDB API grammatical error

[Joshua Bell]

Thanks, fixed.


On Thu, Mar 13, 2014 at 2:42 PM, Danillo Paiva <
danillo.paiva.tol...@gmail.com> wrote:

> 3.1.3 Keys
>
> (...)
>
> Operations that accept keys must perform as if each key parameter value,
> in order, is copied *by the by the* structured clone algorithm [HTML5]
> and the copy is instead used as input to the operation, before proceding
> with rest of the operation.
>
> Link: https://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html
>
>
>
> Att,
> Danillo
>
>

Re: [gamepad] preventing default/capturing controller

[Patrick H. Lauke]

On 14/03/2014 15:52, Ted Mielczarek wrote:

After ruminating, though, my thought was that an explicit API is
probably not necessary--if a web page accesses the Gamepad API at all
then the browser can relinquish using the controller as navigation to
allow the page to do its thing.


Yes, that sort of automagic behavior could also work (perhaps coupled 
with a dialog similar to fullscreen mode - asking for forgiveness - or 
access to geolocation API - asking for permission).


Would this be happen when, say, getGamepads is being called? And would 
any time spent approving, for instance, block the page's JS? I guess it 
would depend on the logic implemented in the page (does it just check 
getGamepads once, or continues polling until a gamepad is detected).



The only thing necessary is for the
browser to have some way to "break out" of this mode so the user can
dismiss the page or navigate somewhere else.


And potentially once the user "breaks out", fire a gamepaddisconnected 
event?



Thoughts? This is certainly something that the spec should talk about,
since it will impact usage on consoles which is a pretty important use case.


P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

Re: [gamepad] preventing default/capturing controller

[Ted Mielczarek]

On 3/14/2014 11:36 AM, Patrick H. Lauke wrote:
> On 14/03/2014 15:29, Vincent Scheib wrote:
>> Perhaps I'm missing some context. What issue are you raising that isn't
>> handled by the gamepad API [1]?
>>
>> [1] https://dvcs.w3.org/hg/gamepad/raw-file/default/gamepad.html
>
> The issue is perhaps hypothetical at the moment, but: the spec
> currently does not address (unless I've missed it) the scenario where
> a user agent is already set to react to a gamepad input device - see
> for instance IE on XBox One, where the analogue stick moves an
> on-screen mouse pointer and the d-pad maps to regular cursor keys.
>
> Now, IE doesn't currently support the gamepad API, but once it does -
> or similar devices, particularly in the TV/set-top box space come out
> that do - there will be some conflict between an application using the
> gamepad API to directly tap into those controls AND the browser/OS
> doing its own mapping (analogue stick as mouse, d-pad as cursors).
> You'd end up with, say, a movement of the analogue stick BOTH being
> processed through the API AND the on-screen mouse pointer moving.
>
> For this reason, I was wondering if it's worth pre-emptively
> addressing this situation by defining a way for a website/app to
> "lock" the controller, signalling to the browser/OS that it will
> handle gamepad input directly, and that default browser/OS mappings
> should be ignored.
>
> Hope that makes it a tad clearer?
>
This is a fair point. I've thought about this a little bit in the
context of implementing the API for Firefox for Android. Our Android
implementation already has some Gamepad-based navigation for use on the
Ouya console, so the same conflict will exist.

After ruminating, though, my thought was that an explicit API is
probably not necessary--if a web page accesses the Gamepad API at all
then the browser can relinquish using the controller as navigation to
allow the page to do its thing. The only thing necessary is for the
browser to have some way to "break out" of this mode so the user can
dismiss the page or navigate somewhere else.

Thoughts? This is certainly something that the spec should talk about,
since it will impact usage on consoles which is a pretty important use case.

-Ted

Re: [gamepad] preventing default/capturing controller

[Patrick H. Lauke]

On 14/03/2014 15:29, Vincent Scheib wrote:

Perhaps I'm missing some context. What issue are you raising that isn't
handled by the gamepad API [1]?

[1] https://dvcs.w3.org/hg/gamepad/raw-file/default/gamepad.html


The issue is perhaps hypothetical at the moment, but: the spec currently 
does not address (unless I've missed it) the scenario where a user agent 
is already set to react to a gamepad input device - see for instance IE 
on XBox One, where the analogue stick moves an on-screen mouse pointer 
and the d-pad maps to regular cursor keys.


Now, IE doesn't currently support the gamepad API, but once it does - or 
similar devices, particularly in the TV/set-top box space come out that 
do - there will be some conflict between an application using the 
gamepad API to directly tap into those controls AND the browser/OS doing 
its own mapping (analogue stick as mouse, d-pad as cursors). You'd end 
up with, say, a movement of the analogue stick BOTH being processed 
through the API AND the on-screen mouse pointer moving.


For this reason, I was wondering if it's worth pre-emptively addressing 
this situation by defining a way for a website/app to "lock" the 
controller, signalling to the browser/OS that it will handle gamepad 
input directly, and that default browser/OS mappings should be ignored.


Hope that makes it a tad clearer?

P


On Fri, Mar 14, 2014 at 1:35 AM, Patrick H. Lauke
mailto:re...@splintered.co.uk>> wrote:

No takers on the idea of having some form of control - like a
gamepad capture lock, or some way of preventDefault-ing gamepad
controls before they're turned into mouse/cursor controls by the UA?


On 26/02/2014 10:16, Patrick H. Lauke wrote:

"Currently, the only way for a gamepad to be used as input would
be to
emulate mouse or keyboard events"

I'm wondering if it's in scope for this spec to also address the
situation where a UA *does* already do this natively (for
instance, IE
on Xbox One) - analog stick moving an on-screen mouse pointer, d-pad
firing cursor event.

A few precedents that may be worth looking at:

- Pointer Lock API http://www.w3.org/TR/__pointerlock/


- Opera's spatial navigation on TV browsers, which can be
preventDefault-ed if the website/app wants to handle d-pad input
(mapped
to cursor keys already, mind) on a remote control

http://dev.opera.com/articles/__view/functional-key-handling-__in-opera-device-sdk-based-tv-__browsers/#prevent-default




- Boxee's (discontinued) API to explicitly switch browser into
different
modes (cursor, keyboard, player)
http://developer.boxee.tv/__JavaScript_API#Browser_Modes


There's an argument that this should be left completely up to
the UA,
and that users should switch the UA into different modes.
However, at
the very least it would be nice then to have a way for a site/app to
*signal* that it can handle direct gamepad input.

Thoughts?

P



--
Patrick H. Lauke

www.splintered.co.uk  |
https://github.com/__patrickhlauke 
http://flickr.com/photos/__redux/ 
| http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke





--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

Re: Screen Orientation API Spec (from phrasing confusion)

[Mounir Lamouri]

On Fri, 14 Mar 2014, at 19:07, Lars Knudsen wrote:
> What happened to the initiative done to take a holistic view on all
> orientation related specs and make them seem like they come from the same
> entity (Device Motion, Media Queries, Orientation Lock, ...)?

Device Motion is about the device angle is space. Using the screen
orientation in addition of the device orientation could help developers
do cool things.

Media Queries is something very different and should ideally use Screen
Orientation as a base for its value. AFAIK, it currently knows about
'portrait' and 'landscape' in a way that is fully compatible with Screen
Orientation anyway.

> IMHO - please include different (hands on) developers on different levels
> to try out a spec before it goes out of draft.

I believe Mozilla is shipping this API prefixed since a long time and
might have feedback. It is also used by Firefox OS applications. It will
be soon an experimental API in Chrome Android.

-- Mounir

Re: [gamepad] preventing default/capturing controller

[Vincent Scheib]

Perhaps I'm missing some context. What issue are you raising that isn't
handled by the gamepad API [1]?

[1] https://dvcs.w3.org/hg/gamepad/raw-file/default/gamepad.html


On Fri, Mar 14, 2014 at 1:35 AM, Patrick H. Lauke wrote:

> No takers on the idea of having some form of control - like a gamepad
> capture lock, or some way of preventDefault-ing gamepad controls before
> they're turned into mouse/cursor controls by the UA?
>
>
> On 26/02/2014 10:16, Patrick H. Lauke wrote:
>
>> "Currently, the only way for a gamepad to be used as input would be to
>> emulate mouse or keyboard events"
>>
>> I'm wondering if it's in scope for this spec to also address the
>> situation where a UA *does* already do this natively (for instance, IE
>> on Xbox One) - analog stick moving an on-screen mouse pointer, d-pad
>> firing cursor event.
>>
>> A few precedents that may be worth looking at:
>>
>> - Pointer Lock API http://www.w3.org/TR/pointerlock/
>>
>> - Opera's spatial navigation on TV browsers, which can be
>> preventDefault-ed if the website/app wants to handle d-pad input (mapped
>> to cursor keys already, mind) on a remote control
>> http://dev.opera.com/articles/view/functional-key-handling-
>> in-opera-device-sdk-based-tv-browsers/#prevent-default
>>
>>
>> - Boxee's (discontinued) API to explicitly switch browser into different
>> modes (cursor, keyboard, player)
>> http://developer.boxee.tv/JavaScript_API#Browser_Modes
>>
>> There's an argument that this should be left completely up to the UA,
>> and that users should switch the UA into different modes. However, at
>> the very least it would be nice then to have a way for a site/app to
>> *signal* that it can handle direct gamepad input.
>>
>> Thoughts?
>>
>> P
>>
>
>
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>
>

Re: [admin] Mapping Blink Intent to {Implement,Ship} to Recommendation milestones? [Was: Re: Fwd: [blink-dev] Intent to implement: Push API]

[Peter Beverloo]

On Fri, Mar 14, 2014 at 2:23 PM, Arthur Barstow wrote:

> On 3/11/14 5:45 PM, ext Mounir Lamouri wrote:
>
>> FYI. For those not used to Blink's process, that doesn't mean the
>> feature is planning to ship yet but Google is working on this. The API
>> we are aiming for is a bit different from what the specification
>> currently describes as mentioned in the original message.
>>
>
> Thanks for this info Mounir.
>
> Since I'm one of "those", I'd like to understand if the Blink process has
> some type of mapping or considerations or guidelines re Intent to Implement
> and Intent to Ship vis-a-vis Recommendation milestones? Would you please
> elaborate on that or provide a link to such information?
>

An "Intent to Implement" can be seen as a heads-up to the Blink community
that someone is planning to work on implementing a certain feature. While
initial concerns and feedback can be raised at this time, no formal
approval is necessary to move forward. The goal of this stage is to inform
the Blink community of your plans, and begin raising consensus about the
given feature being a good idea. This does not necessarily mean that Blink
and/or Chromium agree with a specification -- this will often be outlined
in the intent.

An "Intent to Ship" follows when the implementation is (nearly) complete,
and the developers would like to move forward with enabling the feature by
default in Blink, and thereby Chromium and potential other Blink consumers.
This is where the Blink API owners, a group of people responsible for
enforcing that new features follow the project’s policies, need to approve
that this feature does follow the Blink guidelines, is in line with the
project's goals, and that the implementation is mature enough to be shipped
to end-users. Three API owners need to agree with shipping a feature before
this happens.

In regards to Recommendation milestones, an approved Intent to Ship means
that Blink considers the implementation to be mature enough, and that the
feature itself will be enabled by default in future releases of, say,
Chromium.

The process and compatibility guidelines are more carefully documented here:
  http://www.chromium.org/blink

Thanks,
Peter

Based on a quick scan of [blink-dev] for WebApps' specs, I noticed the
> following calls for input this month:
>
> * Shadow DOM - WD - Intent to Ship
> * Blob.close() - LC - Intent to Implement and Ship
> * Push API - WD - Intent to Implement
> * Gamepad API - WD - Intent to Ship
>
> -Thanks, ArtB
>
> [blink-dev]  blink-dev>
>
>
>

[admin] Mapping Blink Intent to {Implement,Ship} to Recommendation milestones? [Was: Re: Fwd: [blink-dev] Intent to implement: Push API]

[Arthur Barstow]

On 3/11/14 5:45 PM, ext Mounir Lamouri wrote:

FYI. For those not used to Blink's process, that doesn't mean the
feature is planning to ship yet but Google is working on this. The API
we are aiming for is a bit different from what the specification
currently describes as mentioned in the original message.


Thanks for this info Mounir.

Since I'm one of "those", I'd like to understand if the Blink process 
has some type of mapping or considerations or guidelines re Intent to 
Implement and Intent to Ship vis-a-vis Recommendation milestones? Would 
you please elaborate on that or provide a link to such information?


Based on a quick scan of [blink-dev] for WebApps' specs, I noticed the 
following calls for input this month:


* Shadow DOM - WD - Intent to Ship
* Blob.close() - LC - Intent to Implement and Ship
* Push API - WD - Intent to Implement
* Gamepad API - WD - Intent to Ship

-Thanks, ArtB

[blink-dev] 

Re: [screen-orientation] Remove the ability to lock to multiple orientations?

[Marcos Caceres]

On March 14, 2014 at 9:58:59 AM, Mounir Lamouri (mou...@lamouri.fr) wrote:
> On Fri, 14 Mar 2014, at 16:09, Jonas Sicking wrote:
> > However it does mean that we need to also have a way to define that
> > orientation should be completely unlocked. This is needed since the
> > manifest spec allows overriding the default unlocked orientation. I.e.
> > it should be possible to use the manifest to say that an app should be
> > in portrait mode, but then allow a page to temporarily override that
> > to allow any orientation.
>  
> Good point. I meant to mention that in the email but obviously forgot. I
> was wondering between ‘any’, ‘all' or 'sensor' (or 'sensor-all'? :)).

`any` should be fine. 

Re: [screen-orientation] Remove the ability to lock to multiple orientations?

[Kenneth Rohde Christiansen]

I agree, and it was also a surprise to me when I first noticed that. I
believe Wonsuk might know the history behind that decision.

Kenneth


On Fri, Mar 14, 2014 at 2:55 PM, Mounir Lamouri  wrote:

> On Fri, 14 Mar 2014, at 6:44, Kenneth Rohde Christiansen wrote:
> > I am cc'ing Wonsuk and Christophe as Tizen is currently implementing (and
> > shipping?) the API as well; it's even unprefixed.
> >
> > We are also supporting the current API in Crosswalk, but I am OK with the
> > change as most of our current users are using Android which doesn't allow
> > these specific locks.
>
> It is a bit surprising to see that API shipping un-prefixed given the
> current status of the specification.
>
> -- Mounir
>



-- 
Kenneth Rohde Christiansen
Web Platform Architect, Intel Corporation.
Phone  +45 4294 9458 ﹆﹆﹆

Re: [screen-orientation] Remove the ability to lock to multiple orientations?

[Mounir Lamouri]

On Fri, 14 Mar 2014, at 16:09, Jonas Sicking wrote:
> However it does mean that we need to also have a way to define that
> orientation should be completely unlocked. This is needed since the
> manifest spec allows overriding the default unlocked orientation. I.e.
> it should be possible to use the manifest to say that an app should be
> in portrait mode, but then allow a page to temporarily override that
> to allow any orientation.

Good point. I meant to mention that in the email but obviously forgot. I
was wondering between 'any', 'all' or 'sensor' (or 'sensor-all'? :)).

-- Mounir

Re: [screen-orientation] Remove the ability to lock to multiple orientations?

[Mounir Lamouri]

On Fri, 14 Mar 2014, at 6:44, Kenneth Rohde Christiansen wrote:
> I am cc'ing Wonsuk and Christophe as Tizen is currently implementing (and
> shipping?) the API as well; it's even unprefixed.
> 
> We are also supporting the current API in Crosswalk, but I am OK with the
> change as most of our current users are using Android which doesn't allow
> these specific locks.

It is a bit surprising to see that API shipping un-prefixed given the
current status of the specification.

-- Mounir

Re: [Editing] Splitting Selection API Into a Separate Specification

[Arthur Barstow]

On 3/13/14 7:43 PM, ext Ryosuke Niwa wrote:

Hi,

It appears that there is a lot of new features such as CSS regions and shadow 
DOM that have significant implications on selection API, and we really need a 
spec. for selection API these specifications can refer to.

Thankfully, Aryeh has done a great work writing the spec. for selection API as 
a part of HTML Editing APIs specification [1] but no browser vendor has been 
able to give meaningful feedback or has implemented the spec due to the 
inherent complexity in HTML editing.  As a result, the specification hasn't 
made much progress towards reaching Last Call or CR.

Given the situation, I think it's valuable to extract the parts of the spec 
that defines selection API into its own specification and move it forward in 
the standards process so that we can make it more interoperable between 
browsers, and let CSS regions, shadow DOM, and other specifications refer to 
the specification.

Any thoughts and opinions?


When we last discussed this spec vis-à-vis the Editing CG and WebApps 
[1], the CG's position was the spec was not ready for "Recommendation 
track work". As such, I would like to hear from Aryeh and/or the Editing 
CG re Ryosuke's proposal.


One factor to consider re WebApps formally working on this spec is 
whether there we have sufficient resource commitment(s) re editing, 
testing, etc. Do we have such commitment(s)?


-Thanks, AB

[1] 





[1] https://dvcs.w3.org/hg/editing/raw-file/tip/editing.html

- R. Niwa

indexedDB API grammatical error

[Danillo Paiva]

3.1.3 Keys

(...)

Operations that accept keys must perform as if each key parameter value, in
order, is copied *by the by the* structured clone algorithm [HTML5] and the
copy is instead used as input to the operation, before proceding with rest
of the operation.

Link: https://dvcs.w3.org/hg/IndexedDB/raw-file/tip/Overview.html



Att,
Danillo

[admin] Reminder: March 28 is Deadline to register for April 10-11 f2f meeting

[Arthur Barstow]

 Original Message 
Subject: 	[admin] Please register for WebApps 10-11 April 2014 f2f 
meeting; deadline March 28

Resent-Date:Mon, 17 Feb 2014 13:51:50 +
Resent-From:
Date:   Mon, 17 Feb 2014 08:50:41 -0500
From:   ext Arthur Barstow 
To: public-webapps 


Hi All,

The registration page for the WebApps' 10-11 April f2f meeting in San
Jose CA US is now open:



Please register for the meeting by March 28.

The meeting page follows. Please feel free to directly add proposed
topics or propose them on the list:

  

Thanks to Daniel Austin and eBay for hosting the meeting!

-AB

Re: [gamepad] preventing default/capturing controller

[Patrick H. Lauke]

No takers on the idea of having some form of control - like a gamepad 
capture lock, or some way of preventDefault-ing gamepad controls before 
they're turned into mouse/cursor controls by the UA?


On 26/02/2014 10:16, Patrick H. Lauke wrote:

"Currently, the only way for a gamepad to be used as input would be to
emulate mouse or keyboard events"

I'm wondering if it's in scope for this spec to also address the
situation where a UA *does* already do this natively (for instance, IE
on Xbox One) - analog stick moving an on-screen mouse pointer, d-pad
firing cursor event.

A few precedents that may be worth looking at:

- Pointer Lock API http://www.w3.org/TR/pointerlock/

- Opera's spatial navigation on TV browsers, which can be
preventDefault-ed if the website/app wants to handle d-pad input (mapped
to cursor keys already, mind) on a remote control
http://dev.opera.com/articles/view/functional-key-handling-in-opera-device-sdk-based-tv-browsers/#prevent-default


- Boxee's (discontinued) API to explicitly switch browser into different
modes (cursor, keyboard, player)
http://developer.boxee.tv/JavaScript_API#Browser_Modes

There's an argument that this should be left completely up to the UA,
and that users should switch the UA into different modes. However, at
the very least it would be nice then to have a way for a site/app to
*signal* that it can handle direct gamepad input.

Thoughts?

P



--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

Re: Screen Orientation API Spec (from phrasing confusion)

[Lars Knudsen]

What happened to the initiative done to take a holistic view on all
orientation related specs and make them seem like they come from the same
entity (Device Motion, Media Queries, Orientation Lock, ...)?

The confusion grows when we have e.g. different "primary" orientations
(landscape, portrait) - we had similar problems even inside a big handset
manufacturer, I worked with some years ago... within the same company but
in different branches.  How can we then expect avg joe developers out there
to know how to make their app support all devices on this little simple
thing?

IMHO - please include different (hands on) developers on different levels
to try out a spec before it goes out of draft.

br
Lars


On Thu, Mar 13, 2014 at 11:22 PM, Bruno Racineux  wrote:

>
> On 3/13/14 10:59 AM, "Mounir Lamouri"  wrote:
>
> >> http://msdn.microsoft.com/en-us/library/ie/dn433241(v=vs.85).aspx
> >>
> >> That seems to defeat the "normal orientation" aspect of the spec and the
> >> usefulness of '-primary' and '-secondary' suffixes "for the initial
> >> state".
> >
> >There is a bug on file to make the explanation a bit clearer:
> >https://www.w3.org/Bugs/Public/show_bug.cgi?id=24699
>
> I don't think you are getting my initial point of confusion in the spec.
> This would make it even more confusing than it already is.
>
> >The relation between -primary and -secondary should be up to the UA.
>
> You mean the *device* not the UA? Or else you are puzzling me.
> The spec said/says: "The concepts of primary orientation and secondary
> orientation depends on the device and the platform"; *not* the browser.
> Or is there a private draft I can't see saying the contrary now?
>
> >If Microsoft wants to give specific angles, why not.
>
> OK now you are *completely* losing me. Why not? What the heck do you mean?
> The current specification *has* a 90 degrees clockwise given angle which
> Microsoft *followed*.
>
> I have the feeling that neither Mozilla or Microsoft were able
> to fully make sense of the spec as you express it here, which as I
> specified, isn't fully understandable on its own terms.
>
> Again, in 3.1: "In both if the device is in landscape-primary and is
> rotated 90 degrees clockwise, that should be represented as
> portrait-primary." You are giving an angle, while referring to 'In both'
> of 2 previous opposite cases. That sentence is deprived of logic with:
> [In both] !== [if the device is in landscape-primary] in the same sentence.
>
> Microsoft's interpretation of that sentence is:
> [In both if the device is in x-primary and is rotated 90 degrees
> clockwise, that should be represented as x-primary.]
> As such Microsoft would be on spec but that's not what the spec says.
>
> While Mozilla seems to map it to fixed angles as per:
> http://mxr.mozilla.org/mozilla-central/source/widget/gonk/OrientationObserv
> er.cpp
>
> static OrientationMapping sOrientationMappings[] = {
>   {nsIScreen::ROTATION_0_DEG,   eScreenOrientation_PortraitPrimary},
>   {nsIScreen::ROTATION_180_DEG, eScreenOrientation_PortraitSecondary},
>   {nsIScreen::ROTATION_90_DEG,  eScreenOrientation_LandscapePrimary},
>   {nsIScreen::ROTATION_270_DEG, eScreenOrientation_LandscapeSecondary},
> };
>
> which sigh, doesn't match with my initial js implemention based on
> Microsoft's spec. That's a discrepancies already between the two
> prefixed implementations.
>
> I don't know how Tizen is interpreting the spec, but this need to be
> clarified before UAs ship it a unprefixed with their own take on it.
> Or this API is looking live a future living hell for developers.
>
> -Bruno
>
>
>
>