Re: [w3c/permissions] Introduce "Automation" section (#151)

jugglinmike commented on this pull request.



> +      <code>|rootDesc|.{{PermissionDescriptor/name}}</code> isn't <a>allowed in
+      non-secure contexts</a>, return <a>error</a> with <a>error code</a>
+      <a>invalid argument</a>.</li>
+      <li>Let |state| by the result of <a>getting the property</a> "`state`"
+      from the |parameters| argument.</li>
+      <li>If |state| is neither "`granted`", "`prompt`", nor "`denied`", return
+      <a>error</a> with <a>error code</a> <a>invalid argument</a>.</li>
+      <li>Let |allRealms| be the result of <a>getting the property</a>
+      "`allRealms`" from the |parameters| argument.</a></li>
+      <li>If |allRealms| is `undefined`, let |allRealms| be false.</li>
+      <li>If |allRealms| is neither true nor false, return <a>error</a> with
+      <a>error code</a> <a>invalid argument</a>.</li>
+      <li>Interpret the value of |state| as <a>new information about the user's
+      intent</a>. If |allRealms| is true, this information applies to other
+      <a>realms</a> with the <a>same origin</a>.
+      <li>Return <a>success</a> with data `null`.</li>

> The other option to consider would be making allRealms the default for the
> API which would encourage test writers to only specify to use an individual
> realm when it makes sense.

In terms of default behavior, I don't really have strong feelings one way or
the other. In terms of API design, though, I find optional arguments that
default to `true` a little counter-intuitive (since that conflicts with
JavaScript semantics regarding the "truthiness" of `undefined`). If we move
forward with the inverse behavior, I'd suggest naming the option something like
`oneRealm` so that the behavior for the "option not specified" case would map
to the `false` value.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/permissions/pull/151#discussion_r126189761