On 23 October 2014 23:29, Martin Thomson martin.thom...@gmail.com wrote:
It means that important features that provide
these measures (do not disturb, more contextual event filtering) are
not available to applications by default.
System-wide do-not-disturb would still work (for example in
:23, Martin Thomson martin.thom...@gmail.com wrote:
On 22 October 2014 11:02, John Mellor joh...@google.com wrote:
a restricted form of push where each push event fired on the SW must
trigger
user-visible UI.
How would that work? Is the idea that there would be a default
notification
Hi folks,
Based on our UX studies for Chrome, we’ve found the clearest way to do
permissions UX for the Push API will be to have one prompt[1] that grants
both full push messaging and background sync[2], and a separate prompt[3]
that grants notifications plus a restricted form of push where each
On 16 October 2014 16:22, Shijun Sun shij...@microsoft.com wrote:
On Thursday, October 16, 2014 12:42 AM, Anne van Kesteren wrote:
You need a browser to run a service worker. The browser is pinged and it
might then decide to start running a service worker to process the incoming
message, or
On 15 October 2014 23:07, Shijun Sun shij...@microsoft.com wrote:
My understanding here is that we want to leverage the push client in the
OS. That will provide new capabilities without dependency on a direct
connection between the app and the app server.
The Push API doesn't use a direct
On the one hand, there are some great use cases for this (video calls,
alarm clocks, two-factor authentication, sending a map from desktop to
mobile before you leave the house, etc).
On the other hand, browsers have traditionally had to block popups except
following a user gesture, and it's easy
deeply yet.
On 2 October 2014 17:47, Martin Thomson martin.thom...@gmail.com wrote:
On 2 October 2014 05:48, John Mellor joh...@google.com wrote:
So I guess this is something we'll want to support eventually, but it's
blocked on coming up with clear UI for safely granting and revoking
Seems likely :)
I'd recommend reading the editor's draft, which is more up to date:
https://slightlyoff.github.io/ServiceWorker/spec/service_worker/
On 2 September 2014 18:45, Brent Shambaugh brent.shamba...@gmail.com
wrote:
In the document: http://www.w3.org/TR/service-workers/
Should:
Yes, moving push (especially register, unregister and isRegistered) onto
ServiceWorkerRegistration instances would make the API a lot easier to use.
Currently it's order dependent, and if a developer tries to register before
they have registered a Service Worker, navigator.push.register will
Hi all,
We demoed the push API https://w3c.github.io/push-api/ and notifications
from a Service Worker
https://www.mail-archive.com/whatwg@lists.whatwg.org/msg37350.html at
Google I/O as part of broader talk about Service Workers (also covering
offline usage, and the proposed background sync API
Jonas wrote:
One thing that I think would help the API would be to unify the
initial registration flow and the you need to reregister since the
push server has lost track of your registration flow. I.e. having a
single API which lets the page check do I need to register now.
Actually, the
Domenic wrote:
this doesn't allow notification that you need to re-register
I was trying to make the point that events letting the webapp know it needs
to re-register should go to the Service Worker, so the webapp can
re-register whether or not it happens to be currently open. Since the app
On Tue, Dec 3, 2013 at 4:52 AM, Jonas Sicking jo...@sicking.cc wrote:
The strongest argument that I can think of is that it would be nice to
keep the manifest spec and the API spec for orientations aligned. So
if we think this is common enough that apps will want to use it in the
manifest,
On Tue, Dec 3, 2013 at 4:48 AM, Jonas Sicking jo...@sicking.cc wrote:
As I understand it, the main use case for putting orientation in the
manifest is to enable the UA to launch the app in the correct
orientation from the get-go. It seems very hard for an implementation
to do that with this
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
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
This all sounds reasonable; it's great that we'll be able to remove the
spec's artificial requirement that if the device is in landscape-primary
and is rotated 90 degrees clockwise, that should be represented as
portrait-primary.
And it potentially opens the door to using a less error-prone
) = (0,1,0) when holding the device portrait up in all
cases will eliminate one layer of mapping. If this is already handled
here, I am sorry for repeating myself.
best wishes
Lars
On Tue, Nov 26, 2013 at 9:25 AM, John Mellor joh...@google.com wrote:
This all sounds reasonable; it's great
, 2013 at 4:34 PM, John Mellor joh...@chromium.org wrote:
Sounds reasonable. I think the main things that are missing are
explanations
of the knock-on effects of Device Adaptation (and the meta viewport tag).
For example the CSSOM View module claims that all its dimensions are in
CSS
pixels
between device pixels and DIPs, and things
like CSS4 image-set).
On Thu, Jun 6, 2013 at 11:21 AM, Kenneth Rohde Christiansen
kenneth.christian...@gmail.com wrote:
Hi there
On Thu, Jun 6, 2013 at 12:15 PM, John Mellor joh...@chromium.org wrote:
There is a distinction to be made between DIPs
of the document scale, unlike
window.innerWidth which expresses the amount of CSS px units
(horizontally) of the document which you see given the current
document scale.
Maybe you have suggestions for how to clarify this in the specs?
On Thu, Jun 6, 2013 at 12:32 PM, John Mellor joh...@chromium.org
Sounds reasonable. I think the main things that are missing are
explanations of the knock-on effects of Device Adaptation (and the meta
viewport tag).
For example the CSSOM View http://dev.w3.org/csswg/cssom-view/ module
claims that all its dimensions are in CSS
22 matches
Mail list logo
