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 getAvailability algorithm?
This concept does not exist in the start algorithm. In start, 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 a PresentationAvailability object whose value is set to false if 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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4