On Fri, Jul 11, 2014 at 12:57 AM, Andrew Wilson <atwil...@google.com> wrote:
> On Fri, Jul 11, 2014 at 2:30 AM, Jonas Sicking <jo...@sicking.cc> wrote:
>> On Thu, Jul 10, 2014 at 1:04 AM, Andrew Wilson <atwil...@google.com>
>> wrote:
>> >
>> > On Thu, Jul 10, 2014 at 5:44 AM, Jonas Sicking <jo...@sicking.cc> wrote:
>> >>
>> >> Hi All,
>> >>
>> >> We've on and off discussed various features added to notifications.
>> >> It'd be great to move forward with some of these improvements.
>> >>
>> >> I think the most low hanging fruit would be to add the following as
>> >> data that can be displayed in a notification:
>> >>
>> >> * Progress bar
>> >> * Lists of title/body pairs
>> >> * Date (for things like "event will happen in 10 minutes")
>> >>
>> >
>> > So, many of these cases were what the original HTMLNotification API was
>> > supposed to address. This was eventually shot down for a number of
>> > (good)
>> > reasons: too much complexity on the implementation side, and more
>> > importantly, the fact that these more complex notifications aren't
>> > compatible with various platform notification frameworks and so this
>> > would
>> > be a source of platform/UA incompatibility. It's not clear to me that
>> > re-adding support for these use cases one at a time as distinct
>> > notification
>> > types is really a good path forward, or that it's necessarily
>> > "low-hanging
>> > fruit" unless we have a good idea for how to deal with the
>> > platform-compatibility issue.
>> Actually, given that the UA has a very high degree of semantic
>> understanding of these properties, I think it should be doable to
>> implement on top of all existing platform notification systems. In all
>> of the above cases you can come up with a reasonable string to add to
>> the end to render the content. This is what pages have to do right now
>> anyway.
> I had assumed from the examples you gave that the goal of these new
> notification types was to have dynamically updating notifications (progress
> bar, timestamps that update with a countdown to an event, etc), which it
> wasn't clear could be cleanly implemented across all platform notification
> systems without significant jank.

For dates the idea is definitely to enable the notifications to be
dynamically updated by the platform.

For progress bars my expectation was not that it would be
automatically updated. Instead it would be updated using the exact
same mechanism that we have for notifications today, i.e. using the
"tag" mechanism. So the jank would be the same whether OS
notifications supports rendering progress bars or if they are just
able to render text.

For lists the idea is not to update them any more or less than for
plain text content. Just like with text content pages will likely want
to update them occasionally, but that's not a core aspect of the

> The intent for things like progress bars
> would be that they have greater visibility than your typical "5 seconds and
> then hidden" email notification, which also may not be doable with many
> notification frameworks.

This is a quite interesting idea. I hadn't thought of that.

> I'm slightly dubious about adding
> new semantic notification types (I'd still rather give app developers the
> tools to build their own richer notifications instead of giving them a
> canned set), but it's definitely worth discussing further.

I'm not sure I understand this argument. If you are concerned about
having poor fallback on platforms that can't render the UI components
discussed above, then surely that concern is even greater if we enable
pages to build their own rich notifications?

My goal has been two-fold:
* Don't limit the web to the lowest common denominator of the
platforms on which it runs.
* Don't encourage pages that simply don't work unless you use the right OS.

The "pre canned" capabilities enable us to on OSs that have advanced
capabilities enable web developers to take advantage of those for the
most commonly requested notification content. While still enabling
users on OSs that don't have such capabilities to still get a useful

/ Jonas

Reply via email to