Rearrange spec structure as more explicit patches #189
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This brings the spec closer to how it would look upon landing in HTML, and explicitly calls out what sections it would expect things to land in. Notable changes: * Moved window.portalHost from "Miscellaneous extensions" into a new "Portal hosts" section, which contains the definitions for both window.portalHost and the PortalHost interface. * Made the onportalactivate event handler addition match HTML's existing structure. * Moved subsections of "Security considerations" which were spec patches into a new dedicated section, "Updates to other specifications". * Noted the connection to whatwg/html#1230 in addition to RFC 7034. * Tweaks the wording in the "Fetch Metadata Request Headers" section's non-normative summary notes.
jeremyroman
approved these changes
May 4, 2020
index.bs
Outdated
| </tr> | ||
| </thead> | ||
| <tbody> | ||
| <tr> | ||
| <td><dfn event for="Window"><code>portalactivate</code></dfn></td> | ||
| <td>{{PortalActivateEvent}}</td> | ||
| <td>The window is associated with a new [=top-level browsing context=] due to activation of its [=portal browsing context=].</td> | ||
| <td>{{Window}}</td> | ||
| <td>Fired at the {{Window}} when it is associated with a new [=top-level browsing context=] |
There was a problem hiding this comment.
Well, the {{Window}} (i.e. the object itself) is still associated with the same top-level browsing context; it's the UA-level window that is associated with a new browsing context. This wording was awkward before this PR too (probably because this was one of the earlier things to be written and terminology has changed).
There was a problem hiding this comment.
Hmm, yeah, I see. Maybe something like this?
Fired at the Window of a portal browsing context when that portal browsing context is activated.
There was a problem hiding this comment.
Sure, sg. The exact details are elsewhere, so this only needs to give the right general intution.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This brings the spec closer to how it would look upon landing in HTML, and explicitly calls out what sections it would expect things to land in. Notable changes:
Moved window.portalHost from "Miscellaneous extensions" into a new "Portal hosts" section, which contains the definitions for both window.portalHost and the PortalHost interface.
Made the onportalactivate event handler addition match HTML's existing structure.
Moved subsections of "Security considerations" which were spec patches into a new dedicated section, "Updates to other specifications".
Noted the connection to HTML's "navigate" algorithm should handle 'X-Frame-Options' and CSP's 'frame-ancestors' whatwg/html#1230 in addition to RFC 7034.
Tweaks the wording in the "Fetch Metadata Request Headers" section's non-normative summary notes.
Preview | Diff