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

[Master Feature] Ability to implement "flying carpet" from within AMPHTML ads #15216

Open
lexandera opened this Issue May 11, 2018 · 15 comments

Comments

@lexandera

lexandera commented May 11, 2018

We get quite a few requests for "flying carpet effect" ads from our publisher clients. We suggested implementing the amp-fx-flying-carpet around the ad slot, but this has two major downsides:

  • It requires involvement from another team which does web site development and is separate from the client's ads team. Times quoted for the requested changes can be several months.
  • All ads served into such slots must then be close to full screen size since if a 300x250 ad is served into a flying carpet, it will only be visible for a short time when the "window" reaches the center of the page, but otherwise it will just show empty space around the ad.

Because of this we would like to be able to achieve the same effect from within the ad itself.

We see two possible approaches:

  • A pre-packaged solution which automatically creates the background layer, aligns it with the ad viewport, and keeps it in place during scrolling.
  • A DIY approach using the combination of amp-position-observer for keeping the background layer in place, and a sizing solution that would allow us to create a background layer of exactly the same height as the device viewport. Currently the sizing part is what's missing since using "height: 100vh" for the background layer matches the height of the ad's iframe viewport instead of the device viewport height, and matching the height is important in order to be able to keep the background stationary across different device sizes and also to avoid bands of empty space at the top and bottom (the second point applies to both approaches).

Here's an example of the format that we're trying to replicate in AMP (scroll the page inside the device):
http://sandbox.celtra.com/preview/89bde6a9#deviceType=Phone

@aghassemi

This comment has been minimized.

Member

aghassemi commented May 11, 2018

/to @jasti

@aghassemi

This comment has been minimized.

Member

aghassemi commented May 11, 2018

/cc @lannka

@lannka

This comment has been minimized.

Collaborator

lannka commented May 11, 2018

Thanks @lexandera for bringing this up. The current flying carpet was implemented for publisher, and we do need a solution for ad networks.

To make the problem clear: how do you plan to use one background image for all different viewport sizes?

@lannka lannka self-assigned this May 11, 2018

@lexandera

This comment has been minimized.

lexandera commented May 11, 2018

@lannka The example uses just a single image as the back layer, but in reality it can be any kind of responsive html (as can the front layer).

Typically the background would be a div set to 100%x100% with a bg image and "background-size: cover" set in css. Above that (but still in the fixed background layer) other elements are added that shouldn't be cropped together with the background image, and they're anchored to top/bottom and sized in % to take up less/more space, depending on the size of the device. As long as the size of the device viewport can be matched, this usually nicely fills the background top to bottom.

@lannka lannka added the P2: Soon label May 14, 2018

@lannka

This comment has been minimized.

Collaborator

lannka commented May 22, 2018

The screen width/height is currently available via window.context.initialIntersection.rootBounds .

To do scroll bound animation in iframe, you will need our position change API, which is right now behind a feature flag. /cc @zhouyx

@lexandera

This comment has been minimized.

lexandera commented May 25, 2018

@lannka The window.context is for JS based/legacy ads, right? Making our existing ads of this type work with AMP pages would also be great; but the main point of the original request was to bring the same kind of functionality to AMPHTML ads.

Regarding the feature flag you mentioned - what is the process for enabling it? Is it something that can be set at the amp-ad tag level if we wanted to test it?

@jasti jasti modified the milestones: New FRs, Prioritized FRs May 31, 2018

@jasti jasti added this to Sprint Candidate in AMP Advertising May 31, 2018

@lannka

This comment has been minimized.

Collaborator

lannka commented May 31, 2018

@lexandera sorry for the misunderstanding. We can try to make amp-flying-carpet work in AMPHTML ads.

The flag I mentioned for non-AMP ads is inabox-position-api. You can turn on by visiting here.

@jasti jasti changed the title from Request: Ability to implement "flying carpet" from within AMPHTML ads to [Master Feature] Ability to implement "flying carpet" from within AMPHTML ads Jul 3, 2018

@jasti

This comment has been minimized.

Collaborator

jasti commented Jul 3, 2018

This feature has been accepted to be implemented in Q3.

@lannka lannka assigned zhouyx and unassigned lannka Aug 29, 2018

@zhouyx

This comment has been minimized.

Collaborator

zhouyx commented Aug 31, 2018

Hi @lexandera Thank you for the two approaches you provide. I investigated into the implementation.

  1. the flying carpet works in AMP because we fix the background with position: fixed. This is impossible to do with an iframe because position:fixed only fixed background element to the iframe itself.
  2. I used <amp-position-observer> and <amp-animation> to created a similar flying carpet effect. Here's the example page
    https://zhouyx-flying-carpet.firebaseapp.com/manual/amp-animation/scrollbound-embeds.amp.html
    As you can find the performance is not great, and that's after all the optimization we had. It's impossible to have the animation compete with native scroll and there will be latency.

Can I ask how you achieve the flying carpet effect in non AMP page? I am curious how you handle the iframe restriction while also ensure good performance.

cc @jasti

@lexandera

This comment has been minimized.

lexandera commented Sep 3, 2018

@zhouyx The formats we built using this effect are almost exclusively used by publishers for serving on their own properties, so we have the benefit of not being sandboxed inside an iframe, which allows us to use various techniques for keeping the position since we can interact with the host page directly. I'm not sure what we use currently - this has varied in the past - but I do recall polling of scroll position from requestAnimationFrame being used at one point.

Your example doesn't load for me because of a JSBin restriction; but I have one example built in AMPHTML using a scroll bound animation that probably looks similar: http://sandbox.celtra.com/preview/4920f5b4

It looks pretty good, but the background drifts slowly because it's not possible to match the height of that image with the height of the browser viewport.

Also, I can't claim this for sure, but it seems to me like previewing this example on mobile is now more jittery than it was ~2 months ago when I built it. The drifting masks it somewhat, but it would probably be a lot more obvious if the image was still.

@zhouyx

This comment has been minimized.

Collaborator

zhouyx commented Sep 4, 2018

Thank you @lexandera

Sounds like we need to make a decision here:

  1. Attempting to use the position:fixed by asking the host window to apply the background image.
  2. Applying background image inside the iframe. But calculate it's translateY offset in real time.

@lexandera Thanks for the example. Yes it looks similar to what I have, except that in mine I eliminate the background drift by applying image height to 100vh. As you also mentioned performance wise it visually feels much worse because you are actually comparing the native scroll to the image animation without the background drift. How do you want to handle it?

I can't claim this for sure, but it seems to me like previewing this example on mobile is now more jittery than it was ~2 months ago when I built it

Could you provide with more information. We should probably investigate into this more if there's visibible performance downgrade.

Thank you.

@zhouyx

This comment has been minimized.

Collaborator

zhouyx commented Sep 5, 2018

@zhouyx

This comment has been minimized.

Collaborator

zhouyx commented Sep 6, 2018

@lexandera Please let us know if the example works for you, and if the requestAnimation approach is acceptable in terms of performance.
In the meanwhile we are exploring using the ScrollTimeline and AnimationWorklet to provider smoother scroll bound animation. #13714

@lexandera

This comment has been minimized.

lexandera commented Sep 17, 2018

@zhouyx Yes, the scroll bound animation approach works for us; but the key missing piece is being able to have a fixed background layer (made out of arbitrary HTML content, not just a single image) in standard ad sizes like 300x250 which seems to be extremely widespread on AMP pages. Changing the amp-ad sizing behavior is usually not an option since we don't control the content pages; we just produce the tools for building ads.

During the development of amp-animation, for example, we managed to get in a request for width()/height() extensions which allowed us to match transform-based animations with responsive HTML layout. I imagine we'd need something similar here, but instead of at animation time, we'd need the ability to reference the device (not iframe) viewport height to size the background layer correctly at layout time, so something equivalent to:

#backgroundLayer {
    width: 100vh; /* matches amp-ad viewport width */
    height: 100devicevh /* matches browser viewport height */
}

After that we could probably use the height(#backgroundLayer) extension in amp-animation to adjust the scroll bound animation to the rendered size of the element.

It doesn't really matter how this gets packaged (css extension, new layout mode, pre-made extension like fx-flying-carpet...) as long as we can get a smaller window that scrolls over edge-to-edge vertical content.

@zhouyx

This comment has been minimized.

Collaborator

zhouyx commented Sep 20, 2018

@lexandera We can have some workaround to get the parent doc viewportHeight within the iframe. However there is another issue that is difficult to deal with.

The background viewport height can be changing because the top header display/hide itself when the user scrolls. Without compensating the height change there, it is difficult to provide a relatively smooth visual effect.

I am going to explore some workaround. Will keep you updated. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment