Re: Thoughts on WebNotification
On Fri, Jun 25, 2010 at 5:34 AM, Jeremy Orlow jor...@chromium.org wrote:
On Thu, Jun 24, 2010 at 7:38 PM, Doug Turner doug.tur...@gmail.com wrote:
I have been thinking a bit on Desktop Notifications [1]. After reviewing
the Web Notification specification [2], I would like to propose the
following changes:
1) Factor out the permission api into a new interface and/or spec. The
ability to test for a permission without bring up a UI would improve the UX
of device access. I could imagine implementing this feature for use with
Geolocation as well as notifications. For example:
interface Permissions {
// permission values
const unsigned long PERMISSION_ALLOWED = 0;
const unsigned long PERMISSION_UNKNOWN = 1;
const unsigned long PERMISSION_DENIED = 2;
void checkPermission(in DOMString type, in Function callback);
}
Then we could do something like:
navigator.permissions.checkPermission(desktop-notification,
function(value) {});
or
navigator.permissions.checkPermission(geolocation, function(value) {});
2) Add language to the spec to indicate that the DOMStrings used
|createNotification| are not to include any mark up. Basically,
implementations are going to hand off notifications to system-level
services. For example, on the Mac, GROWL does not handle any mark up...
their API just takes plain strings. I'd like to see the API reflect this
reality. Something like the |title| and |body| arguments are to be treated
as plain text... or some such language.
3) Move Web notifications to a version 2 of the specification. For the
most basic use cases, this API isn't required and a web developer could use
the more base API to simulate this. Furthermore, as I mentioned above, many
system-level notification services know nothing about rendering html.
I'm happy with this course of action, but first I wanted to ask why not the
gracefully degrade suggestion from the Notifications thread started on
the 3rd of Feb. As far as I can tell, it was never seriously considered,
but several of us brought it up. And I feel like it'd be a much better way
forward than having a different interface for html based notifications and
text notifications.
(The basic idea was to accept either text or html and then if it's the
latter and the notification scheme doesn't support it, we'd use some simple,
specced heuristics to extract data to be used. In the thread, there were
some specific ideas about how the transformations could work. But from a
quick skim, I couldn't find any reasons why it was a bad idea.)
I think history has showed that optional features generally work
pretty poorly. While there are decent heuristics available to extract
textual data from html, I doubt that they'll be good enough. For
example I suspect that people will send notifications like:
You've got mail. Click a href=...here/a to read it
img src='...'
Would you like to take our survey?form ...input name=answer
type=submit value=yesinput name=answer type=submit value=no/form
/ Jonas
Re: Thoughts on WebNotification
On Sat, Jun 26, 2010 at 10:47 AM, Jonas Sicking jo...@sicking.cc wrote:
On Fri, Jun 25, 2010 at 5:34 AM, Jeremy Orlow jor...@chromium.org wrote:
On Thu, Jun 24, 2010 at 7:38 PM, Doug Turner doug.tur...@gmail.com
wrote:
I have been thinking a bit on Desktop Notifications [1]. After
reviewing
the Web Notification specification [2], I would like to propose the
following changes:
1) Factor out the permission api into a new interface and/or spec. The
ability to test for a permission without bring up a UI would improve the
UX
of device access. I could imagine implementing this feature for use
with
Geolocation as well as notifications. For example:
interface Permissions {
// permission values
const unsigned long PERMISSION_ALLOWED = 0;
const unsigned long PERMISSION_UNKNOWN = 1;
const unsigned long PERMISSION_DENIED = 2;
void checkPermission(in DOMString type, in Function callback);
}
Then we could do something like:
navigator.permissions.checkPermission(desktop-notification,
function(value) {});
or
navigator.permissions.checkPermission(geolocation, function(value)
{});
2) Add language to the spec to indicate that the DOMStrings used
|createNotification| are not to include any mark up. Basically,
implementations are going to hand off notifications to system-level
services. For example, on the Mac, GROWL does not handle any mark up...
their API just takes plain strings. I'd like to see the API reflect
this
reality. Something like the |title| and |body| arguments are to be
treated
as plain text... or some such language.
3) Move Web notifications to a version 2 of the specification. For the
most basic use cases, this API isn't required and a web developer could
use
the more base API to simulate this. Furthermore, as I mentioned above,
many
system-level notification services know nothing about rendering html.
I'm happy with this course of action, but first I wanted to ask why not
the
gracefully degrade suggestion from the Notifications thread started
on
the 3rd of Feb. As far as I can tell, it was never seriously considered,
but several of us brought it up. And I feel like it'd be a much better
way
forward than having a different interface for html based notifications
and
text notifications.
(The basic idea was to accept either text or html and then if it's the
latter and the notification scheme doesn't support it, we'd use some
simple,
specced heuristics to extract data to be used. In the thread, there were
some specific ideas about how the transformations could work. But from a
quick skim, I couldn't find any reasons why it was a bad idea.)
I think history has showed that optional features generally work
pretty poorly. While there are decent heuristics available to extract
textual data from html, I doubt that they'll be good enough. For
example I suspect that people will send notifications like:
You've got mail. Click a href=...here/a to read it
img src='...'
Would you like to take our survey?form ...input name=answer
type=submit value=yesinput name=answer type=submit value=no/form
Which proposal are you in favor of then? Your first paragraph seems to
agree with me and your second (which is fairly compelling) seems to
disagree.
J
Re: Thoughts on WebNotification
On Thu, Jun 24, 2010 at 1:29 PM, Doug Turner doug.tur...@gmail.com wrote: Hey Drew, I think this is too vague, as it's sounds like a user agent could *not* ignore markup in the string, and still be compliant with the spec. I think we need to be very explicit that the string *must* be treated as plain text. So if I pass in gt;bfoo/b as the body parameter to createNotification(), the resulting notification must display the string gt;bfoo/b, without stripping or converting any of the substrings that might look like HTML entities. Yup. we should tighten up the language. i think we are on the same page here. I definitely like the direction this is heading. If we tighten the language up I would be all for supporting this in firefox. It still needs to pass through our usual security review and all that, but I suspect we can make something work. / Jonas
Re: Thoughts on WebNotification
On Jun 24, 2010, at 21:00 , Doug Turner wrote:
On Jun 24, 2010, at 11:48 AM, John Gregg wrote:
interface Permissions {
// permission values
const unsigned long PERMISSION_ALLOWED = 0;
const unsigned long PERMISSION_UNKNOWN = 1;
const unsigned long PERMISSION_DENIED = 2;
Small nit, but can we have string constants instead (allowed, denied,
unknown)? They usually turn out to either be less typing or more readable
depending on whether one uses Permissions.PERMISSION_ALLOWED or 1.
so, checkPermission and requestPermission. I am happy with that..
+1
navigator.permissions.requestPermission(geolocation,desktop-notification,...).
I'd make it an array [geolocation, notifications] but yeah.
The bigger question is, are other features interested? Would the
Geolocation spec consider using something like this for permissions?
cc'ing Andrei Popescu - the editor of the Geolocation spec. Not sure how to
formally answer your question. However, if the permission api above was
implemented, I think it naturally follows that geolocation would be one of
the known strings.
DAP would be interested. To talk process a little bit: if we want to make this
into a spec it needs a home. In case WebApps can't or won't take it (given how
complicated rechartering it already is), DAP seem like a natural home for it.
I'd have to ask the group of course but I'm in favour.
--
Robin Berjon - http://berjon.com/
Re: Thoughts on WebNotification
On Jun 24, 2010, at 20:38 , Doug Turner wrote: 3) Move Web notifications to a version 2 of the specification. For the most basic use cases, this API isn't required and a web developer could use the more base API to simulate this. Furthermore, as I mentioned above, many system-level notification services know nothing about rendering html. I agree that it's better to move optional features to a v2 (or additional module). It's not a huge deal but it does help make test suites simpler and keeps complexity out of the core document. -- Robin Berjon - http://berjon.com/
Re: Thoughts on WebNotification
On Thu, Jun 24, 2010 at 7:38 PM, Doug Turner doug.tur...@gmail.com wrote:
I have been thinking a bit on Desktop Notifications [1]. After reviewing
the Web Notification specification [2], I would like to propose the
following changes:
1) Factor out the permission api into a new interface and/or spec. The
ability to test for a permission without bring up a UI would improve the UX
of device access. I could imagine implementing this feature for use with
Geolocation as well as notifications. For example:
interface Permissions {
// permission values
const unsigned long PERMISSION_ALLOWED = 0;
const unsigned long PERMISSION_UNKNOWN = 1;
const unsigned long PERMISSION_DENIED = 2;
void checkPermission(in DOMString type, in Function callback);
}
Then we could do something like:
navigator.permissions.checkPermission(desktop-notification,
function(value) {});
or
navigator.permissions.checkPermission(geolocation, function(value) {});
2) Add language to the spec to indicate that the DOMStrings used
|createNotification| are not to include any mark up. Basically,
implementations are going to hand off notifications to system-level
services. For example, on the Mac, GROWL does not handle any mark up...
their API just takes plain strings. I'd like to see the API reflect this
reality. Something like the |title| and |body| arguments are to be treated
as plain text... or some such language.
3) Move Web notifications to a version 2 of the specification. For the
most basic use cases, this API isn't required and a web developer could use
the more base API to simulate this. Furthermore, as I mentioned above, many
system-level notification services know nothing about rendering html.
I'm happy with this course of action, but first I wanted to ask why not the
gracefully degrade suggestion from the Notifications thread started on
the 3rd of Feb. As far as I can tell, it was never seriously considered,
but several of us brought it up. And I feel like it'd be a much better way
forward than having a different interface for html based notifications and
text notifications.
(The basic idea was to accept either text or html and then if it's the
latter and the notification scheme doesn't support it, we'd use some simple,
specced heuristics to extract data to be used. In the thread, there were
some specific ideas about how the transformations could work. But from a
quick skim, I couldn't find any reasons why it was a bad idea.)
J
Re: Thoughts on WebNotification
On Thu, Jun 24, 2010 at 8:00 PM, Doug Turner doug.tur...@gmail.com wrote:
Thank you for your quick response!
On Jun 24, 2010, at 11:48 AM, John Gregg wrote:
On Thu, Jun 24, 2010 at 11:38 AM, Doug Turner doug.tur...@gmail.com wrote:
I have been thinking a bit on Desktop Notifications [1]. After reviewing
the Web Notification specification [2], I would like to propose the
following changes:
1) Factor out the permission api into a new interface and/or spec. The
ability to test for a permission without bring up a UI would improve the UX
of device access. I could imagine implementing this feature for use with
Geolocation as well as notifications. For example:
interface Permissions {
// permission values
const unsigned long PERMISSION_ALLOWED = 0;
const unsigned long PERMISSION_UNKNOWN = 1;
const unsigned long PERMISSION_DENIED = 2;
void checkPermission(in DOMString type, in Function callback);
}
Then we could do something like:
navigator.permissions.checkPermission(desktop-notification,
function(value) {});
or
navigator.permissions.checkPermission(geolocation, function(value) {});
I like this idea, I think it's definitely preferable to a one-off permission
system just for notifications.
Your proposal doesn't have a way to explicitly request permission. Would
you be willing to add that, with the recommendation that it only take place
on a user gesture? I don't think this eliminates the ability to implement
request-on-first-use, if that's what Mozilla prefers, but I also still think
there is benefit to allowing permissions to be obtained separately from
invoking the API in question.
so, checkPermission and requestPermission. I am happy with that..
and
if really want to get crazy, we could do something like:
navigator.permissions.requestPermission(geolocation,desktop-notification,...).
This would allow a site to request multiple permissions in one go up to
the implementation if this is supported (i'd argue), and up to the
implementation on how best to handle these requests.
The bigger question is, are other features interested? Would the
Geolocation spec consider using something like this for permissions?
cc'ing Andrei Popescu - the editor of the Geolocation spec. Not sure how to
formally answer your question. However, if the permission api above was
implemented, I think it naturally follows that geolocation would be one of
the known strings.
I think it's reasonable. On the other hand, do you think the Geo spec
needs changing to allow this? As I read it, I think it already allows
it.
Thanks,
Andrei
Re: Thoughts on WebNotification
cc'ing Andrei Popescu - the editor of the Geolocation spec. Not sure how to formally answer your question. However, if the permission api above was implemented, I think it naturally follows that geolocation would be one of the known strings. I think it's reasonable. On the other hand, do you think the Geo spec needs changing to allow this? As I read it, I think it already allows it. Clearly no. Just wanted to give you a heads up.
Re: Thoughts on WebNotification
On Thu, Jun 24, 2010 at 1:29 PM, Doug Turner doug.tur...@gmail.com wrote: Hey Drew, I think this is too vague, as it's sounds like a user agent could *not* ignore markup in the string, and still be compliant with the spec. I think we need to be very explicit that the string *must* be treated as plain text. So if I pass in gt;bfoo/b as the body parameter to createNotification(), the resulting notification must display the string gt;bfoo/b, without stripping or converting any of the substrings that might look like HTML entities. Yup. we should tighten up the language. i think we are on the same page here. It's actually more complicated given the various platform behavior. While Growl doesn't interpret markup, NotifyOSD on linux does allow some markup in its notifications (lt; shows , for example) [1, section 5]. So it's not sufficient to just pass the string directly, it has to be escaped in order to present the exact text provided. So perhaps, the user agent must display the string as plain text, without interpreting markup; if using a notification platform which does interpret markup, the user agent should modify the string so that any markup is shown rather than interpreted. [1] https://wiki.ubuntu.com/NotificationDevelopmentGuidelines
Re: Thoughts on WebNotification
I'm happy with this course of action, but first I wanted to ask why not the gracefully degrade suggestion from the Notifications thread started on the 3rd of Feb. As far as I can tell, it was never seriously considered, but several of us brought it up. And I feel like it'd be a much better way forward than having a different interface for html based notifications and text notifications. (The basic idea was to accept either text or html and then if it's the latter and the notification scheme doesn't support it, we'd use some simple, specced heuristics to extract data to be used. In the thread, there were some specific ideas about how the transformations could work. But from a quick skim, I couldn't find any reasons why it was a bad idea.) J There were actually several ways considered to combine the interfaces: - We can a have a method createNotification(text, body, icon, URL) which uses the URL parameter if supported and text/body/icon parameters to be used as the backup if HTML content is not supported (I call this the alt text option). - We can allow the API to take a URL, load that resource and read some meta information from it, such as the title tag. (the title tag option). I prefer the alt text option between these two, because it is much simpler to implement for browsers that don't want to support HTML notifications and would also be better performing, since it doesn't require the resource load. -John
Re: Thoughts on WebNotification
On Jun 25, 2010, at 8:39 AM, John Gregg wrote: On Thu, Jun 24, 2010 at 1:29 PM, Doug Turner doug.tur...@gmail.com wrote: Hey Drew, I think this is too vague, as it's sounds like a user agent could *not* ignore markup in the string, and still be compliant with the spec. I think we need to be very explicit that the string *must* be treated as plain text. So if I pass in gt;bfoo/b as the body parameter to createNotification(), the resulting notification must display the string gt;bfoo/b, without stripping or converting any of the substrings that might look like HTML entities. Yup. we should tighten up the language. i think we are on the same page here. It's actually more complicated given the various platform behavior. While Growl doesn't interpret markup, NotifyOSD on linux does allow some markup in its notifications (lt; shows , for example) [1, section 5]. So it's not sufficient to just pass the string directly, it has to be escaped in order to present the exact text provided. So perhaps, the user agent must display the string as plain text, without interpreting markup; if using a notification platform which does interpret markup, the user agent should modify the string so that any markup is shown rather than interpreted. [1] https://wiki.ubuntu.com/NotificationDevelopmentGuidelines From an implementation pov, this text sorta scares me. Figuring out which notification platform interpret which character sequences sounds hard. And these system are not static and must be reevaluated constantly. I think it might make it a bunch easier to simply say that UA should strip out any escape sequences or html tags. What do you think? Doug
Re: Thoughts on WebNotification
On Fri, Jun 25, 2010 at 4:44 PM, John Gregg john...@google.com wrote: I'm happy with this course of action, but first I wanted to ask why not the gracefully degrade suggestion from the Notifications thread started on the 3rd of Feb. As far as I can tell, it was never seriously considered, but several of us brought it up. And I feel like it'd be a much better way forward than having a different interface for html based notifications and text notifications. (The basic idea was to accept either text or html and then if it's the latter and the notification scheme doesn't support it, we'd use some simple, specced heuristics to extract data to be used. In the thread, there were some specific ideas about how the transformations could work. But from a quick skim, I couldn't find any reasons why it was a bad idea.) J There were actually several ways considered to combine the interfaces: - We can a have a method createNotification(text, body, icon, URL) which uses the URL parameter if supported and text/body/icon parameters to be used as the backup if HTML content is not supported (I call this the alt text option). - We can allow the API to take a URL, load that resource and read some meta information from it, such as the title tag. (the title tag option). A third option would be to take raw HTML rather than a URL and compute the text version if necessary. I prefer the alt text option between these two, because it is much simpler to implement for browsers that don't want to support HTML notifications and would also be better performing, since it doesn't require the resource load. The difficulty in implementation is much less important than difficulty in use is much less important than the difficulty in use. Although it seems that at least one mainstream browser will only implement the text conversion option and thus the alt text version probably won't be as neglected as alt text in an image (at least initially) and this is something we expect mostly advanced web developers will use, I still think it's a mistake to assume web developers will properly support both. So I would support #2 or my #3 much more than #1 which I would support more than Doug's original suggestion (for that reason). J
Re: Thoughts on WebNotification
On Fri, Jun 25, 2010 at 8:56 AM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Jun 25, 2010 at 4:44 PM, John Gregg john...@google.com wrote: I'm happy with this course of action, but first I wanted to ask why not the gracefully degrade suggestion from the Notifications thread started on the 3rd of Feb. As far as I can tell, it was never seriously considered, but several of us brought it up. And I feel like it'd be a much better way forward than having a different interface for html based notifications and text notifications. (The basic idea was to accept either text or html and then if it's the latter and the notification scheme doesn't support it, we'd use some simple, specced heuristics to extract data to be used. In the thread, there were some specific ideas about how the transformations could work. But from a quick skim, I couldn't find any reasons why it was a bad idea.) J There were actually several ways considered to combine the interfaces: - We can a have a method createNotification(text, body, icon, URL) which uses the URL parameter if supported and text/body/icon parameters to be used as the backup if HTML content is not supported (I call this the alt text option). - We can allow the API to take a URL, load that resource and read some meta information from it, such as the title tag. (the title tag option). A third option would be to take raw HTML rather than a URL and compute the text version if necessary. Whenever the spec allows a URL for HTML notifications, I intend that data url is an option for developers who want to specify the HTML as a string. (Chrome supports this already, FYI.) Or did you mean to suggest that only local HTML would be allowed in the suggested API, not a remote URL? I prefer the alt text option between these two, because it is much simpler to implement for browsers that don't want to support HTML notifications and would also be better performing, since it doesn't require the resource load. The difficulty in implementation is much less important than difficulty in use is much less important than the difficulty in use. Although it seems that at least one mainstream browser will only implement the text conversion option and thus the alt text version probably won't be as neglected as alt text in an image (at least initially) and this is something we expect mostly advanced web developers will use, I still think it's a mistake to assume web developers will properly support both. So I would support #2 or my #3 much more than #1 which I would support more than Doug's original suggestion (for that reason). I see the developer-side complexity the opposite way. In #1 the backup plan is very explicit, in #2/3 for the developer to get good results on text-only platforms they have to understand our heuristics. We haven't specified them exactly, but I would speculate that using them would involve at least as much effort as specifying the backup plan explicitly. -John
Re: Thoughts on WebNotification
On Fri, Jun 25, 2010 at 8:50 AM, Doug Turner doug.tur...@gmail.com wrote: On Jun 25, 2010, at 8:39 AM, John Gregg wrote: On Thu, Jun 24, 2010 at 1:29 PM, Doug Turner doug.tur...@gmail.com wrote: Hey Drew, I think this is too vague, as it's sounds like a user agent could *not* ignore markup in the string, and still be compliant with the spec. I think we need to be very explicit that the string *must* be treated as plain text. So if I pass in gt;bfoo/b as the body parameter to createNotification(), the resulting notification must display the string gt;bfoo/b, without stripping or converting any of the substrings that might look like HTML entities. Yup. we should tighten up the language. i think we are on the same page here. It's actually more complicated given the various platform behavior. While Growl doesn't interpret markup, NotifyOSD on linux does allow some markup in its notifications (lt; shows , for example) [1, section 5]. So it's not sufficient to just pass the string directly, it has to be escaped in order to present the exact text provided. So perhaps, the user agent must display the string as plain text, without interpreting markup; if using a notification platform which does interpret markup, the user agent should modify the string so that any markup is shown rather than interpreted. [1] https://wiki.ubuntu.com/NotificationDevelopmentGuidelines From an implementation pov, this text sorta scares me. Figuring out which notification platform interpret which character sequences sounds hard. And these system are not static and must be reevaluated constantly. I think it might make it a bunch easier to simply say that UA should strip out any escape sequences or html tags. What do you think? I'm concerned that it would make it impossible to display a certain category of strings in notifications. Suppose we're both web devs, I'm chatting with you and want to share with you a snippet of code; will the chat notification be blank? I agree with the problem of depending on the providers, but if we do want to be able to specify dependable output for input (my interpretation of this discussion), I think we have to make some sort of effort there. -John -John
Re: Thoughts on WebNotification
On Fri, Jun 25, 2010 at 5:01 PM, John Gregg john...@google.com wrote: On Fri, Jun 25, 2010 at 8:56 AM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Jun 25, 2010 at 4:44 PM, John Gregg john...@google.com wrote: I'm happy with this course of action, but first I wanted to ask why not the gracefully degrade suggestion from the Notifications thread started on the 3rd of Feb. As far as I can tell, it was never seriously considered, but several of us brought it up. And I feel like it'd be a much better way forward than having a different interface for html based notifications and text notifications. (The basic idea was to accept either text or html and then if it's the latter and the notification scheme doesn't support it, we'd use some simple, specced heuristics to extract data to be used. In the thread, there were some specific ideas about how the transformations could work. But from a quick skim, I couldn't find any reasons why it was a bad idea.) J There were actually several ways considered to combine the interfaces: - We can a have a method createNotification(text, body, icon, URL) which uses the URL parameter if supported and text/body/icon parameters to be used as the backup if HTML content is not supported (I call this the alt text option). - We can allow the API to take a URL, load that resource and read some meta information from it, such as the title tag. (the title tag option). A third option would be to take raw HTML rather than a URL and compute the text version if necessary. Whenever the spec allows a URL for HTML notifications, I intend that data url is an option for developers who want to specify the HTML as a string. (Chrome supports this already, FYI.) Good point. Never mind on this third option. Or did you mean to suggest that only local HTML would be allowed in the suggested API, not a remote URL? I prefer the alt text option between these two, because it is much simpler to implement for browsers that don't want to support HTML notifications and would also be better performing, since it doesn't require the resource load. The difficulty in implementation is much less important than difficulty in use is much less important than the difficulty in use. Although it seems that at least one mainstream browser will only implement the text conversion option and thus the alt text version probably won't be as neglected as alt text in an image (at least initially) and this is something we expect mostly advanced web developers will use, I still think it's a mistake to assume web developers will properly support both. So I would support #2 or my #3 much more than #1 which I would support more than Doug's original suggestion (for that reason). I see the developer-side complexity the opposite way. In #1 the backup plan is very explicit, in #2/3 for the developer to get good results on text-only platforms they have to understand our heuristics. We haven't specified them exactly, but I would speculate that using them would involve at least as much effort as specifying the backup plan explicitly. Well, getting things to look would possibly take more effort on a web developer's part, but having _anything_ show up (for developers who only target browsers that support HTML) would always work...even if poorly. With Doug's proposal and the alt text proposal, if developers target a browser that only supports HTML, then things will completely break in browsers that don't support it. Maybe that's OK though? If the conversion algorithm is well specified, getting it to work in one text only browser would mean it works in all of them. (If they all follow the spec that is.) J
Re: Thoughts on WebNotification
On Fri, Jun 25, 2010 at 5:07 PM, Jeremy Orlow jor...@chromium.org wrote: On Fri, Jun 25, 2010 at 5:01 PM, John Gregg john...@google.com wrote: On Fri, Jun 25, 2010 at 8:56 AM, Jeremy Orlow jor...@chromium.orgwrote: On Fri, Jun 25, 2010 at 4:44 PM, John Gregg john...@google.com wrote: I'm happy with this course of action, but first I wanted to ask why not the gracefully degrade suggestion from the Notifications thread started on the 3rd of Feb. As far as I can tell, it was never seriously considered, but several of us brought it up. And I feel like it'd be a much better way forward than having a different interface for html based notifications and text notifications. (The basic idea was to accept either text or html and then if it's the latter and the notification scheme doesn't support it, we'd use some simple, specced heuristics to extract data to be used. In the thread, there were some specific ideas about how the transformations could work. But from a quick skim, I couldn't find any reasons why it was a bad idea.) J There were actually several ways considered to combine the interfaces: - We can a have a method createNotification(text, body, icon, URL) which uses the URL parameter if supported and text/body/icon parameters to be used as the backup if HTML content is not supported (I call this the alt text option). - We can allow the API to take a URL, load that resource and read some meta information from it, such as the title tag. (the title tag option). A third option would be to take raw HTML rather than a URL and compute the text version if necessary. Whenever the spec allows a URL for HTML notifications, I intend that data url is an option for developers who want to specify the HTML as a string. (Chrome supports this already, FYI.) Good point. Never mind on this third option. Or did you mean to suggest that only local HTML would be allowed in the suggested API, not a remote URL? I prefer the alt text option between these two, because it is much simpler to implement for browsers that don't want to support HTML notifications and would also be better performing, since it doesn't require the resource load. The difficulty in implementation is much less important than difficulty in use is much less important than the difficulty in use. Although it seems that at least one mainstream browser will only implement the text conversion option and thus the alt text version probably won't be as neglected as alt text in an image (at least initially) and this is something we expect mostly advanced web developers will use, I still think it's a mistake to assume web developers will properly support both. So I would support #2 or my #3 much more than #1 which I would support more than Doug's original suggestion (for that reason). I see the developer-side complexity the opposite way. In #1 the backup plan is very explicit, in #2/3 for the developer to get good results on text-only platforms they have to understand our heuristics. We haven't specified them exactly, but I would speculate that using them would involve at least as much effort as specifying the backup plan explicitly. Well, getting things to look er...meant to say look good would possibly take more effort on a web developer's part, but having _anything_ show up (for developers who only target browsers that support HTML) would always work...even if poorly. With Doug's proposal and the alt text proposal, if developers target a browser that only supports HTML, then things will completely break in browsers that don't support it. Maybe that's OK though? If the conversion algorithm is well specified, getting it to work in one text only browser would mean it works in all of them. (If they all follow the spec that is.) I suppose that we could spec it such that if someone creates a HTML notification (in Doug's proposal) or doesn't specify alt text in the alt text proposal, we fall back to some algorithm/heuristics to do the conversion automatically. It'd be the most complicated implementation wise, but it'd be the best solution for the web developer. J
Re: Thoughts on WebNotification
I'm concerned that it would make it impossible to display a certain category of strings in notifications. Suppose we're both web devs, I'm chatting with you and want to share with you a snippet of code; will the chat notification be blank? I agree with the problem of depending on the providers, but if we do want to be able to specify dependable output for input (my interpretation of this discussion), I think we have to make some sort of effort there. make sense. i agree with you.
Re: Thoughts on WebNotification
On Fri, Jun 25, 2010 at 9:07 AM, Jeremy Orlow jor...@chromium.org wrote: Well, getting things to look would possibly take more effort on a web developer's part, but having _anything_ show up (for developers who only target browsers that support HTML) would always work...even if poorly. With Doug's proposal and the alt text proposal, if developers target a browser that only supports HTML, then things will completely break in browsers that don't support it. Maybe that's OK though? If the conversion algorithm is well specified, getting it to work in one text only browser would mean it works in all of them. (If they all follow the spec that is.) J An implicit assumption here is that a single block of HTML can both provide an attractive HTML-formatted display, and also be converted to plain text in a way that is attractive for plain text notification mechanisms (I also don't know how this addresses use cases like SVG notifications). I think that developers would inherently have to test both if they want to support both, so I'm not sure this helps. As a developer, I like the current API as it allows me to detect rich notification support via the presence of createWebNotification(), but also allows the user's preference (growl-only, for example) to be expressed even on browsers that can support web notifications by not exposing that API. I may be more blithely confident in developer's abilities to do capability detection than others in this discussion, though :) The advantage of the alt-text solution is it gracefully degrades (you won't get an exception thrown if you screw up capabilities detection) but you also can't do capability detection. I'm not 100% convinced that capabilities detection is important (offhand I'm not able to come up with any compelling use cases where I'd only want to display an HTML notification and not display any notification at all if they are not supported), so I'd support ditching the current API in favor of alt-text if that would lead to more interoperability. -atw
Thoughts on WebNotification
I have been thinking a bit on Desktop Notifications [1]. After reviewing the
Web Notification specification [2], I would like to propose the following
changes:
1) Factor out the permission api into a new interface and/or spec. The ability
to test for a permission without bring up a UI would improve the UX of device
access. I could imagine implementing this feature for use with Geolocation as
well as notifications. For example:
interface Permissions {
// permission values
const unsigned long PERMISSION_ALLOWED = 0;
const unsigned long PERMISSION_UNKNOWN = 1;
const unsigned long PERMISSION_DENIED = 2;
void checkPermission(in DOMString type, in Function callback);
}
Then we could do something like:
navigator.permissions.checkPermission(desktop-notification, function(value)
{});
or
navigator.permissions.checkPermission(geolocation, function(value) {});
2) Add language to the spec to indicate that the DOMStrings used
|createNotification| are not to include any mark up. Basically,
implementations are going to hand off notifications to system-level services.
For example, on the Mac, GROWL does not handle any mark up... their API just
takes plain strings. I'd like to see the API reflect this reality. Something
like the |title| and |body| arguments are to be treated as plain text... or
some such language.
3) Move Web notifications to a version 2 of the specification. For the most
basic use cases, this API isn't required and a web developer could use the more
base API to simulate this. Furthermore, as I mentioned above, many
system-level notification services know nothing about rendering html.
I hope that this is helpful,
Doug Turner
Mozilla Corp
[1] http://dougt.org/wordpress/2010/06/desktop-notifications/
[2] http://dev.w3.org/2006/webapi/WebNotifications/publish/
Re: Thoughts on WebNotification
On Thu, Jun 24, 2010 at 11:38 AM, Doug Turner doug.tur...@gmail.com wrote:
I have been thinking a bit on Desktop Notifications [1]. After reviewing
the Web Notification specification [2], I would like to propose the
following changes:
1) Factor out the permission api into a new interface and/or spec. The
ability to test for a permission without bring up a UI would improve the UX
of device access. I could imagine implementing this feature for use with
Geolocation as well as notifications. For example:
interface Permissions {
// permission values
const unsigned long PERMISSION_ALLOWED = 0;
const unsigned long PERMISSION_UNKNOWN = 1;
const unsigned long PERMISSION_DENIED = 2;
void checkPermission(in DOMString type, in Function callback);
}
Then we could do something like:
navigator.permissions.checkPermission(desktop-notification,
function(value) {});
or
navigator.permissions.checkPermission(geolocation, function(value) {});
I like this idea, I think it's definitely preferable to a one-off permission
system just for notifications.
Your proposal doesn't have a way to explicitly request permission. Would
you be willing to add that, with the recommendation that it only take place
on a user gesture? I don't think this eliminates the ability to implement
request-on-first-use, if that's what Mozilla prefers, but I also still think
there is benefit to allowing permissions to be obtained separately from
invoking the API in question.
The bigger question is, are other features interested? Would the
Geolocation spec consider using something like this for permissions?
2) Add language to the spec to indicate that the DOMStrings used
|createNotification| are not to include any mark up. Basically,
implementations are going to hand off notifications to system-level
services. For example, on the Mac, GROWL does not handle any mark up...
their API just takes plain strings. I'd like to see the API reflect this
reality. Something like the |title| and |body| arguments are to be treated
as plain text... or some such language.
Although the group isn't chartered to deliver the spec forward, FWIW I agree
with this suggestion (it was always the intent) and have made this language
explicit in the editor's draft.
3) Move Web notifications to a version 2 of the specification. For the
most basic use cases, this API isn't required and a web developer could use
the more base API to simulate this. Furthermore, as I mentioned above, many
system-level notification services know nothing about rendering html.
Though I think web content still makes sense for notifications coming from a
web browser, and would want to publish an API which drives things in that
direction, I think this is reasonable if it will encourage greater
implementation of the basic API. As long as the text+icon API we use
doesn't cut off that avenue, and I think what we have now meets that.
-John
Re: Thoughts on WebNotification
Thank you for your quick response!
On Jun 24, 2010, at 11:48 AM, John Gregg wrote:
On Thu, Jun 24, 2010 at 11:38 AM, Doug Turner doug.tur...@gmail.com wrote:
I have been thinking a bit on Desktop Notifications [1]. After reviewing the
Web Notification specification [2], I would like to propose the following
changes:
1) Factor out the permission api into a new interface and/or spec. The
ability to test for a permission without bring up a UI would improve the UX
of device access. I could imagine implementing this feature for use with
Geolocation as well as notifications. For example:
interface Permissions {
// permission values
const unsigned long PERMISSION_ALLOWED = 0;
const unsigned long PERMISSION_UNKNOWN = 1;
const unsigned long PERMISSION_DENIED = 2;
void checkPermission(in DOMString type, in Function callback);
}
Then we could do something like:
navigator.permissions.checkPermission(desktop-notification, function(value)
{});
or
navigator.permissions.checkPermission(geolocation, function(value) {});
I like this idea, I think it's definitely preferable to a one-off permission
system just for notifications.
Your proposal doesn't have a way to explicitly request permission. Would you
be willing to add that, with the recommendation that it only take place on a
user gesture? I don't think this eliminates the ability to implement
request-on-first-use, if that's what Mozilla prefers, but I also still think
there is benefit to allowing permissions to be obtained separately from
invoking the API in question.
so, checkPermission and requestPermission. I am happy with that..
and
if really want to get crazy, we could do something like:
navigator.permissions.requestPermission(geolocation,desktop-notification,...).
This would allow a site to request multiple permissions in one go up to the
implementation if this is supported (i'd argue), and up to the implementation
on how best to handle these requests.
The bigger question is, are other features interested? Would the Geolocation
spec consider using something like this for permissions?
cc'ing Andrei Popescu - the editor of the Geolocation spec. Not sure how to
formally answer your question. However, if the permission api above was
implemented, I think it naturally follows that geolocation would be one of
the known strings.
2) Add language to the spec to indicate that the DOMStrings used
|createNotification| are not to include any mark up. Basically,
implementations are going to hand off notifications to system-level services.
For example, on the Mac, GROWL does not handle any mark up... their API just
takes plain strings. I'd like to see the API reflect this reality.
Something like the |title| and |body| arguments are to be treated as plain
text... or some such language.
Although the group isn't chartered to deliver the spec forward, FWIW I agree
with this suggestion (it was always the intent) and have made this language
explicit in the editor's draft.
cool beans.
3) Move Web notifications to a version 2 of the specification. For the most
basic use cases, this API isn't required and a web developer could use the
more base API to simulate this. Furthermore, as I mentioned above, many
system-level notification services know nothing about rendering html.
Though I think web content still makes sense for notifications coming from a
web browser, and would want to publish an API which drives things in that
direction, I think this is reasonable if it will encourage greater
implementation of the basic API. As long as the text+icon API we use doesn't
cut off that avenue, and I think what we have now meets that.
Make it optional allows us to have a spec that interoperates. I am not sure
that Mozilla (or I) would want to implement this part of the specification. My
goal is for tight system level integration and I do not believe that web
notifications helps on that.
Again, thank you for your thoughts,
Doug Turner
Re: Thoughts on WebNotification
On Thu, Jun 24, 2010 at 11:38 AM, Doug Turner doug.tur...@gmail.com wrote:
I have been thinking a bit on Desktop Notifications [1]. After reviewing
the Web Notification specification [2], I would like to propose the
following changes:
1) Factor out the permission api into a new interface and/or spec. The
ability to test for a permission without bring up a UI would improve the UX
of device access. I could imagine implementing this feature for use with
Geolocation as well as notifications. For example:
interface Permissions {
// permission values
const unsigned long PERMISSION_ALLOWED = 0;
const unsigned long PERMISSION_UNKNOWN = 1;
const unsigned long PERMISSION_DENIED = 2;
void checkPermission(in DOMString type, in Function callback);
}
Then we could do something like:
navigator.permissions.checkPermission(desktop-notification,
function(value) {});
or
navigator.permissions.checkPermission(geolocation, function(value) {});
2) Add language to the spec to indicate that the DOMStrings used
|createNotification| are not to include any mark up. Basically,
implementations are going to hand off notifications to system-level
services. For example, on the Mac, GROWL does not handle any mark up...
their API just takes plain strings. I'd like to see the API reflect this
reality. Something like the |title| and |body| arguments are to be treated
as plain text... or some such language.
Agreed. The current language reads:
The user agent may ignore any markup in this string and treat it as plain
text.
I think this is too vague, as it's sounds like a user agent could *not*
ignore markup in the string, and still be compliant with the spec. I think
we need to be very explicit that the string *must* be treated as plain text.
So if I pass in gt;bfoo/b as the body parameter to
createNotification(), the resulting notification must display the string
gt;bfoo/b, without stripping or converting any of the substrings that
might look like HTML entities.
3) Move Web notifications to a version 2 of the specification. For the
most basic use cases, this API isn't required and a web developer could use
the more base API to simulate this. Furthermore, as I mentioned above, many
system-level notification services know nothing about rendering html.
I'm not certain what moving WebNotifications to version 2 would mean,
especially since as specified, user agents already are free to leave
createWebNotification() undefined. Can you please clarify what you think, in
practice, having createWebNotification() moved to version 2 would
accomplish? Since compliant user agents are already free to *not* implement
this API, it sounds like your only goal could be to discourage other user
agents from implementing the createWebNotification() API, and I'm not at all
convinced that's either appropriate or feasible.
I hope that this is helpful,
Doug Turner
Mozilla Corp
[1] http://dougt.org/wordpress/2010/06/desktop-notifications/
[2] http://dev.w3.org/2006/webapi/WebNotifications/publish/
Re: Thoughts on WebNotification
Hey Drew, I think this is too vague, as it's sounds like a user agent could *not* ignore markup in the string, and still be compliant with the spec. I think we need to be very explicit that the string *must* be treated as plain text. So if I pass in gt;bfoo/b as the body parameter to createNotification(), the resulting notification must display the string gt;bfoo/b, without stripping or converting any of the substrings that might look like HTML entities. Yup. we should tighten up the language. i think we are on the same page here. 3) Move Web notifications to a version 2 of the specification. For the most basic use cases, this API isn't required and a web developer could use the more base API to simulate this. Furthermore, as I mentioned above, many system-level notification services know nothing about rendering html. I'm not certain what moving WebNotifications to version 2 would mean, especially since as specified, user agents already are free to leave createWebNotification() undefined. Can you please clarify what you think, in practice, having createWebNotification() moved to version 2 would accomplish? Since compliant user agents are already free to *not* implement this API, it sounds like your only goal could be to discourage other user agents from implementing the createWebNotification() API, and I'm not at all convinced that's either appropriate or feasible. My thinking, right or wrong, was that it might be nice to say that most UAs will support version v.1 (that doesn't include things like webnotifications). And in v.2 is the things that some UAs aren't willing to implement at the present time. In practice, though, it really doesn't matter. Doug
