-
Notifications
You must be signed in to change notification settings - Fork 118
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Resolve a relative URL in resources on a bundle's URL, instead of doc… #700
Conversation
…ument's base URL The discussion is: WICG#699 (comment)
What about I'm confused whether |
It seems the current explainer has a structural issue.. Let's fix that later in another PR. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then let's mention about scopes
.
Co-authored-by: Kunihiko Sakamoto <ksakamoto@chromium.org>
I've committed a suggestion. Thanks. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
The explainer PR is: WICG/webpackage#700 One of the gaps between the Subresource Loading with WebBundles and Bundle Preloading proposals is "how to resolve a relative URL of resources". The former is using document's base URL, and the latter is using the bundle's URL. We have to align. At the era of <link>-based API, using a document's base URL might make sense because `resources` are specified in the link element's attribute. Now we use <script>-based APIs, and `resources` is specified in JSON, so we no longer have any strong reason to use a document's base URL. See the spec discussion for details: WICG/webpackage#699 (comment) Bug: 1263807 Change-Id: Ic71f095589daa42db2d4649e2cf77212616b2f25
The explainer PR is: WICG/webpackage#700 One of the gaps between the Subresource Loading with WebBundles and Bundle Preloading proposals is "how to resolve a relative URL of resources". The former is using document's base URL, and the latter is using the bundle's URL. We have to align. At the era of <link>-based API, using a document's base URL might make sense because `resources` are specified in the link element's attribute. Now we use <script>-based APIs, and `resources` is specified in JSON, so we no longer have any strong reason to use a document's base URL. See the spec discussion for details: WICG/webpackage#699 (comment) Bug: 1263807 Change-Id: Ic71f095589daa42db2d4649e2cf77212616b2f25
The explainer PR is: WICG/webpackage#700 One of the gaps between the Subresource Loading with WebBundles and Bundle Preloading proposals is "how to resolve a relative URL of resources". The former is using document's base URL, and the latter is using the bundle's URL. We have to align. At the era of <link>-based API, using a document's base URL might make sense because `resources` are specified in the link element's attribute. Now we use <script>-based APIs, and `resources` is specified in JSON, so we no longer have any strong reason to use a document's base URL. See the spec discussion for details: WICG/webpackage#699 (comment) Bug: 1263807 Change-Id: Ic71f095589daa42db2d4649e2cf77212616b2f25
The explainer PR is: WICG/webpackage#700 One of the gaps between the Subresource Loading with WebBundles and Bundle Preloading proposals is "how to resolve a relative URL of resources". The former is using document's base URL, and the latter is using the bundle's URL. We have to align. At the era of <link>-based API, using a document's base URL might make sense because `resources` are specified in the link element's attribute. Now we use <script>-based APIs, and `resources` is specified in JSON, so we no longer have any strong reason to use a document's base URL. See the spec discussion for details: WICG/webpackage#699 (comment) Bug: 1263807 Change-Id: Ic71f095589daa42db2d4649e2cf77212616b2f25 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3244822 Reviewed-by: Kunihiko Sakamoto <ksakamoto@chromium.org> Commit-Queue: Hayato Ito <hayato@chromium.org> Cr-Commit-Position: refs/heads/main@{#935333}
The explainer PR is: WICG/webpackage#700 One of the gaps between the Subresource Loading with WebBundles and Bundle Preloading proposals is "how to resolve a relative URL of resources". The former is using document's base URL, and the latter is using the bundle's URL. We have to align. At the era of <link>-based API, using a document's base URL might make sense because `resources` are specified in the link element's attribute. Now we use <script>-based APIs, and `resources` is specified in JSON, so we no longer have any strong reason to use a document's base URL. See the spec discussion for details: WICG/webpackage#699 (comment) Bug: 1263807 Change-Id: Ic71f095589daa42db2d4649e2cf77212616b2f25 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3244822 Reviewed-by: Kunihiko Sakamoto <ksakamoto@chromium.org> Commit-Queue: Hayato Ito <hayato@chromium.org> Cr-Commit-Position: refs/heads/main@{#935333}
The explainer PR is: WICG/webpackage#700 One of the gaps between the Subresource Loading with WebBundles and Bundle Preloading proposals is "how to resolve a relative URL of resources". The former is using document's base URL, and the latter is using the bundle's URL. We have to align. At the era of <link>-based API, using a document's base URL might make sense because `resources` are specified in the link element's attribute. Now we use <script>-based APIs, and `resources` is specified in JSON, so we no longer have any strong reason to use a document's base URL. See the spec discussion for details: WICG/webpackage#699 (comment) Bug: 1263807 Change-Id: Ic71f095589daa42db2d4649e2cf77212616b2f25 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3244822 Reviewed-by: Kunihiko Sakamoto <ksakamoto@chromium.org> Commit-Queue: Hayato Ito <hayato@chromium.org> Cr-Commit-Position: refs/heads/main@{#935333}
…ive URL on the bundle's URL, a=testonly Automatic update from web-platform-tests <script type=webbundle>: Resolve a relative URL on the bundle's URL The explainer PR is: WICG/webpackage#700 One of the gaps between the Subresource Loading with WebBundles and Bundle Preloading proposals is "how to resolve a relative URL of resources". The former is using document's base URL, and the latter is using the bundle's URL. We have to align. At the era of <link>-based API, using a document's base URL might make sense because `resources` are specified in the link element's attribute. Now we use <script>-based APIs, and `resources` is specified in JSON, so we no longer have any strong reason to use a document's base URL. See the spec discussion for details: WICG/webpackage#699 (comment) Bug: 1263807 Change-Id: Ic71f095589daa42db2d4649e2cf77212616b2f25 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3244822 Reviewed-by: Kunihiko Sakamoto <ksakamoto@chromium.org> Commit-Queue: Hayato Ito <hayato@chromium.org> Cr-Commit-Position: refs/heads/main@{#935333} -- wpt-commits: 6bbec86c72b31033d100beb6c571c37f1cdc5446 wpt-pr: 31395
…ive URL on the bundle's URL, a=testonly Automatic update from web-platform-tests <script type=webbundle>: Resolve a relative URL on the bundle's URL The explainer PR is: WICG/webpackage#700 One of the gaps between the Subresource Loading with WebBundles and Bundle Preloading proposals is "how to resolve a relative URL of resources". The former is using document's base URL, and the latter is using the bundle's URL. We have to align. At the era of <link>-based API, using a document's base URL might make sense because `resources` are specified in the link element's attribute. Now we use <script>-based APIs, and `resources` is specified in JSON, so we no longer have any strong reason to use a document's base URL. See the spec discussion for details: WICG/webpackage#699 (comment) Bug: 1263807 Change-Id: Ic71f095589daa42db2d4649e2cf77212616b2f25 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3244822 Reviewed-by: Kunihiko Sakamoto <ksakamoto@chromium.org> Commit-Queue: Hayato Ito <hayato@chromium.org> Cr-Commit-Position: refs/heads/main@{#935333} -- wpt-commits: 6bbec86c72b31033d100beb6c571c37f1cdc5446 wpt-pr: 31395
The explainer PR is: WICG/webpackage#700 One of the gaps between the Subresource Loading with WebBundles and Bundle Preloading proposals is "how to resolve a relative URL of resources". The former is using document's base URL, and the latter is using the bundle's URL. We have to align. At the era of <link>-based API, using a document's base URL might make sense because `resources` are specified in the link element's attribute. Now we use <script>-based APIs, and `resources` is specified in JSON, so we no longer have any strong reason to use a document's base URL. See the spec discussion for details: WICG/webpackage#699 (comment) Bug: 1263807 Change-Id: Ic71f095589daa42db2d4649e2cf77212616b2f25 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3244822 Reviewed-by: Kunihiko Sakamoto <ksakamoto@chromium.org> Commit-Queue: Hayato Ito <hayato@chromium.org> Cr-Commit-Position: refs/heads/main@{#935333}
The explainer PR is: WICG/webpackage#700 One of the gaps between the Subresource Loading with WebBundles and Bundle Preloading proposals is "how to resolve a relative URL of resources". The former is using document's base URL, and the latter is using the bundle's URL. We have to align. At the era of <link>-based API, using a document's base URL might make sense because `resources` are specified in the link element's attribute. Now we use <script>-based APIs, and `resources` is specified in JSON, so we no longer have any strong reason to use a document's base URL. See the spec discussion for details: WICG/webpackage#699 (comment) Bug: 1263807 Change-Id: Ic71f095589daa42db2d4649e2cf77212616b2f25 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3244822 Reviewed-by: Kunihiko Sakamoto <ksakamoto@chromium.org> Commit-Queue: Hayato Ito <hayato@chromium.org> Cr-Commit-Position: refs/heads/main@{#935333} NOKEYCHECK=True GitOrigin-RevId: f06d042b5412ac6654e62c62a602468fa3646ecc
…ument's base URL
The discussion is:
#699 (comment)