Consider removing settings object's responsible document #4335
Comments
|
As a follow-up or as part of this it might also be nice to tackle "responsible event loop" which should always be accessible from the encompassing agent, so it's not clear we need a separate point of access here. |
|
Working on #4394 two things jumped out at me:
|
Whatever's shorter or more convenient. Settings objects have some useful fields; if you need to access those, go for the settings object. Globals have a few others. Probably for this issue we'll mostly want globals since they have associated Documents. This issue is indeed about removing one of the redundant pointers ("responsible document") mostly by replacing it with the equivalent one ("associated Document"). |
In particular, the reason why I think removing this is important is because intuitively you might think of "responsible document" for worker settings objects as being their owner document. But that's not the case; the spec notes that
In general, the environment settings object concept can be viewed like a polymorphic class hierarchy. There's an abstract base class/interface, "environment settings object", which defines the contract but no specifics. And there are several concrete subclasses, like window ESO and worker ESO and service worker ESO, which define concrete algorithms for how to get things like "module map" or "HTTP state" or "origin". With this view, "responsible document" is a violation of the Liskov Substitution Principle. The expectation is that when given an ESO, you can generically call its algorithms and get something useful out of them, without caring about what subtype of ESO you're using. But for the "responsible document" algorithm, that's not true; it's meaningless in the general case, and only works for window ESOs. |
* Removes uses of "responsible document". This term is on its way out, per whatwg/html#4335. * The straightforward substitution of using the associated Document didn't always make sense, because in many cases there was no sensible settings object (e.g., the algorithms were consulting the "current settings object" but were in parallel, where there is no current settings object). So, this restructures the algorithms to be more clear about what work is done in parallel vs. what work is done in queued tasks. * Similarly, a lot of work was done on main-thread data structures and objects while in parallel, e.g. creating WakeLockSentinel objects or consulting internal slots. That was moved to be done either up front, before the algorithms go in parallel, or in queued tasks. This includes user activation checking, which allows us to eliminate the wrapper "obtain permission" algorithm.
This term is on its way out, per whatwg/html#4335.
This term is on its way out, per whatwg/html#4335.
* Remove uses of "responsible document" This term is on its way out, per whatwg/html#4335.
It was confusing to have this as a generic on environment settings objects, since it only applied to window environment settings objects. Instead, specifications should get the Window object's associated Document directly, if necessary by looking at the settings object's global object (which will, in some cases, be a Window object). Closes #4335.
It was confusing to have this as a generic on environment settings objects, since it only applied to window environment settings objects. Instead, specifications should get the Window object's associated Document directly, if necessary by looking at the settings object's global object (which will, in some cases, be a Window object). Closes #4335.
It was confusing to have this as a generic on environment settings objects, since it only applied to window environment settings objects. Instead, specifications should get the Window object's associated Document directly, if necessary by looking at the settings object's global object (which will, in some cases, be a Window object). Closes whatwg#4335.
It's seems you could always get the associated Document from the settings object's global object instead.
An alternative might be defining "relevant document" and using that throughout.
This came up in https://github.com/whatwg/html/pull/4214/files#r253238258.
This seems worthwhile as currently one of the requirements on
BroadcastChannel's settings object reads "a global object that is a Window object and a responsible document that is fully active" which might make one think the Window object's associated Document is something else.(This is a rather good issue if you're already somewhat familiar with the HTML Standard and are interested in streamlining language and potentially introducing new concepts that can be used across all the various standards that build upon HTML.)
The text was updated successfully, but these errors were encountered: