- From: François Daoust via GitHub <sysbot+gh@w3.org>
- Date: Wed, 24 Aug 2016 13:58:39 +0000
- To: public-secondscreen@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