Drop step 6 of getAvailability for consistency with start? #383
Comments
|
On removing step 6: That seems fine, but the step is not useless. I would want to adjust the language in the "monitor" steps to set the list of displays to empty and abort if monitoring is disabled, effectively moving the step to a different list of steps. That seems like an editorial improvement. On disabling monitoring: From a user experience point of view, agreed it would be better to run the monitoring algorithm with an empty list, so that existing |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
That did not strike me as odd before, but why we do we need to call out the unability to "monitor the list of available presentation displays for the entire duration of the controlling browsing context" in step 6. of the
getAvailabilityalgorithm?This concept does not exist in the
startalgorithm. Instart, I think this is captured by the fact that the algorithm to monitor the list of available presentation displays will simply create an empty list of available presentation displays.Following the same logic in
getAvailability, given an empty list of available presentation displays, step 9. correctly returns aPresentationAvailabilityobject whosevalueis set tofalseif the list of available presentation displays. In other words, step 6. seems useless to me.A user agent may let users disable the ability to monitor the list of available presentation displays at any time. If that happens and there's already a list of available presentation displays, I would expect the user agent to run the monitoring algorithm once again (with an empty list of presentation displays) in the background. I'm not sure this needs to be made explicit in the spec given that we leave it up to implementers to run the monitoring algorithm again whenever they want, including "never" if they so choose.
The text was updated successfully, but these errors were encountered: