We should allow publishers to specify icons and their corresponding events to be dispatched. We should also allow some basic customization like vertical (header/footer) and horizontal (start/end) placement. See https://github.com/ampproject/amphtml/issues/30031#issuecomment-685842504 for more details on the API.
Work plan:
Button-specific:

The player will accept an inline JSON object with the desired configuration, the fields and requirements are as follows:
“controls”: array of objects, each one containing:
“name”: a string with the name of the button. If the name is part of the default set of buttons (close / (un)mute / share) the following fields are optional but overridable.
“backgroundImageUrl”: (required when not part of the default set of buttons) accepts URLS and `data:image` URIs like base64 images and svgs.
“visibility”: “hidden” or “visible”
“position”: “end” or “start” string values
An example of it being used within the player:
<amp-story-player style="width: 360px; height: 600px;">
<script type="application/json">
{
"controls": [ // Required.
{
"name": "mute", // If name is part of default set: the default event/behavior and icon will be used, but can be overridden.
"backgroundImageUrl": "icon.jpg", // Supports URLS and `data:image` URIs like base64 images and svgs.
},
{
"name": "close",
"position": "start", // Values: "start" or "end".
},
{
"name": "customButton", // If not part of default set, the following fields will be required.
"backgroundImageUrl": "data:image/svg+xml;charset=utf-8,<svg ... "
}
]
}
</script>
<a href="story.com/1.html">...</a>
<a href="story.com/2.html">...</a>
</amp-story-player>
For the dev preview version, we will only allow up to 3 controls in mobile, and 6 in desktop.
The default set will include: (mobile) share, speaker, close (desktop) share, speaker, play/pause, skip-next, close. If limit is reached, other buttons are discarded.
Looks good! We need semantics to avoid name collisions on the buttons (e.g. amp-mute instead of mute). Otherwise we can't add new default buttons or we might break someone that was using that.... Right?
Or will the icon and event even override default buttons?
The idea is that icon and event are optional if part of the default set, but overridable if desired. So if publisherX is using a buttonX with their own icon and event, and we later introduce buttonX as part of the default set, we will still respect the pubisherX's icon and event, because it overrides the default behavior. Does this sound good to you? @newmuis @gmajoulet
Thanks for clarifying!
All main tasks have been finished. Remaining items are:
exit-control API.Will file separate issues for those.
Most helpful comment
The idea is that
iconandeventare optional if part of the default set, but overridable if desired. So if publisherX is using abuttonXwith their owniconandevent, and we later introducebuttonXas part of the default set, we will still respect the pubisherX'siconandevent, because it overrides the default behavior. Does this sound good to you? @newmuis @gmajoulet