profile
viewpoint

Automattic/node-canvas 7169

Node canvas is a Cairo backed Canvas implementation for NodeJS.

domenic/chai-as-promised 1372

Extends Chai with assertions about promises.

benschwarz/developers.whatwg.org 202

Used to create the contents of developers.whatwg.org

benjamingr/RegExp.escape 183

Proposal for adding RegExp.escape to the ECMAScript standard

domenic/browserify-deoptimizer 26

Transforms browserify bundles into a collection of single files

davidrosenberg/ml2018 22

DSGA-1003: Machine Learning and Computational Statistics, Spring 2018

davidrosenberg/ml2015 13

Website for DS-GA 1003: Machine Learning and Computational Statistics

domenic/amd-wrap 12

Wraps CommonJS files in `define(function (require, exports, module) { ... })`.

davidrosenberg/ml2016 10

DS-GA 1003: Machine Learning and Computational Statistics, Spring 2016

pull request commentwhatwg/url

Refactor query state to operate on a buffer

Can we get web platform tests for this that are URL-specific? Probably not part of the JSON files though.

annevk

comment created time in 3 hours

Pull request review commentwhatwg/url

Refactor query state to operate on a buffer

 inclusive, and U+007E (~). all code points, except the <a>ASCII alphanumeric</a>, U+002A (*), U+002D (-), U+002E (.), and U+005F (_). -<p>To <dfn for="code point">percent-encode after encoding</dfn>, given an <a for=/>encoding</a>-<var>encoding</var>, <a for=/>code point</a> <var>codePoint</var>, and a-<var>percentEncodeSet</var>, run these steps:+<p>To <dfn for=string>percent-encode after encoding</dfn>, given an <a for=/>encoding</a>+<var>encoding</var>, <a for=/>string</a> <var>input</var>, a <var>percentEncodeSet</var>, and an+optional boolean <var>spaceAsPlus</var> (default false), run these steps:  <ol>- <li><p>Let <var>bytes</var> be the result of <a lt=encode>encoding</a> <var>codePoint</var> using- <var>encoding</var>.+ <li><p>Let <var>encoder</var> be the result of <a>getting an encoder</a> from <var>encoding</var>. - <li>-  <p>If <var>bytes</var> starts with 0x26 (&amp;) 0x23 (#) and ends with 0x3B (;), then:--  <ol>-   <li><p>Let <var>output</var> be <var>bytes</var>, <a>isomorphic decoded</a>.+ <li><p>Let <var>inputQueue</var> be <var>input</var> onverted to an <a for=/>I/O queue</a>. -   <li><p>Replace the first two code points of <var>output</var> with "<code>%26%23</code>".--   <li><p>Replace the last code point of <var>output</var> with "<code>%3B</code>".--   <li><p>Return <var>output</var>.-  </ol>+ <li><p>Let <var>output</var> be the empty string. -  <p class="note no-backref">This can happen when <var>encoding</var> is not <a>UTF-8</a>.+ <li>+  <p>Let <var>potentialError</var> be 0. - <li><p>Let <var>output</var> be the empty string.</p></li>+  <p class=note>This needs to be a non-null value to initiate the subsequent while loop.   <li>-  <p>For each <var>byte</var> of <var>bytes</var>:+  <p>While <var>potentialError</var> is non-null:    <ol>-   <li><p>Let <var>isomorph</var> be a <a for=/>code point</a> whose <a for="code point">value</a>-   is <var>byte</var>'s <a for=byte>value</a>.+   <li><p>Let <var>encodeOutput</var> be an empty <a for=/>I/O queue</a>. -   <li><p>Assert: <var>percentEncodeSet</var> includes all non-<a>ASCII code points</a>.+   <li><p>Set <var>potentialError</var> to the result of running <a>encode or fail</a> with+   <var>inputQueue</var>, <var>encoder</var>, and <var>encodeOutput</var>. -   <li><p>If <var>isomorph</var> is not in <var>percentEncodeSet</var>, then append-   <var>isomorph</var> to <var>output</var>.+   <li>+    <p>For each <var>byte</var> of <var>encodeOutput</var> converted to a byte sequence: -   <li><p>Otherwise, <a for=byte>percent-encode</a> <var>byte</var> and append the result to-   <var>output</var>.-  </ol>+    <ol>+     <li><p>If <var>spaceAsPlus</var> is true and <var>byte</var> is 0x20 (SP), then append+     U+002B (+) to <var>output</var>. - <li><p>Return <var>output</var>.-</ol>+     <li><p>Let <var>isomorph</var> be a <a for=/>code point</a> whose <a for="code point">value</a>+     is <var>byte</var>'s <a for=byte>value</a>. -<p>To <dfn for="string">percent-encode after encoding</dfn>, given an <a for=/>encoding</a>-<var>encoding</var>, <a for=/>string</a> <var>input</var>, a <var>percentEncodeSet</var>, and a-boolean <var>spaceAsPlus</var>, run these steps:+     <li><p>Assert: <var>percentEncodeSet</var> includes all non-<a>ASCII code points</a>. -<ol>- <li><p>Let <var>output</var> be the empty string.</p></li>+     <li><p>If <var>isomorph</var> is not in <var>percentEncodeSet</var>, then append+     <var>isomorph</var> to <var>output</var>. - <li>-  <p>For each <var>codePoint</var> of <var>input</var>:+     <li><p>Otherwise, <a for=byte>percent-encode</a> <var>byte</var> and append the result to+     <var>output</var>.+    </ol> -  <ol>-   <li><p>If <var>spaceAsPlus</var> is true and <var>codePoint</var> is U+0020, then append-   U+002B (+) to <var>output</var>.+   <li>+    <p>If <var>potentialError</var> is non-null, then append "<code>%26%23</code>", followed by the+    shortest sequence of <a for=/>ASCII digits</a> representing <var>potentialError</var> in base+    ten, followed by "<code>%3B</code>", to <var>output</var>. -   <li><p>Otherwise, run <a for="code point">percent-encode after encoding</a> with-   <var>encoding</var>, <var>codePoint</var>, and <var>percentEncodeSet</var>, and append the result-   to <var>output</var>.+    <p class="note no-backref">This can happen when <var>encoding</var> is not <a>UTF-8</a>.   </ol>   <li><p>Return <var>output</var>. </ol>  <p>To <dfn for="code point" id=utf-8-percent-encode>UTF-8 percent-encode</dfn> a <a for=/>code point</a> <var>codePoint</var> using a <var>percentEncodeSet</var>, return the result-of running <a for="code point">percent-encode after encoding</a> with <a for=/>UTF-8</a>,-<var>codePoint</var>, and <var>percentEncodeSet</var>.+of running <a for=string>percent-encode after encoding</a> with <a for=/>UTF-8</a>,+<var>codePoint</var> as <a for=/>string</a>, and <var>percentEncodeSet</var>.
<var>codePoint</var> as a <a for=/>string</a>, and <var>percentEncodeSet</var>.
annevk

comment created time in 3 hours

Pull request review commentwhatwg/url

Refactor query state to operate on a buffer

 inclusive, and U+007E (~). all code points, except the <a>ASCII alphanumeric</a>, U+002A (*), U+002D (-), U+002E (.), and U+005F (_). -<p>To <dfn for="code point">percent-encode after encoding</dfn>, given an <a for=/>encoding</a>-<var>encoding</var>, <a for=/>code point</a> <var>codePoint</var>, and a-<var>percentEncodeSet</var>, run these steps:+<p>To <dfn for=string>percent-encode after encoding</dfn>, given an <a for=/>encoding</a>+<var>encoding</var>, <a for=/>string</a> <var>input</var>, a <var>percentEncodeSet</var>, and an+optional boolean <var>spaceAsPlus</var> (default false), run these steps:  <ol>- <li><p>Let <var>bytes</var> be the result of <a lt=encode>encoding</a> <var>codePoint</var> using- <var>encoding</var>.+ <li><p>Let <var>encoder</var> be the result of <a>getting an encoder</a> from <var>encoding</var>. - <li>-  <p>If <var>bytes</var> starts with 0x26 (&amp;) 0x23 (#) and ends with 0x3B (;), then:--  <ol>-   <li><p>Let <var>output</var> be <var>bytes</var>, <a>isomorphic decoded</a>.+ <li><p>Let <var>inputQueue</var> be <var>input</var> onverted to an <a for=/>I/O queue</a>. -   <li><p>Replace the first two code points of <var>output</var> with "<code>%26%23</code>".--   <li><p>Replace the last code point of <var>output</var> with "<code>%3B</code>".--   <li><p>Return <var>output</var>.-  </ol>+ <li><p>Let <var>output</var> be the empty string. -  <p class="note no-backref">This can happen when <var>encoding</var> is not <a>UTF-8</a>.+ <li>+  <p>Let <var>potentialError</var> be 0. - <li><p>Let <var>output</var> be the empty string.</p></li>+  <p class=note>This needs to be a non-null value to initiate the subsequent while loop.   <li>-  <p>For each <var>byte</var> of <var>bytes</var>:+  <p>While <var>potentialError</var> is non-null:    <ol>-   <li><p>Let <var>isomorph</var> be a <a for=/>code point</a> whose <a for="code point">value</a>-   is <var>byte</var>'s <a for=byte>value</a>.+   <li><p>Let <var>encodeOutput</var> be an empty <a for=/>I/O queue</a>. -   <li><p>Assert: <var>percentEncodeSet</var> includes all non-<a>ASCII code points</a>.+   <li><p>Set <var>potentialError</var> to the result of running <a>encode or fail</a> with+   <var>inputQueue</var>, <var>encoder</var>, and <var>encodeOutput</var>. -   <li><p>If <var>isomorph</var> is not in <var>percentEncodeSet</var>, then append-   <var>isomorph</var> to <var>output</var>.+   <li>+    <p>For each <var>byte</var> of <var>encodeOutput</var> converted to a byte sequence: -   <li><p>Otherwise, <a for=byte>percent-encode</a> <var>byte</var> and append the result to-   <var>output</var>.-  </ol>+    <ol>+     <li><p>If <var>spaceAsPlus</var> is true and <var>byte</var> is 0x20 (SP), then append+     U+002B (+) to <var>output</var>. - <li><p>Return <var>output</var>.-</ol>+     <li><p>Let <var>isomorph</var> be a <a for=/>code point</a> whose <a for="code point">value</a>+     is <var>byte</var>'s <a for=byte>value</a>. -<p>To <dfn for="string">percent-encode after encoding</dfn>, given an <a for=/>encoding</a>-<var>encoding</var>, <a for=/>string</a> <var>input</var>, a <var>percentEncodeSet</var>, and a-boolean <var>spaceAsPlus</var>, run these steps:+     <li><p>Assert: <var>percentEncodeSet</var> includes all non-<a>ASCII code points</a>. -<ol>- <li><p>Let <var>output</var> be the empty string.</p></li>+     <li><p>If <var>isomorph</var> is not in <var>percentEncodeSet</var>, then append+     <var>isomorph</var> to <var>output</var>. - <li>-  <p>For each <var>codePoint</var> of <var>input</var>:+     <li><p>Otherwise, <a for=byte>percent-encode</a> <var>byte</var> and append the result to+     <var>output</var>.+    </ol> -  <ol>-   <li><p>If <var>spaceAsPlus</var> is true and <var>codePoint</var> is U+0020, then append-   U+002B (+) to <var>output</var>.+   <li>+    <p>If <var>potentialError</var> is non-null, then append "<code>%26%23</code>", followed by the+    shortest sequence of <a for=/>ASCII digits</a> representing <var>potentialError</var> in base+    ten, followed by "<code>%3B</code>", to <var>output</var>. -   <li><p>Otherwise, run <a for="code point">percent-encode after encoding</a> with-   <var>encoding</var>, <var>codePoint</var>, and <var>percentEncodeSet</var>, and append the result-   to <var>output</var>.+    <p class="note no-backref">This can happen when <var>encoding</var> is not <a>UTF-8</a>.   </ol>   <li><p>Return <var>output</var>. </ol>  <p>To <dfn for="code point" id=utf-8-percent-encode>UTF-8 percent-encode</dfn> a <a for=/>code point</a> <var>codePoint</var> using a <var>percentEncodeSet</var>, return the result-of running <a for="code point">percent-encode after encoding</a> with <a for=/>UTF-8</a>,-<var>codePoint</var>, and <var>percentEncodeSet</var>.+of running <a for=string>percent-encode after encoding</a> with <a for=/>UTF-8</a>,+<var>codePoint</var> as <a for=/>string</a>, and <var>percentEncodeSet</var>.  <p>To <dfn export for=string>UTF-8 percent-encode</dfn> a <a for=/>string</a> <var>input</var> using a <var>percentEncodeSet</var>, return the result of running <a for=string>percent-encode after encoding</a> with <a for=/>UTF-8</a>, <var>input</var>,-<var>percentEncodeSet</var>, and false.+<var>percentEncodeSet</var>.
and <var>percentEncodeSet</var>.
annevk

comment created time in 3 hours

PullRequestReviewEvent
PullRequestReviewEvent

pull request commentwhatwg/html

Make COOP+COEP do not imply crossOriginIsolated.

I agree with @yutakahirano's suggestions. To give more detail on a particularly tricky part:

Modifying logic at https://html.spec.whatwg.org/multipage/window-object.html#script-settings-for-window-objects and adding a note.

My suggestion concretely here is that before step 4, you establish a boolean. Something like:

  1. Let canBeCOI be true if the user agent is willing to give access to COI features to window, and false otherwise.

then you can modify the "cross-origin isolated capability" to be something like:

Return true if all of the following hold:

  • realm's agent cluster's cross-origin-isolated is true
  • canBeCOI is true
  • window's associated Document is allowed to use the "cross-origin-isolated" feature Otherwise, return false

Without establishing the boolean ahead of time, if you just wrote something like "return false at the user agent's discretion" in the COIC algorithm, it would be possible per-spec for the value to change over time.

ArthurSonzogni

comment created time in 4 hours

push eventWICG/import-maps

Domenic Denicola

commit sha 535b5452b4a124f6e8ec9b37fd0ac3b2adc8cc95

Update community polyfills and tooling list See #146.

view details

push time in 4 hours

PR merged WICG/import-maps

Update community polyfills and tooling list

See #146.

+5 -5

0 comment

1 changed file

domenic

pr closed time in 4 hours

push eventWICG/import-maps

Domenic Denicola

commit sha 62e00ce2d15894472936bc8224bbb49b77ba4dd0

Update per comments and #233

view details

push time in 4 hours

pull request commentWICG/import-maps

Add link to @node-loader/import-maps.

Oh, nevermind, it's https://www.npmjs.com/package/@node-loader/import-maps

joeldenning

comment created time in 4 hours

Pull request review commentWICG/import-maps

Update community polyfills and tooling list

 The primary challenges here are in achieving agreement about built-in modules on  Several members of the community have been working on polyfills and tooling related to import maps. Here are the ones we know about: -* [@import-maps/generate](https://www.npmjs.com/package/@import-maps/generate) generates an import map from your `yarn.lock`. * [@import-maps/resolve](https://www.npmjs.com/package/@import-maps/resolve) resolves a specifier relative to an import map. * [@jsenv/node-module-import-map](https://www.npmjs.com/package/@jsenv/node-module-import-map) generates an import map from your `package.json` and `node_modules/` directories.-* [Snowpack](https://www.snowpack.dev) generates an import map when it installs your npm packages to run on the web.-* [Built-in Module Demo (with Rollup)](https://glitch.com/edit/#!/rollup-built-in-modules) contains code for a [Rollup](https://rollupjs.org/) plugin that generates an import map, focused on built-in module polyfills.+* [@jsenv/importmap-eslint-resolver](https://www.npmjs.com/package/@jsenv/importmap-eslint-resolver) enables import map resolution in [ESLint](https://eslint.org/) * [Deno](https://github.com/denoland/deno) is a JavaScript/TypeScript runtime with [built-in support for import maps](https://deno.land/manual/linking_to_external_code/import_maps). * [es-dev-server](https://www.npmjs.com/package/es-dev-server) allows using import maps during development, including polyfills.

Thanks! I'll consolidate these into a link to https://www.npmjs.com/package/@web/dev-server-import-maps

domenic

comment created time in 4 hours

PullRequestReviewEvent

pull request commentWICG/import-maps

Add link to @node-loader/import-maps.

Hmm, do you know why https://www.npmjs.com/package/@node-loader/node-loader-import-maps requires a login? I was hoping npm packages could have npm URLs instead of GitHub URLs, but I don't want to require people to login...

joeldenning

comment created time in 4 hours

PR closed WICG/import-maps

Add link to @node-loader/import-maps.

See https://github.com/node-loader/node-loader-import-maps

+1 -0

1 comment

1 changed file

joeldenning

pr closed time in 4 hours

pull request commentWICG/import-maps

Add link to @node-loader/import-maps.

Thanks! I'll fold this into #231, so we don't have to worry about the IPR bot.

joeldenning

comment created time in 4 hours

issue closedwhatwg/html

html

https://html.spec.whatwg.org/commit-snapshots/895fd80e599ed105b2dbf9afdf72ae65a9aa9096/

closed time in 5 hours

proctortwitchy

PR closed whatwg/html

Create form.md

<!-- Thank you for contributing to the HTML Standard! Please describe the change you are making and complete the checklist below if your change is not editorial. -->

  • [ ] At least two implementers are interested (and none opposed):
  • [ ] Tests are written and can be reviewed and commented upon at:
  • [ ] Implementation bugs are filed:
    • Chrome: …
    • Firefox: …
    • Safari: …

(See WHATWG Working Mode: Changes for more details.)

+67 -0

0 comment

1 changed file

alivapriyadarshini5

pr closed time in 6 hours

issue commentWICG/import-maps

Discussion issue for community tooling, polyfills, etc.

Hi folks,

I've attempted to incorporate the latest updates people have mentioned here in https://github.com/WICG/import-maps/pull/231. I've also tried to remove packages that are marked as deprecated, including some that @LarsDenBakker mentioned, and removed mention of Pika, which @thepassle mentioned, as their current website doesn't seem to discuss import maps. Any thoughts or review would be appreciated!

domenic

comment created time in a day

PR opened WICG/import-maps

Update community polyfills and tooling list

See #146.

+3 -4

0 comment

1 changed file

pr created time in a day

create barnchWICG/import-maps

branch : more-community-stuff

created branch time in a day

pull request commentwhatwg/html

Fix typo in storage interface

Thanks very much, and congrats on your first HTML Standard contribution!

ctur

comment created time in a day

push eventwhatwg/html

ctur

commit sha 895fd80e599ed105b2dbf9afdf72ae65a9aa9096

Fix typo in Storage's key() method

view details

push time in a day

PR merged whatwg/html

Fix typo in storage interface

This PR Fixes #6094 typo in Webstorage - Storage Interface definition

<!-- 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://whatpr.org/html/6095/acknowledgements.html" title="Last updated on Oct 22, 2020, 11:22 AM UTC (7ce3530)">/acknowledgements.html</a> ( <a href="https://whatpr.org/html/6095/440fde8...7ce3530/acknowledgements.html" title="Last updated on Oct 22, 2020, 11:22 AM UTC (7ce3530)">diff</a> ) <a href="https://whatpr.org/html/6095/webstorage.html" title="Last updated on Oct 22, 2020, 11:22 AM UTC (7ce3530)">/webstorage.html</a> ( <a href="https://whatpr.org/html/6095/440fde8...7ce3530/webstorage.html" title="Last updated on Oct 22, 2020, 11:22 AM UTC (7ce3530)">diff</a> )

+2 -1

5 comments

1 changed file

ctur

pr closed time in a day

issue closedwhatwg/html

Typo? local storage

https://html.spec.whatwg.org/multipage/webstorage.html#the-storage-interface

The key(n) method steps are:

  1. If n is greather than or equal to this's map's size, then return null.

greather or greater?

closed time in a day

ctur

push eventwhatwg/participant-data

Domenic Denicola

commit sha 47f5f1a4e70d9e9965c3ca249f56610e4557f32c

Verify and update name for Cem Turesoy See https://github.com/whatwg/html/pull/6095#issuecomment-714769177.

view details

push time in a day

pull request commentwhatwg/html

Fix typo in storage interface

Great, I'll correct it and verify you!

ctur

comment created time in a day

pull request commentwhatwg/html

Fix typo in storage interface

Hi @ctur,

Is "Cem" your full legal name you usually use for signing legal agreements? https://github.com/whatwg/participant-data/blob/master/individuals.json#L2606 shows that you used that to sign the agreement, and I want to make sure we have accurate data for you.

Thanks!

ctur

comment created time in a day

PR opened WICG/import-maps

Reviewers
Remove advisements about future Fetch-based version

I think we should set aside that idea, and close #169. It has serious problems with establishing the appropriate base URL, as discussed in previous issues. So we can remove these paragraphs from the spec and avoid distracting readers with the idea that the spec might dramatically change in the future.

This also removes the indication that we modify "fetch a module worker script graph". It's not clear how we'll integrate in the future, but it seems unlikely it would be via this exact mechanism, since that would flip "acquring import maps" to false immediately, before any modules are ever resolved.

+1 -12

0 comment

1 changed file

pr created time in a day

create barnchWICG/import-maps

branch : cleanup-fetch-stuff

created branch time in a day

issue commentmozilla/standards-positions

Import maps

Hi folks,

After a long hiatus, we are gearing up to send an Intent to Ship in Chrome sometime in the next week, or maybe two weeks. The spec has settled, with a couple of the outstanding edge cases the community discovered being fixed (https://github.com/WICG/import-maps/pull/229 and https://github.com/WICG/import-maps/pull/229). And, most importantly, @hiroshige-g did some heroic work in https://github.com/web-platform-tests/wpt/pull/26064 using service workers to get us proper web platform test coverage that doesn't depend on Chromium's internals. (More on the state of the test suite in https://github.com/WICG/import-maps/issues/170#issuecomment-714642993.)

There's surely more to do in the future, both in import maps and related areas; see https://github.com/WICG/import-maps#further-work and @guybedford's https://github.com/guybedford/import-maps-extensions. We'd love community and Mozilla input on which of those to prioritize, with the recognition that making sure the MVP lands smoothly will still take a good bit of time. But from Chrome's perspective, we're confident that the proposal at it stands is sufficiently future-compatible that we're not foreclosing anything, and we also believe that the overwhelming positivity from web developers is a sign we should deliver this value to them sooner rather than later.

With that said, we'd love to get an official position from Mozilla. I'm available for discussion over IRC, video chat, or similar if that would be helpful in working through any of the concerns raised so far.

annevk

comment created time in a day

issue commentWICG/import-maps

Writing good web platform tests

The status as of today is that I am reasonably comfortable with our web platform tests. In particular, as of https://github.com/web-platform-tests/wpt/pull/26064 and some previous PRs, the tests:

  • Key off of JSON data files that are consumed by standard testharness.js code, much like the URL Standard tests. (Notably, there's no longer a Jest conversion wrapper layer.)

  • Use service workers to test the impact of import maps on resolution, by looking at what URL is requested.

There remain some tests in https://github.com/web-platform-tests/wpt/tree/master/import-maps/common which rely on Chromium internals, namely for resolution of non-service-worker-interceptable URLs, and tests which check how the import map was parsed. However, those are more "unit tests" than WPT-style integration tests; I believe we're testing the majority of the observable consequences of the import maps spec for web developers.

I will do some work to rearrange https://github.com/web-platform-tests/wpt/tree/master/import-maps and probably move the Chromium-internal tests out of that folder, but overall we're in good shape.

domenic

comment created time in a day

PR opened WICG/import-maps

Reviewers
Prevent backtracking above /-prefix entries

Closes #207.

Also changes the error message suggestion for a nearby case to be more helpful and accurate.

+23 -3

0 comment

3 changed files

pr created time in a day

push eventWICG/import-maps

Domenic Denicola

commit sha bad17849af70f42ae454c9af7097e173bb309fc7

Prevent backtracking above /-prefix entries Closes #207. Also changes the error message suggestion for a nearby case to be more helpful and accurate.

view details

push time in a day

create barnchWICG/import-maps

branch : no-backtracking

created branch time in a day

push eventWICG/import-maps

Domenic Denicola

commit sha 8be56ee09701df844fa750dabd970d789cf10eb7

Reference implementation: test all JSON files The previous commit did not actually run the new tests.

view details

push time in a day

delete branch WICG/import-maps

delete branch : no-non-special-slashes

delete time in a day

push eventWICG/import-maps

Domenic Denicola

commit sha ad6f3bbd8a1d8bd66af5fb579635e2c207ce949a

Only apply /-prefix handling to special URL-like specifiers Closes #166.

view details

push time in a day

PR merged WICG/import-maps

Only apply /-prefix handling to special URL-like specifiers

Closes #166.

<!-- 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/WICG/import-maps/pull/227.html" title="Last updated on Oct 22, 2020, 3:37 PM UTC (1863452)">Preview</a> | <a href="https://pr-preview.s3.amazonaws.com/WICG/import-maps/227/1443033...1863452.html" title="Last updated on Oct 22, 2020, 3:37 PM UTC (1863452)">Diff</a>

+68 -9

2 comments

5 changed files

domenic

pr closed time in a day

issue closedWICG/import-maps

data: / blob: URL mapping

Brought up by @jkrems on Twitter - do we permit these mappings? And if so, does that mean that a data: URI with a trailing slash is permitted as a folder mapping?

eg:

{
  "data:application/javascript,console.log('test');//null comment//": "https://site.com/"
}

would the above map any content after the data URI above to the local URL? And conversely:

{
  "x/": "data:application/javascript,//"
}

would the above map x/\nconsole.log('hi') into its executable data URI?

closed time in a day

guybedford

push eventWICG/import-maps

Domenic Denicola

commit sha edd62eb41cf3f785012c4b674cf8be1439f6180f

Minor test harness improvements

view details

Domenic Denicola

commit sha 14430335c1aa6b09455a84f9d8ee9d6f67bcd518

Meta: move to using GitHub actions for CI Travis is too slow. Also fixes a build error introduced by https://github.com/tabatkins/bikeshed/issues/1804.

view details

Domenic Denicola

commit sha cd5c8da19f32e25f9f032b0bebc659c5476f5e50

Only apply /-prefix handling to special URL-like specifiers Closes #166.

view details

Domenic Denicola

commit sha 1863452ae4840c258f507f02f2837238dfef8524

Review feedback

view details

push time in a day

delete branch WICG/import-maps

delete branch : github-actions

delete time in a day

push eventWICG/import-maps

Domenic Denicola

commit sha 14430335c1aa6b09455a84f9d8ee9d6f67bcd518

Meta: move to using GitHub actions for CI Travis is too slow. Also fixes a build error introduced by https://github.com/tabatkins/bikeshed/issues/1804.

view details

push time in a day

PR merged WICG/import-maps

Meta: move to using GitHub actions for CI

Travis is too slow.

<!-- 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/WICG/import-maps/pull/228.html" title="Last updated on Oct 22, 2020, 3:34 PM UTC (6fc3160)">Preview</a> | <a href="https://pr-preview.s3.amazonaws.com/WICG/import-maps/228/edd62eb...6fc3160.html" title="Last updated on Oct 22, 2020, 3:34 PM UTC (6fc3160)">Diff</a>

+47 -88

0 comment

6 changed files

domenic

pr closed time in a day

push eventWICG/import-maps

Domenic Denicola

commit sha 8f5a4bf19377ec83b088b94b9d059ef11b6dec6f

Tweaks

view details

Domenic Denicola

commit sha 6fc3160ccb76a17fc770f37821a4e1f3ac948c55

Delete Travis stuff

view details

push time in a day

PR opened WICG/import-maps

Meta: move to using GitHub actions for CI

Travis is too slow.

+45 -0

0 comment

2 changed files

pr created time in a day

create barnchWICG/import-maps

branch : github-actions

created branch time in a day

push eventWICG/import-maps

Domenic Denicola

commit sha edd62eb41cf3f785012c4b674cf8be1439f6180f

Minor test harness improvements

view details

push time in a day

pull request commentWICG/import-maps

Only apply /-prefix handling to special URL-like specifiers

I just hope we don't restrict custom builtin schemes and alternative schemes though.

For example we might want to include safelisted schemes - whatwg/html#5482.

Protocol handlers only apply to navigation, not to resource fetching, so I don't think that would be the right layering.

domenic

comment created time in a day

Pull request review commentWICG/import-maps

Only apply /-prefix handling to special URL-like specifiers

       "expectedResults": {         "/test": "https://example.com/lib/test2.mjs"       }+    },+    "Non-special vs. special schemes": {

I split it out into a separate file, and included HTTP, HTTPS, and WSS.

domenic

comment created time in a day

PullRequestReviewEvent

push eventWICG/import-maps

Domenic Denicola

commit sha 20d8db52dfd1ab65ebf840f898443a11da73aef7

Review feedback

view details

push time in a day

Pull request review commentWICG/import-maps

Only apply /-prefix handling to special URL-like specifiers

 To <dfn>register an import map</dfn> given an {{HTMLScriptElement}} |element|:   1. Let |normalizedSpecifier| be the [=URL serializer|serialization=] of |asURL|, if |asURL| is non-null; otherwise, |specifier|.   1. [=map/For each=] |scopePrefix| → |scopeImports| of |importMap|'s [=import map/scopes=],     1. If |scopePrefix| is |baseURLString|, or if |scopePrefix| ends with U+002F (/) and |baseURLString| [=string/starts with=] |scopePrefix|, then:-      1. Let |scopeImportsMatch| be the result of [=resolving an imports match=] given |normalizedSpecifier| and |scopeImports|.+      1. Let |scopeImportsMatch| be the result of [=resolving an imports match=] given |normalizedSpecifier|, |asURL|, and |scopeImports|.       1. If |scopeImportsMatch| is not null, then return |scopeImportsMatch|.-  1. Let |topLevelImportsMatch| be the result of [=resolving an imports match=] given |normalizedSpecifier| and |importMap|'s [=import map/imports=].+  1. Let |topLevelImportsMatch| be the result of [=resolving an imports match=] given |normalizedSpecifier|, |asURL|, and |importMap|'s [=import map/imports=].   1. If |topLevelImportsMatch| is not null, then return |topLevelImportsMatch|.   1. <p class="note">At this point, the specifier was able to be turned in to a URL, but it wasn't remapped to anything by |importMap|.</p>     If |asURL| is not null, then return |asURL|.   1. Throw a {{TypeError}} indicating that |specifier| was a bare specifier, but was not remapped to anything by |importMap|. </div>  <div algorithm>-  To <dfn lt="resolve an imports match|resolving an imports match">resolve an imports match</dfn>, given a [=string=] |normalizedSpecifier| and a [=specifier map=] |specifierMap|:+  To <dfn lt="resolve an imports match|resolving an imports match">resolve an imports match</dfn>, given a [=string=] |normalizedSpecifier|, a [=URL=] or null |asURL|, and a [=specifier map=] |specifierMap|:    1. For each |specifierKey| → |resolutionResult| of |specifierMap|,     1. If |specifierKey| is |normalizedSpecifier|, then:       1. If |resolutionResult| is null, then throw a {{TypeError}} indicating that resolution of |specifierKey| was blocked by a null entry.         <p class="note">This will terminate the entire [=resolve a module specifier=] algorithm, without any further fallbacks.</p>       1. Assert: |resolutionResult| is a [=URL=].       1. Return |resolutionResult|.-    1. If |specifierKey| ends with U+002F (/) and |normalizedSpecifier| [=string/starts with=] |specifierKey|, then:+    1. If all of the following are true:++      * |specifierKey| ends with U+002F (/),+      * |normalizedSpecifier| [=string/starts with=] |specifierKey|, and+      * either |asURL| is null, or |asURL| [=is special=]

asURL is null if normalizedSpecifier is something like "moment".

domenic

comment created time in a day

PullRequestReviewEvent

push eventdomenic/origin-isolation-test.com

Domenic Denicola

commit sha 59f1c7637d975a3d145159161bfa5867a567f582

Renew Origin Trial token

view details

push time in a day

issue commentw3c/IntersectionObserver

HTML spec needs further changes in IntersectionObserver for proper integration

It would be ideal if HTML didn't initialize JavaScript-facing IntersectionObserver objects at all. Instead there should be algorithms like "add intersection observer steps", which takes a series of spec steps, which HTML can use. Then the IntersectionObserver constructor would call "add intersection observer steps" with the steps being to invoke the provided callback.

zcorpan

comment created time in a day

PR opened WICG/import-maps

Reviewers
Only apply /-prefix handling to special URL-like specifiers

Closes #166.

+51 -11

0 comment

5 changed files

pr created time in 2 days

create barnchWICG/import-maps

branch : no-non-special-slashes

created branch time in 2 days

issue openedtabatkins/bikeshed

Boilerplate: omit conformance conflict with Complain About: missing-example-ids yes

Previously, if I said Boilerplate: omit conformance and Complain About: missing-example-ids yes, I would be fine. Even if the boilerplate section had <div class="example"> without an ID, there would be no problem.

However, recent attempts to re-build https://github.com/WICG/import-maps/blob/master/spec.bs are failing, because now it seems the processing order has changed, and the check for missing example IDs happens before the removal of the conformance section. So my spec won't build until I remove Complain About: missing-example-ids yes.

created time in 2 days

PR opened tabatkins/bikeshed

Add an ID to the example example

This allows usage of "Complain About: missing-example-ids yes" in W3C specs

+1 -1

0 comment

1 changed file

pr created time in 2 days

create barnchtabatkins/bikeshed

branch : domenic-patch-1

created branch time in 2 days

PR opened WICG/portals

Rebase portals explainer on prerendering explainers

Follows https://github.com/jeremyroman/alternate-loading-modes/pull/5.

The only intentional normative change here is that we now respect prefetch-src and use it as a fallback for portal-src.

+145 -210

0 comment

2 changed files

pr created time in 2 days

create barnchWICG/portals

branch : rebase-on-prerendering

created branch time in 2 days

delete branch WICG/portals

delete branch : marcoscaceres-patch-1

delete time in 2 days

delete branch WICG/portals

delete branch : KenjiBaheux-patch-1

delete time in 2 days

delete branch WICG/portals

delete branch : no-ports

delete time in 2 days

delete branch WICG/portals

delete branch : load-event

delete time in 2 days

delete branch WICG/portals

delete branch : document-policy

delete time in 2 days

delete branch WICG/portals

delete branch : activate-delay

delete time in 2 days

create barnchWICG/portals

branch : activate-delay

created branch time in 2 days

pull request commentwhatwg/html

chore: export historyHandling and navigationType

A link is clicked to "https://app.com/a" (e.g., from another app), the installed app is opened, and navigation occurs.

This does seem like it would require changes to navigation. Or perhaps to link-clicking? I guess it depends on what you want to occur for cases like <iframe src="https://app.com/a">, or location.href = "https://app.com/a", or <meta http-equiv="refresh" content="0; URL=https://app.com/a">.

If you want to intercept all of those cases, then changing navigation so that it ignores the browsingContext parameter, and instead creates or reuses an app browsing context, would be necessary.

If you want to intercept only link-clicking, then you'd want to modify https://html.spec.whatwg.org/multipage/links.html#following-hyperlinks-2 , probably by modifying https://html.spec.whatwg.org/multipage/browsers.html#the-rules-for-choosing-a-browsing-context-given-a-browsing-context-name .

I'm very curious how this is implemented.

marcoscaceres

comment created time in 2 days

issue commentwhatwg/url

Provide a succinct grammar for valid URL strings

Agreed with @sideshowbarker, generally. If people want to work on personal projects that provide alternative URL parser formalisms, that's great, and I'm glad we've worked on a test suite to help. As seen from this thread, some folks might appreciate some alternatives more than they appreciate the spec, and so it could be helpful to such individuals. But the spec is good as-is.

alercah

comment created time in 2 days

issue commentw3c/webtransport

getWriter() access

Yes. This in general goes against the streams design, which tries very hard to separate the streams capability from the writer capability. I'd definitely suggest sticking to the established pattern that all existing streams-based specs use.

If you think this writable stream/writer separation is bad, then it'd be good to open an issue on whatwg/streams to discuss it more generally, so that the ecosystem aligns.

For comparison, this proposal is similar to duplicating a promise's "then" method. E.g. instead of webObject.finished.then(), duplicating then() so you could do webObject.then(). That's pretty weird, I hope you'd agree, and so is this proposal.

wilaw

comment created time in 2 days

issue commentwhatwg/html

Suggest applying accessibilities to DOM nodes

In general on the web, if you can run script on the site, then you can do anything. We don't add protections beyond that. So I think your use case is better served by using existing mechanisms to prevent watermark-removers from running script.

If the watermark-remover you're concerned about is the user (e.g. via devtools), then you're out of luck. The user is in control of what the browser displays, and our spec for the browser (i.e., for the user agent) is not going to work against them.

aleen42

comment created time in 2 days

issue commenttc39/ecma262

How should other specs indicate that they create built-in functions that support [[Construct]]?

Sorry, the question was worded confusingly. I was wondering if there is an example of a built-in constructor in other specs where the [[Construct]] behavior is not a simple wrapper around calling [[Call]]. That is, are there examples where the [[Call]] behavior is completely separate from [[Construct]] behavior?

Ah! In that case, the answer is no: all web platform classes want to use the same delegating-to-[[Call]] behavior. In "non-constructible" cases (e.g. Node), both [[Call]] and [[Construct]] will immediately throw a TypeError.

I can see now that my OP wording was confusing. It's reflecting the history of that https://github.com/heycam/webidl/issues/698 , and not super-helpful as an introduction of the problem for this issue tracker. (Briefly: all Web IDL "non-constructible classes" have always been specified as built-in functions whose function steps are to immediately throw a TypeError. https://github.com/heycam/webidl/issues/698 was debating whether attempting to construct them should throw a TypeError because they have no [[Construct]] at all, or should throw a TypeError because they have a [[Construct]] that delegates to their [[Call]]. This is not observable when doing new Node(), but it is observable when doing an IsConstructor check on Node. We came to the conclusion to prefer the delegation version.)

domenic

comment created time in 3 days

pull request commentWebAudio/web-audio-api

Prohibit arbitrary termination of AudioWorkletGlobalScopes

Hmm, very strange. It's exported in HTML (https://html.spec.whatwg.org/multipage/worklets.html#terminate-a-worklet-global-scope), so it should be in the Bikeshed database... maybe @tabatkins can help debug?

domenic

comment created time in 3 days

issue commenttc39/ecma262

How should other specs indicate that they create built-in functions that support [[Construct]]?

Then I think it's most clear to add a path to MakeConstructor (or a new AO largely the same as MakeConstructor) that invokes the function object's [[Call]] than to have prose like "Identify F as a constructor".

+1, that would be very nice and explicit!

@domenic, is there a concrete need for, or an example of, an exotic built-in constructor that I can look at?

I'm not sure what this is exactly getting at. From what I can tell of the current spec, every built-in function object is exotic:

An exotic object is an object that is not an ordinary object.

An ordinary object is an object that satisfies all of the following criteria: [...] If the object has a [[Call]] internal method, it uses the one defined in 9.2.1.

and built-in functions have the [[Call]] from 9.3.1, not 9.2.1.

domenic

comment created time in 3 days

push eventwhatwg/html

Arthur Sonzogni

commit sha dc4af655235d614fd6d10c91b329b57caff8e0c0

Editorial: improve COOP/COEP cross-linking and metadata

view details

push time in 3 days

PR merged whatwg/html

Editorial: COOP/COEP, minor improvements around cross-reference. topic: cross-origin-embedder-policy topic: cross-origin-opener-policy
  1. For every references to Cross-Origin-*-Policy, make they point to an existing definition (instead of nothing with data-x="")

  2. To maintain consistency with Cross-Origin-Embedder-Policy, do not name the definition of COOP http-cross-origin-opener-policy, but use the default "Cross-Origin-Opener-Policy". Nice side effect, this shorten every references to it.

  3. Add the missing "http-header" attribute for Cross-Origin-Opener-Policy, where it was missing.

  4. Minor improvements, like listing elements using <ul></ul>.

<!-- 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://whatpr.org/html/6087/iana.html" title="Last updated on Oct 20, 2020, 7:54 PM UTC (e2f7025)">/iana.html</a> ( <a href="https://whatpr.org/html/6087/e694724...e2f7025/iana.html" title="Last updated on Oct 20, 2020, 7:54 PM UTC (e2f7025)">diff</a> ) <a href="https://whatpr.org/html/6087/webappapis.html" title="Last updated on Oct 20, 2020, 7:54 PM UTC (e2f7025)">/webappapis.html</a> ( <a href="https://whatpr.org/html/6087/e694724...e2f7025/webappapis.html" title="Last updated on Oct 20, 2020, 7:54 PM UTC (e2f7025)">diff</a> )

+6 -5

4 comments

1 changed file

ArthurSonzogni

pr closed time in 3 days

PullRequestReviewEvent

push eventArthurSonzogni/html

Domenic Denicola

commit sha e2f7025e2f47ce3c7acdd4afea07a8621080928c

Whitespace tweaks

view details

push time in 3 days

issue openedtc39/ecma262

How should other specs indicate that they create built-in functions that support [[Construct]]?

In https://github.com/heycam/webidl/issues/698, we've come to the conclusion that all web platform classes should have a [[Construct]], even if it just throws a TypeError immediately. However, we're unsure how to express that in spec language.

Currently (in create an interface object step 4) we do

Let F be ! CreateBuiltinFunction(steps, « [[Unforgeables]] », realm, constructorProto).

However this doesn't appear to give us [[Construct]] automatically.

For the ES spec itself, it seems things are done fairly implicitly: https://tc39.es/ecma262/#sec-built-in-function-objects says

The behaviour specified for each built-in function via algorithm steps or other means is the specification of the function body behaviour for both [[Call]] and [[Construct]] invocations of the function. However, [[Construct]] invocation is not supported by all built-in functions.

then later

Built-in function objects that are not identified as constructors do not implement the [[Construct]] internal method unless otherwise specified in the description of a particular function.

which manifests in individual built-in functions via clauses like "the Number constructor" versus "the isFinite function".

For web specifications, how would you suggest specifying our counterpart? Especially given our more-imperative realm creation routine. My current guess is to add a step like

  1. Identify F as a constructor. NOTE: this means it implements the default [[Construct]] internal method for built-in functions.

although this feels a bit informal and wishy-washy. (The fact that we have to explain it with a note, instead of e.g. a hyperlink, is a sign of my discomfort.) Would that be the best approach?

created time in 3 days

issue commentheycam/webidl

Define that interface objects are constructors

Thanks @shvaikalesh! Do you know if there are web platform tests for this?

I looked into how we would update the Web IDL spec to be explicit about this, and it's still kinda unclear to me, largely because the ES spec is unclear. I will open an issue on tc39/ecma262 asking for guidance.

Ms2ger

comment created time in 3 days

issue commentwhatwg/html

Ordinal number word attribute

It's a strong signal for spec authors to consider that maybe HTML should step in and offer a standard.

Again, the ubiquity of a class is not a reason for HTML to move that out of the perfectly-working class="" attribute. If anything, it's a strong signal to keep it there, since it would be disruptive and duplicative to move it out.

A signal that something needs standardization is instead a set of use cases. Again, see https://whatwg.org/faq#adding-new-features, especially step 1 and 2.

jfbrennan

comment created time in 3 days

issue commentwhatwg/html

Ordinal number word attribute

Semantic attribute to describe an element's precedence is helpful for developers

A class seems just as helpful.

Helps blind users understand elements' precedence

Tabindex, or other technology that actually affects accessibility technology, would work better for this. Since no accessibility technology keys off of unknown attributes like this one, it isn't beneficial.

If accessibility technology vendors were suggesting that this would be helpful (more than tabindex), then we could reconsider this point. But I'm very skeptical of people claiming accessibility benefits without AT vendors lined up to implement based off of them.

A standard attribute enables CSS framework creators like Bootstrap to drop all these unique classes and standardize around an attribute.

This can be done without changing the HTML Standard to introduce a no-op attribute. They can just collaborate themselves.

Maybe browsers can optimize the paint of higher precedence elements?

This is not feasible given how browser painting architecture works.

Custom Element creators could make good use of this kind of like CSS framework creators

I don't understand this point, or how they could make use of it differently than class=""

Cool things developers will come up with that weren't anticipated!

This is not really the way standardization works. We work from use cases and benefits first, instead of going through the trouble of writing specs/tests/implementations in 3 browser engines, and only then hoping that it helps someone.

You can learn more about this in https://whatwg.org/faq#adding-new-features . In particular I'd strongly suggest you focus on steps 1 and 2.

jfbrennan

comment created time in 3 days

PullRequestReviewEvent
PullRequestReviewEvent

pull request commentwhatwg/html

chore: export historyHandling and navigationType

Hmm, yeah, this looks like it's monkey-patching navigation, if I'm reading it correctly? In particular, it seems like you want to modify the navigation algorithm to add an early step that's something like

If browsingContext is a top-level browsing context, and resource is a request whose url is a deep link, then set historyHandling to "replace"

maybe?? Although that doesn't seem right; that would make it so that every navigation within the context is done with replacement...

I'm not sure exactly what the intent is, but I think you're trying to change how navigations work, right? In particular the structure of "If the user agent is asked to navigate, then it MUST immediately navigate in a modified way" seems a bit strange.

marcoscaceres

comment created time in 3 days

issue commentwhatwg/html

Ordinal number word attribute

This seems exactly what the class attribute is designed for. It's unclear what the benefit of creating a new classification attribute would be.

jfbrennan

comment created time in 3 days

issue closedw3c/css-houdini-drafts

[worklets] Restrict worklets to same-origin

See https://github.com/whatwg/fetch/pull/527#issuecomment-335560252 by @wanderview. This would allow us to make worklets proper clients.

cc @jakearchibald @jungkees @mikewest

closed time in 4 days

annevk

issue commentw3c/css-houdini-drafts

[worklets] Restrict worklets to same-origin

Closing then; see also some IRC discussion in https://freenode.logbot.info/whatwg/20201019#c5510723

annevk

comment created time in 4 days

issue closedwhatwg/html

HTMLTableElement caption/tHead/tFoot setters exception inconsistencies

  • HTMLTableElement.caption

    Does not mention anything about throwing an exception when the new value is neither null nor HTMLTableCaptionElement, but setting to a value that is neither of these causes a TypeError to be thrown.

  • HTMLTableElement.tHead

    The setter steps say that setting to a value that is neither null nor HTMLTableSectionElement should throw a HierarchyRequestError, but browsers seem to throw a TypeError instead.

  • HTMLTableElement.tFoot

    Same as HTMLTableElement.tHead.

Tested in Firefox and Edge Chromium.

Example:

const t = document.createElement('table');
const a = document.createElement('a');

t.caption = a;
t.tHead = a;
t.tFoot = a;

closed time in 4 days

TRowbotham

issue commentwhatwg/html

HTMLTableElement caption/tHead/tFoot setters exception inconsistencies

These TypeErrors are generated by the Web IDL for these properties: as defined in https://html.spec.whatwg.org/multipage/tables.html#htmltableelement plus https://heycam.github.io/webidl/#dfn-attribute-setter step 4.6.

This is the general pattern used by all web platform API specification setters.

I'll close this, since the specification covers this, but feel free to ask any further questions about this behavior in case there's something I missed.

TRowbotham

comment created time in 4 days

Pull request review commentjeremyroman/alternate-loading-modes

First draft of prerendering browsing context

 # Prerendering browsing contexts -TODO placeholder. Grab stuff from portals.+We envision modernized prerendering to work by loading content into a **prerendering browsing context**. A prerendering browsing context can be thought of as a tab that is not yet shown to the user, and which the user has not yet affirmatively indicated an intention to visit. As such, it has additional restrictions placed on it to ensure the user's privacy and prevent disruptions. -* apply mitigations as above to subresource and scripted fetches-* deny scripted access to unpartitioned storage, such as cookies and IndexedDB-* deny permission to invoke `window.alert`, autoplay audio, and other APIs inappropriate at this time+Prerendering browsing contexts can be _activated_, which causes them to transition to being full top-level browsing contexts (i.e. tabs). From a user experience perspective, activation acts like an instantaneous navigation, since unlike normal navigation it does not require a network round-trip, creation of a `Document`, or running of the web-developer-provided initialization JavaScript. All of that has already been done in the prerendering browsing context. Activation might replace an existing top-level browsing context, for example if the user clicks a normal link whose target has been prerendered. Or it might just cause the a new top-level browsing context to exist, for example if the user clicks on a `target="_blank"` link. Activation lifts the restrictions on the prerendered content, as by that point a user-visible navigation has occurred. -JS API probably belongs here (maybe it should use page visibility API instead):+In general, activation of a prerendering browsing context is done by the user agent, when it notices a navigation that could use the prerendered contents. However, some forms of prerendering, such as [portals](https://github.com/WICG/portals/blob/master/README.md), can provide explicit entry points for navigation.++Documents rendered within a prerendering browsing context have the ability to react to activation, which they can use to upgrade themselves once free of the restrictions. For example, they could start using permission-requiring APIs, or get access to unpartitioned storage.++_Note: a browsing context is the right primitive here, as opposed to a `Window` or `Document`, as we need these restrictions to apply even across navigations. For example, if you prerender `https://a.example/` which contains `<meta http-equiv="refresh" content="0; URL=https://a.example/home">` then we need to continue applying these restrictions while loading the `/home` page._++<!-- START doctoc generated TOC please keep comment here to allow auto update -->+<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->+## Table of contents++- [Example](#example)+- [Restrictions](#restrictions)+  - [Privacy-based restrictions](#privacy-based-restrictions)+    - [Storage access blocking](#storage-access-blocking)+    - [Communications channels that are blocked](#communications-channels-that-are-blocked)+    - [Communications channels that match navigation](#communications-channels-that-match-navigation)+  - [Restrictions on the basis of being non-user-visible](#restrictions-on-the-basis-of-being-non-user-visible)+  - [Restrictions on loaded content](#restrictions-on-loaded-content)+- [JavaScript API](#javascript-api)+  - [Current proposal](#current-proposal)+  - [Adjacent APIs](#adjacent-apis)+- [Session history](#session-history)+- [Rendering-related behavior](#rendering-related-behavior)+- [CSP integration](#csp-integration)++<!-- END doctoc generated TOC please keep comment here to allow auto update -->++## Example++Consider `https://a.example/`, which contains the following HTML:++```html+<link rel="prerender2" href="https://b.example/">++<a href="https://b.example/">Click me!</a>+```++_The `"prerender2"` rel here is illustrative only. See the [triggers document](./triggers.md) for more serious discussion of potential APIs for triggering prerendering._++Upon loading `https://a.example/`, the browser notices the request to prerender `https://b.example/`. It does so by creating a prerendering browsing context, which it navigates to `https://b.example/`. This navigation takes place using [special fetch modes](./fetch.md), which ensure that `https://b.example/` has [opted in](./opt-in.md) to being prerendered, and ensures that the request for `https://b.example/` and any of its subresources is performed without any credentials that might identify the user.++Within this prerendering browsing context, assuming the opt-in check passes, loading of `https://b.example/` proceeds mostly as normal. This includes any expensive web-developer-provided JavaScript necessary to initialize the web app found there. It could even include server- or client-side redirects to other pages, perhaps even other domains.++However, if `https://b.example/` is one of those sites that requests notification permissions on first load, such a permission prompt will be denied, as if the user had declined. (TODO or should it hang, as if the user refused to respond?) Similarly, if `https://b.example/` performs an `alert()` call, the call will instantly return, without the user seeing anything. Another key difference is that `https://b.example/` will not have any storage access, including to cookies. Thus, the content it initially renders will be a logged-out view of the web app, or perhaps a specially-tailed "prerendering" view which leaves things like logged-in state indeterminate.++Now, the user clicks on the "Click me!" link. At this point the user agent notices that it has a prerendering browsing context originally created for `https://b.example/`, so it activates it, replacing the one displaying `https://a.example/`. The user observes their browser navigating to `https://b.example/`, e.g., via changes in the URL bar contents and the back/forward UI. And since `https://b.example/` was already loaded in the prerendering browsing context, this navigation occurs seamlessly and instantly, providing a great user experience.++Upon activation, `https://b.example/` gets notified via [the API](#javascript-api). At this point, it now has access to storage and cookies, so it can upgrade itself to a logged-in view if appropriate:++```js+document.loadingMode.addEventListener('change', () => {+    if (document.loadingMode.type === 'default') {+        document.getElementById('user').textContent = localStorage.getItem('current-user');+    }+});+```++This completes the journey to a fully-rendered view of `https://b.example/`, in a user-visible top-level browsing context.++## Restrictions++### Privacy-based restrictions++Prerendering is intended to comply with the [W3C Target Privacy Threat Model](https://w3cping.github.io/privacy-threat-model/). This section discusses the aspects of that threat model that are particularly relevant to the browsing context part of the story, and how the design satisfies them.++A prerendering browsing context can contain either a same-site or cross-site resource. Same-site prerendered content don't present any privacy risks, but cross-site resources risk enabling [cross-site recognition](https://w3cping.github.io/privacy-threat-model/#model-cross-site-recognition) by creating a messaging channel across otherwise-partitioned domains. For simplicity, when a cross-site channel needs to be blocked, we also block it for same-site cross-origin content. In some cases we even block it for same-origin content.++Because prerendered browsing contexts can be activated, they (eventually) live in the first-party [storage shelf](https://storage.spec.whatwg.org/#storage-shelf) of their origin. This means that the usual plan of [storage partitioning](https://github.com/privacycg/storage-partitioning) does not suffice for prerendering browsing contexts as it does for nested browsing contexts (i.e. iframes). Instead, we take the following measures to restrict cross-origin prerendered content:++- Prevent communication with the referring document, to the same extent we prevent it with a cross-site link opened in a new tab.+- Block all storage access while content is prerendered.++If we allowed communication, then the prerendered content could be given the user ID from the host site. Then, after activation gives the prerendered page access to first-party storage, it would join that user ID with information from its own first-party storage to perform cross-site tracking.++If we allowed access to unpartitioned storage, then side channels available pre-activation (e.g., server-side timing correlation) could potentially be used to join two separate user identifiers, one from the referring site and one from the prerendered site's unpartitioned storage.

I got a little lost here as it's talking about unpartitioned storage while it a few paragraphs back said partitioning storage is not sufficient.

Maybe it would be clearer as "(unpartitioned) storage" instead? The idea is to explain why you get no storage access at all.

But the two user IDs can only be joined if "referrer.test" and "prerendered.test" have access to the same storage, no?

Or if they have access to any communications channels, including side channels. So for example, if both referrer.test and prerendered.test know the time that prerendered.test loads, they can both communicate back to a collaborating server like so:

  • At time t = 1603137935244, a user with referrer.test user ID "DomenicReferrer" was on referrer.test, and loaded prerendered.test.
  • At time t = 1603137935244, a user with prerendered.test user ID "DomenicPrerendered" loaded prerendered.test.

The server then realizes that DomenicReferrer and DomenicPrerendered are the same person.

The mitigation is to cut off prerendered.test's storage access pre-activation, so that it doesn't know the user ID "DomenicPrerendered" at prerendering time. It only gets to know that user ID after a user-visible full-screen activation.

domenic

comment created time in 4 days

PullRequestReviewEvent

Pull request review commentjeremyroman/alternate-loading-modes

First draft of prerendering browsing context

 # Prerendering browsing contexts -TODO placeholder. Grab stuff from portals.+We envision modernized prerendering to work by loading content into a **prerendering browsing context**. A prerendering browsing context can be thought of as a tab that is not yet shown to the user, and which the user has not yet affirmatively indicated an intention to visit. As such, it has additional restrictions placed on it to ensure the user's privacy and prevent disruptions. -* apply mitigations as above to subresource and scripted fetches-* deny scripted access to unpartitioned storage, such as cookies and IndexedDB-* deny permission to invoke `window.alert`, autoplay audio, and other APIs inappropriate at this time+Prerendering browsing contexts can be _activated_, which causes them to transition to being full top-level browsing contexts (i.e. tabs). From a user experience perspective, activation acts like an instantaneous navigation, since unlike normal navigation it does not require a network round-trip, creation of a `Document`, or running of the web-developer-provided initialization JavaScript. All of that has already been done in the prerendering browsing context. Activation might replace an existing top-level browsing context, for example if the user clicks a normal link whose target has been prerendered. Or it might just cause the a new top-level browsing context to exist, for example if the user clicks on a `target="_blank"` link. Activation lifts the restrictions on the prerendered content, as by that point a user-visible navigation has occurred. -JS API probably belongs here (maybe it should use page visibility API instead):+In general, activation of a prerendering browsing context is done by the user agent, when it notices a navigation that could use the prerendered contents. However, some forms of prerendering, such as [portals](https://github.com/WICG/portals/blob/master/README.md), can provide explicit entry points for navigation.++Documents rendered within a prerendering browsing context have the ability to react to activation, which they can use to upgrade themselves once free of the restrictions. For example, they could start using permission-requiring APIs, or get access to unpartitioned storage.++_Note: a browsing context is the right primitive here, as opposed to a `Window` or `Document`, as we need these restrictions to apply even across navigations. For example, if you prerender `https://a.example/` which contains `<meta http-equiv="refresh" content="0; URL=https://a.example/home">` then we need to continue applying these restrictions while loading the `/home` page._++<!-- START doctoc generated TOC please keep comment here to allow auto update -->+<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->+## Table of contents++- [Example](#example)+- [Restrictions](#restrictions)+  - [Privacy-based restrictions](#privacy-based-restrictions)+    - [Storage access blocking](#storage-access-blocking)+    - [Communications channels that are blocked](#communications-channels-that-are-blocked)+    - [Communications channels that match navigation](#communications-channels-that-match-navigation)+  - [Restrictions on the basis of being non-user-visible](#restrictions-on-the-basis-of-being-non-user-visible)+  - [Restrictions on loaded content](#restrictions-on-loaded-content)+- [JavaScript API](#javascript-api)+  - [Current proposal](#current-proposal)+  - [Adjacent APIs](#adjacent-apis)+- [Session history](#session-history)+- [Rendering-related behavior](#rendering-related-behavior)+- [CSP integration](#csp-integration)++<!-- END doctoc generated TOC please keep comment here to allow auto update -->++## Example++Consider `https://a.example/`, which contains the following HTML:++```html+<link rel="prerender2" href="https://b.example/">++<a href="https://b.example/">Click me!</a>+```++_The `"prerender2"` rel here is illustrative only. See the [triggers document](./triggers.md) for more serious discussion of potential APIs for triggering prerendering._++Upon loading `https://a.example/`, the browser notices the request to prerender `https://b.example/`. It does so by creating a prerendering browsing context, which it navigates to `https://b.example/`. This navigation takes place using [special fetch modes](./fetch.md), which ensure that `https://b.example/` has [opted in](./opt-in.md) to being prerendered, and ensures that the request for `https://b.example/` and any of its subresources is performed without any credentials that might identify the user.++Within this prerendering browsing context, assuming the opt-in check passes, loading of `https://b.example/` proceeds mostly as normal. This includes any expensive web-developer-provided JavaScript necessary to initialize the web app found there. It could even include server- or client-side redirects to other pages, perhaps even other domains.++However, if `https://b.example/` is one of those sites that requests notification permissions on first load, such a permission prompt will be denied, as if the user had declined. (TODO or should it hang, as if the user refused to respond?) Similarly, if `https://b.example/` performs an `alert()` call, the call will instantly return, without the user seeing anything. Another key difference is that `https://b.example/` will not have any storage access, including to cookies. Thus, the content it initially renders will be a logged-out view of the web app, or perhaps a specially-tailed "prerendering" view which leaves things like logged-in state indeterminate.++Now, the user clicks on the "Click me!" link. At this point the user agent notices that it has a prerendering browsing context originally created for `https://b.example/`, so it activates it, replacing the one displaying `https://a.example/`. The user observes their browser navigating to `https://b.example/`, e.g., via changes in the URL bar contents and the back/forward UI. And since `https://b.example/` was already loaded in the prerendering browsing context, this navigation occurs seamlessly and instantly, providing a great user experience.++Upon activation, `https://b.example/` gets notified via [the API](#javascript-api). At this point, it now has access to storage and cookies, so it can upgrade itself to a logged-in view if appropriate:++```js+document.loadingMode.addEventListener('change', () => {+    if (document.loadingMode.type === 'default') {+        document.getElementById('user').textContent = localStorage.getItem('current-user');+    }+});+```++This completes the journey to a fully-rendered view of `https://b.example/`, in a user-visible top-level browsing context.++## Restrictions++### Privacy-based restrictions++Prerendering is intended to comply with the [W3C Target Privacy Threat Model](https://w3cping.github.io/privacy-threat-model/). This section discusses the aspects of that threat model that are particularly relevant to the browsing context part of the story, and how the design satisfies them.++A prerendering browsing context can contain either a same-site or cross-site resource. Same-site prerendered content don't present any privacy risks, but cross-site resources risk enabling [cross-site recognition](https://w3cping.github.io/privacy-threat-model/#model-cross-site-recognition) by creating a messaging channel across otherwise-partitioned domains. For simplicity, when a cross-site channel needs to be blocked, we also block it for same-site cross-origin content. In some cases we even block it for same-origin content.++Because prerendered browsing contexts can be activated, they (eventually) live in the first-party [storage shelf](https://storage.spec.whatwg.org/#storage-shelf) of their origin. This means that the usual plan of [storage partitioning](https://github.com/privacycg/storage-partitioning) does not suffice for prerendering browsing contexts as it does for nested browsing contexts (i.e. iframes). Instead, we take the following measures to restrict cross-origin prerendered content:++- Prevent communication with the referring document, to the same extent we prevent it with a cross-site link opened in a new tab.+- Block all storage access while content is prerendered.++If we allowed communication, then the prerendered content could be given the user ID from the host site. Then, after activation gives the prerendered page access to first-party storage, it would join that user ID with information from its own first-party storage to perform cross-site tracking.

Without activation, there's no user info to exfiltrate to the server, since you have no storage access.

domenic

comment created time in 4 days

PullRequestReviewEvent

Pull request review commentjeremyroman/alternate-loading-modes

First draft of prerendering browsing context

 function afterPrerendering() { if (!document.loadingMode || document.loadingMode.type === 'default') {   afterPrerendering(); } else {-  document.addEventListener('loadingmodechange', () => {+  document.loadingMode.addEventListener('change', () => {

I feel like we have three paths for this API:

  • Super-minimal; no dedicated API. Maybe add a "prerender" mode to visibilityState, since per @bokan that seems web-compatible. (And it already has a change event.) But mostly people rely on purpose-specific APIs like permissions and storage access.

  • Minimal but extensible. That's what my proposal here is trying to do: it has a LoadingMode interface, which so far only has EventTarget / onchange and the type property, but could grow if we want it to.

  • Maximal, i.e. try to figure out the whole API including parameterization before shipping.

Maybe super-minimal is best?

domenic

comment created time in 4 days

PullRequestReviewEvent
PullRequestReviewEvent

push eventwhatwg/html

Domenic Denicola

commit sha de47fa3d65b3b8f57ef53d85f3f84f00c7a3f919

Disallow import() in worklets Closes https://github.com/w3c/css-houdini-drafts/issues/506.

view details

push time in 4 days

more