Use Navigables instead of browsing contexts #104
Comments
|
At least if we use browsing contexts instead of navigables, we should probably have a note explaining why that is necessary |
rakuco
added a commit
to rakuco/device-posture
that referenced
this issue
Mar 8, 2024
Related to w3c#104. The end result is the same, but we now avoid using deprecated terms. The text has also been simplified: saying that something applies to the top-level browsing context and all child contexts is redundant (it basically says it applies to all pages); the relevant point which is that navigables that are not top-level traversables reflect the latter's value, has been kept.
rakuco
added a commit
that referenced
this issue
Mar 8, 2024
#119) Related to #104. The end result is the same, but we now avoid using deprecated terms. The text has also been simplified: saying that something applies to the top-level browsing context and all child contexts is redundant (it basically says it applies to all pages); the relevant point which is that navigables that are not top-level traversables reflect the latter's value, has been kept.
rakuco
added a commit
to rakuco/device-posture
that referenced
this issue
Mar 8, 2024
The original main goal was to give a name to the existing algorithm that used to run in the "next animation frame task" so that it could be referenced in the upcoming WebDriver section, but "animation frame task" as a concept did not exist, and one thing led to another and the final change includes a better version of the original algorithms, but without any user-visible changes. This change borrows a lot of ideas from the Screen Orientation spec as of its 2023-08-09 Editor's Draft. Most important changes: - The "update the device posture information" algorithm was renamed to "calculate the device posture information" so that it returns a value instead of updating `[[CurrentPosture]]` directly -- that is done as task queued in the user interaction task source (more on this below). - Call the main algorithm "device posture change steps". - Merge the separate page visibility-related algorithm into the main one, and add the proper checks to it to ensure that documents whose visibility state is "hidden" are not updated and that calls to "update the device posture information" that result in the same value being stored do not fire any "change" events. - The "change" event is now queued to be fired in the user interaction task source so that the moment it is actually fired is more predictable (the "device posture change steps" are not running at any specific point of the HTML event loop). While here: the definition of the `onchange` attribute was updated to mention the current terms defined in the HTML spec, along with a proper `<dfn>` for the event handler event type. The language and the references used in the text have also been updated: we no longer deal with browsing contexts, but with navigables; the PAGE-VISIBILITY spec is no longer treated as a separate specification, as it was merged into HTML a few years ago. Related to w3c#104. Fixes w3c#95.
rakuco
added a commit
that referenced
this issue
Mar 8, 2024
The original main goal was to give a name to the existing algorithm that used to run in the "next animation frame task" so that it could be referenced in the upcoming WebDriver section, but "animation frame task" as a concept did not exist, and one thing led to another and the final change includes a better version of the original algorithms, but without any user-visible changes. This change borrows a lot of ideas from the Screen Orientation spec as of its 2023-08-09 Editor's Draft. Most important changes: - The "update the device posture information" algorithm was renamed to "calculate the device posture information" so that it returns a value instead of updating `[[CurrentPosture]]` directly -- that is done as task queued in the user interaction task source (more on this below). - Call the main algorithm "device posture change steps". - Merge the separate page visibility-related algorithm into the main one, and add the proper checks to it to ensure that documents whose visibility state is "hidden" are not updated and that calls to "update the device posture information" that result in the same value being stored do not fire any "change" events. - The "change" event is now queued to be fired in the user interaction task source so that the moment it is actually fired is more predictable (the "device posture change steps" are not running at any specific point of the HTML event loop). While here: the definition of the `onchange` attribute was updated to mention the current terms defined in the HTML spec, along with a proper `<dfn>` for the event handler event type. The language and the references used in the text have also been updated: we no longer deal with browsing contexts, but with navigables; the PAGE-VISIBILITY spec is no longer treated as a separate specification, as it was merged into HTML a few years ago. Related to #104. Fixes #95.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
https://html.spec.whatwg.org/multipage/document-sequences.html#infrastructure-for-sequences-of-documents
"Most of this standard works in the language of navigables, but certain APIs expose the existence of browsing context switches, and so some parts of the standard need to work in terms of browsing contexts."
"Browsing contexts are a developer-facing representation of a series of documents. They correspond 1:1 with WindowProxy objects. Each navigable can present a series of browsing contexts, with switches between those browsing contexts occuring under certain well-defined circumstances."
The text was updated successfully, but these errors were encountered: