- From: Brady Eidson <notifications@github.com>
- Date: Wed, 18 Oct 2023 09:28:27 -0700
- To: w3c/push-api <push-api@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
Received on Wednesday, 18 October 2023 16:28:32 UTC
> …should this allow notification payloads with just `"data"`? The use case would be apps that keep settings like, say, the chosen app language purely on the client. For example, for an airline travel app, this would allow the server to send a notification with a `"data"` object like… I don't think so. Because as you mention: > This of course requires allowing script execution, so may be out of scope slightly. The primary goal here is that a payload *always* represents a user visible action the platform or user agent can take without javascript. A "data only" message that's immutable would, of course, be a no-op. A "data only" message that's mutable could be processed by SW javascript, but doesn't have the user visible fallback that is required by the proposal. e.g. if the JS failed to display a notification, the UA wouldn't have the default message to display. A "data only message that absolutely requires JS to display the notification" is actually a precise description of existing web push, which lives side-by-side with the declarative model. -- Reply to this email directly or view it on GitHub: https://github.com/w3c/push-api/issues/360#issuecomment-1768911953 You are receiving this because you are subscribed to this thread. Message ID: <w3c/push-api/issues/360/1768911953@github.com>
Received on Wednesday, 18 October 2023 16:28:32 UTC