On Mon, Aug 11, 2014 at 9:27 AM, Andrew Wilson <atwil...@google.com> wrote:
> On Fri, Aug 8, 2014 at 2:48 PM, Peter Beverloo <bever...@google.com>
> wrote:
> > Hi Andrew,
> >
> > On Wed, Aug 6, 2014 at 12:59 PM, Andrew Wilson <atwil...@google.com>
> wrote:
> >>
> >> On Wed, Aug 6, 2014 at 12:48 PM, Anne van Kesteren <ann...@annevk.nl>
> >> wrote:
> >> > On Wed, Aug 6, 2014 at 10:08 AM, Andrew Wilson <atwil...@google.com>
> >> > wrote:
> >> >> I understand your concern that is driving this proposal: you don't
> >> >> want to provide rich APIs that can't be well implemented on every
> >> >> platform, and thereby fragment the web platform. I just don't want to
> >> >> see us go down this path of adding these new notification types that
> >> >> are so limited in ability that people will just keep using general
> >> >> notifications anyway - I'd rather just stick with the existing API.
> >> >
> >> > Are you unenthusiastic about any of the proposed additions (what about
> >> > those already added?) or is this more about the more "complex"
> >> > features such as indication of progress?
> >>
> >> I'm (somewhat) unenthusiastic about the new semantic types, because
> >> I'm not sure they'd get enough uptake to be worth the effort to
> >> implement (note that this is just my personal opinion - I'm no longer
> >> as heavily involved in the notification work within Chromium, so Peter
> >> B's opinion carries much more weight than mine when it comes to
> >> determining what we'd implement).
> >
> >
> > I find myself being in favor of the semantic types.
> >
> > The primary reason for this is that it allows us to provide a much more
> > consistent user experience, especially on platforms where we don't
> control
> > rendering of the notification, compared to HTML notifications. On Chrome
> for
> > Android we want to provide for a consistent user experience, where
> > notifications should be visually indistinguishable (aside from clarifying
> > the origin) from those created by native apps. The proposed semantic
> types
> > would get us there.
> >
> > Furthermore, support for HTML notifications will be much more difficult
> to
> > implement across the board. Some mobile OSes, notably Firefox OS and iOS,
> > wouldn't support this at all. Others, such as Android, theoretically
> could
> > support it, but won't because it means creating an entire WebView --
> causing
> > very significant memory pressure on already resource constrained devices.
>
> To be clear, I'm not arguing for HTML notifications - as I said in my
> original post to this thread, HTML notifications were removed from the
> spec for various good reasons. But I think it's a mistake to just bake
> in canned notification types. What if a developer wants a progress bar
> with a cancel button? A progress bar with a timestamp? A list
> notification that contains an event with timestamp? Or some other
> different notification that doesn't specifically match one of your
> curated templates, but could easily be built if you gave him a
> lower-level set of primitives?
You raise an interesting question. Given the following notification:
var notification = new Notification('Title', {
body: 'Hello, world!',
icon: '/my-icon.png',
items: [
{ title: 'Message 1', body: 'Contents of message 1' },
{ title: 'Message 2', body: 'Contents of message 2' },
{ title: 'Message 3', body: 'Contents of message 3' }
],
buttons: [
'Reply',
'Reply to all',
'Forward'
],
date: new Date('2014-08-11T16:35:00'),
progress: 40
});
What do we expect to be displayed?
I *think* Android can mix and match some of those, but expect at least
progress bars and lists of items to be mutually exclusive. I don't have a
good answer for this right now. UAs rendering their own notifications could
support this more easily, but it will still raise interesting UX questions.
Thanks,
Peter
