profile
viewpoint

WICG/change-password-url 804

A Well-Known URL for Changing Passwords

WICG/background-sync 552

A design and spec for ServiceWorker-based background synchronization

WICG/aom 405

Accessibility Object Model

WICG/background-fetch 248

API proposal for background downloading/uploading

WICG/cq-usecases 175

Use cases and requirements for standardizing element queries.

WICG/construct-stylesheets 108

API for constructing CSS stylesheet objects

WICG/animation-worklet 90

🚫 Old repository for AnimationWorklet specification ➡️ New repository: https://github.com/w3c/css-houdini-drafts

WICG/async-append 86

A way to create DOM and add it to the document without blocking the main thread.

WICG/cookie-store 83

Sketching an asynchronous JavaScript cookies API for documents and workers

issue commentWICG/admin

TPAC Sessions

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?

marcoscaceres

comment created time in 5 minutes

startedWICG/scroll-to-text-fragment

started time in 22 minutes

issue commentWICG/layout-instability

The "move distance" metric imposes a strange penalty on extremely-offscreen content (depending on how far offscreen it was)

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.)

dholbert

comment created time in 29 minutes

issue commentWICG/layout-instability

The "move distance" metric imposes a strange penalty on extremely-offscreen content (depending on how far offscreen it was)

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?

dholbert

comment created time in an hour

issue commentWICG/layout-instability

layout instability spec needs to clarify whether (and which) unpainted nodes are considered or not

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 :)

dholbert

comment created time in an hour

PR opened WICG/proposals

Add some how-to steps
+6 -1

0 comment

1 changed file

pr created time in 2 hours

create barnchWICG/proposals

branch : managing-proposals

created branch time in 2 hours

startedWICG/webusb

started time in 2 hours

push eventWICG/proposals

Travis Leithead

commit sha c9fe75f169c7c4e0f64bf8d3399e5fc3e4b1ee5a

Update README.md

view details

push time in 2 hours

issue commentWICG/portals

Styling hook for unactivated portal

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.

triblondon

comment created time in 2 hours

push eventWICG/proposals

Travis Leithead

commit sha edaca96bda27c6737d584fb5241bb09e3d762ade

Update README.md

view details

push time in 2 hours

issue openedWICG/layout-instability

The "move distance" metric imposes a strange penalty on extremely-offscreen content (depending on how far offscreen it was)

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.

created time in 2 hours

issue commentWICG/portals

Styling hook for unactivated portal

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'));
triblondon

comment created time in 2 hours

issue commentWICG/portals

Styling hook for unactivated 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.

triblondon

comment created time in 2 hours

issue commentWICG/portals

Styling hook for unactivated portal

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?

triblondon

comment created time in 2 hours

issue commentWICG/portals

Styling hooks while portaled

  1. What should the default be?

I agree that scaling it down seems reasonable.

  1. 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.

  1. 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.

bokand

comment created time in 2 hours

issue commentWICG/portals

Use canvas-like width & height

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

jakearchibald

comment created time in 3 hours

issue closedWICG/portals

Styling hooks while portaled

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?

closed time in 3 hours

bokand

issue commentWICG/portals

Styling hooks while portaled

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.

bokand

comment created time in 3 hours

issue commentWICG/portals

Styling hooks while portaled

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.

bokand

comment created time in 3 hours

startedWICG/open-ui

started time in 3 hours

issue commentWICG/largest-contentful-paint

Why 'has dispatched scroll event' depends on whether untrusted scroll events have been dispatched?

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

I don't quite understand why keyup is special.

smaug----

comment created time in 3 hours

push eventWICG/native-file-system

Travis CI

commit sha 83f8bc90d8f7a4daca19335422190ac9777623b0

Deploy to GitHub Pages: 81f49a825fb5d6ea8f992f0e74cf217cb3a1aead

view details

push time in 4 hours

push eventWICG/native-file-system

Marijn Kruisselbrink

commit sha 81f49a825fb5d6ea8f992f0e74cf217cb3a1aead

Update README.md

view details

push time in 4 hours

issue commentWICG/admin

Hypothetical: what if we moved from Discourse to Github

Indeed

marcoscaceres

comment created time in 4 hours

delete branch WICG/webmonetization

delete branch : dependabot/npm_and_yarn/website/websocket-extensions-0.1.4

delete time in 5 hours

push eventWICG/webmonetization

dependabot[bot]

commit sha c76aa95a1269c6c38bea9fe84bd778321d4609c9

chore(deps): bump websocket-extensions from 0.1.3 to 0.1.4 in /website Bumps [websocket-extensions](https://github.com/faye/websocket-extensions-node) from 0.1.3 to 0.1.4. - [Release notes](https://github.com/faye/websocket-extensions-node/releases) - [Changelog](https://github.com/faye/websocket-extensions-node/blob/master/CHANGELOG.md) - [Commits](https://github.com/faye/websocket-extensions-node/compare/0.1.3...0.1.4) Signed-off-by: dependabot[bot] <support@github.com>

view details

push time in 5 hours

PR merged WICG/webmonetization

chore(deps): bump websocket-extensions from 0.1.3 to 0.1.4 in /website dependencies

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 compatibility score

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>

+3 -3

0 comment

1 changed file

dependabot[bot]

pr closed time in 5 hours

delete branch WICG/webmonetization

delete branch : dependabot/npm_and_yarn/website/lodash-4.17.19

delete time in 5 hours

push eventWICG/webmonetization

dependabot[bot]

commit sha 08c44d48d6c652045cb1be46f34990a4e96f8700

chore(deps): bump lodash from 4.17.15 to 4.17.19 in /website Bumps [lodash](https://github.com/lodash/lodash) from 4.17.15 to 4.17.19. - [Release notes](https://github.com/lodash/lodash/releases) - [Commits](https://github.com/lodash/lodash/compare/4.17.15...4.17.19) Signed-off-by: dependabot[bot] <support@github.com>

view details

push time in 5 hours

PR merged WICG/webmonetization

chore(deps): bump lodash from 4.17.15 to 4.17.19 in /website dependencies

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 compatibility score

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>

+3 -3

1 comment

1 changed file

dependabot[bot]

pr closed time in 5 hours

pull request commentWICG/webmonetization

chore(deps): bump lodash from 4.17.15 to 4.17.19 in /website

Marked as non substantive for IPR from ash-nazg.

dependabot[bot]

comment created time in 5 hours

push eventWICG/webmonetization

CircleCI

commit sha 3dececcc18888423888affc1904d30c549f585da

Deploy website Deploy website version based on 12944398b3715f7dbaf0682687db3ea24e1abb4c

view details

push time in 5 hours

push eventWICG/webmonetization

Robert Anthonie Soriano

commit sha 12944398b3715f7dbaf0682687db3ea24e1abb4c

Add svelte-monetization to tools

view details

push time in 5 hours

PR merged WICG/webmonetization

Add svelte-monetization to tools

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

+60 -0

1 comment

2 changed files

sorxrob

pr closed time in 5 hours

pull request commentWICG/webmonetization

Add svelte-monetization to tools

Marked as non substantive for IPR from ash-nazg.

sorxrob

comment created time in 5 hours

push eventWICG/proposals

Travis Leithead

commit sha a164786693a2d29900244a7d5e27f8bdf96f21b6

Update CONTRIBUTING.md

view details

push time in 5 hours

push eventWICG/proposals

Travis Leithead

commit sha 57fd84318565fb4f691fdcc489bf0165530a1005

Update LICENSE.md

view details

push time in 5 hours

issue commentWICG/trust-token-api

Multiple crypto algorithms should be supported

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.

erik-anderson

comment created time in 5 hours

push eventWICG/proposals

Travis Leithead

commit sha 114b9a15345548280c878d062c9d7ea9f9cfe00c

Update w3c.json Mark this repo as a "process" repo (rather than a draft-producing repo)

view details

push time in 5 hours

issue commentWICG/admin

Hypothetical: what if we moved from Discourse to Github

I assume this is the intent of WICG/proposals?

marcoscaceres

comment created time in 5 hours

startedWICG/native-file-system

started time in 6 hours

startedWICG/proposals

started time in 6 hours

push eventWICG/proposals

Travis Leithead

commit sha 161d874dda9833563aa0f6abe4af20a548fba103

Adding baseline w3c.json

view details

push time in 6 hours

push eventWICG/proposals

Travis Leithead

commit sha 17037f962b4b65b4b7c2f23d3a9e3018634d41d8

Adding baseline CODE_OF_CONDUCT.md

view details

push time in 6 hours

push eventWICG/proposals

Travis Leithead

commit sha 11256be4f8c21e5f2c1154777ea7951ca9ef9ca5

Adding baseline README.md

view details

push time in 6 hours

push eventWICG/proposals

Travis Leithead

commit sha 70293cb1f358cf38010d77b848687d9f06aab9d7

Adding baseline CONTRIBUTING.md

view details

push time in 6 hours

create barnchWICG/proposals

branch : master

created branch time in 6 hours

created repositoryWICG/proposals

created time in 6 hours

issue commentWICG/trust-token-api

Multiple crypto algorithms should be supported

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?

erik-anderson

comment created time in 6 hours

push eventWICG/native-file-system

Thomas Steiner

commit sha ff04845f9fa0cfb0319a486148789128194f7e2a

Trivial typo fix (#212)

view details

push time in 6 hours

PR merged WICG/native-file-system

Trivial typo fix

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>

+1 -1

0 comment

1 changed file

tomayac

pr closed time in 6 hours

issue commentWICG/trust-token-api

Multiple crypto algorithms should be supported

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.

erik-anderson

comment created time in 6 hours

startedWICG/open-ui

started time in 6 hours

issue commentWICG/native-file-system

getOriginPrivateDirectory is not a name that's friendly to partitioning

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

annevk

comment created time in 6 hours

issue openedWICG/trust-token-api

Multiple crypto algorithms should be supported

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.

created time in 6 hours

issue commentWICG/native-file-system

getOriginPrivateDirectory is not a name that's friendly to partitioning

Good point. Any name suggestions?

annevk

comment created time in 6 hours

issue commentWICG/scroll-to-text-fragment

Client-side redirects (e.g. Twitter t.co) loses user gesture, breaks text fragment

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.

kevinmarks

comment created time in 7 hours

push eventWICG/scroll-to-text-fragment

David Bokan

commit sha ed08e87aee20326f09e8e0fde5302d1d9508cd51

Remove spec text forbidding the page to know the text fragment

view details

push time in 7 hours

issue commentWICG/largest-contentful-paint

Why 'has dispatched scroll event' depends on whether untrusted scroll events have been dispatched?

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.

smaug----

comment created time in 8 hours

issue commentWICG/event-timing

Event's delay is rather vague

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).

smaug----

comment created time in 9 hours

Pull request review commentWICG/raw-sockets

Security considerations in explainer

 See [Discourse](https://discourse.wicg.io/t/filling-the-remaining-gap-between-we User agents will need to carefully consider when to make the Raw Sockets API available to web applications, and what UI will be shown to the user. +++### Threat++MITM attackers may inject sockets API calls into a web page.++### Mitigation++The API will only available in secure contexts (HTTPS).++++### Threat++A web app might initiate connections without the user realizing.++### Mitigation++When initiating a connection, the user agent would show some UI.++The user can be asked to specify a hostname or IP address, with an option to permit future connections to this host.

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

Mock added: preview

ewilligers

comment created time in 10 hours

push eventWICG/trust-token-api

davidvancleve

commit sha bdf633ca0a7ab10d89f298f77f0e554983923ef5

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

view details

Steven Valdez

commit sha 1645c5f6bacb8491ee4050f63f32a8776a5eeff4

Merge pull request #37 from davidvancleve/patch-3 Add discussion of non-web sources of tokens

view details

push time in 10 hours

PR merged WICG/trust-token-api

Add discussion of non-web sources of tokens

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

+3 -0

1 comment

1 changed file

davidvancleve

pr closed time in 10 hours

push eventWICG/wicg.github.io

Philippe Le Hegaret

commit sha 7890cc3138ca663fc172219865a77fab29c5b654

Spreadsheet snapshot

view details

push time in 11 hours

push eventWICG/wicg.github.io

Philippe Le Hegaret

commit sha 7e9c400271cb5d61bc1510978154f6fa18233241

Spreadsheet snapshot

view details

push time in 11 hours

issue commentWICG/conversion-measurement-api

Attributes naming and terms

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.

maudnals

comment created time in 12 hours

issue commentWICG/largest-contentful-paint

Why 'has dispatched scroll event' depends on whether untrusted scroll events have been dispatched?

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?

smaug----

comment created time in 12 hours

issue openedWICG/content-index

Error handling for delete()

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™️

created time in 13 hours

Pull request review commentWICG/raw-sockets

Security considerations in explainer

 See [Discourse](https://discourse.wicg.io/t/filling-the-remaining-gap-between-we User agents will need to carefully consider when to make the Raw Sockets API available to web applications, and what UI will be shown to the user. +++### Threat++MITM attackers may inject sockets API calls into a web page.++### Mitigation++The API will only available in secure contexts (HTTPS).++

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?"

ewilligers

comment created time in 13 hours

PR opened WICG/native-file-system

Trivial typo fix

s/three different filter/three different filters/

+1 -1

0 comment

1 changed file

pr created time in 14 hours

startedWICG/portals

started time in 14 hours

issue openedWICG/native-file-system

getOriginPrivateDirectory is not a name that's friendly to partitioning

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

created time in 15 hours

startedWICG/focus-visible

started time in 15 hours

startedWICG/native-file-system

started time in 15 hours

startedWICG/virtual-scroller

started time in 17 hours

Pull request review commentWICG/raw-sockets

Security considerations in explainer

 See [Discourse](https://discourse.wicg.io/t/filling-the-remaining-gap-between-we User agents will need to carefully consider when to make the Raw Sockets API available to web applications, and what UI will be shown to the user. +++### Threat++MITM attackers may inject sockets API calls into a web page.++### Mitigation++The API will only available in secure contexts (HTTPS).++

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.

ewilligers

comment created time in 18 hours

PR opened WICG/scroll-to-text-fragment

Remove spec text forbidding the page to know the text fragment

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.

+25 -53

0 comment

2 changed files

pr created time in 19 hours

issue openedWICG/scroll-to-text-fragment

Expose text-fragment to page

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.

created time in 19 hours

startedWICG/layout-instability

started time in 20 hours

startedWICG/ua-client-hints

started time in 20 hours

Pull request review commentWICG/raw-sockets

Security considerations in explainer

 See [Discourse](https://discourse.wicg.io/t/filling-the-remaining-gap-between-we User agents will need to carefully consider when to make the Raw Sockets API available to web applications, and what UI will be shown to the user. +++### Threat++MITM attackers may inject sockets API calls into a web page.++### Mitigation++The API will only available in secure contexts (HTTPS).++

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

ewilligers

comment created time in 20 hours

Pull request review commentWICG/raw-sockets

Security considerations in explainer

 See [Discourse](https://discourse.wicg.io/t/filling-the-remaining-gap-between-we User agents will need to carefully consider when to make the Raw Sockets API available to web applications, and what UI will be shown to the user. +++### Threat++MITM attackers may inject sockets API calls into a web page.++### Mitigation++The API will only available in secure contexts (HTTPS).++++### Threat++A web app might initiate connections without the user realizing.++### Mitigation++When initiating a connection, the user agent would show some UI.++The user can be asked to specify a hostname or IP address, with an option to permit future connections to this host.

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.

ewilligers

comment created time in 20 hours

startedWICG/import-maps

started time in 20 hours

startedWICG/raw-clipboard-access

started time in 21 hours

startedWICG/trust-token-api

started time in 21 hours

Pull request review commentWICG/raw-sockets

Security considerations in explainer

 See [Discourse](https://discourse.wicg.io/t/filling-the-remaining-gap-between-we User agents will need to carefully consider when to make the Raw Sockets API available to web applications, and what UI will be shown to the user. +++### Threat++MITM attackers may inject sockets API calls into a web page.++### Mitigation++The API will only available in secure contexts (HTTPS).++++### Threat++A web app might initiate connections without the user realizing.++### Mitigation++When initiating a connection, the user agent would show some UI.++The user can be asked to specify a hostname or IP address, with an option to permit future connections to this host.++++### Threat++Attackers may use the API to DDOS third parties.++### Mitigation++Connection attempts would be rate limited.

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.

ewilligers

comment created time in 21 hours

issue commentWICG/layout-instability

layout instability spec needs to clarify whether (and which) unpainted nodes are considered or not

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.

dholbert

comment created time in 21 hours

Pull request review commentWICG/raw-sockets

Security considerations in explainer

 See [Discourse](https://discourse.wicg.io/t/filling-the-remaining-gap-between-we User agents will need to carefully consider when to make the Raw Sockets API available to web applications, and what UI will be shown to the user. +++### Threat++MITM attackers may inject sockets API calls into a web page.++### Mitigation++The API will only available in secure contexts (HTTPS).++++### Threat++A web app might initiate connections without the user realizing.++### Mitigation++When initiating a connection, the user agent would show some UI.++The user can be asked to specify a hostname or IP address, with an option to permit future connections to this host.++++### Threat++Attackers may use the API to DDOS third parties.++### Mitigation++Connection attempts would be rate limited.++Connections will only be able to be initiated after transient activation (user interaction with the page).

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

ewilligers

comment created time in 21 hours

issue openedWICG/layout-instability

layout instability spec needs to clarify whether (and which) unpainted nodes are considered or not

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.

created time in 21 hours

push eventWICG/idle-detection

Reilly Grant

commit sha 659306c58b8364b3cc81a3adf8edb0da3f30bf05

Word wrap README.md at 80 columns

view details

push time in a day

push eventWICG/idle-detection

Reilly Grant

commit sha 070fcf21b8e54f53b3b12b7cb440ab460369802a

Update HOWTO.md with availability information The API is available in Chrome 84 and later as an Origin Trial.

view details

push time in a day

startedWICG/video-editing

started time in a day

issue commentWICG/web-codecs

Importing / exporting out of band side data

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!

steveanton

comment created time in a day

startedWICG/trust-token-api

started time in a day

issue commentWICG/portals

Use canvas-like width & height

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?

jakearchibald

comment created time in a day

issue openedWICG/portals

Styling hooks while portaled

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?

created time in a day

more