Gutenberg: Embeds: Different blocks/classes on different embed methods

[Luehrsen]

Issue Overview

While styling our themes I found an issue, where media can be embedded in two seperate ways to draw two differently marked up blocks.

This provides issues in the frontend for the class element, as theme devs can never be sure about the class a oembed element or the wp-block-element has. While this can be alleviated thanks to unqualified attribute selectors like [class^='wp-block-embed'], they are known to be a huge hit on performance, as they first match every element and then reduce town to the matched attribute. (see https://jsperf.com/id-vs-class-vs-tag-selectors/2)

Steps to Reproduce (for bugs)

1. Find an oEmbed source (e.g. https://www.youtube.com/watch?v=XOY3ZUO6P0k)
2. Paste the URL into a newly create default block (enter on the keyboard), the block should be replaced by a standard embed block
3. Add a new, specialized embed block according to the oEmbed source (for our purpose, youtube)
4. Check the frontend markup for both blocks, one should have wp-block-embed, the other one should have wp-block-embed-youtube as a class.
   

Expected Behavior

While the two approaches to embedding the media yield the same result, the resulting markup is not identical.

The ideal solution would be, that the block for embedded media provides a broad, but not bloated description of the media. A youtube block would ideally have the classes wp-block-embed embed-video embed-youtube.

That way theme developers can add proper styling to all wp-block-embed elements and not worry about anything. And if they choose to, they can style broad groups, like make videos proper responsive 16:9 and create special markup for special sources.

Screenshots / Video

https://youtu.be/YcJ6qUH1jvQ

[youknowriad]

The wp-block-embed-youtube class is automatically generated (similar to other blocks).

We could keep this className and add the wp-block-embed one to all embeds.

[Luehrsen]

Yes, but please note, that this is only half the issue.

To clarify: Currently the user can use two different ways to generate an embed-block. The way of just putting a youtube url into a new text-block will yield a ´core/embed´, using the inserter will yield a ´core-embed/youtube´.

The difference is, that the first method is more convenient, but will not add the appropriate classes/information to style the block appropriately (e.g. respect aspect ratio).

So the ideal behavior ´core/embed´ would be to analyse the oEmbed provider, check if there is a specialized block for that embed and switch to that block. Does that make sense?

[youknowriad]

Does that make sense?

yes, it does, thanks for clarifying. The problem is that we don't know the provider in the save function and can't fetch it remotely (it's synchronous). An option would be to save it as an attribute but I wonder if it's worth the complexity.

[Luehrsen]

From a theme builders perspective knowing whats inside an iframe is extremely valuable.

Just the ability to provide correct aspect ratio to video-embeds would be amazing.

[notnownikki]

The problem is that we don't know the provider in the save function and can't fetch it remotely (it's synchronous). An option would be to save it as an attribute but I wonder if it's worth the complexity.

I wonder if we could transform the block when the preview renders?

When we call doServerSideRender, we get back all the metadata from oEmbed, which includes provider_name, which has sensible things in it like "YouTube" and "Twitter".

If we were able to set a provider name on each embed block, these could be used to transform the block when we get the response back from the oEmbed API.

Does that sound realistic?

[Luehrsen]

@notnownikki That is exactly what we are doing in #4118

[notnownikki]

@Luehrsen I just saw the PR :) Maybe I'm missing something there (and I probably didn't explain my idea too well either), I see the provider name used, but I don't see the block getting transformed, and I don't see each block registering which provider it handles.

I'm mainly thinking about how this could be extended. If we make our Twitter block have extra, twitter specific options, and someone pastes a twitter url into the default "embed" block, we'd want that to become a twitter block. But perhaps that's beyond the scope of this, and worth a separate issue...

[Luehrsen]

Ah, now I understand what you are talking about. (The 'transform' was throwing me off, especially the gutenberg/react meaning of it).

Yeah, doing that would certainly be possible, but currently pointless, when all the embed-blocks are literally copies of the main embed block.

edit: But I would very much like to see a plugin being able to hook into this functionality and extend the options of a certain embed block. But would you consider that core territory?

[Luehrsen]

Has been implemented with #4118