- From: Jonas Sicking <jonas@sicking.cc>
- Date: Fri, 8 Aug 2014 16:30:12 -0700
- To: Peter Beverloo <beverloo@google.com>
- Cc: WHAT Working Group <whatwg@whatwg.org>, Andrew Wilson <atwilson@google.com>
On Fri, Aug 8, 2014 at 5:48 AM, Peter Beverloo <beverloo@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
Received on Friday, 8 August 2014 23:31:07 UTC