-
Notifications
You must be signed in to change notification settings - Fork 3.1k
Description
As noted in #1312 (comment), current usage is ambiguous. The spec says:
If the browsing context container element E is in the Document D, then P is said to be the parent browsing context of C and C is said to be a child browsing context of P.
i.e., it defines "browsing context C is a child browsing context of browsing context P".
Later the spec says:
Because they are nested through an element, child browsing contexts are always tied to a specific Document in their parent browsing context.
In practice, how the phrase "child browsing context" is used is usually by referring to a document's child browsing contexts, or sometimes a window. This is not really well-defined.
Later in the spec when defining window.length, it says:
The number of child browsing contexts of a Window object W is the number of child browsing contexts that are nested through elements that are in a Document that is the active document of the Window object's associated Document object's browsing context.
This concept of "child browsing contexts that are nested through elements that are in a Document" maybe is equivalent to "the document's child browsing contexts", but I am not sure. Later, in [[GetOwnProperty]] for WindowProxy, the spec uses
the indexth child browsing context of the Document that is nested through an element that is in W's Document, sorted in the order that the elements nesting those browsing contexts were most recently inserted into the Document, the WindowProxy object of the most recently inserted browsing context container's nested browsing context being last.
I'd suggest centralizing these definitions and defining:
- C is a child browsing context of P
- A Window object's child browsing contexts (an ordered list) + the number of child browsing contexts of a Window W (which should be the cardinality of that list)
- A Document object's child browsing contexts
- A Document object's descendant browsing contexts
- Optionally: a Window object's same-origin child browsing contexts (could be used for "child browsing context name property set")
Then an audit should be done of all places in the spec that use "child browsing context" to see if we can re-frame them in terms of one of these definitions. E.g. I think [[GetOwnProperty]] should use the Window object's child browsing contexts.
I could work on this but maybe @annevk wants to give it a shot?