Re: [draft] Comments/questions on Web Notifications Last Call WD

[This is a draft WG reply to the Frederick's last call comments. Comments on the proposed resolution are welcome; if no one objects in a week’s time, this will be the WG’s official response to his comment. -Jon]

On Oct 14, 2013, at 2:03 PM, Frederick.Hirsch@nokia.com wrote:

> I have some personal comments/questions on the Web Notifications Last Call WD, offered as Last Call feedback.  
> 
> This feedback refers to http://www.w3.org/TR/2013/WD-notifications-20130912/
> 
> General
> 
> (1) How will this notification API work with devices that are touch based? Specifically, is onclick appropriate in those cases? 

I agree with Anne’s comment [1] that “click” is synonymous with “activate”. I suggest we pull in Anne’s update to the WHATWG spec [2].

> (2) Is there more to be said on security and privacy? Section 2.1 "Security" states:
> 
> "Notifications should only be presented when the user has indicated they are desired; without this they could create a negative experience for the user."
> 
> Is there any opportunity for attacks using notification data, such as the icon URL, body or tag? Are there restrictions on the body content, could it contain executed javascript? Are there assumptions about the notification mechanism being sandboxed? Is there any risk with sharing URLs in notification bodies?

Anne’s right, that the body is just text. How the notification platform handles the notification is outside the scope of the spec.

> (3) It would help to clarify which specific terminology from DOM, HTML, IDL and URL is used (in Section 3), so it is clear when specific meanings are intended.
> 
> The terminology "pending" and "active notification" should also be defined in this section. (Pending means queued, active means has been displayed to the user?)

Those concepts remain defined inline since they are specific to the feature.

> (4) Section 4, the model should state the assumptions and constraints. For example, the document assumes that there is only one outstanding notification per origin/tag combination, and that a new notification  replaces an earlier one.
> This is an important aspect of the model that should be included in a summary at the start of section 4.

Notifications platforms have different constraints, but you are correct that the show/replace steps do assume that notifications with common origin/tag combinations get replaced. I suggest making an editorial change to introduce that notion earlier, in section 4. Anyone else have thoughts on this?

> (5) In section 4.2, what happens when the language is unknown? Clarifying text would be helpful.

Anne is right that nothing is expected to happen, and it only acts as a hint to the notification platform. See [3].

> (6) Are there any best practices/experiences related to tags that should be noted? (though the example provides some information on the intent)

I agree with Anne that more experience will be needed.

====

Please let us know promptly whether this response satisfies your comments and suggestions.

Jon

[1] http://lists.w3.org/Archives/Public/public-web-notification/2013Oct/0010.html
[2] https://github.com/whatwg/notifications/commit/7df4f93d843cf9b9a63eddff8580d39638b8d47c
[3] http://lists.w3.org/Archives/Public/public-web-notification/2013Oct/0002.html