We received a report on Twitter that the embed block wasn't fully responsive.
WordPress and the WordPress block editor handle responsive embeds in various way.
First of all, they require themes to opt in. But even without that, there is _some_ responsiveness for embeds.
Then there are differences between iframes like the WordPress embeds and embeds with a fixed aspect ratio like YouTube videos.
They do it with this ol' trick using padding and pseudo elements.
Some code references:
https://github.com/WordPress/gutenberg/blob/4fe937c2188e0677b03e6eb5d2c54292705f6c45/packages/block-library/src/embed/style.scss#L37-L84
https://github.com/WordPress/gutenberg/blob/4857ad58c1241b3d63d21a6880c989b85746c3dc/packages/block-library/src/embed/util.js#L132-L185
Our embed block has one big difference to that: users can set width & height to their liking, so we have to do the aspect ratio calculation on the fly.
This is not really an issue with the embed block itself, but more of a question about how to style the player correctly.
Possible solution
div with the class name wp-block-embed__wrapper around <amp-story-player>css
position: absolute;
top: 0;
left: 0;
width: 100%;
height: 100%;
wp-block-embed__wrapper element the following inline style:css
position: relative;
overflow: hidden;
padding-top: calc(600 / 360 * 100%);
height: 0;
calc()This is basically the Gutenberg solution but with support for arbitrary aspect ratios. That's why we cannot use a pseudo element here, since pseudo elements cannot be styled via inline styling.
Using custom properties for the aspect ratio could be an alternative.
a) Don't let users edit the height, maintain a fixed aspect ratio
b) Solve this in the <amp-story-player> component
Player docs: https://github.com/ampproject/amphtml/blob/master/spec/amp-story-player.md
_Do not alter or remove anything below. The following sections will be managed by moderators only._
max-width and setting --aspect-ratioEmbed class in Admin.php to generate markup for embed block. @enriqe Pinging you to hear your thoughts on responsiveness for <amp-story-player>. Has this come up before?
cc @pbakaus
Yeah, I think we could certainly provide an option at the <amp-story-player> level. Our current recommendation for responsive sizing is using vw, but I think we can do better given that your users provide a set width & height.
cc @gmajoulet @newmuis for thoughts
From what I remember you should be able to size the player using any CSS you like. You could set a width/height directly on the player element, or make it fill its container with the CSS you mentioned or position relative and width/height 100%.
Just seeing this now. Feels to me like an aspect-ratio attribute or custom property on the player could make sense too!
I think having the size set from the first HTML render is important. If the story player sets the size after reading an attribute or after its CSS is loaded, we might have a layout shift.
Fair point. Ideally the aspect-ratio CSS property will eventually make this easy for everyone 馃檪
Thanks for the insights so far everyone!
Not sure the vw approach would work well for our use case. For consistency with rest of WordPress blocks and to meet user expectations it sounds like we might want to move forward with the CSS solution outlined in the original post.
@enriqe @newmuis @gmajoulet Quick follow-up question about this: are there any updated docs for using the player on AMP pages? I can resize it using any CSS I like on non-AMP pages, but for AMP pages I'm gonna need to set the width and height explicitly.
Currently it only supports any size-defined layouts. Here is the existing docs for the AMP version of the player: https://github.com/ampproject/amphtml/blob/master/extensions/amp-story-player/0.1/amp-story-player.md#layout
Maybe the responsive or fill layout could work for your use case here?
For extra context, you can learn more about AMP layouts here: https://amp.dev/documentation/guides-and-tutorials/learn/amp-html-layout/layouts_demonstrated/?format=websites#container
Recategorizing this as a Bug rather than Enhancement. While it will certainly improve and enhance the product, the current implementation seems "broken" to a user as responsiveness is assumed for this type of embedding, so want to treat this with higher importance than a typical enhancement/feature request.
@o-fernandez Makes sense & I agree. Just note that since this is already in progress / in review it's probably not that impactful of a change :)
Verified in QA
Related proposal for a "responsive" option for the embed block vs. static sizing status quo: https://github.com/google/web-stories-wp/issues/4977#issuecomment-713807086
However, we should do two things to provide a more sensible default. The current default size is too wide for most mobile devices (I've seen a lot of unintentional horizontal truncation).
- Change default static size 360x600 to 280x500.
- Support a new "responsive sizing" mode that preserves 9:16 aspect-ratio with the padding-bottom trick (AMP also uses this for layout=responsive).
- Add this as an option to the "Story dimensions" settings section and make it the default (enabling it disables the static size text fields and vice versa).
The current default size is too wide for most mobile devices (I've seen a lot of unintentional horizontal truncation). Change default static size 360x600 to 280x500.
Given that we've fixed the truncation issue with this ticket, this seems less of a concern now.
Support a new "responsive sizing" mode that preserves 9:16 aspect-ratio with the padding-bottom trick
That's exactly what we already did here (using padding-bottom trick).
Add this as an option to the "Story dimensions" settings section and make it the default (enabling it disables the static size text fields and vice versa).
The text field currently acts for setting the aspect ratio and the maximum size for the responsive player.