Re: Art steps down - thank you for everything

[Mounir Lamouri]

It has been a pleasure working with you Art. Your expertise, leadership
and diplomacy will be missed. I wish you the best for your future
endeavours!

-- Mounir

On Sat, 30 Jan 2016, at 12:29, Jungkee Song wrote:
> Thank you Art! It has been a great experience and joy working with you.
> Your calm leadership and warm support will be missed.
> 
> On Sat, Jan 30, 2016 at 4:18 AM, Alex Russell 
> wrote:
> 
> > Sorry to hear you're leaving us, Art. Your skills and humor will be missed.
> >
> > On Fri, Jan 29, 2016 at 7:51 AM, Philippe Le Hegaret  wrote:
> >
> >> Thank you Art.
> >>
> >> You carried out this group and community over so many years.
> >>
> >> Your first email to the AC was entitled "Just say NO?" as a response to a
> >> proposal from W3C. It will take a while for me to realize you won't be
> >> standing and come to the microphone to challenge us as you used to do for
> >> so many years.
> >>
> >> Philippe
> >>
> >>
> >> On 01/28/2016 10:45 AM, Chaals McCathie Nevile wrote:
> >>
> >>> Hi folks,
> >>>
> >>> as you may have noticed, Art has resigned as a co-chair of the Web
> >>> Platform group. He began chairing the Web Application Formats group
> >>> about a decade ago, became the leading co-chair when it merged with Web
> >>> APIs to become the Web Apps working group, and was instrumental in
> >>> making the transition from Web Apps to the Web Platform Group. (He also
> >>> chaired various other W3C groups in that time).
> >>>
> >>> I've been very privileged to work with Art on the webapps group for so
> >>> many years - as many of you know, without him it would have been a much
> >>> poorer group, and run much less smoothly. He did a great deal of work
> >>> for the group throughout his time as co-chair, efficiently, reliably,
> >>> and quietly.
> >>>
> >>> Now we are three co-chairs, we will work between us to fill Art's shoes.
> >>> It won't be easy.
> >>>
> >>> Thanks Art for everything you've done for the group for so long.
> >>>
> >>> Good luck, and I hope to see you around.
> >>>
> >>> Chaals
> >>>
> >>>
> >>
> >
> 
> 
> -- 
> 
> Jungkee Song

Re: [manifest] Manifest "background_color" with gradient?

[Mounir Lamouri]

On Thu, 15 Oct 2015, at 20:07, Binyamin wrote:
> בע"ה
> 
> 
> How about gradients in "background_color" (linear-gradient,
> radial-gradient, repeating-linear-gradient, repeating-radial-gradient)?
> Anything delays such spec/implementation?

The goal is to be able to paint something on the screen as soon as
possible. Using complex colours could make the task complex. For
example, Chrome Android uses the background_color information to create
an Android native View while Chrome is loading. Unless we can use
gradients with Android, we would need to re-implement gradients outside
of Blink.

-- Mounir

Re: [manifest] Manifest "splash_screens" with animated "any" size SVG

[Mounir Lamouri]

Domenic is right. The design of the splashscreen feature is to keep the
user experience smooth while Chrome loads its processes and get the
first bits to render on the screen.

-- Mounir

On Thu, 15 Oct 2015, at 20:14, Domenic Denicola wrote:
> I don’t know the details of the implementation at all, but I would
> imagine this would defeat the point. My guess as to why Chrome does
> things this way is to show something before they spin up an entire
> HTML/SVG/etc. rendering engine. During that time displaying an animated
> SVG is going to be impossible.
> 
> If you want an animated loading screen for your app, you should work on
> using techniques like service worker to make sure that the app is loaded
> as fast as possible from the cache API, and you can display your loading
> screen while you fetch fresh content from the network.
> 
> From: Binyamin [mailto:7rai...@inbox.lv]
> Sent: Thursday, October 15, 2015 15:08
> To: public-webapps@w3.org
> Cc: Mounir Lamouri <mou...@lamouri.fr>
> Subject: [manifest] Manifest "splash_screens" with animated "any" size
> SVG
> 
> בע"ה
> 
> Hi,
> 
> 
> Google recently has published icon support centered in splash screen in
> Chrome 47 requiring icon minimum size 196px,
> https://developers.google.com/web/updates/2015/10/splashscreen.
> 
> I propose instead "splash_screens" with animated SVG that could display
> loading process similarly to almost any this days Android/iOS-native apps
> like Skype, etc. Link to spec
> https://w3c.github.io/manifest/#splash_screens-member
> 
> {
> "src": "splashscreen.svg",
> "sizes": "any"
> }
> 
> 
> 
> Binyamin
> 

Re: [manifest] Manifest "sizes" fallback logic

[Mounir Lamouri]

Hi Binyamin,

Thank you for your question.

I think this behaviour should be left to the implementation there is a
lot of UI decisions here that can't be spec'd. For example, Chrome would
likely pick a 32x32 image when it needs a 16x16 one but might not do the
other way around. Some UA might avoid taking a 32x32 image instead of a
16x16 image because one is twice as big as the other and might not be
optimized to be seen as small. Obviously, all browsers should do a best
effort in picking an image.

-- Mounir

On Mon, 12 Oct 2015, at 21:01, Binyamin wrote:
> בע"ה
> 
> 
> Hi,
> 
> 
> Does "sizes" (https://w3c.github.io/manifest/#sizes-member) has any
> fallback for device required different icon sizes?
> 
> {
> "icons": [
> {
> "src": "32x32.png",
> "sizes": "32x32"
> }, {
> "src": "48x48.png",
> "sizes": "48x48"
> }, {
> "src": "128x128.png",
> "sizes": "128x128"
> }
> ]
> }
> 
> 1. For example, would device request for 16x16 return scaled down image
> 32x32.png?
> 2. What about request 40x40 - would it scale up 32x32.png or scale down
> 48x48.png (40x40 is in middle of both those sizes (+8 = 48, -8 = 32))?
> 3. Would request 96x96 use 128x128.png?
> 4. Would request 192x192 and 512x512 use 128x128.png?
> 
> 
> 
> Binyamin

Re: [manifest] Manifest "sizes" fallback logic

[Mounir Lamouri]

Having guidelines in the specification is something we can do but we
can't have any requirements in there because browser UI will ultimately
be up to the browser vendor. Web developers should be encouraged to have
various sized icons so a browser will be able to pick the best one
depending on its own requirements. For example, if Chrome needs a 48px
icon for the homescreen, it will not use a 40px icon instead. However,
if it needs a 256px icon, it might pick a 192px icon. These are purely
case by case UI decisions that the spec couldn't define rigorously.

-- Mounir

On Tue, 13 Oct 2015, at 10:07, Binyamin wrote:
> בע"ה
> 
> 
> Maybe lets define standard spec for it
> https://github.com/w3c/manifest/issues/409, so that every browser
> vendor/engine would know what is correct to do. For example lets help to
> decide to pick 32x32.png or 48x48.png while requiring missing 40x40
> size image.
> 
> 
> Binyamin
> 
> 
> On Tue, Oct 13, 2015 at 11:51 AM, Mounir Lamouri <mou...@lamouri.fr>
> wrote:
> 
> > Hi Binyamin,
> >
> > Thank you for your question.
> >
> > I think this behaviour should be left to the implementation there is a
> > lot of UI decisions here that can't be spec'd. For example, Chrome would
> > likely pick a 32x32 image when it needs a 16x16 one but might not do the
> > other way around. Some UA might avoid taking a 32x32 image instead of a
> > 16x16 image because one is twice as big as the other and might not be
> > optimized to be seen as small. Obviously, all browsers should do a best
> > effort in picking an image.
> >
> > -- Mounir
> >
> > On Mon, 12 Oct 2015, at 21:01, Binyamin wrote:
> > > בע"ה
> > >
> > >
> > > Hi,
> > >
> > >
> > > Does "sizes" (https://w3c.github.io/manifest/#sizes-member) has any
> > > fallback for device required different icon sizes?
> > >
> > > {
> > > "icons": [
> > > {
> > > "src": "32x32.png",
> > > "sizes": "32x32"
> > > }, {
> > > "src": "48x48.png",
> > > "sizes": "48x48"
> > > }, {
> > > "src": "128x128.png",
> > > "sizes": "128x128"
> > > }
> > > ]
> > > }
> > >
> > > 1. For example, would device request for 16x16 return scaled down image
> > > 32x32.png?
> > > 2. What about request 40x40 - would it scale up 32x32.png or scale down
> > > 48x48.png (40x40 is in middle of both those sizes (+8 = 48, -8 = 32))?
> > > 3. Would request 96x96 use 128x128.png?
> > > 4. Would request 192x192 and 512x512 use 128x128.png?
> > >
> > >
> > >
> > > Binyamin
> >

Re: Permissions API vs local APIs

[Mounir Lamouri]

On Wed, 6 May 2015, at 19:07, Doug Turner wrote:
 
  On May 6, 2015, at 11:00 AM, Jonas Sicking jo...@sicking.cc wrote:
  
  FWIW, the permission API as it currently stands is pretty trivial to
  implement. So I don't see a reason to delay until 2017 or even Q3
  2015.
 
 If the spec is ready to go (what’s anne’s worry), then lets implement it
 and remove the stuff from PushAPI.
 
 Marcos|Mounir, do you two have any thoughts on this?

I agree with Jonas: we should delegate the check to the Permissions API.
However, I don't see how I can enforce that if the Push API doesn't want
to. I would be more than happy to have the spec specify the
PermssionDescriptor for Push, FWIW.

-- Mounir

Standardizing autocapitalize

[Mounir Lamouri]

(bcc: public-webapps@)

Hi,

I would like to standardize the Apple's proprietary autocapitalize
attribute. This attribute is widely used and it would probably benefit
the platform to have a broader support for it. The implementation cost
should be fairly low while it can be very beneficial for the user
experience with the keyboard on Mobile.

I wrote a small proposal document based on Apple's document and live
tests on latest Safari mobile:
https://github.com/mounirlamouri/html-autocapitalize/blob/master/proposal.md

I would be really interested to hear from other vendors, particularly if
they would be interested to implement it.
In addition, if Apple has some feedback about the proposal, it would be
very valuable.

Thanks,
-- Mounir

Re: [manifest] I18N review in progress

[Mounir Lamouri]

Thank you for the report.

Internationalization is clearly one of the major next milestones for the
Manifest. As long as it only contains simple properties like name or
icons, i18n is a minor problem because often these properties are
fairly stable across locales - at least, even if we are aware of the
theoretical problem, we did not hear any feedback from developers.
Something they might do is to serve a Manifest depending on HTTP
headers.

However, when the Manifest will start to have more complex values like
maybe a web app description, it will require some i18n of some sort. One
solution we have been thinking about would be based on Mozilla's Open
Web App Manifest, see
https://developer.mozilla.org/en-US/Apps/Build/Manifest#locales

What would you think of this solution on a i18n POV?

Cheers,
-- Mounir

On Thu, 26 Feb 2015, at 16:54, Phillips, Addison wrote:
 Dear webapps,
 
 The Internationalization Working Group is reviewing [2] your
 specification Manifest for web application per your request [1]. We
 were unable to complete our review during this week's teleconference. Our
 next teleconference is scheduled for 5 March, which is your deadline for
 comments. This note is to let you know that we will have some comments
 for you.
 
 There are two concerns that I want to note in advance that perhaps you
 can clarify:
 
 1. There is no localization model or apparently a means of finding out
 about the availability of different languages of a given app, including
 alternate icons, names, short names and such. I'm curious as to whether
 there is an intention to provide this capability? What do authors of
 localized web applications do?
 
 2. There is no provision for language or bidirectional control for
 natural language text inside a manifest. For example, you can't tag the
 name of an app as being in Japanese (necessary for correct font selection
 by the host environment, for example) or to set the base direction of the
 name (so that mixed right-to-left and left-to-right text is drawn
 correctly).
 
 Thanks (for I18N),
 
 Addison
 
 [1]
 https://lists.w3.org/Archives/Public/www-international/2015JanMar/0067.html
 [2] https://www.w3.org/International/wiki/Review_radar 
 
 Addison Phillips
 Globalization Architect (Amazon Lab126)
 Chair (W3C I18N WG)
 
 Internationalization is not a feature.
 It is an architecture.
 

Re: New approach to activities/intents

[Mounir Lamouri]

(I realise that my reply went to public-webapps instead of whatwg, not
sure why. I will blame my email client :))

On Fri, 7 Nov 2014, at 20:36, Anne van Kesteren wrote:
  Wouldn't be worth experimenting first with a list of predefined share
  endpoints (that you anyway might want to have) and see if the feature is
  actually something that users are looking for?
 
 We have something like that in Firefox Nightly. Apple ships something
 similar in Safari. Both can be extended through proprietary APIs.

I think it would be great if Mozilla could keep track of the usage of
this feature and share that data.

  Furthermore, wouldn't
  that make sense to have a similar mechanism than Open Search and have a
  way for a website to advertise its share endpoint(s)? Maybe the Manifest
  could be a good use for that. Generally speaking, I see a lot of common
  aspects between Open Search and this proposal.
 
 Maybe. It would be even less flexible and depend even more on user
 interface innovation from the user agent.

I don't think the issue here is flexibility. It's extensibility. You
want website to be able to advertise themselves in that list. Thus,
websites will only try to do so if they see a benefit in doing that, in
other words, if that feature is actually used by Firefox users.

As a side note, I don't think that innovation always need to come from
new APIs. That feature sounds like a great opportunity to innovate
within the browser UI then iterate with an API.

-- Mounir

Re: New approach to activities/intents

[Mounir Lamouri]

On Tue, 4 Nov 2014, at 03:42, Anne van Kesteren wrote:
 A couple of us at Mozilla have been trying to figure out how to revive
 activities/intents for the web. Both work relatively well in closed
 environments such as Firefox OS and Android, but seem harder to deploy
 in a generic way on the web.
 
 What we've been looking at instead is solving a smaller use case. A
 Sharing API to start and then hopefully reuse the building blocks for
 other features that need to be liberated.
 
 https://wiki.whatwg.org/wiki/Sharing/API has a sketch for what a very
 minimal Sharing API could look like.
 
 Our thinking is that something like the overlay browsing context could
 be reused to make e.g. input type=file or save as extensible going
 forward.
 
 However, admittedly it still doesn't really click. It feels a bit too
 much like e.g. the various search extensions browsers offer. Too much
 work for little return. Furthermore, freeing the web somehow from
 closely knitted silos seems like a worthwhile goal, but is often
 counter to what those silos are interested in. So it might be that
 we're still not quite there yet, thoughts appreciated.

My understanding of the document is that a website can register itself
as a share endpoint but can't try to programmatically starts a share
action; instead, the user will use the browser UI to do so. Is that
correct? I assume also that the UA would show a UI requesting the user
whether they want to accept foo.com to be added as a share endpoint,
right?

Wouldn't be worth experimenting first with a list of predefined share
endpoints (that you anyway might want to have) and see if the feature is
actually something that users are looking for? Furthermore, wouldn't
that make sense to have a similar mechanism than Open Search and have a
way for a website to advertise its share endpoint(s)? Maybe the Manifest
could be a good use for that. Generally speaking, I see a lot of common
aspects between Open Search and this proposal.

-- Mounir

Re: CfC: publish LCWD of Screen Orientation API; deadline September 18

[Mounir Lamouri]

Can we at least publish a new WD so people stop referring to the old
TR/?

-- Mounir

On Wed, 1 Oct 2014, at 20:36, Arthur Barstow wrote:
 On 9/25/14 9:26 AM, Mounir Lamouri wrote:
  On Thu, 25 Sep 2014, at 21:52, Arthur Barstow wrote:
  On 9/25/14 6:36 AM, Anne van Kesteren wrote:
  It effectively comes down to the fact that the specification describes
  something, but Chrome implements it in another way per how I suggested
  it should work (using animation frame tasks).
  So this appears to be [Issue-40] and I think a one-line summary is the
  Editors consider this something that can be deferred to the next version
  and Anne considers it something that should be addressed before LC is
  published.
 
  Vis-a-vis this CfC, it seems the main options are:
 
  1. Continue to work on this issue with the goal of getting broader
  consensus on the resolution
 
  2. Publish the LC as is
 
  3. Publish the LC as is but explicitly highlight this Issue and ask
  for Implementer/Developer feedback
 
  4. Other options?
 
  Of course, I'd like to hear from others but I tend to think we should
  first try #1 (especially since Anne indicates the spec and at least one
  implementations are currently not aligned).
 
  Mounir, Marcos - would you please work with Anne on a mutually agreeable
  solution?
  Last I checked, animation frame task was still underdefined. This is
  what you can read in the WHATWG's fullscreen specification:
  Animation frame task is not really defined yet, including relative
  order within that task, see bug 26440.
 
  In my opinion, if the spec is changed to use animation frame task, it
  would not change much in the current state of things.
 
 Well, perhaps this would be true but the devil's in the details and 
 the details do matter (see below).
 
  Also, I'm not entirely sure why Anne is so loudly complaining about that
  issue. The issue was not closed or waived but postponed until we can
  properly hooked to the thing. LC doesn't freeze the specification and we
  could definitely get this fixed before moving to CR.
 
  What I suggested to him on IRC and what I believe is the best approach
  to reconcile the two worlds (WHATWG live standards and W3C snapshots) is
  to take the current version of the spec to LC and update the ED to use
  animation frame task and mark it as a WIP feature. I opened issue 75
  last week as a reminder to do that.
 
  Arthur, what do you think of that solution?
 
 We can certainly publish a LC with open issues (as was explicitly noted 
 in the original CfC [1]). However, I do want to emphasize that if any 
 substantive issue is filed after the LC is published, and the group 
 agrees to address any such issue(s), the group must publish another LC 
 before the spec can move to CR. I mention this because LC-LC loops 
 are time consuming for the group, implementers and developers and thus 
 should be avoided if possible. As such, it seems like pursuing #1 should 
 be the next step.
 
 -Thanks, AB
 
 

Re: CfC: publish LCWD of Screen Orientation API; deadline September 18

[Mounir Lamouri]

On Thu, 25 Sep 2014, at 23:26, Mounir Lamouri wrote:
 On Thu, 25 Sep 2014, at 21:52, Arthur Barstow wrote:
  On 9/25/14 6:36 AM, Anne van Kesteren wrote:
   It effectively comes down to the fact that the specification describes 
   something, but Chrome implements it in another way per how I suggested 
   it should work (using animation frame tasks). 
  
  So this appears to be [Issue-40] and I think a one-line summary is the 
  Editors consider this something that can be deferred to the next version 
  and Anne considers it something that should be addressed before LC is 
  published.
  
  Vis-a-vis this CfC, it seems the main options are:
  
  1. Continue to work on this issue with the goal of getting broader 
  consensus on the resolution
  
  2. Publish the LC as is
  
  3. Publish the LC as is but explicitly highlight this Issue and ask 
  for Implementer/Developer feedback
  
  4. Other options?
  
  Of course, I'd like to hear from others but I tend to think we should 
  first try #1 (especially since Anne indicates the spec and at least one 
  implementations are currently not aligned).
  
  Mounir, Marcos - would you please work with Anne on a mutually agreeable 
  solution?
 
 Last I checked, animation frame task was still underdefined. This is
 what you can read in the WHATWG's fullscreen specification:
 Animation frame task is not really defined yet, including relative
 order within that task, see bug 26440.
 
 In my opinion, if the spec is changed to use animation frame task, it
 would not change much in the current state of things.
 
 Also, I'm not entirely sure why Anne is so loudly complaining about that
 issue. The issue was not closed or waived but postponed until we can
 properly hooked to the thing. LC doesn't freeze the specification and we
 could definitely get this fixed before moving to CR.
 
 What I suggested to him on IRC and what I believe is the best approach
 to reconcile the two worlds (WHATWG live standards and W3C snapshots) is
 to take the current version of the spec to LC and update the ED to use
 animation frame task and mark it as a WIP feature. I opened issue 75
 last week as a reminder to do that.
 
 Arthur, what do you think of that solution?

Given the lack of answer, should we just go ahead and follow that plan?

-- Mounir

Re: CfC: publish LCWD of Screen Orientation API; deadline September 18

[Mounir Lamouri]

On Tue, 16 Sep 2014, at 08:28, Jonas Sicking wrote:
 I think it's likely to result in many implementation bugs if we rely
 on this being defined buried inside an algorithm rather than at least
 mentioned at the definition of the property.

I think it's good feedback. I could probably make this more visible.
Would you mind opening an issue marked as Enhancement and may go with
a proposal of what you believe would be easier to find. I don't want to
have you do the editor work but given that the problem isn't that the
information is missing but that it is not well exposed, fresh eyes would
be better to help with that ;)

-- Mounir

Re: Proposal for a Permissions API

[Mounir Lamouri]

On Tue, 16 Sep 2014, at 06:50, Frederick Hirsch wrote:
 [cross posted to DAP]
 
 I’d like to point out that work such as this would be allowed under the
 W3C Device APIs WG charter [1] if this is of interest (not being sure of
 current plans):

Arthur, would that work be aligned with the WebApps charter?

-- Mounir

Re: CfC: publish LCWD of Screen Orientation API; deadline September 18

[Mounir Lamouri]

On Fri, 12 Sep 2014, at 08:52, Jonas Sicking wrote:
 Sorry, my first comment is a naming bikeshed issue. Feel free to
 ignore as it's coming in late, but I hadn't thought of it until just
 now.

I remember a wise person who once said never count on me to bikeshed
names. I think he was named Jonas Sicking :)

 It's somewhat inconsistent that we use the term natural to indicate
 the most natural direction based on hardware, but we use the term
 primary when indicating the most natural portrait/landscape
 direction based on hardware.
 
 Why do we use primary for one and natural for the other?

natural and primary have very different meaning. There can be only
one natural orientation for a device, it's when angle = 0. However,
portrait-primary and portrait-secondary would depend of the context. For
example, I have two monitors in front of me. They are both in portrait
orientation but they could both have different angles, if that was the
case, one device would have angle = 90, one would have angle = 270 but I
would expect to both be portrait-primary.

 Second, I'm still very worried that people will interpret
 screen.orientation.angle=0 as portrait. I don't expect to be able to
 convince people here to remove the property. However I think it would
 be good to at least make it clear in the spec that the .angle property
 can not be used to detect portrait vs. landscape.
 
 A informative note in the description of the angle property saying
 something like:
 
 The value of this property is relative to the natural angle of the
 hardware. So for some devices angle will be 0 when the device is in
 landscape mode, and on other devices when the device is in portrait
 mode. Thus this property can not be used to detect landscape vs.
 portrait. The primary use case for this property is to enable doing
 conversions between coordinates relative to the screen and coordinates
 relative to the device (such as the ones returned from the
 DeviceOrientationEvent interface).
 
 In order to check if the device is in portrait or landscape mode,
 instead use the orientation.type property.

Isn't Best Practice 1: orientation.angle and orientation.type
relationship what you are looking for?

 Also, I can't find any normative definition of if orientation.angle
 should increase or decrease if the user rotates a device 90 degrees
 clockwise?

I believe you found the definition in the specification according to
your reply.

-- Mounir

Re: Proposal for a Permissions API

[Mounir Lamouri]

On Fri, 5 Sep 2014, at 03:23, Edward O'Connor wrote:
 We should be avoiding adding features to the platform that have to
 resort to explicit permissioning. Instead of adding features which
 require prompting for permission, we should be designing features—like
 drag  drop or input type=file—that don't require prompting for
 permission at all.

That is a pious wish that I can understand but it is unfortunately not
possible. Features like input type='file' are great features with
regards to security and permission: the user knows what is happening and
the developer is aware of the flow, it is consistent and reliable.
Generally speaking, I think most of us would agree that the picker flow
is good and should be used when possible.

This said, we cannot use that model all the time and there are many APIs
that are constantly implemented via a permission prompt. The Web
platform tried to stay away of that implementation detail for long but
this is unfortunately crippling Web applications way more than it
should.

Note that the Permissions API model isn't requiring all APIs to abide by
its model. Having no permissions at all for an API is a decent model if
possible. For example, having a permission concept for input
type='file' doesn't make much sense. Other APIs could use the
permission model but have some UA mostly returning 'granted' because
they have an opt-out model instead of opt-in, such as most
implementations of fullscreen.

-- Mounir

Re: Proposal for a Permissions API

[Mounir Lamouri]

On Thu, 4 Sep 2014, at 01:33, Kostiainen, Anssi wrote:
 Given there's good discussion going on at the Paris meeting right now [4]
 and the topic is on the agenda, I’m expecting more input from the meeting
 participants on how to proceed.

Could you share here the outcome of that discussion if not the minutes?

Thanks,
-- Mounir

Re: Proposal for a Permissions API

[Mounir Lamouri]

On Wed, 3 Sep 2014, at 04:41, Jonas Sicking wrote:
 I'm generally supportive of this direction.
 
 I'm not sure that that the PermissionStatus thing is needed. For
 example in order to support bluetooth is might be better to make the
 call look like:
 
 permissions.has(bluetooth, fitbit).then(...);

That's more Permission than PermissionStatus, right?

What you proposed here would probably be something like that in WebIDL:
Promise has(PermissionName name, any options);

But really, we could make that option bag be a dictionary because it
gives good context about what you are passing like what does fitbit
means here? Is that a black listed device or a white listed one? The one
you want to target?

I agree that it might be unusual to have a required name than might
often be used alone but it makes the API way more javascript-y and self
explanatory. IMO, this call is nicer to read than the one you wrote
above:
  permissions.has({ name: 'bluetooth', devices: 'fitbit' });
because I understand what the call is trying to do. In addition, as you
pointed, it gives a lot of flexibility.

On Wed, 3 Sep 2014, at 05:45, Boris Zbarsky wrote:
 On 9/2/14, 9:51 AM, Mounir Lamouri wrote:
 required PermissionName name;
 
 Glad to see required being put to good use.  ;)

Let say that required was added at the right time. My draft had this
odd requirement before ;)

  interface PermissionManager {
 
 IDL nit: This needs Exposed=(Window,Worker)
 
  [NoInterfaceObject, Exposed=Window,Worker]
 
 And parens.

The proposal in the document has been updated accordingly.

On Wed, 3 Sep 2014, at 07:10, Dave Raggett wrote:
 Have you considered making this return a promise, as per Nikhil's
 proposal:

It does. navigator.permissions.has({}) returns a
PromisePermissionStatus.

 p.s. I will bring your idea to the trust  permissions in the open web 
 platform meeting, we're holding in Paris this week, see:

Adrienne Felt from Chrome Security will be representing Google at that
meeting. She should be able to present the proposal and answer any
questions about it. It was on purpose sent before the meeting FWIW.

-- Mounir

Proposal for a Permissions API

[Mounir Lamouri]

TL;DR:
Permissions API would be a single entry point for a web page to check if
using API /foo/ would prompt, succeed or fail.

You can find the chromium.org design document in [1].

# Use case #

The APIs on the platform are lacking a way to check whether the user has
granted them. Except the Notifications API, there is no API that I know
of that expose such information (arguably, somehow, the Quota API does).
The platform now has a lot of APIs using permissions which is expressed
as permission prompts in all browsers. Without the ability for web pages
to know whether a call will prompt, succeeded or fail beforehand,
creating user experience on par with native applications is fairly hard.

# Straw man proposal #

This proposal is on purpose minimalistic and only contains features that
should have straight consensus and strong use cases, the linked document
[1] contains ideas of optional additions and list of retired ideas.

```
/* Note: WebIDL doesn’t allow partial enums so we might need to use a
DOMString
 * instead. The idea is that new API could extend the enum and add their
 own
 * entry.
 */
enum PermissionName {
};

/* Note: the idea is that some APIs would extend this dictionary to add
some
 * API-specific information like a “DOMString accuracy” for an
 hypothetical
 * geolocation api that would have different accuracy granularity.
 */
dictionary Permission {
  required PermissionName name;
};

/* Note: the name doesn’t matter, not exposed. */
enum PermissionState {
  // If the capability can be used without having to ask the user for a
  yes/no
  // question. In other words, if the developer can’t ask the user in
  advance
  // whether he/she wants the web page to access the feature. A feature
  using a
  // chooser UI is always ‘granted’.
  “granted”,
  // If the capability can’t be used at all and trying it will be a
  no-op.
  “denied”,
  // If trying to use the capability will be followed by a question to
  the user
  // asking whether he/she wants to allow the web page to be granted the
  // access and that question will no longer appear for the subsequent
  calls if
  // it was answered the first time.
  “prompt”
};

dictionary PermissionStatus : Permission {
  PermissionState status;
};

/* Note: the promises would be rejected iff the Permission isn’t known
or 
 * misformatted.
 */
interface PermissionManager {
  PromisePermissionStatus has(Permission permission);
};

[NoInterfaceObject, Exposed=Window,Worker]
interface NavigatorPermissions {
  readonly attribute PermissionManager permissions;
};

Navigator implements NavigatorPermissions;
WorkerNavigator implements NavigatorPermissions;
```

The intent behind using dictionaries is to simplify the usage and
increase flexibility. It would be easy for an API to inherit from
Permission to define new properties. For example, a Bluetooth API could
have different permissions for different devices or a Geolocation API
could have different level of accuracies. See [1] for more details.

WDYT?

[1]
https://docs.google.com/a/chromium.org/document/d/12xnZ_8P6rTpcGxBHiDPPCe7AUyCar-ndg8lh2KwMYkM/preview

-- Mounir

Re: Screen Orientation Feedback

[Mounir Lamouri]

+ri...@opera.com

On Wed, 6 Aug 2014, at 07:14, Jonas Sicking wrote:
 Hi All,
 
 I think the current interaction between the screen orientation and
 device orientation specs is really unfortunate.
 
 Any time that you use the device orientation in order to render
 something on screen, you have to do non-obvious math in order to get
 coordinates which are usable. Same thing if you want to use the device
 orientation events as input for objects which are rendered on screen.
 
 I would argue that these are the by far most common use cases for
 
 I agree that the main problem here is that the deviceorientation spec
 defined that their events should be relative to the device rather than
 to the screen. However we can still fix the problem by simply adding
 
 partial interface DeviceOrientationEvent
 {
   readonly attribute double? screenAlpha;
   readonly attribute double? screenBeta;
   readonly attribute double? screenGamma;
 }
 
 No new events needs to be defined.
 
 I guess we can argue that this should be added to the
 DeviceOrientation spec, but that seems unlikely to happen in practice
 anytime soon. I think we would do developers a disservice by blaming
 procedural issues rather than trying to solve the problem.
 
 I think mozilla would be happy to implement such an addition to the
 DeviceOrientation event (I'm currently checking to make sure). Are
 there other UAs that have opinions (positive or negative) to such an
 addition?

Maybe this feedback should be more for DeviceOrientation than Screen
Orientation. There has been a few discussions there
(public-geolocation).

Anyway. I am not convinced that adding new properties will really fix
how developers handle this. I asked around and it seems that native
platforms do not expose Device Orientation relative to the screen. I am
not sure why we should expose something different on the Web platform. I
think we should work on providing developers the right tools in order
for them to do the right thing. For example, without the Screen
Orientation API, they do not know the relative angle between the device
natural orientation and the screen. This API is not yet widely
available. Some version of it ships in Firefox and IE but is prefixed.
It should be in Chrome Beta soon.

In addition, Tim Volodine recently suggested (in public-geolocation)
that we could add a quaternion representation of the device orientation.
If we could introduce quaternions to the platform and offer tools to do
simple math operations on them, we could narrow the complexity of going
from the device origin to the screen origin to one operation.

Finally, my understanding is that the biggest problem with
DeviceOrientation isn't that the orientation is relative to the device
instead of the screen but the rather high incompatibility. Rich Tibbett
made a great VR demo [1] using DeviceOrientation. I had the chance to
chat with him and he told me that he faced a lot of problems with angles
being very different depending on the device, and the browser. Actually,
I tried to show the demo to a colleague a few days after on an old Nexus
7 and it was completely busted.

The number one problem we should tackle with DeviceOrientation is the
interop issue. The API is currently worthless because if you write it
for one browser on one device, the chance of it working as expected on
another device or browser are fairly low. It is a shame for example that
even Chrome and Firefox running on Android do not have full
interoperability. We should start by working together toward a fully
interoperable implementation (at least for browsers running on Android).
Then we should figure out why some devices are outliers.

[1] http://richtr.github.io/threeVR/examples/vr_basic.html

-- Mounir

Re: [Screen Orientation] Best Practice wording comment

[Mounir Lamouri]

On Fri, 25 Jul 2014, at 14:34, Bruno Racineux wrote:
 Just took a peak at the latest spec [1], since Chrome Canary breaks my
 code
 made for the previous spec
 and I have to update to a dual screen.orientation object|string context
 (It
 was previously a string).
 
 Good to see the new 'natural' keyword and angles.
 
 1. One minor comment on the Best Practice 1 box for the phrase:
 Never assume any kind of relationship between the screen orientation
 type
 and the screen orientation angle
 
 Any kind seems too strong a statement, since there is a relationship
 between type and angle during the length of a browsing context/runtime as
 mentioned afterwards.
 
 I suggest adding a permanent relationship qualification and/or
 cross-devices dimension in that sentence.

Fixed:
https://github.com/w3c/screen-orientation/commit/d1adfa1b1419d534c8b124331a70c7a322451008

 2. I am noting that the definition 1 and 2 of reading current screen
 orientation type is going to require that IEMobile and iOS change the
 reporting of their current screen.width and screen.height to the correct
 orientation, and stop reporting portrait only. I suppose that's a good
 thing
 even if it might break a few scripts.

Do you mean that they do not update the screen.width and screen.height
when the screen rotates?

-- Mounir

Re: WebIDL Spec Status

[Mounir Lamouri]

On Tue, 24 Jun 2014, at 10:45, Glenn Adams wrote:
 On Mon, Jun 23, 2014 at 3:05 PM, Marcos mar...@marcosc.com wrote:
  Even if we were able to take the V1 bits to Rec (a lot of which is now
  obsolete), the V2 stuff is already widely supported and heavily relied on
  by browser vendors. IMO, it's a waste of everyone's time to try to maintain
  multiple versions.
 
 
 I agree that the V1 CR should be abandoned or replaced with a completed
 snapshot of V2. Though it would be useful to ask a wider community about
 the value of moving some flavor of V1 to REC.

What's the benefits from having a REC based on v1 even if we know it is
already obsolete?

-- Mounir

Re: WebApp installation via the browser

[Mounir Lamouri]

On Sat, 31 May 2014, at 10:40, Jeffrey Walton wrote:
 I have a question about Use Cases for Installable WebApps located at
 https://w3c-webmob.github.io/installable-webapps/.
 
 Under section Add to Homescreen, the document states:
 
 ... giving developers the choice to tightly integrate their web
 applications into the OS directly from the Web browser is
 still somewhat new...
 
 ... [Installable WebApps] are different in that the
 applications are installed directly from the browser itself
 rather than from an app store...
 
 It sounds like to me the idea is to allow any site on the internet to
 become a app store. My observations are the various app stores provide
 vendor lock-in and ensure a revenue stream. Its architected into the
 platform. Companies like Apple, Microsoft and RIM likely *won't* give
 up lock-in or the revenue stream (at least not without a fight).
 
 Are there any platforms providing the feature? Has the feature gained
 any traction among the platform vendors?

Isn't Add to homescreen feature something you can find in a more or
less advanced fashion on Safari iOS, Firefox Android, Firefox OS and
Chrome Android? I believe IE had something similar some time ago on
desktop but I don't know what's the current status of that. Chrome Apps
is also doing some experiments on desktop [1].

[1] https://plus.google.com/+FrancoisBeaufort/posts/74WCmneFJ8j

-- Mounir

Re: [manifest] Fetching restriction, Re: [manifest] Update and call for review

[Mounir Lamouri]

On Wed, 28 May 2014, at 8:59, Jonas Sicking wrote:
 On Tue, May 27, 2014 at 12:39 PM, Marcos Caceres w...@marcosc.com wrote:
 
 
  On May 27, 2014 at 2:30:32 PM, Jonas Sicking (jo...@sicking.cc) wrote:
  On Tue, May 27, 2014 at 9:11 AM, Marcos Caceres wrote:
   The only way that gmail would allow my own app store to use its 
   manifest would be for
  Google to include the HTTP header:
  
   Access-Control-Allow-Origin: http://myownappstore.com;
 
  This is a bit of an abuse of CORS.
 
  hmmm... I thought this was *exactly* the point of having the 
  *-Allow-Origin header (restrict sharing to the domains the server chooses 
  in browsers).
 
  Adding an
  Access-Control-Allow-Origin: * header currently has the semantic
  meaning of any website can read the contents of this file. I.e. it
  only means that the bits in the file are accessible from other
  websites.
 
  Yep. The point was that combined with the `start_url` member, you can make 
  install pages away from the origin where the application resides.
 
  That means that for a webserver on the public internet it is currently
  always safe to add the Access-Control-Allow-Origin: * header to any
  file since all files can be read anyway by simply using a different
  HTTP client than a browser, such as wget.
 
  Sure. But that's not the point here. The use of CORS here is to control who 
  can do what within the context of the browser (as the policy enforcement 
  point). Of course, anyone can just go and download  anything with wget or 
  whatever - but that's not going to give that person a web app with the 
  manifest applied.
 
 So let's start by asking this: What are you trying to protect against
 by using CORS at all? Rather than using the policy that img uses.
 
 If the *only* thing you are trying to protect is the actual bytes in
 the manifest itself, then CORS is indeed the right solution.

This is exactly what I was going to ask: I'm not sure what is the
benefit of CORS restricted manifest fetching if we allow the manifest
start_url to point to a cross origin URL. As is, the manifest doesn't
contain sensitive data. It is only metadata that aren't user-specific
and should be fairly public (at least as public as the website is). In
that regards, the only benefit from enforcing CORS restrictions on the
manifest fetching I think is to be safe and future-proof (if the
manifest ends up having sensitive stuff in it, we don't need to break
all the things).

This said, I think that start_url should be same origin as the manifest.
It sounds very odd to navigator to foo.com, fetch foo.com/manifest.json
and then ends up going to bar.com when I try to navigate again to the
foo.com page via my bookmark. It might not make much sense for the user
and the confusion could lead to attach scenarios. I would be more
comfortable to have everything in the manifest being same origin as the
manifest itself.

Then, it might make sense to have the manifest same origin as the web
page because obviously making start_url same origin as the manifest
would be moot if the manifest doesn't have to be same origin with the
web page ;)

-- Mounir

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

[Mounir Lamouri]

On Thu, 1 May 2014, at 21:38, Arthur Barstow wrote:
 On 4/30/14 1:19 PM, Mounir Lamouri wrote:
  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 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.
  I believe this will be the WebApps team including Marcos and I for the
  moment:
  https://github.com/orgs/w3c/teams/webapps
 
 Cindy - it appears Mounir is asking to create a new WebApps team i.e. 
 https://github.com/orgs/w3c/teams/WebApps and to include him (I don't 
 know Mounir's GH uname), Marcos (marcosc), Eudardo (efullea) and Bryan 
 (blsaws).  Mounir - is this correct?

Not exactly. There is already a WebApps team with Marcos and I. Eduardo
and Bryan might need to be added.

-- Mounir

Re: Should events be preferably sent to the Window or the nearest object?

[Mounir Lamouri]

On Thu, 10 Apr 2014, at 0:01, Arthur Barstow wrote:
 Perhaps it would be good then to file a bug for the Screen Orientation 
 spec and/or to add a related note to the ED. WDYT?

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

-- Mounir

Re: Screen Orientation Status

[Mounir Lamouri]

On Tue, 8 Apr 2014, at 9:08, Bruno Racineux wrote:
 On https://www.w3.org/Bugs/Public/show_bug.cgi?id=25088 :
 
 You cannot fire on window without also having the window.orientation
 property (with its own issues*). That would break existing code relying
 on
 the webkit api (expecting to read a value on window.orientation).

I understand your concerns. Blink is implementing the legacy Webkit
window.orientation API so we will definitely send feedback here, and the
specification will be modified accordingly if we can't implement this
wrt backward compatibility.

 I am not sure, I was able to get my point across previously, for lack of
 feedback on it, but I strongly believe that mixing 'device' orientation
 and 'screen' orientation is a mistake going forward and important point.
 
 In the not so distant future, we will likely use screens 'attached'
 to mobile devices. In that, the screen will be entirely independent from
 the mobile table/phone/watch/etc.
 
 Sample use case:
 Let's imagine an ipad like 'iScreen' plugged to an iPad with dual screen
 capability with two different browser viewport on each screen.  When the
 iPad rotates, it shall only fire for the iPad screen, not the external
 iScreen if the later doesn't rotate, and vice-versa.
 
 How will you differentiate those two from an implementation standpoint?
 I have no idea how that goes, but I'd like to raise that question.

I don't think the specification should handle multi-screen scenarios
explicitly given that window.screen doesn't and the Web usually doesn't
too. However, we should make sure that we actually match window.screen
so I will change the specification to make sure the screen is the
output device. That way, we should get consistency between the values
of window.screen and window.screen.orientation.

Note that if you are interested in the scenarios you are mentioning, you
might want to have a look at the webscreens CG.

-- Mounir

Re: Should events be preferably sent to the Window or the nearest object?

[Mounir Lamouri]

On Tue, 8 Apr 2014, at 8:37, Ian Hickson wrote:
 On Mon, 7 Apr 2014, Marcos Caceres wrote:
  On March 20, 2014 at 2:30:55 PM, Marcos Caceres (w...@marcosc.com) wrote:
   On March 20, 2014 at 12:58:44 PM, Tab Atkins Jr. wrote:
Agreed. The exact target isn't very important here, and so being 
consistent with legacy event firing for the same system is probably 
a good idea.
  
   Agree. Let's go with consistency, even though it feels a bit weird.
  
  Ian, would it be possible to have some kind of hook in HTML to give us 
  this behaviour for free? 
  
  That is, given an event handler IDL attribute on some interface, we get 
  the HTML attribute equivalent on body element (all wired up and ready to 
  be used). That would be useful in that we wouldn't need to define the 
  HTML onorientationchange attribute in the Orientation Lock spec (and all 
  future specs). This could really help with consistency.  
 
 I'm very happy to add any such attributes to the HTML spec, just file a 
 bug once you're confident that it won't change.

When we will be in LC and close to CR, I will file a bug to remove the
monkey patching I am doing on the HTML spec.

-- Mounir

Screen Orientation Status

[Mounir Lamouri]

Hi,

I have just updated the specification WD, solving most of the
outstanding issues:
https://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html (it
is hot off the press, be gentle with typos and nits)

There are now only two outstanding bugs now:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25053
https://www.w3.org/Bugs/Public/show_bug.cgi?id=25054

I have an idea on how to handle them but I would like to discuss those
during the F2F next week.

Implementation status:
- Implemented and shipped prefixed in Firefox Desktop, Firefox Mobile
and Firefox OS;
- Implemented and shipped prefixed in IE11 Mobile;
- Currently being implemented in Blink for Chrome Android
(implementation match current ED).

Note: the implementations are not compatible with the current ED but no
implementer raised concerns about the changes when discussed here.

Path to LC:
Unless there are new outstanding issues being raised, I would like to go
to LC when the two bugs above are fixed. Hopefully just after the F2F.

Test suite:
None yet. No test suite coordinator at the moment.

Thanks,
-- Mounir

Should events be preferably sent to the Window or the nearest object?

[Mounir Lamouri]

Hi,

I would love to gather the opinion of public-webapps on a discussion
Hixie and I had for two different APIs recently: if an array |foo| can
change, should the change event be fired on its parent or the window
(its grandparent)? The two cases we discussed with Hixie were
navigator.languages and screen.orientation for which Hixie thinks the
change events should be fired on the window so developers can do body
onlanguagechange=... onorientationchange=... but I feel that having
the change event sent on the parent would make things more
self-contained.

I would love to hear people's opinion on this.

(Note: sending an orientationchange event to the window object would
have other implications because there is a proprietary API that does
that but this is entirely orthogonal.)

Thanks,
-- Mounir

Re: Push API - use parameterized Promise types

[Mounir Lamouri]

On Fri, 21 Mar 2014, at 2:28, Michael van Ouwerkerk wrote:
 In WebIDL we can now use parameterized Promise types:
 http://heycam.github.io/webidl/#idl-promise
 
 My suggestion is that we make some minor changes in the Push API spec to
 take advantage of this. It reads much better and the prose can be
 simplified.
 
 The following promise types:
 
 interface PushManager {
 Promise register ();
 Promise unregister (DOMString pushRegistrationId);
 Promise registrations ();
 };
 
 Can be changed like this:
 
 interface PushManager {
 PromisePushRegistration register ();
 PromiseDOMString unregister (DOMString pushRegistrationId);
 PromisePushRegistration[] registrations ();
 };
 
 What do you think?

I wrote a quick patch for Respec (the tool being used for a few spec,
including that one) so it will correctly recognize parameterized
Promise: https://github.com/darobin/respec/pull/299 It's far from
perfect but hopefully Robin et al will help fix this quickly.

-- 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: [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 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: [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 w...@marcosc.com 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: [push-api] Dependency on System Messages

[Mounir Lamouri]

On Thu, 13 Mar 2014, at 22:45, SULLIVAN, BRYAN L wrote:
 One of the other changes in progress is to include service workers on the
 design of the API. I don't know if that replaces system messages in total
 but the necessary changes will be considered when a new draft is
 submitted.

System Messages are definitely abandoned, I do not think any
specification should use them. Even in SysApps, we started working on
something called Event Pages (similar to what Chrome Apps does) before
Service Worker took off.

-- Mounir

Re: Screen Orientation API Spec (from phrasing confusion)

[Mounir Lamouri]

On Sun, 23 Feb 2014, at 20:12, Bruno Racineux wrote:
 Unless I am missing, something my current issue with screen.orientation
 is
 that it does not actually specify which is the natural orientation
 right
 away, UNLESS the device is rotated once. Is this really by design?
 Ref. again: 
 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

The relation between -primary and -secondary should be up to the UA. If
Microsoft wants to give specific angles, why not. As pointed in another
thread in this mailing list, I am planning to add an angle information
to the API.

 On Wed, Nov 6, 2013, at 11:17, Jonas Sicking wrote:
  Last I looked the property was useless because window.orientation=0
  meant different things on different devices. I.e. on some devices it
  meant landscape mode and others it meant portrait mode.
 
 It's not completely useless because one can tell the initial orientation
 by other means. (either media queries or deduction from screen
 width/height)
 
 As per Mounir, 0 indicates the natural orientation, which
 screen.orientation lacks as best illustrated by M. Gifford:
 http://www.matthewgifford.com/blog/2011/12/22/a-misconception-about-window-
 orientation/
 
 Based on the above, the implied official specs of window.orientation is
 quite consistent with legacy implementations.

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|.

 So unless webcompat at some point requiring it, I don't see us adding it.
 
 I think it should be, because the screen orientation API lack the
 'natural' orientation, at the moment anyway. I was actually trying to
 somehow polyfill the [0,90,-90,180] of window.orientation with
 screen.orientation. But I cannot account for the 0 (normal orientation)
 due to the initial orientation value having two definitions. :\
 
 And honestly with screen.orientation, I currently have to write 12 lines
 of code to deduct whether the device was turned left of right, from the
 initial state, as opposed to the more straight forward window.orientation
 for that particular goal.

Your use case will be taken care of, see this bug:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24698

 On Wed, 06 Nov 2013 11:27:08,Mounir Lamouri wrote:
 Indeed, if I remember correctly, window.orientation=0 is the natural
 orientation and then, the value is the angle between the current
 orientation and the natural one in the range ] -180 ; 180 ].
 
 Mounir, note that there is no -180 angle, as far as I know.
 
 I think that -180 only applies to DeviceOrientation Events.

That's correct. That's why I wrote ] -180; 180 ] instead of [ -180; 180
] ;)

-- Mounir

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

[Mounir Lamouri]

Hi,

I would like to change the Screen Orientation API to make the locking
steps a bit simpler. Currently, the API tries to be flexible and allow
locking to any combination of values like portrait, landscape,
portrait-primary but also [ portrait, landscape-primary ], [
portrait-primary, landscape-primary ]. The three first orientations
are very common. The others are pretty odd and I doubt I ever saw that
in the wild.

Allowing to pass an array of orientation has a lot of impact on the
specification:
- given that the combinations are pretty exotic, we should assume that
some UA will not be able to lock because the system will not allow it
[1];
- we have the problem of whether all the items in the array should be
available or only one of them to work. The specifacation currently
answer the question of whether portrait = [ portrait-primary,
portrait-secondary ] but what about [ landscape-primary,
portrait-primary ].

Removing this feature will allow the specification to enforce that all
states are working because it is fair to assume that the system will not
block the UA to lock to those basic orientations. In addition, this
would be a future-compatible change in the sense that adding this later
will be smooth. I am really eager to make the specification a bit less
flexible because right now, implementing this specification without
being able to lock would be following the specification.

I am particularly interested to hear feedback from Microsoft and Mozilla
who have prefixed implementations. I know that Firefox Android only
allows the basic orientations but Firefox OS allows any orientation to
be passed I believed [2]. I unfortunately can't test IE11 on mobile.

[1] Very likely, any UA could simply re-write the mechanism that listen
for device orientation changes and do manual screen locking based on
that, though...
[2]
http://mxr.mozilla.org/mozilla-central/source/widget/gonk/OrientationObserver.cpp

-- Mounir

Fwd: [blink-dev] Intent to implement: Push API

[Mounir Lamouri]

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.

Cheers,
-- Mounir

- Original message -
From: Michael van Ouwerkerk mvanouwerk...@google.com
To: blink-dev blink-...@chromium.org, John Mellor
joh...@chromium.org
Subject: [blink-dev] Intent to implement: Push API
Date: Wed, 5 Mar 2014 18:00:44 +

Contact emails

mvanouwerk...@chromium.org, joh...@chromium.org

Spec

https://dvcs.w3.org/hg/push/raw-file/tip/index.html

Summary

Provides a way for a web app to receive push messages from the app
server.
We are working with the spec editor to make this work based on Service
Workers. When a message is received, an event will be fired in a Service
Worker. The SW will be brought up if it is not yet running.

Motivation

This system enables communication from server to page (via a Service
Worker) even when the page is not running. This new capability is a
popular
request from web developers.

An example use case would be an email app that receives a push message
about a new email in the background. Messages can have a limited
payload,
or data can be fetched in the background in response to the push
message.

Compatibility Risk

Medium.

There is an implementation of an early version of the specification in
Firefox OS:
https://developer.mozilla.org/en-US/docs/Web/API/Navigator.push

The Push API has a dependency on ServiceWorker:
https://github.com/slightlyoff/ServiceWorker/ - its implementation in
Blink/Chromium and standardization are incomplete but making good
progress.

We expect to make some changes in the Push API specification based on
implementation experience.

Ongoing technical constraints

None.

Will this feature be supported on all five Blink platforms (Windows,
Mac,
Linux, Chrome OS and Android)?

Yes. On Android, we will integrate this with the GCM framework in Java.
On
all other platforms, we will generalize the infrastructure that is
already
in place for Chrome apps and extensions.

OWP launch tracking bug?

https://code.google.com/p/chromium/issues/detail?id=349474

Link to entry on the feature dashboard http://www.chromestatus.com/

http://www.chromestatus.com/features/5416033485586432

Requesting approval to ship?

No.

To unsubscribe from this group and stop receiving emails from it, send
an email to blink-dev+unsubscr...@chromium.org.

PSA: new Screen Orientation WD

[Mounir Lamouri]

Hi,

Arthur pointed out that the Screen Orientation API WD was not updated
since a long time. However, the ED got a few updates so we would like to
refresh the WD to have a better reflection of the current state of the
implementation.

You can find the current specification at:
http://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html

Also, have a look at the commits in the mercurial repository if you want
to know what happened since the last WD:
https://dvcs.w3.org/hg/screen-orientation/shortlog
Any change in the last 12 months would be new to this WD (20-25
changes).

The target date for the new WD is the 20th of February.

Thanks,
--
Mounir

Re: Officially deprecating main-thread synchronous XHR?

[Mounir Lamouri]

On Sat, 8 Feb 2014, at 12:19, James Greene wrote:
 There are certain situations where sync XHRs are, in fact, required...
 unless we make other accommodations. For example, in the Clipboard API,
 developers are allowed to inject into the clipboard as a semi-trusted
 event
 during the event handling phase of certain user-initiated events (e.g.
 `click`).[1]  This has not yet been implemented in any browsers yet.
 
 However, if browser vendors choose to treat this scenario as it is
 treated
 for Flash clipboard injection, then the semi-trusted state ends after the
 default action for that event would occur.[2]
 
 For Flash clipboard injection, this means that any required on-demand
 XHRs must be resolved synchronously. For the DOM Clipboard API, it would
 be
 nice to either still be able to use sync XHRs or else we would need to
 specially authorize async XHRs that are started during the semi-trusted
 state to have their completion handlers also still resolve/execute in a
 semi-trusted state.

Couldn't the semi-trusted state be kept for any promise created while
the semi-trusted is set? In other words, promises could keep the
semi-trusted state along the chaining. Though, as Olli said, this is
something the Clipboard API specification should fix.

-- Mounir

Re: [manifest] HTTP-based solution for loading manifests

[Mounir Lamouri]

On Wed, Dec 11, 2013, at 14:48, Marcos Caceres wrote:
 Would any potential implementer consider supporting a HTTP based solution
 to loading manifests? 

It seems quite premature to discuss a HTTP based solution to advertise a
manifest. Even if it happens to be something developers ask for, we will
anyway need to provide a link solution. It seems that the best course
of actions we could take here is to implement the manifest feature using
link and gather developer feedback to evaluate that alternative.
Unless Jonas' concerns are that the manifest adoption could be strongly
limited because of the lack of that feature?

--
Mounir

Re: New manifest spec - ready for FPWD?

[Mounir Lamouri]

On Wed, Dec 4, 2013, at 10:03, Marcos Caceres wrote:
 From the research we’ve done, none of the proprietary solutions currently
 do this. I’ve added this as a feature request [1] so we can see how much
 interest there is.  

I think it is exaggerated to say that pages rely on the user seeing the
page title. It is very uncommon to be able to read more than a couple of
words and depending on your browser/system you might not even see the
page title at all (the case for me because I rarely have less than a
dozen tabs open). I think the back button and reload buttons might be
critical to be able to run some apps while the page title is simply a
nice to have.

--
Mounir

Re: inline declarative manifest, was Re: New manifest spec - ready for FPWD?

[Mounir Lamouri]

On Mon, Dec 9, 2013, at 20:33, Yoav Weiss wrote:
 IMO, it might be better not to define an explicit way to inline the
 manifest, and let authors simply use data URIs to do that, if they see
 such
 a need.
 e.g.  link rel=manifest href=data:application/manifest+json,{ ... }
 
 If this becomes a common authoring pattern, an explicit mechanism might
 be
 a good fit. Otherwise, there may not be a need.

Sounds like a good plan to me.

-- Mounir

Re: inline declarative manifest, was Re: New manifest spec - ready for FPWD?

[Mounir Lamouri]

On Thu, Dec 5, 2013, at 6:06, Jonas Sicking wrote:
 On Dec 4, 2013 6:20 AM, Henri Sivonen hsivo...@hsivonen.fi wrote:
   meta name=manifest content='{
   a: 1,
   b: foopy
   }'
 
  Are manifests really short enough for this kind of thing?
 
 For single-page apps I would imagine it will be quite simple yes. Not
 quite
 as short as the above, but will reasonable to type.
 
 Additionally, since no extra escaping is done, you are not typing more
 than
 what you'd type into the external file anyway.

I do not think it is correct to assume that single page apps will have
shorter or simpler manifests. But as you said, this solution does not
have much overhead regarding typing or syntax.

However, using an inlined manifest comes with a cost: web crawlers or
app stores will no longer be able to fetch a simple file to know about
updates but will have to download the entire application.

-- Mounir

Re: Browser search API

[Mounir Lamouri]

On Thu, Dec 5, 2013, at 2:08, Mitar wrote:
 But I agree, that requires some more changes. For example, currently
 it is not really possible to style how found elements are highlighted.
 And it is not possible for page to say to UA to retry searching
 because the document has modified. I believe that for full solution
 this parts should be implemented as well. Because they would be useful
 for other cases. So:
 
 - styling of how matched text looks, and how highlighted text looks
 (when user selects to highlight all matches in UAs that support that)
 - telling to the webapp that search is being in progress and what is
 being searched for
 - telling UA that it should retry the search because content has been
 changed/rendered/modified

I think styling the search highlights, if not already doable, could be
nice.

Though, my feeling is that such an API might try to support too many UC
and at some point one of them will be styling the search field. I think
allowing the content to take full control of the search in page might be
the best solution for the content and the UA: simple and efficient. It
might be a lot of work to re-implement a search UI but libraries could
help with that if needed (we will agree that pages that try to imitate
the search field are not simple pages usually).

--
Mounir

Re: in-page search, was Re: New manifest spec - ready for FPWD?

[Mounir Lamouri]

On Wed, Dec 4, 2013, at 10:17, Marcos Caceres wrote:
 On Wednesday, December 4, 2013 at 7:43 AM, Charles McCathie Nevile wrote:
 
  Yes. In-apge Search is something that might also be useful within an app -
  especially if you can find out it is happening and respond to it
  intelligently if the app hides things by default.
 
 The ability to do this is useful, but I wonder if it’s kinda context
 specific. Just some very lose thoughts off the top off my head:
 
 * no (mobile) native application platform let’s you do this, AFAIK (just
 a fact - not a judgment or a good/bad thing).
 * hardly any mobile browser currently supports this (which sucks, IMO).  

This is supported by Chrome and Firefox on Android I believe.

 * searching in page is not something that is usually shown by default:
 you have to press ctrl-f on most browsers to bring up in-page search.  
 * apps might only want specific runs of text (a group of elements) to be
 searchable… maybe this is a HTML feature section searchable?  
 
 So I guess the option, if we were to support this, would be something
 like “searchable”. Then the UA can work out the best way to present show
 the search box (e.g., long press - “Search on this screen”).

As mentioned in the bug, I believe it is quite too early to ask
ourselves how to handle that. I think we should focus on the basic
features that would have a wide adoption and keep that kind of features
for later. This is the kind of problems that might or might not exist
later depending on UA UI and developers feedback.

--
Mounir

Re: Browser search API

[Mounir Lamouri]

On Tue, Dec 3, 2013, at 6:48, Mitar wrote:
 And there are real use cases. For example, go to some long document in
 Google Docs and invoke browser search by going through menu (Edit -
 Find or something similar). You will see that it does not work except
 for the current document page. It does not find pages which are
 further down the document, because they have not yet been rendered. If
 you press ctrl-f, Google Docs intercepts this and provides you with
 their own search interface which does work across whole document. This
 is a bit
 hackish in my opinion because it would be better that you would be
 able to use known interface (especially important on mobile devices
 where you are not pressing ctrl-f, and some custom interface might not
 be as well integrated as native one - for example, native one could
 provide voice search for free (as no time needed to implement it)).
 And that it would work across whole document. Google Docs is just an
 example, any dynamic and rich document viewer has this issue, Mozilla
 pdf.js for example as well.

So, it's not clear to me why the inability to search in unloaded pages
will be fixed by intercepting the system find in page unless let the UA
doing the search but then it is no longer clear why you want to know
that a search is actually happening. (This said, if the text is not
loaded, it is not clear how the UA would be more able to search unloaded
content.)

I agree with the native UI issue but wouldn't the page still need a way
to tell the UA that it wants to perform the search itself? In that case,
the idiomatic way to do that is to cancel an event. But I feel like I am
missing something here. How do people use window.getSelection()?

--
Mounir

Re: [screen-orientation] screen orientation angle

[Mounir Lamouri]

On Tue, Dec 3, 2013, at 16:13, Jonas Sicking wrote:
 So I could see apps wanting to lock to that orientation (like you
 pointed out, we found at least one example in Firefox OS).
 
 However I don't understand the use case of locking to 90/180/270
 degrees off of the normal orientation?
 
 Simply adding a default (or hardware or normal) orientation seem
 to keep the API more consistent.
 
 I'd also be worried about introducing the same issues as
 window.orientation has. I.e. that people would come to expect that
 lockOrientation(90) would mean lock to landscape.

I had in mind advanced use cases where an application might want to
rotate the screen. You can imagine four persons playing a game around a
tablet: the UI could switch when turn switches. I admit that it might be
a bit of a small UC but there is simply no way to make that kind of
things possible if we don't give angle relationship between
orientations.

I agree that developers might end up doing lockOrientation(90) instead
of lockOrientation('landscape') but I am not sure if that risk is worth
killing a UC.

-- Mounir

Re: [manifest] orientation member

[Mounir Lamouri]

On Tue, Dec 3, 2013, at 15:48, Jonas Sicking wrote:
 My impression has been that the vast majority of apps only need a
 single orientation that is independent of media-query results. If
 that's the case, then I think the above is too complicated. I.e. if
 that is the common case, then we should support:
 
 orientation: [landscape],
 
 or maybe even
 
 orientation: landscape,

I definitely agree with that. Though, we should allow both syntaxes
(array and string).
If we want a more complex system later, we could move to that. For the
moment, I think we should keep it simple. Also, when comparing how
applications handle landscape/portrait, it is worth considering how
common/easy it is to write responsive UI on the platform. iOS has a very
limited number of device sizes so I am not really surprised that iOS
applications try to optimize for some sizes (thus arbitrary ignore some
others). Is that common on Android? Would that be common using Web
applications?

On Tue, Dec 3, 2013, at 22:03, John Mellor wrote:
 Assuming @viewport is included in inline CSS in the head (which it
 needs
 to be anyway, so the preload scanner can evaluate media attributes and
 responsive images), then the UA will parse the @viewport before it starts
 painting anything. Is there any benefit to the UA knowing the orientation
 before it starts painting the page?

Not sure. Maybe if there are some bits of system UI, rotating that could
take longer than painting?

-- Mounir

Re: [manifest] orientation member

[Mounir Lamouri]

On Tue, Dec 3, 2013, at 23:32, John Mellor wrote:
  I definitely agree with that. Though, we should allow both syntaxes
  (array and string).
  If we want a more complex system later, we could move to that. For the
  moment, I think we should keep it simple.
 
 
 It seems an even simpler option would be to simply omit viewport from the
 manifest for now unless someone can provide a more compelling reason for
 it
 being there.

I think those two options could live side by side. I guess on advantage
of the manifest is that the orientation can be set once and would apply
for the entire app.

 How do the various UAs plan on avoiding a white flash of unpainted page
 when launching web apps? One potential solution to the white flash might
 be
 to delay opening a window for the web app until first paint. In which
 case,
 you wouldn't want to rotate the system UI before launching your window
 anyway...

Interestingly, Chrome Apps is experimenting that: delaying showing new
window until the first paint happens to prevent a white flash. It is
only an experiment because there is the problem of the window not
showing for a long time if the first paint takes a long time to happen.
I think doing that on mobile would be easier because there is usually
one window showing at a time so the user would understand that the app
is being loaded. I'm a bit digressing though.

--
Mounir

Re: Browser search API

[Mounir Lamouri]

Hi,

I am not sure that telling the webpage what the user is currently trying
to search is a great idea. However, if a webpage wants its own find in
page UI I guess a simple solution would be to do something similar to
the Forms Validation UI: a 'findinpage' event could be fired on the
document when the user initiates a find in page and the page would be
able to call .preventDefault() on the event in order to show its own UI.

It could look like:
window.document.addEventListener('findinpage', function(e) {
  e.preventDefault();
  var find = createFindInPageUI();
  find.focus();
});

--
Mounir

On Sat, Nov 30, 2013, at 15:40, Mitar wrote:
 Hi!
 
 Is there already any proposal for browser search API for searching
 over displayed web pages? So that a webapp could know when user is
 searching with a browser interface. I am imagining something where
 browser would send an event with search string content whenever user
 would modify search pattern. Because searching over the page is part
 of the trusted UI, webapp should not have a way to interfere or set
 search string content, but webapp should still know when searching is
 happening.
 
 This would be really useful for assuring search works as expected for
 webapps which work with rich and special content. For example, Google
 Docs would not have to hijack search shortcut to provide their own
 search. And it would still work when user starts searching by enabling
 it through browser menu entry and not through keyboard shortcut.
 
 Another example is Mozilla pdf.js, a canvas based PDF rendering
 library for the web. Because all content is rendered as canvas,
 searching is a really unsatisfying experience. Their current approach
 is same as Google Docs, they hijack search keyboard shortcut to
 display their own search. And again, this makes users be confused if
 they start searching through browser menu.
 
 Not to mention that users using mobile devices probably never start
 searching with keyboard shortcut.
 
 So, is there a plan to standardize something like that? A simple event
 which would be send every time user change string he or she is
 searching for, or an empty string if search was cleared or closed.
 Where should I turn to to propose such a standard?
 
 
 Mitar
 
 -- 
 http://mitar.tnode.com/
 https://twitter.com/mitar_m
 
 

Re: Browser search API

[Mounir Lamouri]

On Mon, Dec 2, 2013, at 23:27, Boris Zbarsky wrote:
 On 12/2/13 6:42 AM, Mounir Lamouri wrote:
  a 'findinpage' event could be fired on the
  document when the user initiates a find in page and the page would be
  able to call .preventDefault() on the event in order to show its own UI.
 
 I assume with a user option to not fire that event and use the browser's 
 default find impl?

Using a cancel-able event would definitely allow implementations to have
such an option.

This said, I was just throwing an idea here. I am not aware of any
implementers actually interested by that feature.

--
Mounir

Re: New manifest spec - ready for FPWD?

[Mounir Lamouri]

On Thu, Nov 28, 2013, at 9:32, Jonathan Bond-Caron wrote:
 On Wed Nov 27 09:20 AM, Mounir Lamouri wrote:
  On Wed, Nov 27, 2013, at 23:59, Jonathan Bond-Caron wrote:
   On Tue Nov 26 04:02 PM, Marcos Caceres wrote:
Over the last few weeks, a few of us folks in the Web Mob IG have
been investigating the use cases and requirements for bookmarking
web apps to home screen. The output of that research  is this living
document:
http://w3c-webmob.github.io/installable-webapps/
   
  
   Would seem useful to add: MAY provide the application version number.
  
  Concept of version on the Web is pretty weak.
  
 
 Depends how you look at the future of applications. Web/http needs to
 evolve, it was built for delivery of information not apps.
 Versioning means there's no need to parse a manifest on every single
 request.

There is no need to parse the manifest on every single request. There
are many caching solutions that would prevent downloading and parsing a
manifest that has not changed. If there is a version specified in the
manifest, it would at best be use as an indication for the user.

Also, reading the version number requires to download and parse the
manifest. Unless you set the version number in an attribute when you
link to the manifest but that would defy the purpose of the manifest
because if you update your version number you will have to change every
single page pointing to your manifest.

That (ongoing) research is helping to inform the manifest spec. A
bunch of us have been working together on IRC, twitter, etc. on a
new version of the manifest
spec:
http://w3c.github.io/manifest/
  
   Any thoughts on adding on 'app' tag? Why is the manifest in JSON?
  
   head
app name=Best News! version=1.1
manifest=more-detailed-stuff.foo/
   /head
  
  Isn't it pretty hairy to add any element to the head because of the 
  parsing
  algorithm?
 
 I'm not sure what you mean by hairy, it's simpler to have important
 metadata directly in the HTML. 

I do not know much about the HTML Parser but last time a feature tried
to add an element to the head - it was intent - people were told
that parsing head is hard and changing the parsing algorithm would be
hairy and was not worth it. I do not know the details.

--
Mounir

Re: [screen-orientation] When window orientation != screen orientation...

[Mounir Lamouri]

On Wed, Nov 27, 2013, at 23:46, John Mellor wrote:
 How should the Screen Orientation API handle cases where the web page's
 window has the opposite orientation to the device's screen? Examples
 where
 this can occur include:
 
 - Split screen tablet (like Win 8 Metro)
 - Non-maximized window on tablet (like Win 8 non-Metro)
 - WebView embedded in native app
 - iframe within larger web page
 
 The orientation media query is defined to
 behttp://www.w3.org/TR/css3-mediaqueries/#orientation
 :
 
 'portrait' when the value of the 'height' media feature is greater than
 or
 equal to the value of the 'width' media feature. Otherwise 'orientation'
 is
 'landscape'.
 
 
 That definition cleverly handles this situation, by always returning the
 orientation of the window - so apps that haven't considered this
 possibility (i.e. almost all of them) will behave as intended.
 
 We can do the same thing for screen.orientation, and have it return
 portrait/landscape using the same logic as the media query (i.e., really
 it
 would provide window orientation). The trickier question, is how should
 this interact with locking the orientation?
 
 For example it would be disastrous if on a portrait split-screen tablet,
 a
 game's window was initially landscape, but the game then locked the
 screen
 to landscape, and the game's window ended up becoming portrait as a
 result!

I think this is an interesting problem. I thought the specification was
pointing that it is an implementation detail but it seems that nothing
is said about that. Also, the intent of Screen Orientation is not to
give the orientation of the window or lock it but to give the
orientation of the screen. The window orientation is a pretty trivial
information to get.

 There are four possible solutions:
 
 1. Only allow locking orientation when the web page's window is maximized
 or fullscreen (hence the orientation of the screen and window should
 almost
 always be the same.

That sounds reasonable. The only issue is that it is mostly a UX issue
and I feel that the specification should limit itself to recommend this
but not enforce it. What do you think?

 2. Rely on developers to notice that their window has the opposite
 orientation to the device's screen, and do the right thing.

Relying on developers to do the right thing in order to not shoot
themselves in the foot is probably a good recipe for a bad API ;)

 3. In cases where the current window is neither maximized nor fullscreen,
 make orientation lock rotate the individual window, not the entire
 screen.

Not a fan of that solution. The Screen Orientation API should be about
the screen, not the window. If you want to rotate your window, you can
use window.resizeTo().

 4. In cases where the window has the opposite orientation to the device's
 screen, invert the orientation values that the developer passes in, i.e.
 calling lockOrientation(landscape) in the portrait split-screen case
 above would keep the device's screen as portrait (and hence the web
 page's
 window would remain landscape), and conversely calling
 lockOrientation(portrait) would rotate the device's screen to landscape
 -
 which would hopefully cause the web page's window to become portrait,
 though that depends on how the window manager handles rotating a split
 screen; if the split is kept in the same orientation rather than being
 rotated, the window end up becoming even move landscape than it used to
 be!
 As you can see this is window-manager-dependent, and isn't completely
 reliable.

As you said after, this is not reliable.

 So, #2 won't work, #4 isn't reliable, and #3 is guaranteed to work but
 isn't necessarily great UX. So I'd recommend that we add #1 to the spec
 as
 a non-normative recommendation. Conveniently though, this is easily
 extensible without breaking compatibility, so if a future browser/OS
 decides that e.g. #3 is fine UX, then they can allow that.

I think the solution #1 is probably the best. We should just judge how
strict should the specification be. I would tend to be lose but I do not
know the best practices regarding UX considerations in specifications.

 In all cases though, making screen.orientation match the media query is
 important.

I do not agree actually. By definition, on my laptop, screen.orientation
should always return 'landscape-primary' unless I play with the display
properties. However, if the orientation media query is based on the
window, I could resize a window in a way that the content will see
itself as portrait wrt the orientation media query and landscape wrt the
screen orientation API. I do not think that needs to change.

--
Mounir

Re: New manifest spec - ready for FPWD?

[Mounir Lamouri]

On Wed, Nov 27, 2013, at 8:02, Marcos Caceres wrote:
 Over the last few weeks, a few of us folks in the Web Mob IG have been
 investigating the use cases and requirements for bookmarking web apps to
 home screen. The output of that research  is this living document:
 http://w3c-webmob.github.io/installable-webapps/
 
 That (ongoing) research is helping to inform the manifest spec. A bunch
 of us have been working together on IRC, twitter, etc. on a new version
 of the manifest spec:
 http://w3c.github.io/manifest/
 
 The Editors would appreciate if people take a look and see if you agree
 with the feature set. 

The feature set sounds pretty good. I would gladly discuss more why some
properties are defined and how some others are but the general gist
sounds fine. Maybe some properties should be removed to make things go
faster. For example, what's the current support to implement 'mode' and
'dont-share-cookies-and-stuff'?

 ** Right now, please refrain from bike-shedding! ** 

Ok :(

 Unless anyone objects, the Editors would like to request the start of a
 CFC towards publishing a FPWD of the manifest spec. 

Please do.

--
Mounir

Re: [screen-orientation] screen orientation angle

[Mounir Lamouri]

If Screen Orientation angle and Device Orientation have the same top for
the device, it should be easy to make an angle relative to the top of
screen instead of the top of the device. I would not recommend changing
Device Orientation API.

--
Mounir

On Wed, Nov 27, 2013, at 7:41, Kenneth Rohde Christiansen wrote:
 Hi,
 
  It seems a better option would be for the Device Orientation API to provide
  values relative to the current screen up direction. This could be optional
  if anyone can think of use cases where you both a) need absolute device
  orientation, and b) wouldn't have already locked the screen orientation.
 
 I think it would be great if the device orientation could have an
 argument or setting like 'followOrientation or similar.
 
 Kenneth
 

Re: New manifest spec - ready for FPWD?

[Mounir Lamouri]

On Wed, Nov 27, 2013, at 23:59, Jonathan Bond-Caron wrote:
 On Tue Nov 26 04:02 PM, Marcos Caceres wrote:
  Over the last few weeks, a few of us folks in the Web Mob IG have been
  investigating the use cases and requirements for bookmarking web apps to
  home
  screen. The output of that research  is this living document:
  http://w3c-webmob.github.io/installable-webapps/
  
 
 Would seem useful to add: MAY provide the application version number.

Concept of version on the Web is pretty weak.

  That (ongoing) research is helping to inform the manifest spec. A bunch
  of us
  have been working together on IRC, twitter, etc. on a new
  version of the manifest
  spec:
  http://w3c.github.io/manifest/
 
 Any thoughts on adding on 'app' tag? Why is the manifest in JSON?
 
 head
  app name=Best News! version=1.1
  manifest=more-detailed-stuff.foo/
 /head

Isn't it pretty hairy to add any element to the head because of the
parsing algorithm?

-- Mounir

[screen-orientation] Locking to 'current' orientation

[Mounir Lamouri]

Hi,

I got some requests from different organizations to add the ability to
lock to the 'current' orientation in the Screen Orientation API.

From Javascript, that would allow writing
  window.screen.lockOrientation('current');
instead of
  window.screen.lockOrientation(window.screen.orientation);
Basically, a syntax sugar.

From the manifest, writing the following
  'orientation': 'current',
would allow locking the application to the orientation it is loaded in
at startup.
It is a tiny use case but it seem that there are apps out there doing
that (like the iOS Task Switcher, I was told).

WDYT?

--
Mounir

[screen-orientation] screen orientation angle

[Mounir Lamouri]

Hi,

The Screen Orientation API defines an angle relationship between
portrait-primary and landscape-primary. The reason for that is that
developers would know which orientation is at 90 degrees from the
current orientation, which one is at 180 degrees, etc. However, by
forcing the two primary orientations to have a relationship, we prevent
UA to do clever things like having landscape-primary being related to
how the user uses his phone (eg. usually depending on which hand is
used, the most common landscape is not going to be different).

In addition, some use cases might need to know the angle between the
current orientation and the native device orientation. For example, a
compass using DeviceOrientation would need to know this angle to be able
to draw the correct information on the screen [1].

This is also a UC that Mozilla has with Firefox OS where some apps want
to lock the orientation to the native device orientation (ie. angle=0)
[2].

So, the Screen Orientation API should allow locking to a specific
orientation angle. For that, we could allow an integer to be passed to
the lockOrientation() function, a modulo operation would be applied on
the number to have it in the [0; 360[ range. If the UA is not able to
lock to the specified angle, the method should fail (return false for
the moment, the promise should fail in the future).

The orientation angle should also be read. It would be possible to
simply use window.orientation. I am not a big fan of that solution [3]
but this is implemented by most Mobile UAs already so it might as well
be the best thing to do. An alternative would be to have something like
screen.orientationAngle or screen.orientation.angle (and
screen.orientation.name).

WDYT?

[1] http://oldworld.fr/google/compass.html
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=908058
[3] the value can be negative, which is a footgun and the having this
value living in window and the rest in window.screen is odd

--
Mounir

Re: [screen-orientation] Locking to 'current' orientation

[Mounir Lamouri]

On Wed, Nov 27, 2013, at 2:52, Marcos Caceres wrote:
 IMHO, it would be confusing to have an app that when you launch it the
 first time locks one way... but when you launch it the next time, locks
 another way. 
 
 In the 300 apps we've been cataloguing for orientation [1], there is not
 a single instance of that exhibits this behaviour. I've also never
 personally seen any app do this on startup.  
 
 Mounir, what is the use case for locking to current on startup? Which
 applications do you know that exhibit this behaviour? 

Eh... My understanding was that there was a consensus for this to be
added. I was told that you pointed the iOS UC. I quite agree with you
that it does not sound like a nice UX. I was willing to spec that
because I assumed there was a consensus. If there is not, we should
discuss it further ;)

   the one with JavaScript seems more clear to me (as it's more evident that 
   it's dynamically derived). current is kinda weird because setting the 
   orientation is an async operation, so by the time you work out what 
   current is, it might not longer be the current one... so it's kind or 
   a race condition.
  
  Why? If it rotating at the moment you call it, it could just fail, if
  it is not, it could lock immediately. It is no different from using
  the window.screen.orientation.
 
 Sure, but it's more about setting expectations. For me personally, using
 window.screen.orientation is more explicit about what I want... like:
 
 var current = screen.orientation; 
 console.log(ok! locking it to:, current );
 screen.lockOrientation(current);
 
 current is more like requesting. That's just me tho. 

If 'current' is added, I wouldn't say that there is a race condition
issue because if you lock to 'current' you do not really care about the
actual orientation.

This said, I do not think that 'current' is very useful from the JS API,
it only saves a few characters.

--
Mounir

Re: [screen-orientation] screen orientation angle

[Mounir Lamouri]

On Wed, Nov 27, 2013, at 3:49, Kenneth Rohde Christiansen wrote:
 a) Will this be a delta from the current orientation? or relative to
 the default device orientation? I guess the former makes the most
 sense.

Orientation angle compared to the native device orientation.

 b) What should happen if the device is already busy changing
 orientation when the request is done? I think failing might make the
 most sense.

That sounds a bit orthogonal to the thread but I would say that if you
do
 screen.lockOrientation(0);
 screen.lockOrientation(90);
both calls should succeed even though the orientation might never be
locked to the 0 angle.

 When we are moving to promises I would rename it to
 requestOrientationLock though as it fits more inline with other APIs.

I was not aware of that convention. Do you have examples? (other than
fullscreen)

--
Mounir

Re: Define window.orientation

[Mounir Lamouri]

On Tue, Nov 5, 2013, at 22:35, Anne van Kesteren wrote:
 On Tue, Nov 5, 2013 at 11:23 AM, Kenneth Rohde Christiansen
 kenneth.christian...@gmail.com wrote:
  They are somewheat different things. The former is basically a way to get
  accelerometer info (useful for games etc) and the latter is about actual
  OS(/Screen) orientation, in which the window.orientation (Browser
  orientation) falls.
 
 Fair. So let's add it to the latter :-)

I remember that Mozilla was not interested in implementing
window.orientation for various reasons. Has that position changed? I
would understand that Mozilla wants to implement that for compat reasons
and if that the case, I would gladly add it to the spec. Does IE11
implements window.orientation?

Anne, if Mozilla ends up starting implementing window.orientation. could
you open a bug on the spec and assign it to me?

Cheers,
--
Mounir

Re: Define window.orientation

[Mounir Lamouri]

On Wed, Nov 6, 2013, at 11:17, Jonas Sicking wrote:
 Last I looked the property was useless because window.orientation=0
 meant different things on different devices. I.e. on some devices it
 meant landscape mode and others it meant portrait mode.

Indeed, if I remember correctly, window.orientation=0 is the natural
orientation and then, the value is the angle between the current
orientation and the natural one in the range ] -180 ; 180 ].

-- Mounir

Re: Polished FileSystem API proposal

[Mounir Lamouri]

On 15/07/13 23:26, Kinuko Yasuda wrote:
 OTOH one limitation I could think of in not having JS object is it'll
 disallow a possible future API expansion for sending a 'Directory'
 object to another app by postMessage.  (It's another popular request we
 get in Chrome)

Isn't a Directory object just a path? I mean, would you send the list of
files and their content or just the path to the directory? If you
literally want to pass the Directory object, I am not sure how passing
the path is different except that you would have to know if this is
temporary or permanent storage.

--
Mounir

Re: Polished FileSystem API proposal

[Mounir Lamouri]

Hi,

I am not a big fan of the Directory approach of this proposal. It puts
the API between a high level, object oriented API and a low level API.
It is unfortunately not really high level because you have to use the
Directory for most operations and the File objects can't be subject to
any action.

I designed an API that looks very similar to the one proposed here but
based around DOMString instead of File and Directory. This API is meant
to be low level and more basic/simple. It gives room for JS libraries to
come up with their own high level object oriented API design and adds
very little overhead for simple use case.

This API is built around a FileSystem interface that exposes all the
methods needed to manipulate the virtual filesystem. Getting a
FileSystem object would be done with:
 navigator.getFileSystem({temporary, permanent}).
An alternative would be to have navigator.filesystem that would return a
FileSystem object and navigator.requestPermanentFileSystem() that could
be used to make the navigator.filesystem object different (ie. permanent
vs temporary). That approach would make using temporary storage more
straightforward but could make using permanent storage a bit more painful.

This API is a bit less polished than the initial proposal (there were
less eyes on it) and contrary to the initial proposal, it is trying to
be very simple regarding the behaviour. For example, .remove() would
remove the directory/file and all sub-directories. The consumer of the
API is expected to check if the directory is empty before calling the
method. The API is re-using FileHandle and FileHandleWritable.

There are a couple of functions there only to make developers' life
easier assuming they would make a common use case simpler. Removing them
is definitely an option.

The interface below describes this alternative proposal. The comments
should give a rough explanation of what each method is doing.

enum FileSystemType {
  temporary,
  persistent
};

partial interface Navigator {
  FileSystem getFileSystem(optional FileSystemType type = temporary);
};

interface FileSystem {
  // Those two methods will create the directory/file if it does not
  // exist but will keep there content as is. The returned value will
  // be whether something as been created.
  Promiseboolean createDir(DOMString path);
  Promiseboolean createFile(DOMString path);

  // Can be used to rename or move. Whether for a file or directory.
  Promisevoid move(DOMString source, DOMString destination);

  // Mostly to make developer's life easier.
  Promisevoid copy(DOMString source, DOMString destination);

  // Removes the file if the path is a file or the sub-tree if the path
  // is a directory.
  Promiseboolean remove(DOMString path);

  // The next three functions would reject if the path is a directory.
  PromiseFileHandle read(DOMString path);
  PromiseFileHandleWritable write(DOMString path);
  // This is for convenience so we can easily write a Blob.
  Promisevoid write(DOMString path, Blob data);

  // TODO: we could add append().
  // For convenience. Could be expressed as:
  // .read(path).then(f) { return f.getFile(); }
  PromiseFile getFile(DOMString path);

  EventStreamDOMString enumerate(DOMString path, optional boolean deep
= false);

  // Those two methods are trivial. They could be merged into one
  // method that would return a tri-state enum: file, directory,
  // notfound.
  Promiseboolean isDirectory(DOMString path);
  Promiseboolean exists(DOMString path);

  // TODO: we could add something like .childrenCount that would return
  // how many files/directory a directory contains. Would be 0 for a
  // file. This could also be .isEmpty(). But that might be
  // mis-interpreted for files.
};

Thanks,
--
Mounir

On 12/07/13 17:31, Jonas Sicking wrote:
 Hi All,
 
 Yesterday a few of us at mozilla went through the FileSystem API
 proposal we previously sent [1] and tightened it up.
 
 Executive Summary (aka TL;DR):
 Below is the mozilla proposal for a simplified filesystem API. It
 contains two new abstractions, a Directory object which allows
 manipulating files and directories within it, and a FileHandle object
 which allows holding an exclusive lock on a file while performing
 multiple read/write operations on it.
 
 It's largely modeled after posix, but because we've tried to keep it
 author friendly despite it's asynchronous nature, it differs in a few
 cases.
 
 There are opportunities for further simplifications by straying
 further from posix. It's unclear if this is desired or not.
 
 Detailed proposal:
 
 partial interface Navigator {
   PromiseDirectory getFilesystem(optional FilesystemParameters parameters);
 };
 
 interface Directory {
   readonly attribute DOMString name;
 
   PromiseFile createFile(DOMString path, MakeFileOptions options);
   PromiseDirectory createDirectory(DOMString path);
 
   Promise(File or Directory) get(DOMString path);
 
   Promisevoid move((DOMString or File or Directory) entry,
 

Re: Kickoff application manifest work

[Mounir Lamouri]

On 24/06/13 12:24, Robin Berjon wrote:
 * When Mozilla made this restriction (I don't know if it's still in
 place) for its apps, developers complained.

Having multiple sub-domains is more complex than creating a directory
for a developer. Also, sometimes, it is not possible, depending on your
hosting solution. A very simple example are GH Pages which live in the
same origin for a given user. That means that with a one-app-per-origin
rule, you would only be able to install one app from a given developer
if his/her apps are hosted on GitHub.

--
Mounir

Re: Futures and transactions

[Mounir Lamouri]

On 15/04/13 12:50, Anne van Kesteren wrote:
 So I guess the current solution is fine as longs as either
 * No JS libraries will want to implement APIs that uses locks, or
 * Such libraries are ok with not using the built-in Future API and
 instead re-implementing the Future API themselves.
 
 The problem with exposing this directly is that you can also do bad stuff.

What kind of bad stuff? There is nothing that the content will magically
be able to do and wouldn't be able to do before. Also, this would force
content to write their own Future implementation to workaround this
limitation which is I believe the opposite intent of specifying Futures
in the DOM specification.

Given the IndexedDB use case, it seems to me that adding an optional
synchronousFlag parameter to the methods in FutureResolver is worth it.

Cheers,
--
Mounir

Editor change for Web Application Manifest Format and Management APIs specification

[Mounir Lamouri]

Hi,

Anant stepped down as an editor of Web Application Manifest Format and
Management APIs specification [1] but Mozilla is still interested in
this specification so I will replace Anant as an editor.

However, given the feedback we got on this specification [2], we are
merging it with the Runtime and security model specification that will
happen in the System Applications Working Group [3].
We are not against keeping the specification in this WG but we fear that
it might not gain much traction as-is.

[1] http://mozilla.github.com/webapps-spec/
[2] http://lists.w3.org/Archives/Public/public-webapps/2012AprJun/1017.html
[3] http://www.w3.org/2012/09/sysapps-wg-charter

Cheers,
--
Mounir

[screen-orient] Updated editor draft

[Mounir Lamouri]

Hi,

I've just pushed a new editor draft [1] with some cosmetic/editorial
changes and a new feature: lockOrientation() can now be called with a
sequenceDOMString to lock the screen to different orientations (for
example, portrait-primary and landscape-primary).

Any feedback is welcome!

Note that I will update the WD in about a week if I do not hear anything
in the meantime.

[1] http://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html

Thanks,
--
Mounir

Re: Pre-fetch rough draft

[Mounir Lamouri]

On 10/30/2012 10:22 AM, Charles McCathieNevile wrote:
 Hi,
 
 I mentioned this and it's somethign we are working on.
 
 Basic idea: site provides list of resources that it uses and can be
 cached for general improvements on the whole site. (We're seeing
 load-time improvement from 50% - 300% in our testing. We are using it on
 sites - mail.yandex.ru/prefetch.txt has an example).
 
 The draft spec here is still very rough, but it shows what we've
 implemented and some of what we think it is good for.
 
 This is meant as input to the appcache/packaging/etc discussion, and may
 or may not be something this group takes on.

At a first glance, it seems that appcache could do the same things.
Which use cases appcache can't currently solve? In the process of fixing
appcache, it could be interesting to add those use cases.

--
Mounir

Web Activities: counter-proposal to Web Intents

[Mounir Lamouri]

Hi,

With some people at Mozilla, we've been working on an API similar to Web
Intents in some points but distant enough to be a counter-proposal. We
believe that the API is now in a good enough shape to be officially sent
in those mailing lists and discussed.

You can have an overview of the API
here:https://wiki.mozilla.org/WebAPI/WebActivities

Web Activities' intent is not to be a clone of Google's Web Intents with
some naming and API details changed. Web Activities aim to be a simple
API trying to solve a very clear set of use cases.

It has been a bit hard to judge the desired scope of Web Intents. People
have suggested that Intents should be able to solve everything from
getting low-level Sensor information [1] to the ability to implement
services like Push Notifications [2] to doing discovery and control of
DVR hardware from the browser [3]. It is unclear if this is just a list
of things people wish that Intents could help with, or if these are hard
requirements that the spec authors are using to design the spec for.

An API which allows building a wide range of applications is generally a
good API, however it is also important to have a concrete set of use
cases when designing an API to make sure that it solves those use cases
well. Our concern is that Intents are designed to solve the ambigious
use case of communicating with anything.

As a reminder, the basic use cases of Web Intents seem to be: Users use
many different services on the web to handle their day to day tasks,
such as sharing images, editing documents and listening to music. They
expect their applications to be connected and to work together
seamlessly. [4] and the basic actions/intents/activities the API
mentions are share, edit, view, pick [4].

The current shape of Web Intents seems to allow consumers of the API to
use it for:
1. Delegating: an application delegates an activity to another application.
2. Discovery: some consumers seem to be inclined to use Web Intents to
discover other services. This is what Bryan Sullivan suggested for the
Push Notification API. When the Intent is invoked no action would
actually be taken, instead a URL is returned and then it's up to the
page to communicate with that URL with the Web Intent API no longer
involved.
3. Communication: you can use Web Intents to simply create a channel of
communication between APP A and APP B: you can easily specify which
service should be used to handle the intent and then, you can
communicate with it.

We believe we should restrain the API to (1).

(2) is something that is better done with a separate Discovery API since
the model here is very different. It is no longer transparent to the two
parties involved who they are communicating with, and the UA no longer
has the ability to mediate the communication.

(3) is something that can be solved with already existing parts of the
platform, like MessageChannel or WebSockets.

The main issue we see with trying to solve all those use cases in one
API is regarding implementation and especially UI. The way we see it,
when an application wants to start an activity/intent, a UI should show
the list of applications able to handle it, and it should be clear to
the user that this application will be used to complete the action
he/she intended to do. For example, if the user clicks on the camera
button, a UI will ask him/her which application should be used to
pick/take a picture.
If you try to mix (2) and (3) in here, you will have serious problems
like an application initializing a communication channel with another
application at startup: the user might see a UI asking him/her to chose
an application in the list but will have no idea why and for what. This
could apply for the Push Notification case: the UA cannot know that the
intent/activity was sent to discover a push service instead of
delegating an activity to it. Actually, for security purposes, we are
even going to limit activities so they can be started only when
generated from a user action.

Basically, we think Web Activity should be a very simple API that allows
an application to delegate an activity to another application with very
clear rules regarding starting the activity, handling it and the UI
in-between.
Another simple API could be used to do (2) and (3). Basically, you can
imagine an API that would allow you to discover a service doing foo
and if the service agrees, both parts will get a MessageChannel port
they can use to communicate with each other. This API is out of scope of
Web Activites but might be helpful for applications that want to
discover services and communicate with them in the background.

So, we would like to suggest, if Google agrees, to work together on a
common version of that API that would be restricted to the use cases we
mentioned. It could be based on Web Activities (or Web Intents stripped
from all unnecessary stuff). We are willing to discuss any detail of the
API as long as we do not include any feature we believe are out of 

Re: Push API draft uploaded

[Mounir Lamouri]

On 05/31/2012 03:28 PM, Tobie Langel wrote:
 I'm probably missing something here, but notifications don't seem to be
 going through a system- / browser-wide notification panel from which the
 user can decide whether or not to navigate to an application. In other
 words, it looks like we're considering server -- app push notifications,
 rather than server -- user push notifications.
 
 If that's case, how are we planning to handle waking up application A
 without disrupting the experience of the user currently busy using
 application B in the foreground (thinking essentially of mobile here)?
 
 Are we going to wake up application B but run it as a background app? If
 so, where is that behavior defined? Is that akin to a WebWorker or more of
 a headless window? What's the life-cycle of such an app? Also, how can
 this app alert the user that it has something new for him? Do we also have
 system level notifications in the work?
 
 If a given notification's sole purpose is to advise the user of some
 information he may or not want to act upon (e.g.: you have new mail),
 what are the benefits of waking up the application (or even spawning a
 worker) to do so? That seems like it would drain the battery of mobile
 devices for little purpose.
 
 Finally, aren't we conflating the notion of background work following a
 remote server or system event with that of push notification to the user?
 
 An example of background work following a remote server event would be the
 background update of daily news for a newspaper application. A remote
 server would send an event to the system / browser which itself would
 launch a WebWorker, that worker would perform the necessary io to upload
 the fresh content and save it in a db.

 An example of background work following a system event would be a
 location change event spawning a background worker which itself either
 stored the coordinates in a db or sent them to a remote server, e.g. for a
 cycling app tracking your rides.
 
 Example of push notifications for the user are things like You've got a
 new message, It's Emma's birthday today, etc. The user can decide to
 act upon them (i.e. follow the provided link) or not, but until he does,
 there's no reason to launch an app or even a worker.
 
 Note that similar notifications would also need to be issued by background
 workers / windows. E.g. The worker spawned above to upload fresh content
 for the newspaper app would be able to send a notification to the user
 when it's done (e.g. Today's news are  been downloaded.)
 
 Sorry if the above feels a bit like a brain dump. I'm really struggling to
 understand the scope of this proposal. :-/

Actually, our System Message API [1] seems to answer most of those
questions: an application will be able to specify a worker or a page to
use when handling a message so it will be able to just run stuff in the
background and depending on what happened do something like show a
notification (via Desktop Notifications) or update a DB, or whatever.

[1]
https://groups.google.com/group/mozilla.dev.webapi/browse_thread/thread/a3c6e4c31d04b663/

Cheers,
--
Mounir

Re: Push API draft uploaded

[Mounir Lamouri]

On 05/29/2012 06:13 PM, SULLIVAN, BRYAN L wrote:
 * I wonder if it is really useful to have clients requesting a specific
 Push service. I totally understand why a user would request to use his
 preferred Push service but that is part of the UA. I would tend to think
 we should not add that parameter until it's proven to be needed by some
 consumer of the API. Adding it would be simple; removing it might not be
 an option. Also, allowing a website to chose the Push service might
 break the entire idea of decentralization here: you might end up with
 most websites requesting to use push.popularservice.com.

 bryan If a service is effective and thus popular, why shouldn't it be 
 accessible to developers? Rather than break decentralization, this 
 flexibility enables it IMO, so I think there is a misunderstanding 
 somewhere. To enable some degree of Push service (and thus service provider) 
 flexibility, I have also proposed that we could use Web Intents as a way to 
 allow the user to select the service provider, but if the app has particular 
 requirements (e.g. security or delivery methods/bearers), I see no reason 
 why we should obfuscate the developer intent by making the user play the 
 match maker. The requested service URL also provides means to negotiate 
 additional functionality/options between the app and the Push service 
 directly e.g. as above (e.g. security, delivery methods/bearers, application 
 characteristics, ...).
 
 I don't how this could be related to Web Intents? Picking the service
 provider should be up to the UA (using whichever method the UA feels
 appropriate). If a website *needs* a specific service provider that
 means this API has been a failure so I wouldn't add a parameter that
 would help this happen.
 
 bryan The concept of service provider selection by the user (in essence the 
 provider of some functionality distributed as Web pages/applications/workers 
 etc) is fundamental to the Web Intents concept, so it seemed natural to me to 
 consider that for this API. I don't think UA's should be exclusively 
 responsible for service provider selection, for this purpose or others. If 
 service providers can be more flexibly integrated through APIs such as Web 
 Intents IMO that is good for the Web.

I do not understand why a concept should be used in this specification
because it is used in Web Intents. And I do not understand why making an
API integrated with Web Intents is good for the Web. Really.

 * |readyState| should be a DOMString.

 bryan The jury is out on this, AFAICT. It's a short in EventSource and 
 XHR. I was following their lead.
 
 I don't know for XHR but the new way is DOMString for multiple
 reasons. I believe Ms2ger pointed you to a link which likely explains those.
 
 bryan If we can get Webapps resolution on that as a recommended design 
 approach going forward, as I said I am open to this. Perhaps the XHR and 
 EventSource editors can voice an opinion here?

XHR just can't be changed, this is why it is keeping integers instead of
string for errors. I do not know for EventSource. Anyhow, I'm not going
to argue more on that subject.

 * I guess the idea of |onmessage| is that the PushService instance will
 get an event when the backend will push a notification to the webapp.
 However, I wonder how you do handle the situation when the application
 is actually not being ran. Or should we wait for it to be launched?
 Anyhow, coupling the URL request and the event handling at the same
 place seems weird.

 bryan Not at all. This is the way that EventSource works for example (the 
 message handler is overtly associated with the request to a specific service 
 URL). I'm not sure what you mean by when the application is actually not 
 being ran... if you mean when the app is not running, the answer is yes, 
 the app should be started and the event then delivered to it.
 
 Running a webapp/website then sending an event to it seems a rather hard
 task. This is actually what motivated the System Message Handler API.
 
 bryan I'm not sure how it's hard; the Webapp just arranges for Push message 
 delivery when it is invoked, and events are delivered to the object that 
 represents the service arrangement (whether connection-based or 
 connectionless or whatever). I may be missing your counterpoint.

I wasn't clear I think. If you start an application because of a
particular event, the application has no way to know it has been started
because of the event until the event is actually sent. But the event
will be sent at a point during load (or after) and in the meantime, the
application might show a UI as if it was simply started by the user. So
you might have a weird UI flickering where something will be shown and
very quickly will be changed to something else because of the push
notification coming.

 * If we want want a |wakeup| attribute, this might need to live in the
 manifest as Jose suggested. In general, I wonder if that should be
 something the UA 

Re: Push API draft uploaded

[Mounir Lamouri]

On 05/26/2012 05:06 AM, SULLIVAN, BRYAN L wrote:
 * As far as I understand it, |requestRemotePermission| and
 |checkRemotePermission| could be one single method which could be named
 something like |getPushServiceUrl|. The only difference between those
 two methods is the permission asking part but that should stay as a UA
 decision. Given that the method is anyway asynchronous, the UA can do
 whatever wanted before sending a result. Showing a permission prompt
 could be one of those.
 
 bryan I agree that these methods could collapse into one. But as this 
 interface was based upon the Mozilla proposal 
 (https://wiki.mozilla.org/Services/Notifications/Push/API) I would like to 
 get the author's view on the potential to collapse the two methods into one.

I wouldn't name the proposal on the wiki page as Mozilla's proposal.
This wiki is public and what is described is far from being a finished work.
In addition, the wiki page is quite explicit about the existence of
those two methods and the given reasons are quite invalid.

 * I wonder if it is really useful to have clients requesting a specific
 Push service. I totally understand why a user would request to use his
 preferred Push service but that is part of the UA. I would tend to think
 we should not add that parameter until it's proven to be needed by some
 consumer of the API. Adding it would be simple; removing it might not be
 an option. Also, allowing a website to chose the Push service might
 break the entire idea of decentralization here: you might end up with
 most websites requesting to use push.popularservice.com.
 
 bryan If a service is effective and thus popular, why shouldn't it be 
 accessible to developers? Rather than break decentralization, this 
 flexibility enables it IMO, so I think there is a misunderstanding somewhere. 
 To enable some degree of Push service (and thus service provider) 
 flexibility, I have also proposed that we could use Web Intents as a way to 
 allow the user to select the service provider, but if the app has particular 
 requirements (e.g. security or delivery methods/bearers), I see no reason why 
 we should obfuscate the developer intent by making the user play the match 
 maker. The requested service URL also provides means to negotiate additional 
 functionality/options between the app and the Push service directly e.g. as 
 above (e.g. security, delivery methods/bearers, application characteristics, 
 ...).

I don't how this could be related to Web Intents? Picking the service
provider should be up to the UA (using whichever method the UA feels
appropriate). If a website *needs* a specific service provider that
means this API has been a failure so I wouldn't add a parameter that
would help this happen.

 * I'm not sure why you have a |requestUrl| attribute in PushService. Do
 you have any use case for that?
 
 bryan The use case is that an app can have multiple Push service requests 
 active at a time, with different URLs. In order to be able to associate each 
 PushService object with a specific set of options or services for example, it 
 needs to know what URL was used when the PushService object was created. The 
 intent is similar to that of EventSource, which has the url attribute for a 
 similar purpose (at least that is how I have used it). And since the 
 checkRemotePermission() method needs to verify the permission for the same 
 URL, it is better to have the resolved form of the URL available as an 
 attribute, so that it's easy to call the checkRemotePermission() method for 
 the right URL (as the absolute URL may have changed since the original 
 resolution).

The resolving part seems quite useless because contrary to EventSource,
it might be pretty uncommon to use a relative path to the push service.
Anyhow, I think this should disappear with the parameter in the methods.
The client shouldn't know which server is used: this is part of the
user's privacy.

 * |readyState| should be a DOMString.
 
 bryan The jury is out on this, AFAICT. It's a short in EventSource and XHR. 
 I was following their lead.

I don't know for XHR but the new way is DOMString for multiple
reasons. I believe Ms2ger pointed you to a link which likely explains those.

 * I guess the idea of |onmessage| is that the PushService instance will
 get an event when the backend will push a notification to the webapp.
 However, I wonder how you do handle the situation when the application
 is actually not being ran. Or should we wait for it to be launched?
 Anyhow, coupling the URL request and the event handling at the same
 place seems weird.
 
 bryan Not at all. This is the way that EventSource works for example (the 
 message handler is overtly associated with the request to a specific service 
 URL). I'm not sure what you mean by when the application is actually not 
 being ran... if you mean when the app is not running, the answer is yes, 
 the app should be started and the event then delivered to it.

Running a 

Re: Push API draft uploaded

[Mounir Lamouri]

On 05/24/2012 09:14 AM, SULLIVAN, BRYAN L wrote:
 Thanks to the inestimable help of the W3C staff I am now plugged into the 
 mercurial mainline and have uploaded the first stab at the Push API
 http://dvcs.w3.org/hg/push/raw-file/default/index.html
 
 I incorporated Mozilla's client API ideas in 
 https://wiki.mozilla.org/Serices/Notifications/Push/API as the PushManager 
 interface, and also in the PushService interface with some additions to 
 support a more explicit event model for received message delivery, derived 
 from Server-Sent Events.
 
 A lot is still left unsaid, and I will work on examples.
 
 I also have not addressed the server API aspect that Mozilla mentioned in 
 their proposal. Like a lot that is left unsaid in their client API proposal 
 (how does the browser determine what that magic server URL is...?), the 
 server API is likely related to the specific Push service that is bound to 
 the API. I am considering the use of Web Intents to discover and select the 
 Push Service provider that the user wants apps to use, assuming that we can 
 leave the backend details to the intent provider. I'm not yet sure how the 
 pieces will fit together, how much needs to be defined, and how my earlier 
 proposal about specific event source selection and filtering fits into this, 
 but it's a start.

Hi,

I have a few random comments:

* As far as I understand it, |requestRemotePermission| and
|checkRemotePermission| could be one single method which could be named
something like |getPushServiceUrl|. The only difference between those
two methods is the permission asking part but that should stay as a UA
decision. Given that the method is anyway asynchronous, the UA can do
whatever wanted before sending a result. Showing a permission prompt
could be one of those.

* I wonder if it is really useful to have clients requesting a specific
Push service. I totally understand why a user would request to use his
preferred Push service but that is part of the UA. I would tend to think
we should not add that parameter until it's proven to be needed by some
consumer of the API. Adding it would be simple; removing it might not be
an option. Also, allowing a website to chose the Push service might
break the entire idea of decentralization here: you might end up with
most websites requesting to use push.popularservice.com.

* I'm not sure why you have a |requestUrl| attribute in PushService. Do
you have any use case for that?

* |readyState| should be a DOMString.

* I guess the idea of |onmessage| is that the PushService instance will
get an event when the backend will push a notification to the webapp.
However, I wonder how you do handle the situation when the application
is actually not being ran. Or should we wait for it to be launched?
Anyhow, coupling the URL request and the event handling at the same
place seems weird.

* If we want want a |wakeup| attribute, this might need to live in the
manifest as Jose suggested. In general, I wonder if that should be
something the UA requests. I would understand why the UA would ignore
|wakeup = true| but I wouldn't understand why it should always follows
the passed value.

For the two last points, maybe using Mozilla's System Message Handler
would help?
See:
https://groups.google.com/group/mozilla.dev.webapi/browse_thread/thread/a3c6e4c31d04b663/

Cheers,
--
Mounir

Re: WebApps' new charter has been approved

[Mounir Lamouri]

On 4/27/12 3:07 PM, Arthur Barstow wrote:

Hi All,

Yesterday the Director announced WebApps' new charter [Charter] was
approved so thanks to all that helped with the chartering effort.

I added all of the new specs to our [PubStatus] page and made a couple
of tweaks to the group's [WorkMode] wiki.


Hi,

The Screen Orientation API is now listed as View Orientation API.
I do not really understand why this change has been made. I could 
understand that Screen Orientation might be confusing with 
DeviceOrientation but View Orientation isn't really making that 
easier to understand.
In addition, the Screen Orientation API is about getting and locking 
the entire device's screen, not the application view. Using View 
instead of Screen might make this intent very unclear.


What was the reasons behind this renaming?

Thanks,
--
Mounir

Re: CfC Re: Charter addition proposal: screen orientation lock

[Mounir Lamouri]

On 02/15/2012 10:09 AM, Vincent Scheib wrote:
 Mounir, I ran into the same confusion regarding how does the API expose
 locking?. May I suggest that you explicitly state in the abstract that
 the API is pending?

I just updated the draft so the locking part is now part of it.

Cheers,
--
Mounir

Re: CfC Re: Charter addition proposal: screen orientation lock

[Mounir Lamouri]

On 02/15/2012 04:29 AM, Tobie Langel wrote:
 In the Screen Orientation API draft, I don't see any references to
 locking. Is this by design?
 
 It's in the abstract:
 
 The Screen Orientation API's goal is to provide an interface for web
 applications to be able to read the screen orientation state, to be
 informed when this state changes and to be able to lock the screen
 orientation to a specific state.
 --http://dvcs.w3.org/hg/screen-orientation/raw-file/tip/Overview.html

I only wrote the reading part for the moment because there are still
some discussions in Mozilla's WebAPI mailing list [1] about the locking
part. When the specification draft will be complete, I will send a
message here.

[1] https://www.mozilla.org/about/forums/#dev-webapi

--
Mounir

Re: Charter addition proposal: screen orientation lock

[Mounir Lamouri]

On 01/30/2012 12:43 PM, Kenneth Rohde Christiansen wrote:
 Hi there,
 
 Orientation lock is already part of the CSS Device Adaption spec as part
 of the viewport meta tag, though this is only going to be optional and
 should be ignored for normal web browsing due to the effect on usability
 (think about navigating session history). It is thus mostly useful for
 fullscreen applications and stand alone web apps.

Actually, I was thinking of asking this to be removed from CSS DA.
A JS API seems more useful than an CSS property. For example, CSS DA
doesn't seem to allow you to read screen orientation value. It also
doesn't allow you to know when the screen orientation changes. In
addition, doing dynamic changes to the current screen orientation is
pretty annoying (doable with CSSOM I believe).
In the other hand, a JS API would allow you to do all of that and
locking the orientation very easily. The only drawback is that you can't
declare the screen orientation of your application in the header of the
HTML file. However, at Mozilla we believe that could be set in the
application manifest (see the link to the conversion Robin gave for more
details).

Also, I do not think the specifications should restrain the conditions
in which the screen orientation lock can happen. At least not at the
beginning (so implementors can easily experiment) and that should not be
a hard requirement (not a MUST). If a UA wants to allow content to lock
the screen orientation in any situation, that should be doable. UA
should take care of their own user experiences. Some UA might require
fullscreen to be set before (that seems sensible), some might just allow
this for pre-installed content (without requiring fullscreen).

 On the other hand, I think it would be nice to have a hint to the
 fullscreen api requestFullscreen where you could define a preferred
 orientation (which it would then lock to), something like
 requestFullscreen(HORIZONTAL). It would even be nice if the UA could
 tell whether it was possible to enter horizontal fullscreen mode or not,
 so that there can be some kind of fallback. Having it this way, it would
 be possible to click/tap on some element and animate the transition
 (scale + rotation) into the final state.

Linking screen orientation and fullscreen like that seems a bad idea.
Basically, you can only lock and never reads. In addition, how do you
handle an iframe requesting fullscreen?

Cheers,
--
Mounir

Re: Charter addition proposal: screen orientation lock

[Mounir Lamouri]

On 01/30/2012 03:57 PM, Kenneth Rohde Christiansen wrote:
 Also, I do not think the specifications should restrain the conditions
 in which the screen orientation lock can happen. At least not at the
 
 
 It doesn't have to do that, but it could point out that UAs might want
 to restrict the orientation lock to certain situations. But I think we
 might end up with most browsers acting differently and causing
 fragmentation, thus some recommendation should be fine and can be
 ignored if the UA seems fit.

This is what I meant by not a MUST, so I guess we agree :)

 Linking screen orientation and fullscreen like that seems a bad idea.
 Basically, you can only lock and never reads. In addition, how do you
 handle an iframe requesting fullscreen?
 
 
 We need this to be tied together in some way, so that it is possible to
 click on say, a video element and have to animate entering fullscreen
 and rotating at the same time. Doing these two transitions separately,
 would look pretty bad (at least animated).

Sounds interesting. Maybe we could extend the fullscreen API later.
However, we shouldn't force authors to use the fullscreen API to lock
the screen.

--
Mounir

Re: CfC Re: Charter addition proposal: screen orientation lock

[Mounir Lamouri]

On 01/30/2012 02:26 PM, Charles McCathieNevile wrote:
 OK, since I was planning to have the charter up today, let's have a
 quick call for consensus on this. Please reply by end of business
 Wednesday if you support or object to this - silence will be taken as
 not explicitly supporting it, and without support it isn't going to get
 into the draft charter. If it does go there, there will still be
 opportunities to object but it will be harder to squeeze in.

I guess I can speak for Mozilla to say that we support this.

Though, I would prefer to name this Screen Orientation API or Screen
Orientation given that it shouldn't be limited to locking the screen.

Cheers,
--
Mounir