-
Notifications
You must be signed in to change notification settings - Fork 32
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
Proposal for changes to fenced frames urns/attributes #48
Comments
This CL creates a struct to represent fenced frame inner properties, and carries them in the browser from the urn mapping into the FrameTreeNode. There will be a second refactor CL to eliminate the now-redundant equivalents of these properties outside of the struct. See WICG/fenced-frame#48 The second refactor is here: https://chromium-review.googlesource.com/c/chromium/src/+/3806500 Bug: 1347953 Change-Id: Ie26ba7f2c67f25c2304bd46259bd8646791d34fa Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3781046 Reviewed-by: Shivani Sharma <[email protected]> Reviewed-by: Dominic Farolino <[email protected]> Reviewed-by: Alex Moshchuk <[email protected]> Commit-Queue: Garrett Tanzer <[email protected]> Cr-Commit-Position: refs/heads/main@{#1035235}
As a follow-up to the above proposal: Previously, we conceptualized opaque identifiers as a means to map only a Given that these opaque identifiers have become and are continuing to become more expansive (describing more about the resulting fenced frame’s characteristics than just the resource URL), we don’t think it makes as much sense anymore to set them using the For some examples of how this might look in practice:
There would be a bit of complexity in migrating to this new approach for ongoing origin trials; it is likely that both urn:uuids and the new opaque identifier object would have to be supported simultaneously for some period of time. |
Closing since FencedFrameConfig is now part of the explainer. |
Previously, we talked about urn:uuids mapping to URLs. But this is a bit imprecise, because there was actually other metadata associated with those URLs, like reporting metadata for FLEDGE
reportEvent()
, budget metadata for sharedStorage, etc.This proposal makes this explicit, saying that urn:uuids map to a set of attributes, one of which is the
src
attribute. And we can add additional attributes likewidth
andheight
that allow consumer APIs to have more control over and flexibility with information flow for their particular use case. See this document for the full proposal.Here is an existing issue about how the proposal affects FLEDGE: WICG/turtledove#312
We welcome feedback. 🙂
The text was updated successfully, but these errors were encountered: