I think this is not currently possible, but would be worth double-checking
/cc @choumx — WDYT about this as a feature for amp-list + amp-bind?
EDIT: attempting to summarize the discussion below into specifications for this feature request.
Dynamic resizing needs to cover the following cases:
<amp-accordion>
.<amp-bind>
. amp-bind
to change the src
attribute of <amp-list>
can cause us to fetch contents that will have a different height from <amp-list>
's current height. <amp-list>
to contain elements that will be loaded later. E.g. collapsible ads. <amp-list>
should intelligently adjust its height based on the actual height of its contents. <amp-list>
might contain fewer elements and would hence need to resize. Caveats to note:
<amp-list>
in <amp-sidebar>
use case. <amp-list>
. Tentative proposed solution(s):
<amp-list>
to behave like layout CONTAINER
after first load. resizeOnChange
. are width
, height
, layout
not bindable? seems useful regardless of use-case with amp-list
.
I believe width and height are bindable — not sure about layout, though: do you have a use case in mind for that?
This would be super useful to have. We're building a product listing page (an ampStart template) and would like to update the products based on an input select change. Unfortunately, the height of the amp-list element doesn't get updated.
Simple example here
https://gurmukh-test.firebaseapp.com/templates/e-commerce/product-listing.amp
@ericlindley-g could this be prioritised?
@aghassemi one wrinkle for this request is that amp-list would have to resize based on the data pulled in, so in some cases this wouldn't be known by the client until the data is rendered by the template
@choumx — @gurmukhp is working on AMP Start templates, and the ability for amp-list to resize when src is updated by amp-bind would be useful there (product listing page with filtering capabilities which vary the number of products displayed via amp-list, using amp-bind). Is this something you've thought about before, or would be easy to fold into the other amp-list work you're looking at? @gurmukhp and team are working on templates that we're hoping to launch soon, and it would be ideal not to have to design around this issue at launch.
Just verified that width
and height
bindings work in amp-list on a local example. layout
currently isn't bindable.
@gurmukhp The amp-list element in that page doesn't appear to have a width/height binding.
@choumx — does this allow amp-list to resize based on the content pulled in via JSON, as opposed to a specific height pre-determined on the client?
For instance: I give users the ability to filter by price and color of a product, but I'm not able to hard-code on the frontend the exact height for each price/color combination. What I would need would be for amp-list to dynamically resize based on the height of the items it pulls in through JSON (which would also accommodate for elements (like text) that change height based on viewport width. Is that currently supported?
Yes, by using amp-state
as an intermediary store. Just tested something like this locally:
<amp-state id="myData" [src]="'http://data.com/json?filter=' + myFilterVar">
<script type="application/json">
{
"items": [] // Insert default data here.
}
</script>
</amp-state>
<button on="tap:AMP.setState({myFilterVar: 'red'})">Set filter to 'red'</button>
<!-- "30" is the height per item. -->
<amp-list [state]="myData.items" [height]="myData.items.length * 30"></amp-list>
Probably not immediately obvious for people new to amp-bind. Good candidate for ABE. 😄
Nice! I'm guessing this doesn't work for variable-height items like text (which could wrap and cause new lines depending on viewport width)—is that right? Either way, this is super-useful
If this doesn't work for variable-height items: would it be possible for amp-list to understand the height of its children and resize based on that when amp-bind changes its src?
Correct, we'd have to allow amp-bind to change layout
to "container"
. It'd be a simpler solution than the one above. Seems like a reasonable FR.
Awesome — changing the title of the bug to reflect the request.
This feature would be really useful in the e-commerce template for AmpStart. We have a list of products that are loaded in dynamically. The height of amp-list is dependant on the width of the device so binding using the [height] attribute isn't possible.
Thanks for the feedback.
On second thought, adding a new element-specific action called "resize" might be better than allowing binding to layout property. For one, amp-bind doesn't do anything when the property value doesn't change, e.g. [layout]
changing from "container" to "container" even if [src]
changes.
<amp-list [src]="myUrlVariable" id="foo" on="change:foo.resize"></amp-list>
An even simpler way is to allow automatic resizing when [state]
or [src]
bindings change, perhaps toggled via a new boolean attribute:
<amp-list resizeOnChange [src]="myUrlVariable"></amp-list>
Good conversation thread with @aghassemi and @dvoytenko in duped issue: https://github.com/ampproject/amphtml/issues/11535#issuecomment-333971409
Any updates here?
This is a blocker for launching a top site. SImilar to https://github.com/ampproject/amphtml/issues/10230#issuecomment-318026363 they're an ecommerce company and the sidebar is showing categories. Categories show subcategories on click. And when those are shown the sidebar is stuck on overflow: none;
Like https://github.com/ampproject/amphtml/issues/11535 that was dupped 3 weeks ago the logical quick solution is to add overflow: auto, but that's not allowed.
@choumx , for the on-load case, where the user hasn't interacted with the page, what do you think about just queuing the resize and executing it when it can be done with good UX? (i.e. If the user isn't scrolling: if the bottom of amp-list is in the viewport, wait until it isn't anymore, then resize and correct scroll if the viewport is below amp-list. If the bottom of amp-list is not in the viewport, then just resize at will. )
That should work and is probably how resize requests ought to work in the first place.
OOC, is that a valuable use case? I.e. users scrolling past an amp-list and then scrolling back up to it.
Excellent—excited to have a solution for the on-load case! (Though I should double-check: could this conditional resize work with container layout (or a similar notion), so amp-list effectively has container layout, as long as it ensures the good resizing UX described above?)
To answer your question, I'm not aware of cases where users are scrolling past amp-list and then scrolling back up to it—I mention that more as an edge case that I think we'd have to handle if we wanted amp-list to resize automatically (Say, if the user had already visited the page and wanted to scroll quickly down to content they had seen already.)
I think the most likely scenario (the primary use case) is that the resize happens while the user is consuming content above.
FWIW: As a naive though unfamiliar with the implementation path either for this or for the resize on user action we've been talking about: I wonder if the resize that we want to allow on user interaction through bind could just be a rule added to the above ruleset, so the resize logic is all in one place.
The resize logic is part of the runtime and used by other extensions too: amp-ad
, amp-facebook-like
, amp-imgur
, etc. The logic is quite complex -- I'll have to take a closer look.
Would you mind filing another issue for this? Something like "More flexible height-change requests."
Since a relatively simple issue (#11535) was dup'ed into this more involved one, is there a way to handle the overflow use case without all the complexity?
Specifically, AMP sets overflow: hidden !important
on the list. While this prevents resizing, so would overflow: scroll. Could there be an option to opt in to overflow scroll in rather than overflow hidden?
@ericlindley-g might be able to give more context, but I believe scrollbars are not allowed since generally they're pretty bad UX:
No user defined element in an AMP document may have a scrollbar.
https://github.com/ampproject/amphtml/blob/master/spec/amp-html-format.md#properties
Have you tried using an overflow button for your use case?
Thanks for thinking through this with us, @jamesshannon—+1 to @choumx's note on the scrollbar being a bad UX practice (it can end up being disorienting, where users get "trapped" inside a scrollable container and aren't able to scroll the main document), and recommending the overflow button in the short term.
Hopefully the fix we're discussing should address the root cause of the problem, so for most cases we won't need some of the partial fixes like the overflow button
I wasn't aware of the no-scrollbar spec. Makes sense (for 95% of use cases, I guess).
See this video for my partner's use case. As you can see the nav's size is fixed and the overflow:hidden prevents it from being usable until I remove that. Seems really similar to @WalliSmith's original issue.
Scrollbar isn't necessary. In fact my "fix" got it working without one due to the browser's scrollbar UX. (Though I do think that a scroll bar is a good signal that the content is individually scrollable.)
The size of the amp-list is fixed (which is fine) but the overflow: hidden prevents the other content (which has gotten larger) from being usable. It seems like you guys are onto a solution for resizing the entire amp-list, but in the meantime it'd be nice to find a more straightforward way to get this working.
Thanks for the sample page. I think a reasonable resize policy should also work for this case since the amp-list is very close to the "bottom" of the sidebar (which uses the fixed layer). Resize logic for fixed layer elements might be lacking. I'll add this note to the FR Eric just created.
Any updates on the FR? The resize logic for fixed elements, specifically amp-list seems to be a recurring issue for several partners.
@aghassemi Were you planning to have your team take this on?
@rangarajanr Thanks for bringing it up. This is in our radar to tackle over the next couple of months.
/cc @ericlindley-g
Any updates on this ? i really need a solutions
@choumx
I create a amp-list based on json response with "show more" featured using amp-form, amp-bind.. like this: https://ampbyexample.com/advanced/show_more_button/
I can calculate the height of a fixed amount of elements (example 24 items * 300px), but when the json response was 4 items the amp-list height is too much
Im using amp-bind to recalculate the height when click on "show more" button but i need to recalculate on amp-list first load.
thanks
if you use amp-state
and load the endpoint values into a variable, then you can bind the height
of amp-list
to the length of the array. In hotel sample we do something similar, could you check if that would work in your case?
@kul3r4 I'm currently doing it like that, but my problem is when amp-list load the first elements on page load not by user interaction
are you using amp-state
? I just tried to minimize the list height to 200 and I can see that it resize to a taller list because the height is in a binding without clicking on a button.
This is my example: https://www.cibercuba.com/tags/tiroteo-broward if i set the height of the amp-list to 800px for example the list does not resize until user clicks
im usin amp-state doing this [height]="(nodesState.items.length / 2) * 400"
<amp-state id="nodesState" src="/json/46637/nodes.json?amptheme&nocache=1" class="i-amphtml-element i-amphtml-layout-container" aria-hidden="true" style="display: none;"></amp-state>
you are right, sorry about the confusion!
@choumx
We made homepage with AMP for one of the e-commerce channel www.tatacliq.com for responsive and it's live since one month.
We are planning to go for AMP to change the Listing and Detail pages of products.
I agree that we could use amp-state with height multiplication but, this won't work in cases like showing multiline texts.
So, the dynamic height for amp-list would really help over these conditions.
@vamshi5889 Thanks for the input. We're actively discussing how to implement this right now, stay tuned!
Thanks a ton @choumx
Any updates on allowing container
as a layout type for amp-list
?
@malls Most likely won't happen generally (on page load). We do plan on treating amp-list as a container for changes after page load e.g. on user gesture.
Thanks for the prompt response. I'm trying to build a horizontally scrolling widget with dynamic data. Is this possible with amp-list
given the .i-amphtml-layout-size-defined
class? Or is it possible to use amp-carousel
with dynamic data?
@malls You could achieve that by clubbing both of them. Use amp-carousel inside amp-list.
<amp-list src="api_call">
<template type="amp-mustache">
<amp-carousel>
{{#response.carouselItems}}
<!-- Bind Your Widget Info Here -->
{{/response.carouselItems}}
</amp-carousel>
</template>
</amp-list>
@choumx , @ericlindley-g and @aghassemi
Is there any update on allowing dynamic heights for amp-list? We are eagerly waiting for this FR.
I would recommend, introducing a new layout option for amp-list
Thanks,
Kvg
@vamshi5889 — this feature is on the stack of things we're working to fix before the end of June, but we don't have a solid release date yet
@ericlindley-g -- Thanks Eric.
Actually fixed-height layout is working for me and height is set dynamically on page load. But if i expand any accordion, height is not getting increased. And user cannot see the bottom content (not-scrollable). Refer the below two states of a page i'm working on.
In the below page, I gave height="600" with fixed-height and it dynamically/automatically changed to 1615px (dynamic height) on page load.
Page on load.
Page after expanding Accordion. Height not getting increased (still 1615px)
Hope you understood the problem i'm facing. Let me know for more inputs
@choumx @aghassemi
Thanks,
Vamshi
Thanks for the detailed use-case @vamshi5889 — fortunately, that amp-accordion issue is one of the things that will be fixed with the amp-list resizing update that we're working on. We'll update this bug when it's fixed so you can verify, and we can make sure this use case is addressed
Thanks @ericlindley-g 😄
@vamshi5889 I did similar stuff as yours. app-accordion with an arrow up/down. How you change the direction of the arrow when the content is opened or closed?
@fr-cdc-nicholas By using the CSS rotate property, you can change the direction of the arrow when the section is expanded.
Like below,
.pd-sizes > amp-accordion > section[expanded] .pd-features-arrow {transform: rotate(180deg);}
@vamshi5889 I need to make a dynamic string based on same amp-states. How can I do that? I have tried following :
src="https://google.com/search?language=en&locales[]=en&query=" +(form.query)
src="https://google.com/search?language=en&locales[]=en&query=" +{{form.query}}
src="https://google.com/search?language=en&locales[]=en&query=form.query"
but none of these work. How can I achieve this?
@rajatgupta1993 Please see below,
First way (if binding mustache variable),
src="https://google.com/search?language=en&locales[]=en&query={{form.query}}"
Second way - Dynamic Binding (If you want to read the text entered and append to the request)
[src]="'https://google.com/search?language=en&locales[]=en&query=' + searchTerm"
See https://ampbyexample.com/advanced/combobox/ for reference
Let me know if this doesn't help you
I know it has been said that a fix is coming for this around the end of June (pending other work), but just wanted to 'throw my hat in the ring' to say this issue is also currently affecting my site. See my post on Stack Overflow for details.
@craigscott29 I'm eagerly waiting for this dynamic height resolution for amp-list. Hope we get this resolved very soon.
Good Day Guys!!!
Part of dynamic height issue resolved for me by setting css position of amp-list like below,
#product-container amp-list[height] {height: 100%; position: inherit;}
Now with this, i'm able to scroll to the bottom in the second picture above (after expanding accordion).
I have same issue - when I apply filters which returns less than than 30 items (first page load returns 30 items) empty white space is visible below product list. Waiting for dynamic resizing :)
I've attempted to edit this issue description to summarize all the use cases I'm seeing noted in this thread as well as internal documentation. @ericlindley-g can you let me know if I'm missing anything here?
Dynamic resizing needs to cover the following cases:
<amp-accordion>
.<amp-bind>
. amp-bind
to change the src
attribute of <amp-list>
can cause us to fetch contents that will have a different height from <amp-list>
's current height. <amp-list>
to contain elements that will be loaded later. E.g. collapsible ads. <amp-list>
should intelligently adjust its height based on the actual height of its contents. <amp-list>
might contain fewer elements and would hence need to resize. Caveats to note:
<amp-list>
in <amp-sidebar>
use case. Tentative proposed solution(s):
<amp-list>
to behave like layout CONTAINER
after first load. resizeOnChange
. If anyone subscribing to this thread has any examples of case 3 above, I'd greatly appreciate it if you could share it for testing / verification purposes. =)
@cathyxz This is really good as you covered most of the use cases around it.
We have to cover one more resizing scenario where the view/display gets changed through classes.
Below two images are part of my AMP page. I had a requirement to toggle the view of products (grid - list) and in this case i'm not changing the [state] or [src]. I am toggling the classes on tapping the grid/list icon (can see those in below images).
When i switch (basically i'm changing the CSS class of each tile on toggle to make it list view), there is a leftover space at the bottom.
Hope you've this case as well!!!
I use local query for dynamically amp-list and set with this expression [height]="filteredProduct.length * 300"
It works at mobile screen size. Every row one product.(as in the hotel example) All my product boxes fixed width=200 height=300
But I want to use this set up for both mobile and desktop screens,
so I need to calculate how many product per row. I need screenWidth variable then I can write my expression
[height]="300 * (filteredProduct.length / (windowWIDTH / 200))"
(windowWIDTH / 200) = how many product per row. My all product width=200
is it meanigfull.
thanks...
@dulgar , As I said above, you can resolve the dynamic height issues across web and mobile layouts with below CSS,
#product-container amp-list[height] {height: 100%; position: inherit;}
Are there any updates on when this will be resolved? We were hoping for a fix in June as stated by @ericlindley-g back in April. We're getting into August now.
The lack of dynamic resizing is preventing us from being able to give our AMP visitors a similar experience to regular web visitors on our article pages.
I'am also waiting for an update. Dynamic resizing is highly required for my project.
@jarek-gilewski @mpaw There is a PR open for this and we are currently testing it.
@cathyxz see https://github.com/ampproject/amphtml/issues/10230#issuecomment-395330906 for a demo Url from @jarek-gilewski to test with.
@mpaw do you also have a Url we can test with to make sure the fix addresses your particular use-case?
I created an amp-list with a specific height. But actually, the result JSON data was bigger than that. The amp-list could be expanded to an expected length. It's working well and I see no problem.
BUT, when I directed to somewhere and then clicked "go back" button in the browser. The results were still there but the amp-list was not expanded anymore. It stayed with the specified height.
Have you guys encountered with this scenario? Maybe @vamshi5889 @cathyxz can give me some help?
Hi @fr-cdc-nicholas
I believe i have encountered this problem long back. But i'm not seeing this issue now in my pages.
Try adding below css,
#product-container amp-list[height] {height: 100%; position: inherit;}
Let me know if this doesn't work.
Or ping me in hangouts to below email, so we can resolve it later part of the day together
[email protected]
@vamshi5889 Appreciate for the help. Unfortunately, it's not working as I expected. I plan to use an SSR way (Mustache + JSON) to avoid using amp-list since it has a lot of limitations for now.
@fr-cdc-nicholas I've tested more cases on you're scenario like expanding an accordion inside amp-list
, go back and land again (using browser back buttons). It worked fine.
There are many advantages of using amp-list
than its disadvantages. I don't think SSR is a better approach as amp-mustache
is fine enough for us.
Add screenshots if possible related to the issue so we'll get to know on what's happening.
@vamshi5889 thx for the reply. We had different situations. My page is kind of waterfall structure, the header and footer will be overlapped with those lines of CSS.
@fr-cdc-nicholas is there any way I can get in touch to investigate your issue? I'm looking for test cases for a tentative fix. I'm cathyxz on slack / [email protected] via email. =)
@cathyxz Sure, let me describe this via an example, I retrieve JSON data by amp-list and render as cards (card uses responsive layout with width/height 1:1 and width 50%, two cards in a row).
Btw, I use Mustache template engine to inject data then generate amp pages to make them pure static, and problem solved. But I think it should be a way to solve this issue.
@fr-cdc-nicholas
I have implemented the exact page you have described above. But i don't have this issue.
I want to see your code to fix it. Fork it somewhere or ping me in hangouts. I don't think it'll take much time fix it.
@vamshi5889 I tried several times, only reproduced the bug once, let me finish the work first and give more info later.
Adding a auto-resize
attribute to <amp-list>
per #16564. TODO:
auto-resize
when it reaches production. This is a high priority issue but it hasn't been updated in awhile. @cathyxz Do you have any updates?
@sebastianbenz indicated on Stackoverflow that a solution might be available soon.
You can track the release issue https://github.com/ampproject/amphtml/issues/18159 for when #16564 lands in production.
is there documentation on the arguments for amp-list
? For example: height="auto-resize"
Our documentation tends to land earlier than our code (generally resulting in a lot of confusion), so I was waiting for the code to land first, but the usage is just <amp-list ... auto-resize>
.
When it goes on production (auto-resize for AMP-list component)?
You can follow #18159 for when it lands in production (it's targeted for next Tuesday).
Was this released? I got a bit lost after #18159 was delayed and closed
@leonalicious @lsarni @jarek-gilewski @jaygray0919 and other folks thins this thread.
We like to temporarily put auto-resize
behind an experiment flag which will disable the behaviour back to the status quoe from 2 weeks ago. This will allow us to iterate and fix a few bugs before its usage goes beyond out deprecation threshold. Please see https://github.com/ampproject/amphtml/issues/18849 for details.
This change is expected on next Canary.
I'm a bit confused - can I use "resizable-children" without a risk of getting AMP validator Search Console warnings/errors today or next month?
I try to use resizable-children in my project,but it's no use and the AMP validator warnings. i want to know when we can use the attribute,my project is really need the attribute soon.
@Feas1 With this change, we are simply back to few weeks ago when this feature did not exist. resizable-children
is under experimental flag until we have resolved all the edge case bugs for this feature. As per the roll-back, it is tricky fix and we want to be sure it's solid before relaunching again.
At now, I cannot still unable to use resizable-children
@hoavo This feature is under an experimental flag until we are fully ready to launch it again.
Any suggestions on how to work around the amp-list height issue when the number of items changes (filter/search/paginating), switching views (grid/list) or viewport resize?
I'm pulling our wines and grapes posts from a custom endpoint using the WordPress rest api (https://winefolly.staging.wpengine.com/wp-json/api/v1/wines), formatted as a nested "items" array, as recommended in the amp docs, then using amp-bind to adjust the src url.
I tried the auto-resize attribute, but I see it's now moved to experimental. I also tried using the flex-item layout, with a wrapping div outside of my mustache loop (but still inside the mustache template wrapper), but the wrapping div gets outputted on each individual item. I'm not sure if this is due to something in the WP AMP plugin or if I'm just missing something obvious.
The dev version of our wines and grapes index can be found here -> https://winefolly.staging.wpengine.com/grapes-wines/
Here is a pastie of the markup I'm adding to output the amp-list (in WordPress):
https://www.pastiebin.com/5bf28d91dc8fa
We're working on a changeToLayoutContainer
action and a is-layout-container
attribute per #19184. It'll be experimentally gated under amp-list-resizable-children
. Basically this will allow you to trigger a change to layout container on user interaction.
Thanks for the reply @cathyxz :)
I read through #19184 and it sounds like this would address the height issues we're having.
I went ahead and added the AMP Experiment meta tag for _amp-list-resizable-children_, then added the is-layout-container attribute to my amp-list and finally the _changeToLayoutContainer()_ action to my search input.
Checking the site after the update I don't see any change to the amp-list height when the number of items returned changes. Is there something else I should be doing in order to get this working?
Here is an example of my search input:
https://gist.github.com/devignerforhire/0330af8ee3339959035a854ca1fc4117
Or you can see the full version on our staging site:
https://winefolly.staging.wpengine.com/grapes-wines/
The PR is not yet merged. It will probably make the next canary cut and land in production in approximately two weeks.
Ok cool :) I'm looking forward to testing it out once it's released. In the meantime I removed the grid/list toggle and set the api call to show all posts, that way we don't need the pagination and can push the update. Thanks again for your input and your contributions to AMP :)
changeToLayoutContainer
is now launched experimentally in canary. To use it, go to https://cdn.ampproject.org/experiments.html and turn on both Dev Channel and amp-list-resizable-children
. Here's a sample glitch app that you can remix / edit: https://amp-list-demo.glitch.me/amp-list-resize.html. The same sample is also in this repository under test/manual/amp-list-resize.amp.html
.
Awesome! I'll take it for a spin once I'm done pushing todays update and report back with my findings.
@cathyxz I just downloaded canary and enabled both the dev channel and amp-list-resizable-children, then tested out the demo page you put together, but the list isn't resizing and I'm getting the following main errors in the chrome console:
v0.js? [sm]:130 Experiment amp-list-resizable-children is disabled
v0.js? [sm]:130 Method not found: changeToLayoutContainer in
Should the list height be resizing or is there something else I need to do to get this working?
My canary version is 72.0.3626.0 (Official Build) canary (64-bit) - is that the right one?
@devignerforhire that error message seems to be indicating that the amp-list-resizable-children
experiment is not enabled. If you navigate to the experiments page using the same page, are you sure that the experiment is on? To fix that, you could also try AMP.toggleExperiment('amp-list-resizable-children')
in your browser's JS console. That should achieve the same effect as turning on the experiment though....
Also by canary, I'm referring to the AMP canary, which is 1811272154520. For example, if you use the glitch link I pasted above, you should see the following in your JS console:
Powered by AMP ⚡ HTML – Version 1811272154520 https://amp-list-demo.glitch.me/amp-list-resize.html
The response to AMP.isExperimentOn('amp-list-resizable-children')
should be true:
AMP.isExperimentOn('amp-list-resizable-children')
true
@cathyxz thanks for clarifying :) I tested it again in my normal chrome with dev channel and amp-list-resizable-children enabled and it seems to work now.
After playing with it for a bit it seems it's just switching the layout to container . Would it not be possible to add container layout support to amp-list, so if I know the list length needs to be dynamic, I can just set the layout to container from the start?
I want to test this with our list, but don't see any way to load the canary version of amp in the WordPress plugin, so I'll need to setup a codepen or glitch project. I'll report back once I have something up.
Great question! Supporting layout container was my first reaction to solving this too. Unfortunately we can't support layout container out of the box due to the potential of content jumping before user interaction. This action forces the change to layout container and any subsequent content shift to be a result of direct user interaction. It might be a good idea in the future to support layout container as an api in amp-list but force it to be fixed until user interaction.
A side note: this canary will hit production I think by EOD today or tomorrow, so you will just need to turn on the experiment (which you can do via js console) when that happens.
Thanks for the explanation. That makes sense :)
That's great news about it being available in production so soon! I was expecting we'd have to wait a couple of weeks :P
I'll keep an eye out for the update then test it out on our staging site with the example meta tag. Will let you know how it goes.
Heya @cathyxz,
I just updated our grapes and wines index using the new amp-list-resizable-children experiment with changeToLayoutContainer and it seemed to be working until I checked the list on my other laptop. I had previously enabled the experiment in my console using AMP.toggleExperiment('amp-list-resizable-children') and had also enabled it in the experiments page.
I've added the meta tag to activate the experiment, but it doesn't seem to be having any effect. Is there anything else I should be doing?
You can see our dev site (with the updated list) over here:
https://winefolly.staging.wpengine.com/grapes-wines/
Hi! Has this been released to prod yet? We're eager to try this out too :)
Discussed offline a bit in more details. tldr a new action (and equivalent bindable attribute) to turn layout of amp-list to container upong user action (e.g. toggling between list and grid views) is live but under an experiment flag so folks can try it and provide feedback
@aghassemi Hey Ali,
I tested this on our staging and it's working as expected. Is there a way to enable this for our users on the production site? I added the experimental meta tag, but it doesn't work unless the experiment is activated in the console (or the amp experiments page).
@devignerforhire Thanks for trying it out. I don't mind turning this into a doc-level option experiment so you can enable it with the experimental meta tag. We can keep it a doc-in for a month and unless we hear negative feedback as folks try it, we can launch end of Jan, @cathyxz thoughts?
I wanted to see if it was possible to address the feedback of this approach being overly verbose, but I don't think that will impact the existence or API of this action. I'm cool with this launching by the end of Jan.
We are using amp-state to bind the height, but we calculate the height on the server side which is not perfect and doesn't cover all the cases, so we are waiting this feature. @cathyxz we are happy to help if you need.
Our code on production you can check it out, https://iprice.my/nike/. the filter part is using amp list.
Thanks @aghassemi and @cathyxz. This is one of the biggest challenges we've had with amp-list, so I'm excited to start using this in production.
On a side note, I'm needing to push an update to our wines index sorting (specifically changing the rarity sorting to popularity and sorting by total acreage). All works as expected when the popularity default is initially loaded or one of the other sorting options is selected, but then has a weird spacing issue below each row when switching back to the popularity default.
Adding changeToLayoutContainer fixes the issue, but since that will only be available end of Jan, I was wondering if either of you have any other ideas on how to fix the spacing issue, so I can push the update. The view switching can hold off until end of Jan, but the current sorting doesn't take into account the acreage and as such isn't really accurate, hence the update.
Any ideas would be much appreciated.
Just a call out to those following on this thread. We've now had this feature in experiment for a month now in canary. The main feedback I've gotten is the verbosity (which we can work on in future iterations), but so far it seems to unblock everyone that has tried it and doesn't seem to break anyone. I'd like to go ahead and launch this in the Jan 15th release if there are no objections.
Cheers,
Cathy
Did I miss the bikeshed party? 😅 How about containerize
action and [container]
binding?
That's exactly what I proposed, but it lost the vote.... =(
No promises but we hope we can just support <amp-list layout=container>
in V2 of amp-list
(with enough restrictions to make the content shifting case very unlikely and automatically handling the case where overflow happens with some default UI)
Per previous threads, we request that the <amp-list>
be generated as a <span>
object, not as a <div>
object.
While some have suggested that CSS can be used to keep 2+ amp-list
s together in a <p>
, we cannot reliably and consistently achieve that use case.
We have several cases where a single paragraph uses different amp-lists.
An example is several tool-tips used within paragraph, as seen on the Washington Post
We can say from experience that it is nearly impossible to consistently produce an amp-lightbox
with data from an amp-list
in a format like the WaPo.
Because of the generated <div>
, the values for each unique amp-list cause a line break.
If the generated amp-list structure is packaged in a <span>
, we won't have to go thru different contortions to apply unreliable keep-together
CSS rules.
---
to clarify:
one amp-list
per tool-tip
(where tool-tip is an amp-lightbox
).
we've talked with WaPo tool-tip developers; their tool-tips are re-usable objects (selectable from a library).
they "drop" a specific tool-tip into articles where sports figures are mentioned.
we also want to build re-usable tool-tips, where each tool-tip is a combo amp-lightbox
+ amp-list
.
But re-use is currently being defeated by the code generated when using an amp-list (a non-conforming inline element <div>
)
Hi @jaygray0919 thanks a lot for your comments, but they seem parallel to this issue. I'm aware of issues you have with trying to implement a tooltip experience via amp-lightbox and I know that we have https://github.com/ampproject/amphtml/issues/8366. But I'm missing a bit of context on trying to produce tooltips with <amp-list>
. Do you mind tagging me on the relevant issue(s), or filing a separate issue to consolidate and help us better triage? I'd like to keep discussion on this thread specific to the issue of dynamic resizing for amp-list. =)
Hi @cathyxz - will do. Had not seen https://github.com/ampproject/amphtml/issues/8366 but have used other amp-list
threads to present our issue. We'll update the #8366 thread with examples and past comments by @aghassemi and @choumx. We will need a systematic tool-tip solution soon, so will use #8366 to find a solution. However, the content of an amp-lightbox
for a tool-tip is variable height (i.e. the size of different amp-list
s supporting tool-tips is irregular). In contrast, the content of a WaPo lightbox is a regular height. So we sit on this dynamic-sizing
thread because we have that issue when building our tool-tips. For example, a tool-tip that features one national language has a different height than a tool-tip featuring 10 national languages. To repeat, the content for all amp-lightbox
based tool-tips is amp-list
, hence why we squat on this and related amp-list
and amp-mustache
threads.
The relevant changes from #20314 should land in canary and release candidate tomorrow and land in production by next Tuesday.
Hi,
I am still not able to get dynamic height in amp-list
in AMP Email yet... If anyone has a solution please help. I want my amp-list to change its height as per the dynamically loaded data inside it on the first load.
We can use this playground code for the sample to get how to remove the empty whitespace and make the height dynamic on the first load.
@ShivamS136: it isn't a well documented (or even fully launched) feature, and it only works within email environments for now.
I believe you need to use layout=container
for it to work
Most helpful comment
Adding a
auto-resize
attribute to<amp-list>
per #16564. TODO:auto-resize
when it reaches production.