Ads composed of multiple pieces - rendering details

[jonasz]

Hi,

We are taking a closer look at what it will take to port our banners to FLEDGE, and I was wondering if you could clarify a number of questions relating to the rendering of "Ads composed of multiple pieces":

• Will all fenced frames in the tree know their slot size?
• Can the parent fenced frame send messages to nested fenced frames?
  • Example use case: implementing animations, like highlighting products in a round-robin fashion
• Can the parent frame resize the nested frames?
  • Use case: on mouse hover, expand the nested frame to fill the entire banner
• Can the parent frame clone the nested frames?
  • Use case: "spotlight + grid" - products are displayed in a grid, and additionally each product, in a round robin fashion, is showcased in an additional bigger slot
• Will all fenced frames in the tree receive mouse events? (Hover, click.)
  • Example use case: product animation on mouse hover

// It seems that the fenced-frame repository is more about technical details of fenced frames, and the questions above are more about "what's allowed in FLEDGE", but let me know if this issue would be better suited for the fenced-frame repository.

@shivanigithub, a friendly ping for visibility

Best regards,
Jonasz

[MattMenke2]

These might be best asked on the fenced frame explainer, which I believe is still on Shivani's person github repo: https://github.com/shivanigithub/fenced-frame

[shivanigithub]

Apologies for the delay, I missed the ping here.
It's a good question for the fenced frame repository, but answering them here for now.

Can you confirm if the tree referred in the questions is a fenced frame with multiple nested iframes or is it a fenced frame with nested fenced frames?

• Will all fenced frames in the tree know their slot size?

Yes they will. But the set of sizes allowed is limited to the popular ad sizes e.g. the ones mentioned here

• Can the parent fenced frame send messages to nested fenced frames?

This well depend on the answer to my high-level question above. A root fenced frame can communicate with its nested iframes but cannot communicate with nested fenced frames.

• Example use case: implementing animations, like highlighting products in a round-robin fashion
• Can the parent frame resize the nested frames?

If they are nested iframes they can be resized but not if they are nested fenced frames.

• Use case: on mouse hover, expand the nested frame to fill the entire banner
• Can the parent frame clone the nested frames?

Could you elaborate on what is meant by clone here?

• Use case: "spotlight + grid" - products are displayed in a grid, and additionally each product, in a round robin fashion, is showcased in an additional bigger slot
• Will all fenced frames in the tree receive mouse events? (Hover, click.)

Yes, mouse events are received by fenced frames.

• Example use case: product animation on mouse hover

// It seems that the fenced-frame repository is more about technical details of fenced frames, and the questions above are more about "what's allowed in FLEDGE", but let me know if this issue would be better suited for the fenced-frame repository.

@shivanigithub, a friendly ping for visibility

Best regards,
Jonasz

[jonasz]

Hi Shivani,

Can you confirm if the tree referred in the questions is a fenced frame with multiple nested iframes or is it a fenced frame with nested fenced frames?

My understanding of the rendering process, in case of ads composed of multiple pieces, is the following:

• generateBid returns a list of render urls. The first one is a url to the "container" (in other words, a "template"), and the remaining ones are urls for products.
• The browser will have to render each such url separately (each in a dedicated fenced frame), and then allow the rendered "container" to fill in its designated slots with rendered products.
  • To this end, the container's fenced frame would receive handlers to fenced frames representing rendered products, so that it could compose them into a grid.
  • The result will look somehow like this: https://github.com/WICG/turtledove/blob/main/assets/creative_mock.png. Here, each headphones would be a separate "product" fenced frame. The "container" fenced frame arranges products into a 1x7 grid, and is also responsible for displaying the advertiser's logo. (Of course this example is very minimalist, the products could also show prices, zoom-in animations, and more.)

So what I meant by the "tree" is the container's fenced frame that holds references to "product" fenced frames. (So - a depth-one tree.) There are no iframes involved in this example, just fenced frames.

Before I follow up on your replies to specific questions, please let me know, does my understanding of the rendering of "ads composed of multiple pieces" align with yours?

[shivanigithub]

Before I follow up on your replies to specific questions, please let me know, does my understanding of the rendering of "ads composed of multiple pieces" align with yours?

Thanks! That all makes sense.
/cc @michaelkleber

[jonasz]

Great! Let me follow up on specific questions, I'll add some numbering so it's easier to manage the discussion.

1. FF knowing its size

   Yes they will. But the set of sizes allowed is limited to the popular ad sizes e.g. the ones mentioned here

   In that case, it would seem that we should have a similar list of sizes for products, right? E.g. if I'd like to display a 4x3 product grid in a 1024x768 ad, I'd need a 256x256 slot for each product. (If I'd like to display a differently sized grid, plus maybe the advertiser's logo, a different product size would be required.)

2. Top-down communication

   A root fenced frame (...) cannot communicate with nested fenced frames.

   Would you say this is a FLEDGE design choice, or a technical limitation of fenced frames? (This question is also relevant to 3), as resizing is a form of communication.)

3. Resizing nested fenced frames

   If they are nested iframes they can be resized but not if they are nested fenced frames.

   Some mechanism for choosing the size of the product fenced frame based on the container's size and the number of products will be needed. It seems that the easiest approach would be to allow the "container" fenced frame to resize the children fenced frames.

   // This is a basic use case, a more complex one is described in 4)

   Do you think this could be supported, or do you see any conceptual / technical issues here?

4. cloning fenced frames

   Could you elaborate on what is meant by clone here?

   Sure - given a handler to a fenced frame with a product, I'd like to create a new fenced frame, with identical content. (Later on, I'd resize the newly created fenced frame, and display it in another place. So effectively, a single product is displayed twice, once in a grid, and once in a bigger "spotlight" slot. Of course this use case is also relying on 3).)

[shivanigithub]

Discussed this further with @michaelkleber and we discussed that a FF can either have a size which is one of the standard sizes baked in the browser, or it can be a list of small sizes that have been declared beforehand (possibly in the interest group) and the browser will make sure that the publisher either creates the FF with a size belonging to the second list (or first list, if second list not present) else the navigation will fail. Does the presence of the second list take care of most of the requirements for the scenario here?

1. FF knowing its size

   Yes they will. But the set of sizes allowed is limited to the popular ad sizes e.g. the ones mentioned here

Would you say this is a FLEDGE design choice, or a technical limitation of fenced frames? (This question is also relevant to 3), as resizing is a form of communication.)

Restricting the set of allowed sizes to a small number is indeed a design choice to make sure that size is not used as a communication channel between the embedding frame and the fenced frame for transferring user identifying information. Since the container ad and the nested ads are all k-anonymous independently, this communication channel needs to be restricted.

Some mechanism for choosing the size of the product fenced frame based on the container's size and the number of products will be needed. It seems that the easiest approach would be to allow the "container" fenced frame to resize the children fenced frames.
// This is a basic use case, a more complex one is described in 4)
Do you think this could be supported, or do you see any conceptual / technical issues here?

As mentioned above, allowing resizing would lead to a communication channel as well, so cannot be supported. However if the ad sizes that are allowed is a flexible list which is pre-declared, it likely supports the requirements?

Sure - given a handler to a fenced frame with a product, I'd like to create a new fenced frame, with identical content. (Later on, I'd resize the newly created fenced frame, and display it in another place. So effectively, a single product is displayed twice, once in a grid, and once in a bigger "spotlight" slot. Of course this use case is also relying on 3).)

Instead of cloning, this requirement can likely be supported by creating another fenced frame with a different size?

[jonasz]

Discussed this further with @michaelkleber and we discussed that a FF can either have a size which is one of the standard sizes baked in the browser, or it can be a list of small sizes that have been declared beforehand (possibly in the interest group) and the browser will make sure that the publisher either creates the FF with a size belonging to the second list (or first list, if second list not present) else the navigation will fail. Does the presence of the second list take care of most of the requirements for the scenario here?

A configurable list of potential sizes should work great, both for container and for product FFs.

At the time the product FFs are created, the creating party (browser? publisher?) will need to know what size to use. Perhaps this information could be part of the ad object? So the entire configuration could look like this:

joinAdInterestGroup({
    ads: [
        {
            'renderUrl': 'http://buyer.com/ads/bigGrid.html',
            'supportedSizes': [
                {'size': '600x600', 'productSize: '200x180'},
                {'size': '300x100', 'productSize: '100x100'},
                (...)
            ],
            (...)
        },
        {
            'renderUrl': 'http//buyer.com/ads/roundRobin.html',
            'supportedSizes': [
                {'size': '300x100', productSize: '200x100'},
                {'size': '200x200': productSize: '200x160'},
                (...)
            ],
            (...)
        },
        (...)
    ],
    (...)
})

In this example, if 'bigGrid.html' wins the auction, the browser will make sure it's rendered in size 600x600 or 300x100. Depending on the actual size, the fenced frames for products will either be created in 200x180, or 100x100.

Restricting the set of allowed sizes to a small number is indeed a design choice to make sure that size is not used as a communication channel between the embedding frame and the fenced frame for transferring user identifying information. Since the container ad and the nested ads are all k-anonymous independently, this communication channel needs to be restricted.

Got it, thanks!

Instead of cloning, this requirement can likely be supported by creating another fenced frame with a different size?

Yes, any way that would allow us to obtain, within the container FF, handlers to a single product rendered twice, in different sizes, would work great. What we are trying to achieve is to render something like this: https://creatives-preview.rtbhouse.com/api/render/normal/NcL3ppyci9LFfcnmmTFw (note the behavior on mouse hover).

If the specification I proposed above looks good to you, it could be extended to support this use case. ('{size': '600x600', 'productSizes: ['100x100', '300x300']} - "If the ad is 600x600, render each product twice, once in 100x100, and once in 300x300").

(From our perspective, support for rendering each product twice could be added in further iterations of FLEDGE.)

[shivanigithub]

A configurable list of potential sizes should work great, both for container and for product FFs.

At the time the product FFs are created, the creating party (browser? publisher?) will need to know what size to use.

To clarify, the publisher is going to use an ad slot size which will feed into the auction stage. That ad slot size specified by the publisher will be independent of the sizes mentioned in the interest group. The ad auction takes that size into account. Post-auction, the publisher creates a FF with the winning ad's urn:uuid and the same ad-slot size as mentioned earlier. The browser will check the winning interest group's allowed sizes and proceed with the FF creation and navigation only if that check is successful.

[jonasz]

I see, of course this makes sense for the container FF.

Could you also clarify how the FFs for the products are created?

[shivanigithub]

For nested FFs, I am thinking something like:

The publisher provides the winning urn:uuids and the container ad slot size. The nested FFs can automatically be applied the size that corresponds to the ad slot size. Taking your example earlier, if the container size is '300x100', the browser can apply the size of '200x100' to the nested fenced frames corresponding to the urn:uuids.

[shivanigithub]

A clarification on my earlier response:

The publisher provides the winning urn:uuids and the container ad slot size. The nested FFs can automatically be applied the size that corresponds to the ad slot size. Taking your example earlier, if the container size is '300x100', the browser can apply the size of '200x100' to the nested fenced frames corresponding to the urn:uuids.

The publisher provides just the winning urn:uuid and not the list of uuids, since not just the sizes but also the count of the nested ads are not leaked from the auction to the publisher. The container ad html document can itself contain the size of the nested ad in the tag and the browser can check to see if that matches with what is mentioned in the interest group.

[jonasz]

The nested FFs can automatically be applied the size that corresponds to the ad slot size. Taking your example earlier, if the container size is '300x100', the browser can apply the size of '200x100' to the nested fenced frames corresponding to the urn:uuids.

That sounds great. To make sure we are on the same page, this means the current specification of FLEDGE will have to be extended in some way, for example as outlined in #186 (comment), right?

The container ad html document can itself contain the size of the nested ad in the tag and the browser can check to see if that matches with what is mentioned in the interest group.

Specifying the expected product size in the container's HTML is attractive, as it makes the rendering specification more self contained. I think the browser teams are better equipped to answer the question where that information should belong: in the IG, in the ad HTML, or in both places, so I'll defer that decision to you :)

[shivanigithub]

The nested FFs can automatically be applied the size that corresponds to the ad slot size. Taking your example earlier, if the container size is '300x100', the browser can apply the size of '200x100' to the nested fenced frames corresponding to the urn:uuids.

That sounds great. To make sure we are on the same page, this means the current specification of FLEDGE will have to be extended in some way, for example as outlined in #186 (comment), right?

That's correct.

The container ad html document can itself contain the size of the nested ad in the tag and the browser can check to see if that matches with what is mentioned in the interest group.

Specifying the expected product size in the container's HTML is attractive, as it makes the rendering specification more self contained. I think the browser teams are better equipped to answer the question where that information should belong: in the IG, in the ad HTML, or in both places, so I'll defer that decision to you :)

Sounds good. When we have a more concrete design for this, will update here.

[shivanigithub]

/cc @gtanzer