Im writing an AMP email and trying to use amp-list to display a list of replies. I'm having trouble setting the height of the amp-list based on the results returned from my src endpoint (they can be in varying sizes so solution were I calculate the height by multiplying the number of items wont work).
this is my current code:
<amp-list
height="100px"
src="https://example.com/posts/amp/171?accountId=739628"
>
<template type="amp-mustache">
<div class="url-entry" role="list">
{{body}}
</div>
</template>
</amp-list>
Is it possible to dynamically set the height of the amp-list?
I tried using the heights attribute and container layout but I didnt manage to get it to work.
two options:
container layout), and display an "overflow" button or some other UI element that the user can use to gesture to expand the amp-list.In the email context, the amp-list would be able to dynamically resize itself if the bottom of amp-list is near the bottom of the email (defined as the minimum of either the bottom 15% of the email document or the bottom 1000 px). If there's no other elements under the amp-list, then this condition is automatically satisfied.
The reason amp-list behaves this way is because of AMP's design principles, which includes prevention of content jumping caused by layout shifts. If auto-resizing the amp-list would result in content below the amp-list getting pushed down, then AMP will not auto-resize it and instead will render the amp-list in its container with the initial size determined by the initial layout you specify on the amp-list. When users are trying to interact with the elements below the amp-list, they should not be annoyed by the elements being pushed further down because of the amp-list above resizing itself.
If there are elements below the amp-list that's more than the minimum of 15% of the email document and 1000px, then the amp-list will not resize itself automatically after the dynamic content loads - it will stay at its initial height. The usual ways to deal with this are:
AMP allows the amp-list to push content down upon a user gesture. This is again a design principle stating that content jumping is okay when it's a result of an explicit user action. The user should not be interacting with any elements that are jumping at the exact instance in time when the user performed the action that caused the content jumping.
The container layout for amp-list is a relatively new feature which is not well-documented. The best documentation is probably in the original feature proposal. In a nutshell, it requires the presence of the placeholder (a <div placeholder> nested under <amp-list>) to determine the initial height. If the list is completely not shown, chances are that the placeholder is missing. There should be a warning in the JS console if there's no placeholder.
If the amp-list has container layout, it means that it will be initially rendered in a container having the same size as its placeholder (the <div placeholder> element nested inside it). However, the size of the placeholder may not be enough to fit the actual dynamic content of amp-list after the fetch. The benefit of the container layout compared to fixed-height layout is that, for amp-list with a placeholder, the initial height of the amp-list can start with the height of the placeholder, as opposed to starting with the initial height of the amp-list (the value of the amp-list's height attribute) and then quickly expanding to the height of the placeholder, which would be observed by the users as a flicker or jank.
AMP will only resize the amp-list in absence of a user gesture to fit the dynamic content under a few conditions.
Optionally, the component can contain an element with the overflow attribute. AMP will display this element if all of the following conditions are met:
- The contents rendered into the amp-list exceed its specified size.
- The bottom of amp-list is within the viewport.
- The bottom of amp-list is not near the bottom of the page (defined as the minimum of either the bottom 15% of the document or the bottom 1000px) If amp-list is outside the viewport, it will be automatically expanded.
https://amp.dev/documentation/components/amp-list/?format=email#specifying-an-overflow
The documentation there talks about when the "overflow" element appears, but it's essentially documenting when the amp-list auto-expands itself during initial load of the page. The amp-list auto-expands itself during initial load if and only if the overflow element does not appear. If the conditions above to make the overflow element appear are true and the amp-list auto-resized itself, then content below the amp-list could get shifted down, resulting in content jumping.
You can specify the overflow element in cases like this. When the user clicks on the overflow element, it will expand the amp-list. The idea here is that content jumping as a result of a user gesture is okay, because the user does expect something to change in the UI after performing some actions. It's only a bad UX when the content jumps without the user gesturing it. This is also why you were able to expand the amp-list by resizing the viewport as illustrated in the video: the action of resizing the viewport is considered a user gesture.
Note that the viewport conditions mentioned above are not really meaningful in the email context. AMP emails are embedded within an iframe that has the height of the AMP document. From AMP's perspective, the amp-list is always in the viewport, because the viewport is the iframe window, not its parent window.
If there's no content beneath the amp-list, then it automatically satisfies the "being near the bottom" condition for amp-list to resize itself:
Notice however, that the typical placement of elements at the bottom of the document almost always guarantees that the AMP runtime can resize them.
https://amp.dev/documentation/components/amp-list/?format=email#displaying-a-dynamic-list
This is pretty much the only reliable way to ensure that amp-list auto-expands, since you can't predict the size of the user's viewport beforehand and thus cannot design the UI in a way that always meets the viewport conditions documented above.