Re: [w3ctag/design-reviews] Specification review for fenced frames (Issue #838)

I've filed https://github.com/WICG/shared-storage/issues/98 to note that any shared storage-specific APIs that appear in the fenced frames specification should be _instead specified in the shared storage specification as _extensions_ of the fenced frames spec, to make the dependency very clear — that fenced frames as a feature can stand alone without shared storage.

> We are actually https://github.com/w3ctag/design-principles/issues/11#issuecomment-1515585583 that would state config objects should also accept plain object literals whenever possible. Would that guidance be helpful in your design process?

I do think this guidance would be pretty useful in general, although we might be running into the "wherever possible" loophole a bit, since the value of a `FencedFrameConfig` object actually has to do with an internal token that is unique to the config and irreplicable on the web platform. The config is largely read-only, reflecting the pieces of information that a config generator API is allowed to expose to the web platform without compromising privacy, so being able to interchange this with a JS-created bag of properties might not be immediately possible for us without considering another mode of fenced frames which allows user/web-platform-created config objects (which we've indeed discussed in the past, and is on the table for future consideration).

----

Regarding the explainer feedback, I was really hopeful that https://github.com/WICG/fenced-frame/blob/master/explainer/README.md would be sufficient to review. I feel that it's not _too_ much longer than a lot of explainers, indeed links out to many other documents as you recommended, and I think we capture "the key points in a single document".

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/838#issuecomment-1629714649
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/838/1629714649@github.com>

Received on Monday, 10 July 2023 20:52:30 UTC