I would like to organize sessions for specifications I've been working on such as Idle Detection, Serial and WebUSB. Do we want to organize sessions here first or have the participants in each incubation organize them for ourselves?

For partially-onscreen stuff, I suspect the current algorithm is fine, yeah.

(Thoughts on that, for the Move Distance metric: if an element moves by 100px, then the user still sees something moving by 100px, regardless of whether the element is fully vs. partially onscreen. So it makes sense for us not to care whether the element is fully vs. partially onscreen for this calculation.

And the offscreen portion will still be "discounted" via the reduction in Impact Area for the moved thing, since the Impact Area excludes offscreen stuff, via the definition of Visual Representation.)

Yea that sounds like a bug to me. I think we should ignore content that was moved from being completely offscreen to partially of fully onscreen. Similarly, we should ignore content that was onscreen and moved to being completely offscreen. For content that was partially onscreen and moved to still be (at least partially) onscreen, does the current algorithm correctly capture the move distance or do you think we need to make some modifications in cases where the content is not fully onscreen?

Yea, painting invisible things is always tricky... In this case, I agree that one possible solution is to say that the above (plus potentially others) may be considered or ignored for the purposes of layout shift. Another possibility is that the above elements really shouldn't trigger layout shifts, and the fact that opacity:0 ones do would be a bug in the Chrome implementation (probably should add WPTs for this). But nonetheless due to the hairy nature of these kinds of elements we should clarify either way. Thanks for pointing out this problem and for the investigation into the Chrome behavior :)

CC @npm1 @mattwoodrow

Agree adding a class isn't horrible but media queries do seem purpose-built for this case.

The example of making your logo and title elements big might not fit that well with the proposal's more recent focus on prerendering.

It depends a lot on the use case. It doesn't fit with "swipe to navigate" type cases but I recall seeing a real-world demo someone made with small ~100x100 link buttons expanding to become the page. In that case, we're still prerendering the successor page but the button is too small to show the page contents - you could have a pretty simple but slick transition that translates the Logo+Title from button-filling into it's final position on the page. That will be a lot easier to do from inside the page than trying to coordinate across pages:

#title-and-logo {
  transition-duration: 1s;
  transition-property: transform;
}

@media (render-mode: preview) {
  #title-and-logo {
    transition-duration: 1s;
    transition-property: transform;
    transform: scale(3) translate3d(-100px, -100px, 0);
  }
}

I think this still fits with the prerendering focus as something like this really relies on being prerendered.

Suppose you have an element that is positioned offscreen (e.g. with position:absolute; left: -50px) which then snaps onscreen (e.g. by changing left to 0)

The spec currently requires us to consider how far the element moved, as one of the inputs to layout shift. (It moved 50px in this example, so it would contribute 50px to the maximum move distance calculation, which then determines the Distance Fraction)

Now: if the node's initial offscreen position were left:-1000px, then we would instead contribute 1000px to the maximum move distance calculation, and this node would have a much harsher impact on the Layout Shift value.

This doesn't really make sense. From a user's perspective, this is content that has just appeared, and the user doesn't know & doesn't care how far offscreen it was before it appeared. (It's not any better or worse for its prior posiiton to be at -1000px vs. -50px, as long as it was entirely clipped at that point, so the score shouldn't give any advantage to one value or another.)

It feels like we should treat this scenario the same as we treat content that was freshly-created (i.e. don't consider it "moved" at all; there's no last-position), in order to capture that actual user experience.

I mean, it's not quite that bad:

if (window.portalHost)
  document.documentElement.classList.add('in-portal');
addEventListener('portalactivate', () => document.documentElement.classList.remove('in-portal'));

I want to point out that if we want pages to display differently inside a portal vs. outside, a CSS hook seems really important. E.g. using the example above, you'd currently have to do something like

<script>
if (window.portalHost) {
  const style = document.createElement('style');
  style.textContent = `
    #logo {
      position: fixed;
      width: 100%; height: 50%;
      left: 0; top: 0;
    }
    #title {
      position: fixed;
      width: 100%; height: 50%;
      left: 0; top: 50%;
    }
  `;
  document.body.appendChild(style);
  
  window.addEventListener("portalactivate", () => {
    style.remove();
  }, { once: true });
}
</script>

which is madness.

The example of making your logo and title elements big might not fit that well with the proposal's more recent focus on prerendering. But a more important stylesheet might be something like

@media (render-mode: preview) {
  .signup-prompt, a.signin, a.signup {
    display: none;
  }
}

(again using GitHub as an example), to avoid the "flash of un-logged-in content".

So IMO some kind of styling hook is pretty high priority, even for an MVP. Something that allows differentiating between small previews and large prerenders, like the preview-scale @bokand mentions, might not be necessary yet; it'll depend on what we see people building with portals.

I missed this issue when I filed #241 so I closed it in favor of this one. I'll repost my suggestion from there which appears to basically a rehash of what's already been proposed here.

To the outer page, the portal should behave as a replaced object like an <img>. The embedder page can lightly control the "image" inside the portal using object-fit and object-position. More detailed customization of a portal preview is left to the embeddee page and we do this by introducing a media query:

@media (render-mode: preview) {
  #logo {
    position: fixed;
    width: 100%; height: 50%;
    left: 0; top: 0;
  }
  #title {
    position: fixed;
    width: 100%; height: 50%;
    left: 0; top: 50%;
  }
}

@jeremyroman correctly points out that in some cases (very small portal), a page might want to use a thumbnail (like above), but that may not be appropriate in other cases (e.g. the scroll into article mentioned above). It'd seem useful (for cross-origin cases where one party doesn't control both ends) to also have some notion of the size we're being displayed in.

I'd propose adding some low-granularity signal (probably also media query, e.g. @media (preview-scale <= 0.5) to let the page adjust itself for a variety of scenarios. To prevent using this as a communication channel, I think this wouldn't be able to change dynamically and the granularity would need to be fixed to some arbitrary increments (e.g. 0.25).

IIUC, authors can register hooks in script for changes to media queries so this looks like it'd be quite flexible. Does a model like this satisfy the use cases folks here are thinking of?

1. What should the default be?

I agree that scaling it down seems reasonable.

2. What styling hooks should the embedder have, if any?

If the target page doesn't expect to be portaled...

This should not be possible. The plan is that content needs to opt-in to being portaled. So, I don't think we need to give embedders much control. And as you say over in #173, they can get some basic control over the experience (but not the rendering) by just slapping an image over the top of the portal or similar.

3. What styling hooks should the embeddee have? How should these interact with those in the second point?

I think this fits nicely with media queries:

I'm not a CSS expert, but I generally agree. I'll move this discussion over to there.

I agree with your conclusions and proposed path forward. Now to go look at #241.

This is closely related to #173 - it seems likely the model we want is a replaced-like model, where the portaled page is rendered with its initial containing block matching the outer viewport size. This will ensure that sizing isn't a communication channel between the embedder and embeddee and that activation is seamless without a big relayout (and also, most content probably isn't well suited to be rendered in small boxes or may switch to a mobile layout).

However, as @domenic mentions - this model would commonly result in a poor preview. I think this invites three questions:

1. What should the default be?
2. What styling hooks should the embedder have, if any?
3. What styling hooks should the embeddee have? How should these interact with those in the second point?

1. What should the default be?

If embedder just dumps a stock <portal> to an unexpecting page, how should it be rendered? IMHO, just scaling the page down using the equivalent of object-fit: contain; object-position: top should look ok (if too small) in most cases. This would look similar to Domenic's first example

2. What styling hooks should the embedder have, if any?

If the target page doesn't expect to be portaled, the embedder could put in some effort to make the portal look more appealing. E.g. by changing object-fit and object-position to fill the portal with the most relevant content. It looks like object-fit doesn't today allow arbitrarily "zooming in" - limiting what an embedder could do but for the sake of argument, assume the embedder could choose the exact rect of the rendered page to use as a preview (in some other way).

It's not clear to me embedders should have this ability - destination pages may not want to give up this control for a number of reasons: brand control, editorialized previews, hiding information, etc.

It definitely seems like embedees should be able to control how their pages are previewed - but, if embedders can also add some customization, what happens if the destination page makes some changes and breaks the outer customizations?

3. What styling hooks should the embeddee have? How should these interact with those in the second point?

Interaction with the above would be easiest if there was no way for the embedder to modify the portal preview and this would be my preference.

OTOH, maybe it's useful enough that we need to allow it; in that case, I think an embeddee provided preview should override the choices of the embedder, rather than try to combine them. Otherwise, when adding/modifying their previews, embeddees would have to anticipate all the choices embedders might have made which they can't realistically account for.

On the mechanism:

I think this fits nicely with media queries:

@media (render-mode: preview) {
  #logo {
    position: fixed;
    width: 100%; height: 50%;
    left: 0; top: 0;
  }
  #title {
    position: fixed;
    width: 100%; height: 50%;
    left: 0; top: 50%;
  }
}

Given the default of object-fit: contain; object-position: top the embeddee will always know how the preview will look, only the size may change. This seems to me like a reasonable amount of richness without adding a ton of complexity.

What do y'all think?

I don't follow the argument for object-position: top

Oops, that's a remenant from when I was toying with making the default object-fit: cover. Agree leaving it as the usual 50% 50% default makes more sense with contain.

It sounds like you might be proposing to restrict the legal values of object-fit to restrict embedder clipping, though it's not clear to me this really prevents much, as the embedder can still clip the preview by putting it in another element and applying clip or overflow: hidden.

Yup, I hadn't thought of this at the time - given that, I agree there's no sense in restricting it.

The last question sounds like a dupe of #3;

Ah, hadn't seen it - I'll close this in favor of it.

making those style changes is probably actually negative for user experience in many cases. It's difficult to figure out how we could distinguish the two without providing too useful a communication channel

Yeah, I think we could provide some kind of low-granularity size information (e.g. 200px increments) and only populate it during load (i.e. resizes aren't communicated). That seems like it'd remove resize as a communication channel; though pages could still remove/re-add a portal and use the size to communicate info. I'm not sure that's an issue since the outer page could also use ordered resource fetches to the same server to communicate similarly.

In any case, I think as long as we have some vaguely plausible path visible to us for how this might work I'm of the mind that we can punt on this for now.

object-fit + object-position do let you zoom/pan as long as the zoom you want is 100% of original size, with object-fit: none. Obviously for 3P cases you might not know where to zoom to.

Defaulting to object-fit: contain makes sense to me mostly because I think stretching the preview (or any replaced content, honestly) looks silly. I don't follow the argument for object-position: top, though; this just affects the alignment of the preview inside the embedder-provided box, which feels like it's very reasonably inside their control (and so I'd have expected the default to be 50% 50% as usual).

It sounds like you might be proposing to restrict the legal values of object-fit to restrict embedder clipping, though it's not clear to me this really prevents much, as the embedder can still clip the preview by putting it in another element and applying clip or overflow: hidden.

The last question sounds like a dupe of #3; a media query may well be useful -- perhaps moreso now that we expect scaling to make the author's content tiny in the common case, giving them more reason to adjust style in this mode. If you want to pursue that now you should probably take over that issue (or merge it with this one, considering they have basically the same name anyhow).

One would hope authors who did this would also add some sort of nice transition to keep this seamless; it's probably not great for seamlessness if authors make radical changes to their style/layout without smoothly transitioning. But not much we can do about that.

The other question, though, is whether authors should make their logo/title/etc huge while in a portal. If the portal is tiny, then it makes sense, but if the portal is at or close to 100% scale, as in a swipe-from-bottom or fullscreen carousel experience, then making those style changes is probably actually negative for user experience in many cases. It's difficult to figure out how we could distinguish the two without providing too useful a communication channel. Maybe a bit that says "scale was >50% when the portal element load started" is safe even if we can't provide the exact scale all the time, or something like that? Alternatively, we could punt on this and see what becomes more common in experimental or real usage.

*enter/leave are triggered by *move, so not sure those need to be listed.

I don't quite understand why keyup is special.

Indeed

Bumps websocket-extensions from 0.1.3 to 0.1.4. <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/faye/websocket-extensions-node/blob/master/CHANGELOG.md">websocket-extensions's changelog</a>.</em></p> <blockquote> <h3>0.1.4 / 2020-06-02</h3> <ul> <li>Remove a ReDoS vulnerability in the header parser (CVE-2020-7662, reported by Robert McLaughlin)</li> <li>Change license from MIT to Apache 2.0</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/faye/websocket-extensions-node/commit/8efd0cd6e35faf9bb9cb08759be1e27082177d43"><code>8efd0cd</code></a> Bump version to 0.1.4</li> <li><a href="https://github.com/faye/websocket-extensions-node/commit/3dad4ad44a8c5f74d4f8f4efd3f9d6e0b5df3051"><code>3dad4ad</code></a> Remove ReDoS vulnerability in the Sec-WebSocket-Extensions header parser</li> <li><a href="https://github.com/faye/websocket-extensions-node/commit/4a76c75efb1c5d6a2f60550e9501757458d19533"><code>4a76c75</code></a> Add Node versions 13 and 14 on Travis</li> <li><a href="https://github.com/faye/websocket-extensions-node/commit/44a677a9c0631daed0b0f4a4b68c095b624183b8"><code>44a677a</code></a> Formatting change: {...} should have spaces inside the braces</li> <li><a href="https://github.com/faye/websocket-extensions-node/commit/f6c50aba0c20ff45b0f87cea33babec1217ec3f5"><code>f6c50ab</code></a> Let npm reformat package.json</li> <li><a href="https://github.com/faye/websocket-extensions-node/commit/2d211f3705d52d9efb4f01daf5a253adf828592e"><code>2d211f3</code></a> Change markdown formatting of docs.</li> <li><a href="https://github.com/faye/websocket-extensions-node/commit/0b620834cc1e1f2eace1d55ab17f71d90d88271d"><code>0b62083</code></a> Update Travis target versions.</li> <li><a href="https://github.com/faye/websocket-extensions-node/commit/729a4653073fa8dd020561113513bfa2e2119415"><code>729a465</code></a> Switch license to Apache 2.0.</li> <li>See full diff in <a href="https://github.com/faye/websocket-extensions-node/compare/0.1.3...0.1.4">compare view</a></li> </ul> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

Bumps lodash from 4.17.15 to 4.17.19. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/lodash/lodash/releases">lodash's releases</a>.</em></p> <blockquote> <h2>4.17.16</h2> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/lodash/lodash/commit/d7fbc52ee0466a6d248f047b5d5c3e6d1e099056"><code>d7fbc52</code></a> Bump to v4.17.19</li> <li><a href="https://github.com/lodash/lodash/commit/2e1c0f22f425e9c013815b2cd7c2ebd51f49a8d6"><code>2e1c0f2</code></a> Add npm-package</li> <li><a href="https://github.com/lodash/lodash/commit/1b6c282299f4e0271f932b466c67f0f822aa308e"><code>1b6c282</code></a> Bump to v4.17.18</li> <li><a href="https://github.com/lodash/lodash/commit/a370ac81408de2da77a82b3c4b61a01a3b9c2fac"><code>a370ac8</code></a> Bump to v4.17.17</li> <li><a href="https://github.com/lodash/lodash/commit/1144918f3578a84fcc4986da9b806e63a6175cbb"><code>1144918</code></a> Rebuild lodash and docs</li> <li><a href="https://github.com/lodash/lodash/commit/3a3b0fd339c2109563f7e8167dc95265ed82ef3e"><code>3a3b0fd</code></a> Bump to v4.17.16</li> <li><a href="https://github.com/lodash/lodash/commit/c84fe82760fb2d3e03a63379b297a1cc1a2fce12"><code>c84fe82</code></a> fix(zipObjectDeep): prototype pollution (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4759">#4759</a>)</li> <li><a href="https://github.com/lodash/lodash/commit/e7b28ea6cb17b4ca021e7c9d66218c8c89782f32"><code>e7b28ea</code></a> Sanitize sourceURL so it cannot affect evaled code (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4518">#4518</a>)</li> <li><a href="https://github.com/lodash/lodash/commit/0cec225778d4ac26c2bac95031ecc92a94f08bbb"><code>0cec225</code></a> Fix lodash.isEqual for circular references (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4320">#4320</a>) (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4515">#4515</a>)</li> <li><a href="https://github.com/lodash/lodash/commit/94c3a8133cb4fcdb50db72b4fd14dd884b195cd5"><code>94c3a81</code></a> Document matches* shorthands for over* methods (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4510">#4510</a>) (<a href="https://github-redirect.dependabot.com/lodash/lodash/issues/4514">#4514</a>)</li> <li>Additional commits viewable in <a href="https://github.com/lodash/lodash/compare/4.17.15...4.17.19">compare view</a></li> </ul> </details> <details> <summary>Maintainer changes</summary> <p>This version was pushed to npm by <a href="https://www.npmjs.com/~mathias">mathias</a>, a new releaser for lodash since your current version.</p> </details> <br />

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

<details> <summary>Dependabot commands and options</summary> <br />

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
• @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
• @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
• @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
• @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

</details>

Marked as non substantive for IPR from ash-nazg.

Hi. This adds svelte-monetization to the list of tools. Let me know if any changes are required.

Marked as non substantive for IPR from ash-nazg.

Ah yes, I guess we still have the crypto in the Request Signing bit that we'll maybe need crypto agility on, though its a bit weird that its really between the client and the downstream consumers. The Trust Token issuers don't really care about what the key looks like/how it works since they're only acting as a witness/signer over the hash.

One fix for that would be to send a key type along with the public key to the issuer, so the redemption record could include that information in the binding, and for the most part the browser can 'grease' the set of key types it supports/are required to be supported by the ecosystem.

I assume this is the intent of WICG/proposals?

If handling it by versioning is a possible approach, we should still look at if browsers should require a set of versions to ensure the ecosystem doesn't snap to a single version.

Regarding dropping the "Signed" part of SRRs-- can you help me better understand what crypto operations would still be happening on the client? I assume signed requests by the client would still be in scope; how can we ensure that a client can have a choice in algorithm for that operation?

s/three different filter/three different filters/

<!-- This comment and the below content is programatically generated. You may add a comma-separated list of anchors you'd like a direct link to below (e.g. #idl-serializers, #idl-sequence):

Don't remove this comment or modify anything below this line.
If you don't want a preview generated for this pull request,
just replace the whole of this comment's content by "no preview"
and remove what's below.

-->

<a href="https://pr-preview.s3.amazonaws.com/tomayac/native-file-system/pull/212.html" title="Last updated on Aug 5, 2020, 9:04 AM UTC (394e99b)">Preview</a> | <a href="https://pr-preview.s3.amazonaws.com/WICG/native-file-system/212/7fbe134...tomayac:394e99b.html" title="Last updated on Aug 5, 2020, 9:04 AM UTC (394e99b)">Diff</a>

More generally, we were thinking that we could just mesh crypto choice with the versioning problem. TrustTokenVA supports only Ed25519, TrustTokenVB supports only P256, etc, and as long as Client Foo always prefers TrustTokenVB configurations over TrustTokenVA configs, then it should be fine for an issuer to have multiple versions in play at the same time, and for crypto agility we could have a few versions supported at a time with different internal crypto. Though there are a number of edge cases that still need to be sorted out.

For having one joint (the version) to vary rather than having a bunch of different parameters at different layers. Though if there's enough of a need for supporting a lot of algorithms, maybe having some sort of list internal to a version might make sense to think about.

All that being said, we're considering dropping the concept of a "Signed" Redemption Record from the protocol and just allowing the issuer to return arbitrary data in the redemption record, which would mean that the selection of signature and distribution of keys/key rotation for that signature would be up to the issuer (presumably with standards/specs for particular ecosystems where the Redemption Record needs to be consumed downstream). The reasoning for pursuing that is that while originally we were considering having the client verify the contents of the Redemption Record, it turns out to be a meaningless mitigation, since associating arbitrary data to the SRR is trivial, and if the client doesn't care about the contents of the Redemption Record, there doesn't seem to be reason to be doing any of this signature verification.

getStorageDirectory() or some such? Or navigator.storage.getDirectory()?

The "TrustTokenV1 Issuer Protocol" document has various steps that depend solely on using Ed25519.

From a long-term protocol health perspective, it’s important that crypto operations support multiple algorithms in case future research indicates one should no longer be used. This is also useful for clients that want to be configured to not use specific algorithms for policy reasons (e.g. guidelines such as FIPS) to choose what algorithm(s) they want to allow.

There are two obvious potential concerns around having an algorithm negotiation scheme: privacy and interoperability.

The privacy concern is that this might provide additional client fingerprinting entropy if different clients support different algorithms.

The interop concern is that one of more of the entities involved in these flows may not validate that they work end-to-end with an algorithm not preferred by a major browser (e.g. imagine if Chrome chooses to always use Ed25519) and therefore not fully support other browsers.

A potential mitigation for both of these concerns might be to have browsers require that issuers support the full set of algorithms and to have some set of browser clients choose an alternative algorithm infrequently and randomly; this would act a little like "GREASE" (albeit with a fixed set of actual algorithms rather than a set of invalid names) to ensure issuers consistently see and test for different algorithms and to ensure it’s not a reliable signal of what browser is in use.

If there is support for solving this, we can talk about what algorithm(s) should be added in this issue or a separate one.

Good point. Any name suggestions?

Is the 'hide things from the client page' paranoia in section 3.4 causing this?

Regarding the paranoia, I've removed the spec text in #129 and opened #128 to discuss adding an API to be able to access this information.

Oh yea I agree that should stop the algorithm too, seems that the spec is just not covering this properly. What about this: we keep a flag that is set when the user performs some interaction which will trigger an event which is not one of mouseMove, mouseEnter, mouseLeave, the touch/pointer counterparts of those, and keyUp.

We do use the event's timeStamp in the implementation, which probably isn't what we want in the long term for 'artificial' input events. This would probably require a lot of work in the input specs, as it would probably require fixing it on a case-by-case basis. For now, the timeStamp is the closest point in time we have to when the user interaction occurred, but it's not perfect.

You're right that the time when we're 'about to run event handlers' is not that precise. I'm tempted to mark that part of the section non-normative (starting from definition of delay). We can clarify there that delay is computed as processingStart - startTime, and processingStart is set in the processing model (so the answer is the latter, the beginning of https://dom.spec.whatwg.org/#concept-event-dispatch).

We don't want to give users the incorrect impression they would be safer installing a native app.

Mock added: preview

This change expands the Future Extensions section to discuss the possibility of obtaining tokens from non-web sources like native applications or operating systems.

Great, thank you. 3. is solved then, I'll open a dedicated PR for this.

This leaves us with "impression" designating several entities (1.) and meaning "view" in the ads space (2.). With your feedback and our chat, here's the completed picture:

1. Several entities are designated by the same term

As of now, "impression" in the explainer and the API is used:

• To designate he HTML <a> tag, be it before or after a click or view has happened
• To designate the event of the user clicking or viewing the ad
• To designate a piece of data stored in the browser once a click or view has happened (= "attributable impression" concept @csharrison proposed)
• In the HTML attributes impression-data and impression-expiry Note: This list is a base to clarify; a distinct term for each of these may not be needed.

[Opinion: from a web development and event-level API newcomer perspective, I think there's value in making theses entity types clear ("[...] tag", "[...] event").]

2. The impression term itself designates "views" in the ads space

In theory, definition: "An online advertisement impression is a single appearance of an advertisement on a web page" (source: IAB).

In theory, uses of this term in the wild: Note: not all of these would map to the event-level API, but this illustrate how the term is used in the ads space.

• Google Ads: "An impression is counted each time your ad is shown" (source: Google Ads Help). "Cost-per-thousand impressions (CPM): A way to bid where you pay per one thousand views (impressions)" (source: Google Ads Help)
• Microsoft Ads: "Impressions are the number of times an ad has been displayed on search results pages" (source: Microsoft Ads Help)
• iOS: "A viewable impression is logged on Workbench when Apple has received confirmation from iOS that 100 percent of the banner was fully displayed on-screen" (source: Apple's Ad Guide for Publishers, May 2020)

Note: this could be partly mitigated by the solutions we come up for 1. - for example, if a renaming is decided on and reduces occurrences of the term "impression" in contexts where it may be misunderstood.

So we'd need some flag to tell when user interaction caused some scrolling. Actual scroll event is dispatched way later. What all is counted as user interaction causing scrolling? What if there is <div onmousemove='setTimeout(function_which_triggers_scroll)'>move mouse over me</div>.

Perhaps I don't quite understand the reasoning around scrolling being special. Why for example using wheel to zoom a map isn't treated the same way?

Currently there is no feedback if the id passed into the delete method doesn't exist in the Content Index.

I'm unsure of what type of exception this should throw, but doing something like:

try {
	registration.index.delete("something");
} catch (e) {
	console.log('Failed to remove content', e.message);
}

would be good programming™️

Isn't there some mechanism that can restrict access to APIs from third-party scripts?

No, unfortunately.

Use of unscrutinized third party script falls into a different class of threats, like disgruntled developer risk, that affect all powerful APIs and are not specific to the web platform.

Right, I think this is where we get into the fundamental philosophical differences in our communities: Mozilla folks are hesitant to add anything to the platform that allow a "disgruntled developer" level attack. Why we have no BlueTooth, MIDI, etc. etc... so, in a sense they are specific to the web platform in as far as Mozilla (and Apple) have not allowed shipped these kinds of APIs for this reason.

That's not to say it's a show stopper - but it gives us a point at which we can ask, "what's this thing trying to do?"

s/three different filter/three different filters/

It assumes that the storage key will forever be an origin, which is less and less the case.

I don't think that is a MITM attack.

If I understand correctly, third-party script loaded in <script> tags with Subresource Integrity has the same security properties as any external script a web developer might copy/paste into their project repo, or list in their npm dependencies or similar.

Use of unscrutinized third party script falls into a different class of threats, like disgruntled developer risk, that affect all powerful APIs and are not specific to the web platform.

See #128 - it can be useful for the page to know the text being targeted. The security/privacy reasons aren't really sound - the page knows its own content and can tell where the user's viewport is so this doesn't offer much in the way of protection.

For compatibility reasons, we strip the fragment directive from the URL before page script has a chance to run. Even if it was available to the page, it would be difficult for the page to know in all cases which piece of text the fragment matches, if any, since it would require effectively re-implementing the browser's implementation and running it on the page.

As mentioned in Mozilla's position of this feature, there exist interesting use cases for knowing the text fragment, such as marginalia. We should expose this information so authors can make use of it for such cases.

We have a window.location.fragmentDirective object used for feature detection (may move to document soon, see https://crbug.com/1057795). This would probably be a good place to add this information. I don't have any concrete API shape in mind yet; as a starting point, how about:

location.fragmentDirective ::= [ Directive* ]

Directive ::= {
  name: 'text',
  data: 'foo-,quote,-bar'
  range: Range
}

Where fragmentDirective is an array of Directive objects (text or otherwise). Each Directive would contain the type (assuming others may be added in the future), raw text data, and type-specific data. In our case, a Range object pointing to the located text, or null if it wasn't found.

Curious if anyone else has thoughts on how this should look. At a start, we should remove parts of the spec and explainer that forbid UAs from exposing this information.

Isn't there some mechanism that can restrict access to APIs from third-party scripts?

Right, but what we should always keep in mind is that (as with all of these "scary" web APIs), we are not adding unheard of abilities to a completely safe vacuum; we are competing with native applications which have much less restricted network access.

If we can replace native apps that need network access with web apps that do so in a highly restrictive model (such as requiring explicit user entry of the destination host), that should severely limit the ability of those apps to conduct large-scale scanning.

The UI would have a control like "[ ] Allow future connections", both to support resilience when network difficulties occur and to avoid permissions fatigue when a given web app is used frequently.

In an industrial context, a dedicated machine might be configured with a web app that connects to specific devices. Requiring user interaction after each device power cycle or other disconnection would be unfortunate.

CC @npm1 and @mattwoodrow

I suspect the current Chrome behavior on my testcase (e.g. the strange behavior-difference between visibility:hidden vs opacity:0) is just a result of Chrome's internal/not-intended-to-be-web-observable decisions about which sorts of boxes generate paintable things vs. which ones don't.

Ideally, I think the spec should allow UAs to exclude unpainted content from contributing to layout shift, because: (1) clearly it doesn't contribute to user-perceived layout shifts (2) it may impose some burden on UAs (and prevent them from implementing certain optimizations) if this spec requires them to record the "hypothetically-painted" positions & sizes of unpainted boxes.

Ideally, the spec should encode this allowance in such a way as to also allow for variations between browser rendering engines on what things they bother to consider painted vs. unpainted. It should also allow for the possibility of new CSS features (like contain:paint which is relatively recent) which can produce obviously-unpainted content that a rendering engine may want to exclude from the layout-shift calculation.

Ack. We are following the general principle of no dialogs without transient activation.

Right now, the layout instability spec officially considers a moved element as contributing to instability if the element "generates one or more boxes", as defined here: https://wicg.github.io/layout-instability/#visual-representation

However, this may not be practical for implementations, and it seems to be inconsistent with how the feature is implemented in Chrome.

Consider for example this testcase, which has an element with visibility:hidden that gets shifted: https://jsfiddle.net/yqr570ex/

In Chrome 84, this testcase does NOT trigger a reported Layout Shift right now, even though the visibility:hidden element definitely "generates a box". I've included a few other notable CSS classes that you can set on the container for the shifted element (the thing with id="giveMeAClass"). And when the shifted element's parent has...

• visibility:hidden: it does NOT trigger a layout shift report in Chrome (as noted above)
• contain:paint and zero size (i.e. fully clipped): it does NOT trigger a layout shift report in Chrome. ...vs.:
• opacity:0: it DOES trigger a layout shift report in Chrome.
• contain:paint and a small nonzero size (i.e. almost-fully clipped, nothing actually painted): it DOES trigger a layout shift report in Chrome.

I think both the spec & Chrome need to be updated to have a coherent story on which of these should be considered. The final one here (contain:paint and small nonzero size) makes sense, but the other three seem like they should be consistent & should be clearly defined by the spec; right now, the spec seems like it would call for them all to trigger layout shifts.

Thank you for the information. It make me clear. As you said, it seems to be hard to do what I considered with different encoder. It looks like that I should handle a unit of IDR period.

I've checked VideoEncoder between latest idl and google doc. It looks work in progress. So I'll be wait to release them. (It's just be RTC use-case though, I concern that I wonder if a path from VideoEncoder to VideoDecoder may be complicated to initialized.)

Anyway thanks!

IMHO, to achieve the use cases above, the onus should be on the destination page to provide the preview. I've outlined how that might look in #241. tl;dr The embeddee may not want anyone to control the preview, changes to the portaled page mean the embedder's customizations may break, and the embedder probably can't provide a great preview anyway. We should define a sensible default and give the destination page a hook to define a good preview.

If a page is especially badly suited, like in @domenic's example above), the embedder could always just slap a GitHub logo and some text over top of the portal and activate it on click.

WDYT? I think the styling hooks aren't necessarily an MVP but I'd like to start implementing the change to use a replaced-like rendering model and fixing the layout size to the outer page's viewport. Does anyone have major objections to doing that?

This is closely related to #173 - it seems likely the model we want is a replaced-like model, where the portaled page is rendered with its initial containing block matching the outer viewport size. This will ensure that sizing isn't a communication channel between the embedder and embeddee and that activation is seamless without a big relayout (and also, most content probably isn't well suited to be rendered in small boxes or may switch to a mobile layout).

However, as @domenic mentions - this model would commonly result in a poor preview. I think this invites three questions:

1. What should the default be?
2. What styling hooks should the embedder have, if any?
3. What styling hooks should the embeddee have? How should these interact with those in the second point?

1. What should the default be?

If embedder just dumps a stock <portal> to an unexpecting page, how should it be rendered? IMHO, just scaling the page down using the equivalent of object-fit: contain; object-position: top should look ok (if too small) in most cases. This would look similar to Domenic's first example

2. What styling hooks should the embedder have, if any?

If the target page doesn't expect to be portaled, the embedder could put in some effort to make the portal look more appealing. E.g. by changing object-fit and object-position to fill the portal with the most relevant content. It looks like object-fit doesn't today allow arbitrarily "zooming in" - limiting what an embedder could do but for the sake of argument, assume the embedder could choose the exact rect of the rendered page to use as a preview (in some other way).

It's not clear to me embedders should have this ability - destination pages may not want to give up this control for a number of reasons: brand control, editorialized previews, hiding information, etc.

It definitely seems like embedees should be able to control how their pages are previewed - but, if embedders can also add some customization, what happens if the destination page makes some changes and breaks the outer customizations?

3. What styling hooks should the embeddee have? How should these interact with those in the second point?

Interaction with the above would be easiest if there was no way for the embedder to modify the portal preview and this would be my preference.

OTOH, maybe it's useful enough that we need to allow it; in that case, I think an embeddee provided preview should override the choices of the embedder, rather than try to combine them. Otherwise, when adding/modifying their previews, embeddees would have to anticipate all the choices embedders might have made which they can't realistically account for.

On the mechanism:

I think this fits nicely with media queries:

@media (render-mode: preview) {
  #logo {
    position: fixed;
    width: 100%; height: 50%;
    left: 0; top: 0;
  }
  #title {
    position: fixed;
    width: 100%; height: 50%;
    left: 0; top: 50%;
  }
}

Given the default of object-fit: contain; object-position: top the embeddee will always know how the preview will look, only the size may change. This seems to me like a reasonable amount of richness without adding a ton of complexity.

What do y'all think?