In an attempt to solve certain resizing issues with amp-list where list items that expand/collapse with interaction (e.g. an accordion expanding inside the list) were clipping the content of the list (see https://github.com/ampproject/amphtml/issues/10230) auto-resize attribute for amp-list was implemented in https://github.com/ampproject/amphtml/pull/16564 as an opt-in feature but without an experiment flag. This feature made it to production few weeks ago at the end of September.
Since launch, we have run into a few bugs that we have been addressing (see https://github.com/ampproject/amphtml/issues/18376 for details) but a few remain.
However because this feature was not explicitly flagged as experimental (although undocumented) the shortcomings and the name itself has caused confusion for a few sites that have used it and expected it to work a certain way.
Given the confusion around the naming and the bugs related to this feature, we like to temporarily disable this feature under an experimental flag until a complete solution and a better name for the feature is ready. We plan to do so:
auto-resize: auto-resize attribute will show a warning on AMP pages using it, but it will not invalidate those pages until a later date. When the feature is fully launched under a new name, existing users of auto-resize will have 6 weeks to migrate before we fully deprecate it, which will invalidate pages that use auto-resize (current usage falls below deprecation policy of AMP however we like to minimize the impact even more on the few sites using this new feature)auto-resize: Existing usages of auto-resize will become a no-op and attribute will be ignored unless a new experimental flag called amp-list-with-resizable-children is enabled. This effectively puts the current feature under an experimental flag.Worth noting: Since auto-resize attribute just slightly changes the behaviour of amp-list, existing usages should not suffer from it being turned off. It simply goes back to the status quo behaviour of 3 weeks ago.
1- Do nothing:: We keep the current name and keep iterating on fixing bugs and handling user-case not covered yet.
Pros: Less heavy-handed
Cons: iterating on auto-resize may keep it unstable for those using it and keeping it around will bring more usage white it is being iterated on. We are stuck with the confusing name.
2- Rename but do not turn off: We start the renaming process (validator warning, etc..) but will not put the feature under an experimental flag which turns it off. We keep iterating on fixing bugs and handling user-case not covered yet.
Same pros and cos and above minus We are stuck with the confusing name. part.
/to @ericlindley-g @choumx @cathyxz for an initial review of this proposal.
Thanks @aghassemi ! I'm in favor of putting it back under an experimental flag while we iterate on it, and potentially changing the name.
PR to disable it under an experiment flag: https://github.com/ampproject/amphtml/pull/18877
Any feedback? Auto-resize is really needed.
reenabled via the new(ish) changeToLayoutContainer https://github.com/ampproject/amphtml/pull/20314
Most helpful comment
Any feedback? Auto-resize is really needed.