You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The specification doesn't appear to use equality anywhere, but it's rather unclear to me how anything could work without it. Presumably we don't want the default identity equality to be used here.
It's also unclear how the specification integrates with the "stronger than" concept.
The text was updated successfully, but these errors were encountered:
Right, I think I had structural equality in mind when I wrote things like "with the same descriptor and settings," but that wasn't clear from the wording.
The only implication of "stronger than" is the requirement on permission states that's included in its definition. I should probably have used it in the "permission state" definition, along the lines of «If there was a previous invocation of this algorithm for the same |feature| that returned "granted", and the previous invocation's descriptor was [=stronger than=] this invocation's, return "granted"», and the converse for "denied". With the new permission store model, I think it might fit better in https://www.w3.org/TR/permissions/#requesting-more-permission, where you'd look for stronger and weaker descriptors before asking the user to express permission.
The specification doesn't appear to use equality anywhere, but it's rather unclear to me how anything could work without it. Presumably we don't want the default identity equality to be used here.
It's also unclear how the specification integrates with the "stronger than" concept.
The text was updated successfully, but these errors were encountered: