https://www.w3.org/Bugs/Public/show_bug.cgi?id=24872
Hayato Ito hay...@chromium.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24872
Ryosuke Niwa rn...@webkit.org changed:
What|Removed |Added
Status|RESOLVED|REOPENED
FWIW, we also have “Server Push” in HTTP/2; that seems confusable as well…
On 11 Mar 2014, at 7:36 pm, Michael van Ouwerkerk mvanouwerk...@google.com
wrote:
I think that's a great suggestion Jeffrey.
Specifically, I would like to avoid confusing concepts and terminology in the
Push API
I agree, Push Message is the term that is used in other standards e.g. OMA
Push. The use of the term notification was a reflection of the current
simplified API design which provides only a trigger to the application, as a
notification that some data is available at the server. As we consider
Sure, we will look out for additional potentially confusing term overlap as
suggested.
Thanks,
Bryan Sullivan
On Mar 11, 2014, at 12:38 PM, Michael van Ouwerkerk
mvanouwerk...@google.commailto:mvanouwerk...@google.com wrote:
I think that's a great suggestion Jeffrey.
Specifically, I would
Sure, but this is only a reflection of the semantic space of the English
language. Many things can be source of confusion. Understanding context is the
responsibility of the reader. We will do what we can to provide clarifying
guidance on the use of terms, but Push Message is a well-established
Hi Bryan, Eduardo, All,
While working through the push notification versus push message
thread, I noticed Push API directly refers to System Messages as
defined by SysApps' [runtime] spec. Based on the Note at the top of
[runtime], it appears work on that spec has stopped. As such, what is
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.
Thanks,
Bryan Sullivan
On Mar 13, 2014, at 12:40 PM, Arthur Barstow
In Blink/Chrome we are looking into the Push API. We intend to use Service
Workers as an alternative for System Messages. The idea is to fire an event
in the SW when a push message is received. This has a big advantage: waking
up a SW should be much faster than loading the whole document.
On March 12, 2014 at 7:16:53 PM, Mitar (mmi...@gmail.com) wrote:
Hi!
There was no reply. :-(
It usually takes a bit of time for Hixie to get around to all the emails (the
volume of email on the WHATWG list + other priorities slow things down - but
I’ve never seen him not respond to a
On Thu, Mar 13, 2014 at 8:17 AM, Marcos Caceres w...@marcosc.com wrote:
On March 12, 2014 at 7:16:53 PM, Mitar (mmi...@gmail.com) wrote:
There was no reply. :-(
It usually takes a bit of time for Hixie to get around to all the emails (the
volume of email on the WHATWG list + other priorities
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
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:
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,
On 3/13/14 1:52 PM, ext Mounir Lamouri wrote:
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.
Given this, seems
On March 13, 2014 at 2:33:08 PM, Arthur Barstow (art.bars...@nokia.com) wrote:
On 3/13/14 1:52 PM, ext Mounir Lamouri wrote:
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
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.
On 3/13/14 10:59 AM, Mounir Lamouri mou...@lamouri.fr wrote:
http://msdn.microsoft.com/en-us/library/ie/dn433241(v=vs.85).aspx
That seems to defeat the normal orientation aspect of the spec and the
usefulness of '-primary' and '-secondary' suffixes for the initial
state.
There is a bug on
Hi,
It appears that there is a lot of new features such as CSS regions and shadow
DOM that have significant implications on selection API, and we really need a
spec. for selection API these specifications can refer to.
Thankfully, Aryeh has done a great work writing the spec. for selection API
From: Ryosuke Niwa [mailto:rn...@apple.com]
Any thoughts and opinions?
Have there been indications from vendors that they would have more resources to
devote to implementing or critiquing the selection API if it were isolated into
a smaller document? Is the idea that the surrounding text
Looking into selection in this brave new world (Shadow DOM for sure, but
there are issues as well with flexbox if I'm not mistaken), is definitely
something we are interested in.
We haven't gotten around it yet which I believe explain our lack of
feedback so far.
2014-03-14 8:43 GMT+09:00
On Mar 13, 2014, at 5:08 PM, Domenic Denicola dome...@domenicdenicola.com
wrote:
From: Ryosuke Niwa [mailto:rn...@apple.com]
Any thoughts and opinions?
Have there been indications from vendors that they would have more resources
to devote to implementing or critiquing the selection API
I'd be fine with changing the API to only take a single string value.
I agree the usecases for locking to multiple orientations isn't strong
enough to warrant the compatibility complexities that come from the
fact that you can't implement the API on android. At least I haven't
heard such usecases.
23 matches
Mail list logo
