Re: issues and questions in the latest TPE draft

On 8/29/12 1:12 AM, Nicholas Doty wrote:
> On Aug 22, 2012, at 12:15 PM, David Singer <singer@apple.com 
> <mailto:singer@apple.com>> wrote:
>>>
>>>   * Finally, section 6.7 includes non-normative language that states
>>>     that UA's may implement exception management as they see fit,
>>>     and gives an example of a UA prompt to allow a requested
>>>     exception. Although this is non-normative, I have concerns about
>>>     the impact. In my view, the requesting party (i.e. the
>>>     publisher) should control the messaging of the request, and the
>>>     UA should provide only a simple yes/no confirmation. The example
>>>     given will create a terrible user experience, as the user will
>>>     be presented with multiple and possible conflicting explanations
>>>     of the request. Let's not encourage this. Canit we please remove it?
>>>
>> I agree with you on the model of the exceptions -- that the site's 
>> pages should explain what's going on, and that the API call and 
>> resulting UI should be a confirmation.  I wonder if, if that is the 
>> case, we need all the explanatory parameters to the API, and I agree 
>> that re-writing 6.7 in the light of that model would be good.
>
> It sounds like the concern is over the possibility of having a UI that 
> uses an explanatory string or a "more info" URI rather than just 
> having a non-normative example at all.
>
> Are there cases where the user sees conflicting explanations of the 
> request? I guess a truly confusing site could provide contradictory 
> statements in its HTML content before the JS call and the optional 
> explanationString parameter (or the detailURI), but our APIs certainly 
> won't prevent sites from choosing to be confusing and sites that don't 
> wish to use the string parameter can simply not use it. The suggestion 
> in January was that a browser could have a good incentive to present 
> this to the user and that optional parameters (and no UI requirements) 
> could provide variety among vendors.
>
> My understanding is that in this thread [0] Jonathan, Shane and Sid 
> ultimately agreed on this approach, and it's been supported in each 
> re-drafting since.
>
> [0] http://lists.w3.org/Archives/Public/public-tracking/2012Jan/0321.html
>
The issue is not conflict between two contradictory UI's or messaging 
presented by the site, but conflict (or redundancy) between the UI and 
message presented by the site vs a UI and message presented by the UA. I 
think there is consensus that the site should control the message around 
the exception request, yes? Assuming that's true, UA's should not be 
encouraged to also provide a UI, which is, I think, what the example does.