Design Review 2019-07-31 20:00 UTC (wg-ads, new loaders, dynamic resizing)

[mrjoro]

Time: 2019-07-31 20:00 UTC (add to Google Calendar)
Location: Video conference via Google Meet

The AMP community holds weekly engineering design reviews. We encourage everyone in the community to participate in these design reviews.

If you are interested in bringing your design to design review, read the design review documentation and add a link to your design doc or issue by the Monday before your design review.

When attending a design review please read through the designs before the design review starts. This allows us to spend more time on discussion of the design.

We rotate our design review between times that work better for different parts of the world as described in our design review documentation, but you are welcome to attend any design review. If you cannot make any of the design reviews but have a design to discuss please let mrjoro@ know on Slack and we will find a time that works for you.

[mrjoro]

The Ads Working Group will be presenting their periodic update at this Design Review (10-15 minutes).

/cc @ampproject/wg-ads @lannka

---

Updates: ampproject/wg-monetization#12

[sparhami]

I would like to briefly talk about #23108

[cathyxz]

I'd like to talk about dynamic resizing in <amp-list> and <amp-render> (design).

Gist: https://gist.github.com/cathyxz/c015f137ed089405b95cb01b8fef5927

[cvializ]

new loaders notes

Load the loaders code after main runtime.

• @cramforce: can we give it a more internal name or prefix to prevent users thinking it's something they should use directly?
• @sparhami: brainstorming, we could create a separate extensions-internal directory or something similar. there are various strategies
• @dvoytenko amp-subscriptions also installs CSS and uses a good pattern
• Can developers specify their own loaders?
• @dvoytenko It's not very unnatural to create an extension for a loader. Could enable people who decide to not include loaders, or include a different type of loader, etc.
• @choumx How do we decide if the ~2k gains are worth the overhead of the extracted loader?
  • @sparhami Lots of factors to consider. e.g. the size of the code is larger because of gzip symbols. But it does improve main thread contention. We expect to see less latency in canary as a result of this change. We will measure it, quantify and make sure.
• @choumx How does this affect median, 90th percentile user? How many concurrent connections are possible and will adding this new request harm performance?
  • @sparhami Showing the document sooner will be better, and this should help show the document sooner. This extension loads late so shouldn't interact with other script requests.

[sparhami]

dynamic resizing

• Context: amp-list layout container action
  • Make this API better for amp-render, amp-listv2
  • amp-list is required to specify height, placeholder
    • do not allow resize when bottom is in viewport
    • show overflow button to resize on click
  • current behavior is problematic
    • size not known up front, since number of items is dynamic
    • content could resize on action (e.g. going between list and grid view or expanding/collapsing an accordion within the list)
    • number of items could change due to refresh or changed src via bind
• Two concerns: API for pre-rendered components vs those not pre-rendered
• Allow some of amp-list/render to have the data present in the page (via an amp-state)
  • could also have the DOM present that is server side rendered
  • would allow the list to resize by using layout=”container”
  • list does not support this layout at the moment
  • @sparhami: clarify that the “pre-rendered data” requires amp-list to have finished downloading
    currently people render the items as a placeholder element
  • @choumx: PR for DOM diffing passed in content to amp-list
  • @sparhami: what about a cap on mutations like amp-script so that fetched data does not match within some delta
  • @cramforce: maybe change name for pre-rendering, since it has meaning in AMP
  • @cramforce: call what Will has done as SSR or inlined
  • @cramforce: what was the benefit to client side (via state)?
    • @choumx: do not need to duplicate rendering logic
• resizing for non-inlined/SSRed data
  • proposal: have an initial size/width
  • current: can resize if bottom of content is beyond the bottom of the viewport
  • proposal: allow shrinking if rendered size is smaller, and component is in viewport
  • proposal: allow blocking of following children for some amount of time
    • @jridgewell: would also need to make the following items invisible, since they will still render (e.g. placeholders)
  • proposal: allow resize if user action is high trust, and some conditions are met
• Discussion questions:
  • @cramforce: do we have has systematic way to determine when we cut off
  • @wassgha: are we giving amp-list special treatment?
  • @cathyxz: people either leave to much space, or get their content cut off)
  • @choumx: doc comments have to do weird stuff like put the footer in the list to prevent jumping
  • @cathyxz: shrinking is another issue that people are running into
  • @dvoytenko: shrinking ads is also a problem
  • @jridgewell: I think we prevent all resizing that makes content smaller
  • @dvoytenko: there are a few more considerations, its complicated

[cramforce]

Clarifying what I mean with systematic: I'd like us to behave consistently across all elements that can request resize and may get that request denied (amp-iframe, now amp-list, anything else?). And if we want to have different behavior, we need to define the rule that leads us toward differing.