W3C home > Mailing lists > Public > public-secondscreen@w3.org > August 2016

[presentation-api] Pull Request: Clarify the default presentation request mechanism?

From: François Daoust via GitHub <sysbot+gh@w3.org>
Date: Wed, 24 Aug 2016 13:58:39 +0000
To: public-secondscreen@w3.org
Message-ID: <pull_request.opened-82546881-1472047117-sysbot+gh@w3.org>
tidoust has just submitted a new pull request for 
https://github.com/w3c/presentation-api:

== Clarify the default presentation request mechanism? ==
I find the section that defines and specifies the behavior of the 
default presentation request somewhat unclear in [6.2.1 Controlling 
user 
agent](https://w3c.github.io/presentation-api/#controlling-user-agent).
 More precisely:

1. There is no proper definition as to what the "default presentation 
request" represents.
2. I am unclear whether the initial value for the attribute is always 
`null`. I think it is, but the spec only specifies behavior when the 
attribute is "set by the controller". Can the attribute be set by the 
controlling user agent? I suppose not (at least that does not seem to 
make sense).
3. The text explicitly covers the case when the sandboxed presentation
 browsing context flag is set, but since that check is part of the 
"start a presentation" algorithm that gets called to initiate the 
presentation, this should not be needed.
4. Similarly, stricto senso, the "start a presentation" algorithm 
won't be allowed to show a popup in that case, so calling it should 
fail right away, which is obviously not the intended behavior.
5. The spec only explicitly says that support for this feature in 
controlling user agents is optional in an editorial note.
6. I do not understand the use of `SHOULD` in the second paragraph. I 
suppose it's meant to convey the fact that controlling user agents may
 not support that feature, but it seems better to be explicit that the
 feature is `OPTIONAL`, or phrase things with a conditional `MUST`, as
 in "if [feature supported], the controlling user agent MUST 
[behavior]". Or is there a good reason not to follow these statements,
 which would indeed justify the `SHOULD` level? (note that comment 
only applies to the paragraph that starts with "If set by the 
controller", the use of `SHOULD` for user gestures looks good).

I propose a rewrite in this pull request. Note that this is not meant 
to introduce any change of behavior, but rather to clarify the intent 
and behavior of the default presentation request mechanism. Main 
proposed changes:

1. I added a definition for "default presentation request" in the 
"Common Idioms" section.
2. The text is now explicit that support for the default presentation 
request mechanism is optional.
3. The text is now clear that step 1. of the "start a presentation" 
algorithm is to be skipped, and that other security checks apply (I 
kept the sandboxing flag as an example in a note)



See https://github.com/w3c/presentation-api/pull/334
Received on Wednesday, 24 August 2016 13:58:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:19:01 UTC