On Fri, Aug 8, 2014 at 5:48 AM, Peter Beverloo <bever...@google.com> wrote:
> I think the benefit of being able to closely match the UI and UX of native
> notifications on the platforms is something that's enabled by using
> declarative properties, whereas that would be near impossible to do with
> HTML notifications. As long as advanced features, especially more compatible
> ones (say, buttons or timestamps) can be feature detected by developers so
> that they can provide a fallback when they're not available, I would be in
> favor of extending the future set with Jonas' declarative proposals.

Cool! I had not though about the need to feature detect. At least for
progress/list/timestamp. My thinking had been to require that the UA
provide a textual fallback on platforms that can't render those
widgets natively.

However I think you are right that we'll need feature detection here.
We might even need two types of it.

First of all not all UAs are going to implement all of these features
right away. So obviously they won't provide any fallback rendering
either. Detecting this seems important.

Second, it might be good to enable pages to detect platforms where a
progress bar is rendered as a native progress bar, rather than as text
fallback. This way the page can choose not to use a progress bar and
instead create its own fallback.

An important point here is for pages that don't choose to test for the
latter, will still get a useful rendering of the notification.

/ Jonas

Reply via email to