Gutenberg: Giant space above all Youtube video in Posts

[Pikkals]

Describe the bug
Giant space above all Youtube video when VIEWING Posts in Gutenberg: Version 3.9.0

To Reproduce
Steps to reproduce the behavior:

1. Go to 'ALL POSTS.'
2. Click on 'EDIT' A POST YOU KNOW HAS A YOUTUBE VIDEO
3. Scroll down to 'YOUTUBE VIDEO BLOCK'
4. You CAN'T SEE the error in the actual Post Edit, but you can see the giant space when VIEWING the post.

Expected behavior
There should be reasonable space around the Youtuve video.

Screenshots

Desktop (please complete the following information):

• OS: WINDOWS 10
• Browser CHROME
• Version 68.0.3440.106 (Official Build) (64-bit)

Additional context
Latest version of Gutenberg: Version 3.9.0

[mkaz]

Thanks for reporting the bug, agreed that does not look right, and I'd imagine frustrating.

I see the whitespace when I visit your site, however I'm not able to reproduce it. I installed the Hueman Free theme, and using the Autooptimize plugin, which I noticed are what you use on your site at: https://www.discerningtheworld.com/

When I create a post with a YouTube embed, I'm not able to get the large space.

To help anyone else when troubleshooting:

I noticed on your embed there is an additional classname wp-embed-aspect-4-3 which when present adds the padding at the top. I can see in the code if the frame width and height are specified that it will add, but I did not see how that would be specified directly in Gutenberg.

Code in: packages/block-library/src/embed/index.js

Can you let me know how you added the embed, and if there is anything you did after adding the embed to help reproduce and solve the issue?

[Pikkals]

Hi mkaz

Yes I saw that "wp-embed-aspect-4-3" in the CSS and because I am not a programmer at all, I had no idea if this should be there or not.

So I will remove it and come back to you.

I added the embed video, by adding a block, then clicking Youtube and only adding the youtube video url nothing else, just the plain url to the video. Everything was working fine till the latest version upgrade.

[Pikkals]

Hi mkaz

Ahhhhh Ha! "wp-embed-aspect-4-3" is indeed the culprit, I removed it and the giant space is gone. But now the big question, where is this additional CSS coming from ? It was not there yesterday. All was hunky dory until I updated to new version of Gutenberg last night.

I see on other posts it's added additional CSS "wp-has-aspect-ratio wp-embed-aspect-16-9". And it too is making a big white space above all my videos.

What do you suggest I do? I can't sit and manually go through 600 articles removing this CSS that's appeared out of nowhere. Help.

[mkaz]

ok, good to see we were able to narrow it down.

Will need to investigate further to see what it was trying to address and figure out a solution.

[Pikkals]

You got me thinking.

I deactivated the Autoptimize plugin and taaadaaaa.... problem resolved.

I will play around with the settings and see if I can get Autoptimize to work without breaking my site...

Do you recommend another plugin similar to Autoptimize?

[SolespireMarcus]

You got me thinking.

I deactivated the Autoptimize plugin and taaadaaaa.... problem resolved.

I will play around with the settings and see if I can get Autoptimize to work without breaking my site...

Do you recommend another plugin similar to Autoptimize?

In the meantime of having the plugin deactivated, you should report that problem to the developers of Autoptimize: https://wordpress.org/plugins/autoptimize/#developers

[Pikkals]

Thank you Marcus.

I have contacted Autoptimiae support here: https://wordpress.org/support/topic/giant-space-above-all-youtube-video-when-viewing-posts-in-gutenberg-v-3-9-0/

[futtta]

Heya everyone;
I'm Autoptimize's developer :-)

I actually still see the gap even with AO disabled, cfr. this screenshot;

There's a padding-top:75% and a padding-top:50% (both for .wp-block-embed__wrapper::before) in wp-content/plugins/gutenberg/build/block-library/style.css. Disabling those rules in the inspector "fixes" the problem?

Happy hunting!
frank

[Pikkals]

Goodgrief, the error is back... I'm now confused... Never the less...

Frank you are a superstar!!!! 🥇

[mkaz]

Thanks for jumping in and looking @futtta - agreed, I don't think it is a conflict with Autoptimize.

To help troubleshoot:

@Pikkals what steps did you do when adding the YouTube embed? It looks like older posts do not have that same issue with embeds, likely because they were not created in Gutenberg. Can you try to delete and add the YouTube block again in that post?

For @notnownikki and @jasmussen who worked on the issue:

It looks like an unintended consequence from this PR #9770 in 3.9.0 the iframe width/height is being detected properly and the additional aspect ratio class is added, however, when the new class is added it includes a large padding at the top.

It looks like the styles in #9550 are what is causing the issue here, but I'm not able to reproduce in my tests when adding a block, using same theme as user.

[chrisvanpatten]

Hi all -

I took a look at this and I think this may be a plugin conflict although I don't believe it's Autoptimize in this case.

When I insert a YouTube embed on my own site, I see this HTML rendered out:

<figure class="wp-block-embed-youtube wp-block-embed is-type-video is-provider-youtube wp-has-aspect-ratio wp-embed-aspect-16-9">
    <div class="wp-block-embed__wrapper">
        <iframe width="660" height="371" src="https://www.youtube.com/embed/GLwz5IJ4AsY?feature=oembed" frameborder="0" allow="autoplay; encrypted-media" allowfullscreen=""></iframe>
    </div>
</figure>

However when I look at a YouTube embed on your site, I see the following:

<figure class="wp-block-embed-youtube wp-block-embed is-type-video is-provider-youtube wp-has-aspect-ratio wp-embed-aspect-4-3">
    <div class="wp-block-embed__wrapper">
        <div class="video-container">
            <span class="embed-youtube" style="text-align:center; display: block;">
                <iframe class="youtube-player" type="text/html" width="640" height="360" src="https://www.youtube.com/embed/Bp00Wh-oaOQ?version=3&amp;rel=1&amp;fs=1&amp;autohide=2&amp;showsearch=0&amp;showinfo=1&amp;iv_load_policy=1&amp;start=108&amp;wmode=transparent" allowfullscreen="true" style="border:0;"></iframe>
            </span>
        </div>
    </div>
</figure>

Note all the extra <div> and <span> tags and CSS classes.

@Pikkals could you provide a list of plugins on your site? I would guess that another plugin is attempting to handle the responsive video, and is colliding with the way Gutenberg handles it.

[Jeanneavelo]

Hi,

Same problem on my blog with Hueman free theme. I don't use any editor plugin (could other kind of plugins be involved ?).

See for example at the bottom of that post modified with Gutenberg 3.9.0 today : http://jeanneavelo.fr/2018/02/22/un-carrefour-urbain-ordinaire-aux-pays-bas/

Older posts (i.e. not edited with Gutenbegrg 3.9.0) are not concerned.

[chrisvanpatten]

Sounds then like it's an issue with the Hueman Free theme in particular then. Perhaps worth reaching out to the theme developer about this.

Also possibly worth looking at whether this should be another opt-in theme feature via add_theme_support to avoid potential conflicts. That ship may have sailed since this feature is now in Gutenberg, but might at least be worth thinking about.

[Pikkals]

Hi guys

I am using the Hueman Pro theme. I will contact the developer and send them here to have a look.

And yes you are right Jeanneavelo posts that have not been edited with Gutenberg are fine.

Ok, I have logged a ticket with Hueman support.

[Pikkals]

Hi chrisvanpatten

Here is a list of all my plugins:

THEME | VERSION : Hueman Pro | v1.1.3
WP VERSION : 4.9.8
- Accelerated Mobile Pages (version 0.9.97.16)
- Agreeable (version 1.5)
- Akismet Anti-Spam (version 4.0.8)
- Auto-Post To Instagram (version 1.4.3)
- Autoptimize (version 2.3.4)
- Childify Me (version 1.2.0)
- Comment Approved (version 1.5.2.3)
- Comments-advanced (version 2.0)
- Comment Toolbar (version 1.4.3)
- Custom Taxonomy Order (version 2.9.5)
- Disable Gutenberg Autosave (version 1.0.1)
- Display All Image Sizes (version 1.1.6)
- EU Cookie Law (version 3.0.5)
- Force Regenerate Thumbnails (version 2.0.6)
- Glue for Yoast SEO & AMP (version 0.4.3)
- Google Analytics Dashboard for WP (GADWP) (version 5.3.5)
- Google Language Translator (version 5.0.48)
- Gutenberg (version 3.9.0)
- Jetpack by WordPress.com (version 6.5)
- List category posts (version 0.78.1)
- MailChimp (version 1.5.7)
- News Announcement Scroll (version 8.8.6)
- Quick Featured Images (version 13.3.2)
- Recent Posts Widget With Thumbnails (version 6.2.1)
- RefTagger (version 2.1.2)
- Schema (version 1.7.1)
- SEO Image Toolbox (version 3.3.1)
- Simple Comment Editing (version 2.1.11)
- Simple Tags (version 2.4.7)
- Sucuri Security - Auditing, Malware Scanner and Hardening (version 1.8.18)
- Target Blank In Posts And Comments (version 3.2)
- Term Management Tools (version 1.1.4)
- VaultPress (version 1.9.6)
- wp-Monalisa (version 4.6)
- WP 404 Auto Redirect to Similar Post (version 0.7.7)
- WP Edit (version 4.0.3) (I'VE DEACTIVATED THIS PLUGIN)
- WP Super Cache (version 1.6.4)
- Yoast SEO Premium (version 8.2.2)

[jasmussen]

Good ticket, thank you.

So this issue happens because embeds created in Gutenberg are now responsive out of the box. The issue here is that if the theme itself also provides responsiveness for embeds through filtering the output, you end up with a double fix, which makes this extra space appear.

There are a number of ways to fix this, @chrisvanpatten I would appreciate your thoughts here as well.

Option 1: Move the responsive Gutenblock CSS from style.scss to theme.scss. The pro is this means Gutenblocks are only responsive if the theme author asks for it, and is therefore aware of it. Con: it means we can't provide responsive videos out of the box.

Option 2: We make it a user toggle, so a user can toggle the responsiveness off on a per-embed basis, if we default to On.

Option 3: Here's some CSS that seems to fix it in the case of THIS particular theme:

.wp-block-embed__wrapper div, .wp-block-embed__wrapper span {
    padding: inherit;
    position: static;
}

But this is a little hacky because it assumes a particular way of adding responsiveness to the videos.

What do you think? CC: @mtias

[Pikkals]

Hmmmm

I see I have a plugin called - WP Edit (version 4.0.3) installed,

I am going to deactivate this and see what happens.

Ok, I see I still have the problem. I'll keep this plugin deactivated as I don't see the need for it.

[notnownikki]

Option 2: We make it a user toggle, so a user can toggle the responsiveness off on a per-embed basis, if we default to On.

I had this on my list to suggest too, thinking of wider themes and narrower videos where it might not look that great.

[Jeanneavelo]

Ok, I have logged a ticket with Hueman support.

So did I : https://wordpress.org/support/topic/display-issue-with-youtube-embedded-video-in-gutenberg-3-9-0-edited-post/

[Pikkals]

I logged my ticket with [email protected] and asked the developers to please come to this thread.

[notnownikki]

As much as it disappoints me, I think we might have to make this opt in. Or, perhaps we make responsive videos opt-in (or out?) at the document level instead of the block level?

[jasmussen]

As much as it disappoints me, I think we might have to make this opt in. Or, perhaps we make responsive videos opt-in (or out?) at the document level instead of the block level?

This PR makes it opt-in through the block styles. But I agree, I would consider that our last option, because I sort of feel a responsibility for Gutenberg to provide responsive features by default, so let's make sure we have a fix in the 4.0, but let's keep thinking of ways to do this without making it opt-in.

Presumably themes which provide their own responsiveness do so with a filter that adds additional wrapping elements and classes, no? Would it be possible/feasible/not break things, if we apply a differently named filter for responsive videos?

[jasmussen]

Additional thought on why it would be good to find a solution that did not require opt in via add_theme_support( 'wp-block-styles' ): many themes are likely going to never opt in, even post-merge, because they want to provide their own blockquote styles and not have to override those provided by core blocks. These themes should still be able to benefit from what I would call structural CSS, such as that necessary for responsive embeds.

[notnownikki]

Would it be possible/feasible/not break things, if we output a different filter for responsive videos?

All this goes through oembed, I think trying to intercept what themes do there will end up in priority fighting heck.

... it would be good to find a solution that did not require opt in via add_theme_support( 'wp-block-styles' ) ..

Ugh, I agree with all of that too. Perhaps a document level option is the way to go? Or perhaps a site-wide option, so if you change your theme, you can toggle the G supplied responsiveness across all posts?

[jasmussen]

I haven't totally thrown in the towel on a code fix. https://github.com/WordPress/gutenberg/issues/10109#issuecomment-423898890 fixes it but I would love for us to try it against a bunch of themes that provide responsive embed support, perhaps even plugins, to see if it works well enough.

[Pikkals]

Email from support on Hueman theme

---

Hi Deborah,
thanks for reporting this!

We've identified the compatibility issue, it happens because both the theme and Gutenberg apply their own code to make the video responsive, but these two codes conflict.

https://imgur.com/a/1BzGIu5

A new theme version containing a fix for it will be released pretty soon.

Meantime, since both the theme, by default, and Gutenberg make the video responsive with the same aspect ratio (16:9), you can act on the Gutenberg block additional classes and remove the plugin CSS class which "produces" the conflict: wp-embed-aspect-16-9

Hope this helps.

Rocco, Support Team @presscustomizr

[Jeanneavelo]

Meantime, since both the theme, by default, and Gutenberg make the video responsive with the same aspect ratio (16:9), you can act on the Gutenberg block additional classes and remove the plugin CSS class which "produces" the conflict: wp-embed-aspect-16-9

Hope this helps.

Thanks for the tweak : it works perfectly well.

[caouic]

I confirm. The conflict between Gutenberg and Hueman Theme Pro occurs too since Gutenberg version 3.9.0 . Thanks for the tweak @Pikkals
You save my day
Au passage, sympa le blog ;)

[Jeanneavelo]

Au passage, sympa le blog ;)

Si le compliment m'est adressé, je dis merci ! :-)

[chrisvanpatten]

Awesome! Since there seems to be a fix I’ll close this issue but if anyone still has problems we can always reopen :)

[notnownikki]

Just a quick mention of the PR that would let you toggle responsiveness on a block-by-block basis :) https://github.com/WordPress/gutenberg/pull/10161

[sandnsurf]

Same issue with the Lensacap theme by Array (https://arraythemes.com/themes/lenscap-wordpress-theme/), not limited to the Hueman Pro theme

Does not occur with old posts with video, just when I edit the page and update (e.g. https://litfl.com/tee-essentials-making-sense-of-the-views/)

When I remove the "wp-embed-aspect-16-9" as suggested all looks good again. https://litfl.com/tee-essentials-assessment-of-the-left-ventricle/

Realise thread closed, just wanted to give feedback from an additional theme.

[joopringelberg]

The very same problem applies to the SiteOrigin Vantage theme. I've created a thread on their forum.

I don't understand how to apply the fix suggested above. Should I edit the CSS file of the installed theme? And just how can I do that?

[notnownikki]

Hey folks, we just merged
https://github.com/WordPress/gutenberg/pull/10161 which will allow you to turn off the responsiveness on a per-block basis. That'll be in the 4.0 release.

[Jeanneavelo]

I don't understand how to apply the fix suggested above. Should I edit the CSS file of the installed theme? And just how can I do that?

You have to edit each block concerned in html to remove the "wp-embed-aspect-16-9" CSS value.
It isn't a global tweak.

[C47Joe]

I'm on Divi. Just got same issue. Copy and pasted video URLs into post and let it convert to an embed link. Narrowed it down the the 50% padding in wp-block-embed__wrapper::before

If I go into the block's settings to advanced and remove the added css code wp-has-aspect-ratio wp-embed-aspect-16-9 it seems to fix it. But I have to do that for every single video.

[notnownikki]

I just want to confirm with @jasmussen that this is fixed for the 4.0 release

[jasmussen]

Yep there is a feature in the 4.0 to let you easily switch off the baked in responsiveness for videos:

This will be in 4.0. If we need to go further, then there is a "nuclear option" in https://github.com/WordPress/gutenberg/pull/10133 which we hope to not have to use.

[C47Joe]

@jasmussen thanks for the screenshot. Is that a global setting or per YouTube block?

[notnownikki]

It's per block, but the workaround mentioned in https://github.com/WordPress/gutenberg/issues/10109#issuecomment-424289255 will also be 4.0 so turning off the responsiveness is a last resort and _shouldn't_ be needed with 4

[davisshaver]

Bumping this for reconsideration, I ran into the style issue on my theme and the style rules seem a bit too clever, thankfully the snippet above was a good override but it's clearly not a universal solution. This is different from the block styles such as colored blocks because the responsive video styling more drastically changes the page flow. While I appreciate the feature in principle, what is the cost of shipping an ancillary experience that has a demonstrated high likelihood of breaking third-party themes? Could we hold this to a release after 4.0, or make it more opt-in?

[davisshaver]

This is the override style that ended up working for me. @jasmussen's snippet does not override for me.

.wp-block-embed.wp-embed-aspect-16-9 .wp-block-embed__wrapper::before {
padding-top: inherit;
}

[jasmussen]

ran into the style issue on my theme and the style rules seem a bit too clever

Can you elaborate a bit?

I'd prefer to make the block styles solid.

[davisshaver]

@jasmussen I wonder if the feature could be deferred until more bulletproof CSS can be developed. Regarding the actual CSS it seems to be a idiomatic way of achieving the fixed aspect ratio without using JS, but for a tertiary feature that appears to have at least some probability of causing a site to "break" upon first Gutenberg publish, and given the timeline for merge, I wonder if it's necessary for the initial release. I know there's some impetus on me as a commenter to offer a better solution, but I don't have one at-hand unfortunately. Too bad we can't do visual regression with Gutenberg and themes, that would be nice, as admittedly I don't have any way to estimate how many themes would be affected.

[chrisvanpatten]

@davisshaver Could you share the site in question? A bit of extra context would be very valuable!

[jasmussen]

I wonder if the feature could be deferred until more bulletproof CSS can be developed.

While anything is possible, this is the sort of feature that only really makes sense if actually shipped, and I doubt delaying the feature will do anything but delay the pain.

That's not to say we have to force it through, I'd like to make the CSS more "bulletproof", but the only way to do so is see what themes actually do, which is why I inquired about the method you're using.

If the method used is the same as that used for previously mentioned themes, perhaps I can make a pull request that leverages this to provide the responsiveness in a way that overrides a theme.

At this point I think it's very crucial to remember that this responsiveness is applied _only_ to embeds created in Gutenberg, _not_ to embeds created in the classic editor.

On a tangent, depending on how this plays out, themes can provide back compatible responsiveness by scoping the responsive embed CSS to :not(.wp-has-aspect-ratio) ... { }.

[davisshaver]

@jasmussen I am glad to help.. The patch is applied on this site but you can remove the override with dev tools. https://leb.town/2018/09/19/lebanon-teen-bringing-lego-based-stem-education-to-the-region/

In this case rather than other styles I believe the gap is actually being caused by the behavior of AMP version of YouTube embed. I am using AMP plugin v1.x and testing AMP native mode.

If we wanted to patch for this specifically I suppose something like :not(:has(amp-youtube)) {...} could work, or alternatively including the patch in blocks stylesheet with :has(amp-youtube) {...}.

[jasmussen]

Thanks so much for the additional context. Here's the markup from the YouTube AMP plugin:

It appears the AMP YouTube plugin is using basically the same technique, a 56.something% padding element.

So to summarize where we are: many WordPress themes and plugins provide some responsive video embed support. When Gutenberg also provides this, there's a conflict as shown in this thread.

Outside of simply rolling this feature back or making it off by default, here are some ideas:

1. make it opt-in via the block-styles opt-in, i.e. https://github.com/WordPress/gutenberg/pull/10133
2. make it opt-in via a brand new function call, such as add_theme_support('responsive-embeds')
3. change the toggle so embeds are _not_ responsive by default out of Gutenberg
4. find a way to make a global user-facing setting to choose the Gutenberg default
5. try and make a CSS hack that hopefully catches more methods than making themes responsive than the snippet shared here https://github.com/WordPress/gutenberg/issues/10109#issuecomment-423898890

I would love additional opinions on this. On the one hand I strongly feel like the fact that both themes and plugins add this support after the fact, is a strong indication that _it's been done wrong all these years_ and we should fix it at the source.

On the other hand I deeply understand that users won't care about that, they'll just see a giant space above embeds and think they did something wrong.

I would _love_ for us to find a middle-ground that allowed us to ship this by default, but still give some more power into the hands of both themers and users both.

Exploring 5, I wonder if the following could work better than previously shared snippet?

.wp-has-aspect-ratio>.wp-block-embed__wrapper>*:not(.i-amphtml-layout-responsive),
.wp-has-aspect-ratio>.wp-block-embed__wrapper>*:not(.i-amphtml-layout-responsive)::before,
.wp-has-aspect-ratio>.wp-block-embed__wrapper>*:not(.i-amphtml-layout-responsive)::after,
.wp-has-aspect-ratio>.wp-block-embed__wrapper>*:not(.i-amphtml-layout-responsive) *,
.wp-has-aspect-ratio>.wp-block-embed__wrapper>*:not(.i-amphtml-layout-responsive) *::before,
.wp-has-aspect-ratio>.wp-block-embed__wrapper>*:not(.i-amphtml-layout-responsive) *::after {
    padding-top: inherit !important;
    padding-bottom: inherit !important;
    position: static !important;
}
.wp-has-aspect-ratio>.wp-block-embed__wrapper>*:not(.i-amphtml-layout-responsive) iframe {
    position: absolute !important;
}

It would:

• be Gutenberg only, i.e. wouldn't touch posts from classic editor
• scoped to videos (with an aspect ratio)
• catch the markup on http://jeanneavelo.fr/2018/02/22/un-carrefour-urbain-ordinaire-aux-pays-bas/.
• omit AMP entirely, which seems to have its own thing going on, though thankfully in a standardized way

On the flipside, that CSS is a little crazy and heavy handed.

Would love your thoughts, @pento @mtias

[chrisvanpatten]

Another thing to consider is themes that bundle FitVids. That's where I encountered the problem. You could probably detect if jQuery.fn.fitVids is accessible and conditionally disable based on that but it seems like a hack.

I think an opt-in add_theme_support is the best call, even though it sadly means a lot of sites won't get it out of the box. It's the safest option though, and allows themes with specific needs to provide their own responsive solution without needing to ask content editors to remember to disable the responsive embed toggle.

[davisshaver]

@jasmussen I totally agree with you, this should have been done better sooner, but keeping legacy sites working is the hard balance of WordPress... I think that moving to add_theme_support could be a good balance of creating a canonical solution and minimizing risk for legacy users.

For reference, some other responsive embed examples I've seen in the wild include the .shortcake-bakery-responsive implementation as well as Pym.js.

[tofumatt]

With
https://github.com/WordPress/gutenberg/issues/10109#issuecomment-428177248 I think this needs to be re-opened, or another issue filed.

Putting this behind a theme support option seems the best way not to break things.

[dnusca]

+1 for add_theme_support option. Also experiencing this with 3.9.0 and FoundationPress due to the following implementation - https://github.com/olefredrik/FoundationPress/blob/3eafe78872e8d7cf0974632fd7b7aefb500e7b43/library/foundation.php#L103

[notnownikki]

I'm +1 for add_theme_support too. I'll start on this now. My plan is to still assign the classes in the editor, but only load the styles for themes that opt in. That way they won't break anything by being there, themes can opt in and use our styles, or themes can use them to apply their own thing, or totally ignore them if they wish.

[dweuste]

Found this thread after dealing with this issue on multiple sites. Simply removing the auto-added additional CSS classes fixed the issue as does forcing the "embed" block to not auto-become a YouTube or Vimeo block since those classes aren't in the standard embed block.

[chezmat]

I am using a custom theme based on twenty fourteen.
The fix works for the space issue, but broke the global css.
So i still need to delete the css additional class for youtube videos..
:-)

[notnownikki]

PR is up for review that adds a responsive-embeds theme option, https://github.com/WordPress/gutenberg/pull/10477

[rickcurran]

Hi, is the #10477 PR going to make it into a full release? I've encountered this issue with embedded WordPress pages (such as embedding a WordPress plugin directory urls in a page as on my page here: https://suburbia.org.uk/projects), I've had to manually disable the responsiveness on all embeds on this page to stop a gap appearing below them. But it appears this default responsive setting is incorrect at least for this type of embedded page - at least on the standard 2017 theme anyway - so it would be good to disable this globally if possible.

[jasmussen]

@rickcurran yes, this will be part of the 4.1 release coming soon.

[slowaways]

This bug is not fixed:

[thegroovylab]

I have the same issue even when I revert to Twenty Nineteen and add a YT block.

[PaulHale]

Why does WordPress insist on inserting wp-embed-aspect-4-3 every-time I update a post which contains a YouTube video? I keep having to manually hack it all the time. Highly annoying. I want wp-embed-aspect-16-9 and never 4-3

[notnownikki]

Could you post the links of the youtube videos you're embedding, and the themes you're using? I can investigate.

[scottwyden]

I've seen this happen with every youtube video with every theme. So it cannot be video or theme specific.

[notnownikki]

@scottwyden I'm not seeing the issue, here's what the editor and published post look like for me:

What WordPress version are you using? Are you installing the Gutenberg plugin, or using the version bundled with WordPress?

[scottwyden]

try it with anything but an Automattic / default theme.

[notnownikki]

@scottwyden I tried with the Flat Responsive theme, I don't see the issue.

What WordPress version are you using? Are you installing the Gutenberg plugin, or using the version bundled with WordPress?

[scottwyden]

I think the issue might have been fixed in WP 5.2.1 Alpha. I can replicate it with all themes using 5.2 but it's gone in 5.2.1.

[denverds]

I seem to have run into the same issue.
Running WordPress 5.2.1 with Cookd Pro Theme theme. Using Genesis 2.10.1. Using the Gutenberg "blocks" editor.
I'm not a coder, but from what I see, the iframe seems to be setting the 472x745 ratio. I don't know if it's some theme or plugin that is setting it.
I did not have this issue when updating to Gutenberg. Any advice on how I can go about resolving it?

[mrSaraf25]

Hi, I am too facing this issue and I'm using OceanWP theme. This is the HTML when I embed a YouTube video:

<figure class="wp-block-embed-youtube wp-block-embed is-type-video is-provider-youtube wp-has-aspect-ratio wp-embed-aspect-16-9"><div class="wp-block-embed__wrapper">
https://www.youtube.com/watch?v=HAzNm6lxNV8
</div></figure>

The space goes away if I remove wp-embed-aspect-16-9. Every time I update, this gets added back and the space appears again. Is there any permanent fix for this?

[notnownikki]

The aspect ratio classes are only applied if the theme says that it supports responsive embeds, so It would seem to me to be a theme issue, but cc'ing @jasmussen on this because he knows more about the CSS than I do on this one and is more likely to spot what's going on.

[jasmussen]

The Jetpack plugin also has some magic to make videos responsive. But the bug where it made them "double-responsive", I believe, was fixed a while back. Could it be that you are running an older version of the Jetpack plugin?

[mrSaraf25]

I am not using Jetpack plugin

[gregsullivan]

I spent a significant amount of time debugging this on the theme and plugin side, only to find that the oEmbed provider itself was the one supplying the responsive code that was then doubled by Gutenberg. Here are two responses from Vimeo for different videos (edited down to just the html property):

{
  "html": "<div style=\"padding:56.25% 0 0 0;position:relative;\"><iframe src=\"https://player.vimeo.com/video/123?app_id=789\" style=\"position:absolute;top:0;left:0;width:100%;height:100%;\" frameborder=\"0\" allow=\"autoplay; fullscreen\" allowfullscreen></iframe></div><script src=\"https://player.vimeo.com/api/player.js\"></script>",
}

{
  "html": "<iframe src=\"https://player.vimeo.com/video/456?app_id=789\" width=\"640\" height=\"360\" frameborder=\"0\" allow=\"autoplay; fullscreen\" allowfullscreen></iframe>",
}

(I've anonymized my client's videos.)

The first adds its own responsive styles as attributes, and the second doesn't. I'd say the styles are added for around 20% of my client's videos.

That being the case, I think the only solution is a version of the CSS @jasmussen posted. I ended up using this:

.wp-block-embed__wrapper > div {
    padding: inherit !important;
    position: static !important;
}

I'm not excited about using !important, but I'm not sure there's another way. Obviously I could train my client to remove the aspect ratio classes within Gutenberg on the videos that load with a large gap above, but I also worry about the possibility that the content of the oEmbed response could change over time, in which case a gap might appear later.

[notnownikki]

the oEmbed provider itself was the one supplying the responsive code that was then doubled by Gutenberg

Oh... wonderful :( so if providers are _sometimes_ doing their own responsive thing, then we need to detect when that's happening and turn of the gutenberg responsive styles _for that embed_. I guess we could parse the html and see if any of the elements have a relative position applied...?

@gregsullivan thank you for spotting this!

[gregsullivan]

You're welcome, @notnownikki! It occurred to me that this could be happening on three levels on the oEmbed side:

• Inline CSS being added directly to the HTML, as shown above
• Inline CSS being added by a JavaScript file included within the oEmbed response
• An HTML class that is made responsive by a CSS file included within the oEmbed response

I started to wonder whether it might make sense to use JavaScript to check for and remove responsive styling on elements descending from .wp-block-embed__wrapper, but I'm not sure how feasible that is, and it would likely introduce flashes of empty space in the moment before the styles are removed.

Definitely not an easy problem to solve!

[notnownikki]

Definitely not an easy problem to solve!

Indeed!

So the way I'd probably approach this is when we receive a new bunch of preview HTML, set state that says we're checking it for provider supplied responsiveness, and not render the preview until that check is complete. Then we parse the HTML and walk the DOM looking for provider supplied responsiveness (or maybe we render into an iframe and watch DOM changes to see what's going on... perhaps for the first iteration we just parse the HTML and walk the DOM). Once we've done that, we know if we need to disable responsiveness for that embed block or not, we set the state to say "reponsiveness checked" and then the preview would render without any flashing.

[gregsullivan]

That makes sense to me!

Do you see an approach that would prevent issues on the front-end if oEmbed providers were to change the HTML they provide (either by starting as non-responsive and becoming responsive, or vice versa)?

[jasmussen]

Oh golly.

then we need to detect when that's happening and turn of the gutenberg responsive styles for that embed

So — embed providers sometimes also change their icons, and given we include icons that means we also need to update them. This is one of the challenges we more or less took on our shoulders when deciding to have explicit separate embed providers on a whitelist, rather than be more generic in the approach.

In that vein, if we were able to _auto-detect_ this stuff, that would be swell. But if that's not possible, would it make sense to simply create a list instead of embed providers that provide their own responsiveness, and omit those from the block editor treatment?

[notnownikki]

Do you see an approach that would prevent issues on the front-end if oEmbed providers were to change the HTML they provide (either by starting as non-responsive and becoming responsive, or vice versa)?

We'd have to include the same detection on the front end that we do on the backend. I'm not sure we want to do that, or even if it's a good idea. We could end up with race conditions and scripts fighting each other, which in the _editor_ is kinda... yucky not not site breaking. On the front end though, unacceptable.

In that vein, if we were able to auto-detect this stuff, that would be swell. But if that's not possible, would it make sense to simply create a list instead of embed providers that provide their own responsiveness, and omit those from the block editor treatment?

There _might_ be some clever CSS way we can override the responsive padding from the provider and only have _ours_ take effect? That's a question for you really @jasmussen but my feeling is that we might end up breaking more things without realising it if we go down that route.

If the providers are starting to include their own responsiveness, then yes this seems the way to go. I'm not sure why some videos get it and some dont when the videos come from the same provider - it could be some kind of A/B test going on? But if that's the way they're moving, then yeah, just register the blocks with responsive: false and let the providers do their own thing.

[jasmussen]

There might be some clever CSS way we can override the responsive padding from the provider and only have ours take effect? That's a question for you really @jasmussen but my feeling is that we might end up breaking more things without realising it if we go down that route.

I had the same thought back when we were hoping to be able to roll this out without opt in. And I did get it to work, for one such method. But the problem is there are a number of different ways the responsiveness can be built, and unfortunately if I were to have to target them all, it would very likely touch selectors and elements it shouldn't. So I'm not so confident in that approach anymore, unfortunately.

I think you may be right, it could be an A/B test, or it could even be a thing that happens only for new embeds or something in that vein. Perhaps an interim solution is to update the help text here to explain cases where you might want to turn it off?

[gregsullivan]

One further note here: Vimeo seems to be breaking the oEmbed spec with these styles. Here's what oEmbed has to say about the html parameter in 2.3.4.2 (the video type):

The HTML required to embed a video player. The HTML should have no padding or margins. Consumers may wish to load the HTML in an off-domain iframe to avoid XSS vulnerabilities.

(Emphasis mine.)

I've asked my client for access to their Vimeo account; maybe I'll be able to get a sense of what is triggering the responsive styles on some videos and not others. I know it's not new versus old, as it happened in very recent videos as well as videos more than three years old.

[gregsullivan]

Between Vimeo's documentation and access to my client's account, I think I have a decent handle on the cause of the variation between videos.

Vimeo's embed code documentation has a "Responsive embeds" section that says the following:

The responsive code may not play nicely with certain webpage themes and layouts. If you are having trouble with the responsive embed code, we recommend switching back to the fixed size embed code.

So if you're getting the embed code manually, responsive code is triggered by choosing between "Responsive" and "Fixed Size" in the "Share this Video" overlay.

The documentation also says that use of Vimeo Cards causes the embed always to be responsive. This isn't a problem I ran into, but I could see it being an issue for others.

Vimeo's oEmbed documentation says the default is for a non-responsive embed, but also says:

You can't override the video's default settings when the video owner's membership level is anything above Vimeo Basic. (Refer to the account_type field in the oEmbed response to determine this information.)

My client has a Vimeo Pro account. In their account, the videos set to "No preset" had the responsive styles added, whereas their custom preset sets a size of 640 × 360. They occasionally forget to select the preset, and it's those videos that had the responsive styles and corresponding empty space above them.

In conclusion: Videos hosted by Vimeo Pro accounts without fixed sizes set for their embed (and videos using Vimeo Cards) will always send responsive styles when requested via oEmbed.

I'm not sure how feasible this is, but perhaps having WP_Embed create a simplified embed code for Vimeo using the width, height and video_id properties would be the cleanest fix. Something like:

<iframe src="https://player.vimeo.com/video/${video_id}" width="${width}" height="${height}" frameborder="0" allow="autoplay; fullscreen" allowfullscreen></iframe>

[jasmussen]

Thanks for the superb investigation, this is exceptionally helpful.

I'm not sure how feasible this is, but perhaps having WP_Embed create a simplified embed code for Vimeo using the width, height and video_id properties would be the cleanest fix.

There is perhaps a larger question around the UX for responsive embeds, given that technically any oembed provider could change their markup at will. The fact that responsive embeds in the block editor are opt-in, and you can opt out on a per embed basis, is a good start. But I'm wondering what the best next steps are.

• A whitelist of known good responsive embeds is kind of in the vein of what you suggested with an exception for Vimeo. It does sound like it would be a whack-a-mole game to try and detect these things in a generic way.
• Better descriptions and information in the block settings sidebar. Perhaps even consider moving the "Resize for smaller devices" button onto the selected video block itself rather then have it in the sidebar.

@gregsullivan question: does the embed look broken both in the frontend and in the editor? Or just the frontend? If it's in both places, the block toggle on the block itself might be a good UX change because you'd be able to toggle it on and off easily and see the effect instantly.

[gregsullivan]

@jasmussen The embed looks normal in the editor for all the videos I've tested, so it's purely a front-end problem for me.

On the one hand, I agree 100% with the whack-a-mole characterization. On the other hand, I'm curious whether services implementing oEmbed would tend to see the padding change causing the problem as breaking the spec, making the problem rarer.

[gregsullivan]

One further possibility: Is there a willingness to rewrite the CSS responsible for responsive embeds? I took a go at it and made a version that works for both styles of Vimeo output. If you think this is worth pursuing, I could test it across more embeds to ensure compatibility and then share it with you.

It requires some use of !important—let me know if that's a deal-breaker.

[jasmussen]

Better CSS is absolutely an option, and I would suggest that !important was created for use cases like this. Depending on the solution you have in mind I can't know for sure whether it'll work, but I'd be excited to see your solution! Thanks again.

[gregsullivan]

Sounds good! I'll update you when I have something further along to show you.

A related question: Are the embeds meant to support 9:16, 9:6 or both?

If 9:6, I think there's a typo here:

https://github.com/WordPress/gutenberg/blob/429558ad320c55e3e8b5236dfb6ce139fa3a7d25/packages/block-library/src/embed/style.scss#L25

If 9:16, I think this would need to be changed:

https://github.com/WordPress/gutenberg/blob/429558ad320c55e3e8b5236dfb6ce139fa3a7d25/packages/block-library/src/embed/style.scss#L66-L68

Based on the order, it looks like lines 66–68 should actually be:

&.wp-embed-aspect-9-16 .wp-block-embed__wrapper::before {
    padding-top: 177.77%; // 16 / 9 * 100
}

(All of the padding-top values are ascending until that one, and it would potentially make sense to support 16:9 in portrait orientation, so that's my guess as to what's meant to be happening.)

Sorry if this should be a separate issue! Let me know if you think it makes sense to do a pull request just for this.

[jasmussen]

It's very possible there's a typo there. And yes, feel free to open a ticket if you like, you can reference this one and CC me (@jasmussen) and I'll follow it along. I'm going in vacation now, though, so I may not be able to test your code, but I'll certainly be able to ping someone who can.

[gregsullivan]

Great, thanks! I went ahead and did a pull request for the aspect ratio typo: #16573

Enjoy your vacation!

[jessejoeyjames]

Hi @jasmussen @gregsullivan unfortunately my website seems to also have probems with white spacing.

I'm using Sydney theme along with Visual composer. Everything is up to date, but after the Gutenberg change I just can't seem to remove it.

The CSS code you provided, doesn't seem to work for me. Hope you can help me out:
https://www.jessejoeyjames.com/portfolio/

[gregsullivan]

@jessejoeyjames The CSS above is specific to WordPress's built-in block editor. You appear to be encountering a conflict between Visual Composer and FitVids.js. You'd have to figure out which plugin or theme is including the latter to resolve the conflict.

[jessejoeyjames]

@gregsullivan Thank you for replying so quickly. I have no idea how you found that out so quickly, but I searched for Fitvids in cobination with my SydneyTheme. And the theme indeed seems to be using Fitvids.js

Am I supposed to contact Sydney theme or can i simply remove fitvids myself?

EDIT:
Okay so i fixed it by adding this code to the customise CSS part on wordpress

.vce-yt-video-player-inner::before {
padding-top: 0 !important;
}

Please let me know if this is okay, I'm assumming there should be a proper fix. I'm only a very average coder with just basic php,css,html knowledge. But I just tested this out as a combination of @jasmussen 's code and the conflicting area you pointed out.

[gregsullivan]

@jessejoeyjames I'd suggest contacting your theme's developers and asking if there's a way to disable FitVids.js, either using a setting or a filter. Since you're going to continue using Visual Composer, it would be better to remove FitVids.js as one half of the doubled responsive embed styles. The theme's developers should be able to help, though—good luck!

[gregsullivan]

@jasmussen @notnownikki I have another (potentially final) update on this, as my sense is that this is even more of an edge case than I initially thought.

In order to test potential CSS fixes, I added a hook to oembed_fetch_url to force Vimeo to send responsive embeds if ?responsive was added as a query string to the Vimeo URL.

In doing so, I found that the preexisting checks below successfully prevent the embed from being flagged as responsive:

https://github.com/WordPress/gutenberg/blob/62439f083c5710ccc5a87187fa5c66a83c70b41f/packages/block-library/src/embed/util.js#L152-L168

(Vimeo's responsive embed removes the width and height from its iframe and instead gives a padding-top value to the wrapper div to create the desired aspect ratio.)

So in order for the double-responsive issue to occur in this case, the embed needs to change over time, outputting the responsive version after initially outputting the non-responsive version.

I did find that a minor revision to the embed CSS would solve the problem and work both for existing embeds and the responsive Vimeo embed, but I don't know that it warrants a pull request given that it's relatively difficult to trigger the issue. I suppose an argument in favour of the change would be that someone could add the responsive classes to a responsive Vimeo embed that initially loaded without them, and they would work without triggering double-responsiveness.

[TaisaDesigner]

Hi!
I am having this issue with Vimeo. With Youtube it seems like it doesn't add the space, but the preview shows up cropped oddly, and when I play the video, it shows at its original proportions, but into the shape that the preview had. So on my computer maybe I see a square and then a 16:9 video in. But on my mobile there is a 9:16 preview, and then a small 16:9 video in the middle.

Are there any news on this? I also reported to my theme (DIVI) the issue to see if they should do something.

I add some snapshots as example.

[flemmingss]

This problem still exist, I have an updated WP, and today 07.11.19 I have this issue on my site.
This is my forst youtube embed so i don't know how it worked before.
Anyway, removing the wp-embed-aspect-4-3 from code worked here also.

[jessebw]

I had the same problem, from the Youtube Free plugin. Youtube settings > defaults > Unselecting "responsive video sizing" fixed the issue. Its looks like it adds a fluid-width-video-wrapper with a huge amount of padding when ticked. (It might conflict with some theme or plugin styles applied elsewhere.)

[robwent]

Fitvids has an option to exclude certain css classes.
If you can edit the js without hacking anything (Or the theme/plugin using fitvids allows you to add options) then you can use the options to exclude Gutenberg embeds.
Mine looks like this now:

jQuery(".container").fitVids({
        ignore: '.wp-block-embed'
    });

If you remove it completely then videos embedded elsewhere may no longer be responsive.