Meta: export terms for Notifications API

[annevk]

In particular: a navigable's current session history entry, a user agent's top-level traversable set, and a session history entry's URL.

---

This is the use case I have for this in whatwg/notifications#213 (PR does not contain the long paragraph at the moment as it would result in issues):

 <li>
  <p>If <var>navigationURL</var> is non-null:

  <ol>
   <li><p>If there is an existing <a for=navigable>top-level traversable</a> <var>traversable</var>
   within the user agent's <a>top-level traversable set</a> whose
   <a for="navigable">current session history entry</a>'s <a for="session history entry">URL</a>
   <a for=url>equals</a> <var>navigationURL</var> with
   <a for=url/equals><i>exclude fragments</i></a> set to true, then <a>navigate</a>
   <var>traversable</var> to <var>navigationURL</var> and return. If there are multiple
   <a>top-level traversables</a> that satisfy the condition the user agent has to pick one in an
   <a>implementation-defined</a> manner.

   <li><p><a>Create a fresh top-level traversable</a> given <var>navigationURL</var>.
   <!-- Should maybe set userInvolvement correctly here, even though it doesn't do anything today. -->

   <li><p>Return.
  </ol>

---

/document-sequences.html ( diff )

[saschanaz]

If there are multiple that satisfy the condition the user agent has to pick one in an implementation-defined manner.

I'm not very happy to not specify that algorithm but maybe that's off topic here.

[annevk]

What would you suggest to say instead? The way tabs are presented and the ordering they have seems quite implementation-defined material to me.

[domenic]

If there is an existing <a for=navigable>top-level traversable</a> <var>traversable</var>

I think this should not have the for=.

a navigable's current session history entry

Are you absolutely sure you want current, not active? Most things on the platform use active, and that represents what the user sees.

a user agent's top-level traversable set

Exporting this seems very reasonable

and a session history entry's URL.

Exporting this also seems reasonable.

Although, I wonder about this alternate approach?

If there is a top-level traversable in the user agent's top-level traversable set whose active document's URL equals...

In theory the active session history entry's URL should always be in sync with the document's URL. (In practice there are some edge cases in some browsers around javascript: URLs that we still haven't figured out: #6649.)

[saschanaz]

What would you suggest to say instead? The way tabs are presented and the ordering they have seems quite implementation-defined material to me.

But still web visible, right? One can listen on visibilitychange event and guess the algorithm (whether the browser selects the last visible tab) for example. At least we should have some non-normative guide even if it's not fully spec-able.

[annevk]

@domenic thank you! I'll update this PR for your "active document" suggestion, which all around seems much better.

@saschanaz I'm not really sure what guidance we would give. This seems like the kind of thing to sort through with more deployment experience, but I honestly doubt it'll come up much.

[saschanaz]

The guide could be about what the initial implementations are planning to do for tab selection.

[annevk]

I still don't really see how that makes sense as it's also highly dependent on how that implementation opens tabs and such. A web application doesn't know the tab order between its tabs.

[saschanaz]

It doesn't know the visual tab order, if that's what Apple is planning to depend on. It does know which tab got the most recent user interaction / focus / etc.

[saschanaz]

But anyway I'm not very familiar with navigable, maybe @smaug---- is a better person for this PR.

A dumb question: with the proposed behavior, would it be possible to have SPA-like behavior where the existing JS context is used with the new history entry?

[domenic]

I do think there's been a good discussion here about whether we can specify the notifications API algorithm in more detail, but it should probably happen over in the notifications API repo, instead of this meta PR :)

I'll merge this now.