Re: PFWG comments on Web Notifications

Thank you for your further response to the PFWG comments. Preliminary 
feedback from the PFWG is inline below:
On 12/12/2014 5:53 PM, Jon Lee wrote:
>
>> On Dec 11, 2013, at 9:37 AM, Michael Cooper <cooper@w3.org 
>> <mailto:cooper@w3.org>> wrote:
>>
>> Thank you for your responses to the comments received from the 
>> Protocols and Formats Working Group. The view of the WG is inline below.
>>
>> On 05/12/2013 8:50 PM, Jon Lee wrote:
>>> [This is a draft WG reply to the PFWG'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 9, 2013, at 9:21 AM, Michael Cooper <cooper@w3.org 
>>> <mailto:cooper@w3.org>> wrote:
>>>
>>>> Below are two comments from the Protocols and Formats Working Group 
>>>> on Web Notifications Last Call Working Draft of 22 September 2013 
>>>> http://www.w3.org/TR/2013/WD-notifications-20130912/. PFWG approval 
>>>> to send these comments is archived at 
>>>> https://www.w3.org/2013/10/09-pf-minutes.html#item04 (Member-only 
>>>> link right now, should become public in a week).
>>>>
>>>> Comment 1
>>>>
>>>> 4.2states - Thenotification 
>>>> <http://www.w3.org/TR/2013/WD-notifications-20130912/#concept-notification>'slanguage 
>>>> <http://www.w3.org/TR/2013/WD-notifications-20130912/#language>specifies 
>>>> the primary language for thenotification 
>>>> <http://www.w3.org/TR/2013/WD-notifications-20130912/#concept-notification>'stitle 
>>>> <http://www.w3.org/TR/2013/WD-notifications-20130912/#title>andbody 
>>>> <http://www.w3.org/TR/2013/WD-notifications-20130912/#body>. Its 
>>>> value is a valid BCP 47 language tag, or the empty string. The 
>>>> empty string indicates that the primary language is unknown.[LANG] 
>>>> <http://www.w3.org/TR/2013/WD-notifications-20130912/#refsLANG>"
>>>>
>>>> We should add a Note to state that if the primary language is 
>>>> unknown this would be a WCAG violation.
>>>
>>> Software often interacts with, transmits, and presents text without 
>>> knowing which human languages are used in the text. Notification 
>>> services frequently utilize this text to inform the user (e.g., that 
>>> the user has received a new email), so we can't expect software to 
>>> know the human languages used in notification text. We shouldn't 
>>> require software to do something we're certain it can't accomplish.
>> We understand this issue but also consider it important since the 
>> spec expressly permits a null language notification. We suggest this 
>> softened text to alert implementers: "Note that while the language 
>> may be unknown to the system, leaving it unset will create problems 
>> for some users."
>
> Notifications need to be consistent with other parts of the Web 
> platform. HTML5 defines the lang attribute and describes how to use 
> it, but neither requires its use nor declares that leaving it unset 
> creates problems. It's best for us to be following HTML5 here, since 
> most developers using the notifications API won't know the language of 
> the notification text.
Thank you for your explanation. After consideration, the PFWG has 
accepted this rationale and your disposition of this issue, so it can be 
closed.
>
>>>
>>>> Comment 2
>>>>
>>>> The API specifies the ability to supply an icon without the ability 
>>>> to specify any text alternative for the icon. We need an ability to 
>>>> provide alternative content for the icon. Given that notifications 
>>>> are created in JS more or less in real time, a plain string is 
>>>> enough (assuming that the internationalisation story is
>>>> really correct).
>>>
>>> Please see prior discussion [1]. The icon's purpose is decorative 
>>> and provides no additional information. We should consider an 
>>> editorial change to make this clearer.
>> In the prior discussion you reference, we note that Artur Ortega 
>> provided counter-examples for how, notwithstanding the intent of the 
>> specification developers, these icons are often used to convey 
>> meaning. It appears that comment was not addressed and we support and 
>> echo it.
>
> I understand that developers may choose to do this, but if they 
> explicitly ignore one requirement of the spec, it seems unlikely that 
> they will follow other, equally ignorable requirements.
The PFWG is still discussing this issue and has not yet come to 
conclusion. The group plans to continue the discussion in early January 
and send a completed response at that time. Please let us know if you 
have timeline considerations impacted by this.

Michael
>
>> While your intent may be for the icon to be purely decorative, we 
>> believe authors will use it in other ways and think it would be 
>> important for the spec to make it possible for authors to provide 
>> alternative text in such circumstances.
>
> Fortunately, if a Web author violates the requirement that the icon be 
> purely decorative, they have the option of using an image format which 
> can carry its own text alternative, like SVG.
>
> Given that the platform already makes this possible, no further spec 
> changes are necessary here.
>
> Jon