If you would prefer that the IETF wg charter refer to something else,
please let me know promptly. A small correction is still possible, but the
window is closing.
On Sep 26, 2014 1:47 PM, Arthur Barstow art.bars...@gmail.com wrote:
On 9/24/14 1:21 PM, Michael van Ouwerkerk wrote:
The linked
On 9/26/14 10:42 AM, Martin Thomson wrote:
If you would prefer that the IETF wg charter refer to something else,
please let me know promptly. A small correction is still possible, but
the window is closing.
Well, it seems like IETF process would suggest/prescribe what should be
done. (I
On Fri, Sep 26, 2014 at 3:42 PM, Martin Thomson martin.thom...@gmail.com
wrote:
If you would prefer that the IETF wg charter refer to something else,
please let me know promptly. A small correction is still possible, but the
window is closing.
I think the IETF spec should continue to refer
CARRERA
Cc: public-webapps
Subject: Re: [Webpush] IETF proposes new Web-Based Push Notifications Working
Group
On 9/24/14 1:21 PM, Michael van Ouwerkerk wrote:
The linked working draft is now more than a year old. The latest
editor's draft has some inconsistencies while we transition
[ Bcc webp...@ietf.org ]
Hi All,
I recall the IETF's intent to create a web-based push notifications
protocol standard was previously announced on this list. Please note the
draft charter for this WG explicitly mentions WebApps:
[[
http://datatracker.ietf.org/doc/charter-ietf-webpush
On Wed, Sep 24, 2014 at 3:20 PM, Arthur Barstow art.bars...@gmail.com
wrote:
[ Bcc webp...@ietf.org ]
Hi All,
I recall the IETF's intent to create a web-based push notifications
protocol standard was previously announced on this list. Please note the
draft charter for this WG explicitly
On Thursday, September 12, 2013 at 5:19 PM, Arthur Barstow wrote:
WebApps - the Web Notification WG asked WebApps to review their
September 12 LCWD of Web Notifications:
http://www.w3.org/TR/2013/WD-notifications-20130912/
Individual WG members are encouraged to provide individual
WebApps - the Web Notification WG asked WebApps to review their
September 12 LCWD of Web Notifications:
http://www.w3.org/TR/2013/WD-notifications-20130912/
Individual WG members are encouraged to provide individual feedback.
If anyone in WebApps wants to propose an official WG response
Today, the Web Notifications WG[1] has published a Last Call Working Draft of
the Web Notifications specification:
http://www.w3.org/TR/2013/WD-notifications-20130912/
We're targeting October 24 as the end date for the LC review period.
During the review period, the Web Notifications WG would
On Wed, 20 Jun 2012 15:07:27 +0200, Anne van Kesteren ann...@annevk.nl
wrote:
On Wed, Jun 20, 2012 at 3:03 PM, Charles McCathieNevile
cha...@opera.com wrote:
In the default case yes. Can you use something to change that (a la
from-origin)?
I don't really see how. Do you have an example
Hi,
The Web Notifications WG is planning to move Web Notifications to W3C
Last Call meaning we don't intend to change it. But we might have
missed something and would therefore appreciate your review of
http://dvcs.w3.org/hg/notifications/raw-file/tip/Overview.html and any
comments you might have
On 20 June 2012 10:58, Anne van Kesteren ann...@annevk.nl wrote:
Hi,
The Web Notifications WG is planning to move Web Notifications to W3C
Last Call meaning we don't intend to change it. But we might have
missed something and would therefore appreciate your review of
http://dvcs.w3.org/hg
On 06/20/2012 11:58 AM, Anne van Kesteren wrote:
Hi,
The Web Notifications WG is planning to move Web Notifications to W3C
Last Call meaning we don't intend to change it. But we might have
missed something and would therefore appreciate your review of
http://dvcs.w3.org/hg/notifications/raw
On Wed, Jun 20, 2012 at 12:17 PM, Olli Pettay olli.pet...@helsinki.fi wrote:
Seems like tags are global. I think they should be per origin.
Yes I believe they should be.
http://dvcs.w3.org/hg/notifications/rev/563e9af218b9
Thanks,
--
Anne — Opera Software
http://annevankesteren.nl/
http
On Wed, 20 Jun 2012 14:30:08 +0200, Anne van Kesteren ann...@annevk.nl
wrote:
On Wed, Jun 20, 2012 at 12:17 PM, Olli Pettay olli.pet...@helsinki.fi
wrote:
Seems like tags are global. I think they should be per origin.
Yes I believe they should be.
http://dvcs.w3.org/hg/notifications/rev
On Wed, Jun 20, 2012 at 3:03 PM, Charles McCathieNevile
cha...@opera.com wrote:
In the default case yes. Can you use something to change that (a la
from-origin)?
I don't really see how. Do you have an example where it makes sense?
--
Anne — Opera Software
http://annevankesteren.nl/
On Wed, Jun 20, 2012 at 5:30 AM, Anne van Kesteren ann...@annevk.nl wrote:
On Wed, Jun 20, 2012 at 12:17 PM, Olli Pettay olli.pet...@helsinki.fi
wrote:
Seems like tags are global. I think they should be per origin.
Yes I believe they should be.
http://dvcs.w3.org/hg/notifications/rev
On Wed, Jun 20, 2012 at 3:25 PM, John Gregg john...@google.com wrote:
Can we either go back to the original language where in the showing
algorithm you compare both tag and origin (add origin to the model),
Sure.
http://dvcs.w3.org/hg/notifications/rev/93c6983ce465
--
Anne — Opera Software
On Wed, Jun 20, 2012 at 3:17 AM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 06/20/2012 11:58 AM, Anne van Kesteren wrote:
Hi,
The Web Notifications WG is planning to move Web Notifications to W3C
Last Call meaning we don't intend to change it. But we might have
missed something and would
On Wed, Jun 20, 2012 at 2:36 PM, Andrew Wilson atwil...@google.com wrote:
On Wed, Jun 20, 2012 at 3:17 AM, Olli Pettay olli.pet...@helsinki.fi wrote:
On 06/20/2012 11:58 AM, Anne van Kesteren wrote:
Hi,
The Web Notifications WG is planning to move Web Notifications to W3C
Last Call meaning
Hi All,
I've been playing with the webkit notifications API while creating a
chrome-extension. I wanted to raise my concern that I think non-interactive
notifications are unintuitive for some/most scenarios. I understand that
using HTML notifications you can add links/buttons so the user can
Please use the public-web-notification list for the Web Notifications
spec.
John - I think it would be helpful if you would include a note about
public-web-notification in the Status of Document section.
-ArtB
Original Message
Subject:Interacting
The public-web-notification Mail List was created for the Web
Notifications spec and the ML's archive is available at:
http://lists.w3.org/Archives/Public/public-web-notification/
The above includes a subscribe to this list link.
Original Message
Subject:[Work
On Tue, Mar 23, 2010 at 4:53 PM, Ryan Seddon seddon.r...@gmail.com wrote:
On Tue, Mar 23, 2010 at 1:06 PM, John Gregg john...@google.com wrote:
After the extensive discussion several weeks ago, I've been working on a
new draft for Web Notifications which is now available at
http://dev.w3.org
On Tue, 23 Mar 2010 03:06:45 +0100, John Gregg john...@google.com wrote:
After the extensive discussion several weeks ago, I've been working on a
new draft for Web Notifications which is now available at
http://dev.w3.org/2006/webapi/WebNotifications/publish/
The Web IDL should be cleaned up
This looks good. One thing which I suggested previously but which didn't
make it into the spec is the ability for the UA to eliminate duplicate
notifications. Since I've been using the existing experimental notifications
API in Chrome, I've found that duplicate notifications are very common
On Tue, Mar 23, 2010 at 1:06 PM, John Gregg john...@google.com wrote:
After the extensive discussion several weeks ago, I've been working on a
new draft for Web Notifications which is now available at
http://dev.w3.org/2006/webapi/WebNotifications/publish/
Not sure if this has been asked
After the extensive discussion several weeks ago, I've been working on a new
draft for Web Notifications which is now available at
http://dev.w3.org/2006/webapi/WebNotifications/publish/
The most substantial changes are:
- Add requirements section. This is derived from the wiki page which Doug
On Fri, Feb 12, 2010 at 5:06 AM, Henri Sivonen hsivo...@iki.fi wrote:
On Feb 10, 2010, at 20:35, John Gregg wrote:
I agree that this is a good distinction, but I think even considering
ambient notifications there is a question of how much interaction should be
supported. NotifyOSD
that we want to enable in these notifications). The
non-fallback proposals that have been put forward aren't acceptable to
me for the same reasons that Jonas is opposed to the fallback proposals
- we both have a different vision for what the requirements should be.
I'd like to see us focus on gaining some
This thread seems to have languished, and I'm trying to figure out how to
move forward here.
My understanding, grossly simplified, of the current state of the world is
this:
1. Some people have a desire to show HTML / interactive notifications, to
support use cases like remind me
)
that use SVG rather than HTML, which would benefit from these
interactive notifications... shouldn't we define a more generic
CreateWebNotification and pass an optional MIME Type parameter that
defaults to text/html (or some similar mechanism)?
I strongly agree with the sentiment that we
is
this:
1. Some people have a desire to show HTML / interactive notifications, to
support use cases like remind me of this calendar event again in 5 minutes
or Answer this call / hang up this call.
2. Some people have a concern that the proposed way to achieve 1, namely
allowing HTML, will result
*HTMLNotification? I understand that HTML is
really common, and that increasingly SVG can be used as part of HTML, but
there are lots of devices out there (TVs, mobiles, set-top boxes) that use
SVG rather than HTML, which would benefit from these interactive
notifications... shouldn't we define
Hi, Ian-
No need to apologize... HTML is a little bit more widely adopted than
SVG (I suspect that there are 10x as many HTML documents as SVG
documents on the Web).
It may be that only specifying text and HTML notifications is the best
way forward for now, I just wanted to make sure
On Tue, 23 Feb 2010 20:20:13 +0100, Ian Fette (イアンフェッティ)
ife...@google.com wrote:
CreateInteractiveNotification(in DOMString text-fallback, [Optional] in
DOMString MimeType1, [Optional] in DOMString NotificationFormat1,
[Optional]
in DOMString MimeType2, [Optional] NotificationFormat2, ...)
Am 23. Februar 2010 12:11 schrieb Anne van Kesteren ann...@opera.com:
On Tue, 23 Feb 2010 20:20:13 +0100, Ian Fette (イアンフェッティ)
ife...@google.com wrote:
CreateInteractiveNotification(in DOMString text-fallback, [Optional] in
DOMString MimeType1, [Optional] in DOMString NotificationFormat1,
Doug Schepers wrote (on 2/23/10 2:43 PM):
HTML is a little bit more widely adopted than
SVG (I suspect that there are 10x as many HTML documents as SVG
documents on the Web).
I've been told offlist that it may not be obvious that I was joking
here... 10x is an absurdly low figure... HTML is
2010/2/23 Ian Fette (イアンフェッティ) ife...@google.com
Am 23. Februar 2010 12:11 schrieb Anne van Kesteren ann...@opera.com:
On Tue, 23 Feb 2010 20:20:13 +0100, Ian Fette (イアンフェッティ)
ife...@google.com wrote:
CreateInteractiveNotification(in DOMString text-fallback, [Optional] in
DOMString
2010/2/23 Ian Fette (イアンフェッティ) ife...@google.com:
Am 23. Februar 2010 12:11 schrieb Anne van Kesteren ann...@opera.com:
On Tue, 23 Feb 2010 20:20:13 +0100, Ian Fette (イアンフェッティ)
ife...@google.com wrote:
CreateInteractiveNotification(in DOMString text-fallback, [Optional] in
DOMString
Am 23. Februar 2010 13:44 schrieb Jonas Sicking jo...@sicking.cc:
2010/2/23 Ian Fette (イアンフェッティ) ife...@google.com:
Am 23. Februar 2010 12:11 schrieb Anne van Kesteren ann...@opera.com:
On Tue, 23 Feb 2010 20:20:13 +0100, Ian Fette (イアンフェッティ)
ife...@google.com wrote:
on solutions until we had
agreement on requirements (specifically, the amount of interaction that we
want to enable in these notifications). The non-fallback proposals that have
been put forward aren't acceptable to me for the same reasons that Jonas is
opposed to the fallback proposals - we both have
On Feb 10, 2010, at 20:35, John Gregg wrote:
I agree that this is a good distinction, but I think even considering ambient
notifications there is a question of how much interaction should be
supported. NotifyOSD, for example, does not allow the user to take any
action in response
On Fri, Feb 12, 2010 at 5:06 AM, Henri Sivonen hsivo...@iki.fi wrote:
FWIW, Microsoft explicitly says notifications must be ignorable and don't
persist. Notifications aren't modal and don't require user interaction, so
users can freely ignore them. In Windows Vista® and later, notifications
notifications of multiple concurrent things the most. Furthermore, it seems
that notifications are becoming more a part of operating system platfroms.
For example, it looks like Windows 7 has a system API for displaying
notifications:
http://msdn.microsoft.com/en-us/library/ee330740%28VS.85%29.aspx
who install Growl are presumably the kind of users who care about
notifications of multiple concurrent things the most. Furthermore, it seems
that notifications are becoming more a part of operating system platfroms.
For example, it looks like Windows 7 has a system API for displaying
think there are some potentially conflicting goals for any of the HTML
APIs:
1) Providing a single lowest-common-denominator API that we can support
on
every single platform to provide the maximum amount of compatibility. For
notifications, pretty much every capable platform can display
I can't help but think the Growl issue is way overblown. I am the user who
uses Growl and also a GoogleTalkLabsEdition for Mac that pop ups nice
notifications about upcoming meetings, email and chat. Growl is connected to
IRC and something else (don't even remember). They both use top-right corner
On Feb 3, 2010, at 20:54, Drew Wilson wrote:
Following up on breaking out createHTMLNotification() and
createNotification() vs combining them into one large API - I believe the
intent is that a given user agent may not support all types of notifications
(for example, a mobile phone
not support all types of notifications
(for example, a mobile phone application may only support text + icon
notifications, not HTML notifications).
My main concern isn't mobile phones in the abstract but mapping to concrete
system-wide notification mechanisms: Growl and NotifyOSD on Mac and Ubuntu
We ran into this issue when mapping our own browser notifications to
platform notification APIs. For ambient notifications, you can't rely on the
user being able to click on the notification, because the notification might
time out and disappear on its own before the user has had a chance to react
not support all types of notifications
(for example, a mobile phone application may only support text + icon
notifications, not HTML notifications).
My main concern isn't mobile phones in the abstract but mapping to concrete
system-wide notification mechanisms: Growl and NotifyOSD on Mac and Ubuntu
On Thu, Feb 11, 2010 at 11:10 AM, Robert O'Callahan rob...@ocallahan.orgwrote:
We ran into this issue when mapping our own browser notifications to
platform notification APIs. For ambient notifications, you can't rely on the
user being able to click on the notification, because
to check for the existence of HTML support before calling these APIs -
UAs would always have a useful fallback.
The problem with that is that authors who test with a system that supports
HTML notifications could easily provide the wrong non-HTML message, or no
message at all, and not notice
createHTMLNotification() would break the web because web applications would
fail to check for the existence of HTML support before calling these APIs -
UAs would always have a useful fallback.
The problem with that is that authors who test with a system that supports
HTML notifications could
with that is that authors who test with a system that supports
HTML notifications could easily provide the wrong non-HTML message, or no
message at all, and not notice. It also forces authors to say things twice.
Analogously, developers can (and do!) create pages that rely on javascript
or images being
for a plaintext-only
notification framework (possibly opting to fall back to non-native
notifications if the text extraction doesn't work). For example, you could
allow only b and img elements, and for text-only notifications you would
strip b and use the alt text for img, and if the author didn't provide
subset of
HTML, and then consider how the UA should extract text for a plaintext-only
notification framework (possibly opting to fall back to non-native
notifications if the text extraction doesn't work). For example, you could
allow only b and img elements, and for text-only notifications you
before calling these
APIs -
UAs would always have a useful fallback.
The problem with that is that authors who test with a system that
supports
HTML notifications could easily provide the wrong non-HTML message, or
no
message at all, and not notice. It also forces authors to say things
because web applications
would
fail to check for the existence of HTML support before calling these
APIs -
UAs would always have a useful fallback.
The problem with that is that authors who test with a system that
supports
HTML notifications could easily provide the wrong non-HTML message
. The history of the web has generally
been that good features spread to become ubiquitous, and if your concern is
that HTML notifications will become one of those features, then I echo your
concern :)
I think there are some potentially conflicting goals for any of the HTML
APIs:
1) Providing a single
a single lowest-common-denominator API that we can support on
every single platform to provide the maximum amount of compatibility. For
notifications, pretty much every capable platform can display an icon and a
single line of text, so if we wanted to be pedantic we could make that our
API
On Thu, 04 Feb 2010 00:36:26 +0100, John Gregg john...@google.com wrote:
I'm familiar with that version of the proposal (in fact my WHATWG
proposal from March '09 had the same language: untrusted notifications
displayed
in-browser), but considering it more I think it is too limiting
notifications
beforehand;
Aren't notifications by nature somewhat non-important?
Yes, but only if they aren't done well. I have notifications to remind me to
go to meetings, or when someone is trying to reach me in irc. These are very
important to me. oth, I may also have a notification about new
On Fri, Feb 5, 2010 at 6:52 AM, Anne van Kesteren ann...@opera.com wrote:
On Thu, 04 Feb 2010 00:36:26 +0100, John Gregg john...@google.com wrote:
I'm familiar with that version of the proposal (in fact my WHATWG proposal
from March '09 had the same language: untrusted notifications displayed
On Fri, 05 Feb 2010 19:19:24 +0100, Drew Wilson atwil...@google.com
wrote:
I've thought about this some more, and I'm not at all convinced that
in-tab notification support is the right way to go. It seems that in-tab
notifications are a solved problem already (in a few lines of code an app
notifications are a solved problem already (in a few lines of code an app
can create a floating div with whatever content it desires) with the
advantage that the web app can display that notification in a way that is
consistent with the UI in the site (set the notification so
permission in
advance could just call createNotification(), but then never actually call
show() (or, perhaps they could just display a confirmation notification like
Desktop notifications are now enabled for FooMail). As someone who has
integrated notifications into a web app, I have to say that I
added createNotification to window object,
or to .screen.
createNotification and createHTMLNotification could be
merged. Based on the parameters UA could create
a bit different kinds of notifications.
Or depending on what kind of resources get loaded.
PERMISSION_NOT_ALLOWED vs. PERMISSION_DENIED
createNotification to window object,
or to .screen.
The idea was to have a common place to manage notification permissions as
well as create notifications. That would end up with a lot of
notifications-specific items on the window object.
createNotification and createHTMLNotification could
Following up on breaking out createHTMLNotification() and
createNotification() vs combining them into one large API - I believe the
intent is that a given user agent may not support all types of notifications
(for example, a mobile phone application may only support text + icon
notifications
strange. Why do we need
a separate interface for this?
I'd rather added createNotification to window object,
or to .screen.
The idea was to have a common place to manage notification permissions as
well as create notifications. That would end up with a lot of
notifications-specific items
On 2/3/10 8:33 PM, John Gregg wrote:
I will make this more specific in the draft: create[HTML]Notification
should not load the necessary resources until it is about to be
displayed (in case of a queue). Once it is at the top of the queue, it
should:
- load its resources as if opening a new
On 2/3/10 8:55 PM, Jeremy Orlow wrote:
Agreed. Having a shared worker that doesn't need to worry about races
with shutting down windows seems like a big win.
Olli, do you foresee any problems with allowing access from workers?
In a multiscreen environment worker can't define which screen to
.
I have no particular attachment to the name, but would prefer to be agnostic
as to the presentation for non-HTML notifications. Leaving open the
possibility that a user-agent routes this API to a third-party text+icon
notification library, it's not a window and it's a different notion than
load
On Wed, Feb 3, 2010 at 10:58 AM, Olli Pettay olli.pet...@helsinki.fiwrote:
On 2/3/10 8:55 PM, Jeremy Orlow wrote:
Agreed. Having a shared worker that doesn't need to worry about races
with shutting down windows seems like a big win.
Olli, do you foresee any problems with allowing access
On Wed, Feb 3, 2010 at 10:55 AM, Olli Pettay olli.pet...@helsinki.fiwrote:
On 2/3/10 8:33 PM, John Gregg wrote:
I will make this more specific in the draft: create[HTML]Notification
should not load the necessary resources until it is about to be
displayed (in case of a queue). Once it is at
That's true in general about any UI the worker may display (HTTP Auth,
Certificate errors, etc) - the UA generally picks a parent document on
behalf of the worker and displays the UI on the associated screen.
If the client cares about which screen specifically it's displaying on
(because it has
On Wed, 03 Feb 2010 18:55:32 +0100, Olli Pettay olli.pet...@helsinki.fi
wrote:
NotificationCenter is a bit strange. Why do we need
a separate interface for this?
I'd rather added createNotification to window object,
or to .screen.
Shouldn't it be on navigator? We use navigator for other
On Wed, 03 Feb 2010 19:54:44 +0100, Drew Wilson atwil...@google.com
wrote:
Following up on breaking out createHTMLNotification() and
createNotification() vs combining them into one large API - I believe the
intent is that a given user agent may not support all types of
notifications
On Wed, Feb 3, 2010 at 11:38 AM, Anne van Kesteren ann...@opera.com wrote:
On Wed, 03 Feb 2010 18:55:32 +0100, Olli Pettay olli.pet...@helsinki.fi
wrote:
NotificationCenter is a bit strange. Why do we need
a separate interface for this?
I'd rather added createNotification to window object,
I'm not entirely certain I understand this suggestion - is this just a
change to the spec language, or does it impact the actual API (i.e. would
webapps still do the following):
if ('createHTMLNotifications' in window.notifications) {
...html notifications exist...
}
Or are you proposing
is that a given user agent may not support all types of
notifications
(for example, a mobile phone application may only support text + icon
notifications, not HTML notifications). Having these APIs broken out
separately allows the UA to communicate whether it supports one or the
other
to the web
notifications can implement to make it clear it might not be available
and that is somewhat separate. (Not sure whether I agree we need HTML
notifications though, especially for v1.)
I'd be okay with using a separate interface if it is the more clear way
make something optional in the spec
On Wed, 03 Feb 2010 20:52:18 +0100, Jeremy Orlow jor...@chromium.org
wrote:
On Wed, Feb 3, 2010 at 11:38 AM, Anne van Kesteren ann...@opera.com
wrote:
On Wed, 03 Feb 2010 18:55:32 +0100, Olli Pettay
olli.pet...@helsinki.fi
wrote:
NotificationCenter is a bit strange. Why do we need
a
On Wed, 03 Feb 2010 18:55:32 +0100, Olli Pettay olli.pet...@helsinki.fi
wrote:
some random comments about
http://dev.w3.org/2006/webapi/WebNotifications/publish/
(I didn't know that the draft existed until the link was mentioned
in an email to @whatwg mailing list :/ )
Some other thoughts
that an error
callback from createNotification() is sufficient as you generally want to
initiate the permission grant *in advance* of displaying notifications. As
an example, allow me to describe the following use case:
A web mail program would like to display desktop notifications when new mail
Notifications should do the same.
* I'm not a big fan of introducing two new ways to load resources as
proposed in this API. We are not doing that elsewhere either (consider e.g.
drawImage()). Passing a Document and HTMLImageElement (potentially
HTMLCanvasElement and HTMLVideoElement too I suppose
to display permissions UI in advance of having a
notification to show.
The design Hixie once made for notifications was much nicer I thought.
Initially you would get tab-scoped in-browser notifications but the user
could opt-in (maybe when the first of such notifications was shown) into
system
is important for the same reasons as Drew gave: the site should know whether
to display permissions UI in advance of having a notification to show.
The design Hixie once made for notifications was much nicer I thought.
Initially you would get tab-scoped in-browser notifications but the user
could opt
the initial implementation for Chrome, but I've posted a
draft version of a spec for notifications to
http://sites.google.com/a/chromium.org/dev/developers/design-
documents/desktop-notifications/api-specification
I think that's a good starting point for formalizing it.
I think this API would likely
of a spec for notifications to
http://sites.google.com/a/chromium.org/dev/developers/design-documents/desktop-notifications/api-specification
I think that's a good starting point for formalizing it.
I think this API would likely fit under the “User Interaction API”
http://www.w3.org/2009/05
completing the initial implementation for Chrome, but I've posted a
draft version of a spec for notifications to
http://sites.google.com/a/chromium.org/dev/developers/design-documents/desktop-notifications/api-specification
I think that's a good starting point for formalizing it.
I think
Apologies for the delay, I've been spending the majority of my time
completing the initial implementation for Chrome, but I've posted a draft
version of a spec for notifications to
http://sites.google.com/a/chromium.org/dev/developers/design-documents/desktop-notifications/api-specification
I
John Gregg wrote:
Hi Marcos,
I'm doing the implementation for Chromium so I'm pretty familiar with
notifications. Although I'm fairly new to the process, I would be happy
to volunteer to help, since I would definitely like to see a new
notifications spec come together.
Great
Hi Marcos,
I'm doing the implementation for Chromium so I'm pretty familiar with
notifications. Although I'm fairly new to the process, I would be happy to
volunteer to help, since I would definitely like to see a new notifications
spec come together.
-John
On Fri, Sep 4, 2009 at 9:35 AM
to be used on the Web, I'm wondering if we should spawn
a separate specification for notifications? We could use the current
text in the AE [1] as the basis, which is based heavily on what was
originally in HTML5 (or just take the old HTML5 text, create the new
spec, add the hooks
-related
technologies to be used on the Web, I'm wondering if we should spawn
a separate specification for notifications? We could use the current
text in the AE [1] as the basis, which is based heavily on what was
originally in HTML5 (or just take the old HTML5 text, create
Ian Fette (イアンフェッティ) wrote:
We are in the middle of implementing in WebKit and in Chromium, so yes
we are still interested in pursuing. John Gregg (johnnyg@) has been
leading the effort from our end.
Beyond an implementation that people can experiment with, what sort of
resources are you
for notifications? We could use the current
text in the AE [1] as the basis, which is based heavily on what was
originally in HTML5 (or just take the old HTML5 text, create the new
spec, add the hooks for Widgets).
Although notifications have been taken out of HTML5, rumblings
1 - 100 of 102 matches
Mail list logo
