Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use best fitting embed aspect ratio if exact match doesn't exist #10213

Merged
merged 3 commits into from Sep 29, 2018

Conversation

@notnownikki
Copy link
Member

@notnownikki notnownikki commented Sep 27, 2018

Description

This picks the best fit of the common aspect ratios if an exact fit does not appear in our list, for responsive content.

Fixes: #8383 (comment)

How has this been tested?

Embed https://www.youtube.com/watch?v=XT13ijUfSts and check it has the 16-9 style.

Embed https://www.youtube.com/watch?v=uAE6Il6OTcs and check it has the 4-3 style.

Embed https://vimeo.com/139290912 and check it has the 21-9 style.

Embed https://vimeo.com/139290912 again in the same post, and check the new embed has the 21-9 style.

Types of changes

Bug fix (non-breaking change which fixes an issue)

Checklist:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • My code has proper inline documentation.
@notnownikki notnownikki requested review from tofumatt and jasmussen Sep 27, 2018
@notnownikki notnownikki added this to the 4.0 milestone Sep 27, 2018
@jasmussen
Copy link
Contributor

@jasmussen jasmussen commented Sep 28, 2018

This is great! It works well. Twenty Seventeen front:

screen shot 2018-09-28 at 09 44 30

Backend:

screen shot 2018-09-28 at 09 44 37

However that above is after a reload. There seems to be an issue with the Vimeo video where the 2nd and 3rd time you embed it, it's not properly sized:

repeat embed

I did a little inspecting, and as it turns out, the 2nd and 3rd vimeo embed is correctly identified same as the first one. However the right classes are not applied. Compare, this is the body tag of the sandbox iframe for the first vimeo embed:

screen shot 2018-09-28 at 09 53 20

Now compare with the body tag of the same sandbox iframe for the 2nd and 3rd video embeds:

screen shot 2018-09-28 at 09 53 03

Note how the first one has all these CSS classes:

video wp-block-embed-vimeo wp-embed-aspect-21-9 wp-has-aspect-ratio

the 2nd and 3rd one only has this one:

wp-block-embed-vimeo

Note that if you save the post, then reload, evertything is fine, as you can see in the first screenshot. The missing classes happen only on the first edit. The important CSS class we need to have is wp-has-aspect-ratio.

Any idea why the classes go missing the first time but appear after a reload?

@notnownikki
Copy link
Member Author

@notnownikki notnownikki commented Sep 28, 2018

Any idea why the classes go missing the first time but appear after a reload?

That's really strange because this contains a fix specifically for that. I'll take a look again.

@jasmussen
Copy link
Contributor

@jasmussen jasmussen commented Sep 28, 2018

Uhm, let me also clear cache and try again.

@notnownikki
Copy link
Member Author

@notnownikki notnownikki commented Sep 28, 2018

Ugh, ok, so this does set the classes correctly, but it doesn't make it through to the edit's render. The front end published post is fine, but the edit has problems.

@jasmussen
Copy link
Contributor

@jasmussen jasmussen commented Sep 28, 2018

Okay I'm not insane.

It feels like we're 99% there, though ❤️

@notnownikki
Copy link
Member Author

@notnownikki notnownikki commented Sep 28, 2018

Yeah, it's just that there are a number of issues with React components and the type of data updating we do here. I'm considering a refactor to make the edit component very simple, and move most of the logic into the part where we select the data from the store. But, looking at this now.

@notnownikki
Copy link
Member Author

@notnownikki notnownikki commented Sep 28, 2018

Fix for the issue is in another PR, which currently has a conflict with master and so can't be reviewed and merged. I'll fix that PR, but there's nothing we can do in this one to fix the issue, it's to do with passing around attributes when the embed block changes type (which happens when you paste a URL) and there's a refactor in #10035 to fix that.

@jasmussen
Copy link
Contributor

@jasmussen jasmussen commented Sep 28, 2018

In that case I think this is definitely an improvement over we have, especially given how rare embedding the same thing twice is. Expanding for a quick code review.

@jasmussen jasmussen requested a review from WordPress/gutenberg-core Sep 28, 2018
@notnownikki
Copy link
Member Author

@notnownikki notnownikki commented Sep 28, 2018

The other PR will be fixed today and opened up for core review.

Copy link
Member

@tofumatt tofumatt left a comment

Code seems fine, just comments about the loop used and function names, but just ping me if my comments are unclear. If they make sense feel free to modify+merge 😄

more-red-than-green

There's talk of issues here but they're resolved in other PRs so if the UX here is better by @jasmussen I'm cool with the code.

packages/block-library/src/embed/index.js Outdated Show resolved Hide resolved
componentWillUnmount() {
// can't abort the fetch promise, so let it know we will unmount
this.unmounting = true;
receivePreview() {

This comment has been minimized.

@tofumatt

tofumatt Sep 28, 2018
Member

receivePreview seems a bit of an odd name for what it arguably rendering or changing attributes of the preview. I don't know what this.maybeSwitchBlock does because it's another weird maybe function name, but would this be better-named as this.updatePreview? 🤷‍♂️

That or maybe just use this.setAttributesFromPreview() in place of calling this.receivePreview() and add this. .maybeSwitchBlock() to the end of setAttributesFromPreview. Hope that makes sense!

This comment has been minimized.

@notnownikki

notnownikki Sep 29, 2018
Author Member

It's code we need to run whenever we receive a preview, and to keep things small and the functions easy to read, setAttributesFromPreview and maybeSwitchBlock are split. handleIncomingPreview perhaps?

maybe means that calling that method might do what it says, but the conditions are complex and there's no guarantee. The method is short and documented. You can find the maybe prefix in the parser, in the popover component, in the async-generator middleware, in the block list, and in the format toolbar. And in WordPress core PHP code.

This comment has been minimized.

@tofumatt

tofumatt Sep 29, 2018
Member

I know it's elsewhere, but it breaks my brain. I think I want to launch a campaign to improve it. As @aduth has said elsewhere (I'm paraphrasing): "Just because we do it less optimally elsewhere doesn't mean we should here." 😏

But yes, it's not isolated to this patch. I like handleIncomingPreview, that makes more sense to me. 🤷‍♂️

This comment has been minimized.

@notnownikki

notnownikki Sep 29, 2018
Author Member

I was under the (possibly wrong) impression that it was an established pattern, as it's in both WP core and G, with some of the usage in G being added as recently as last week.

I'll change receivePreview to handleIncomingPreview, that does make it clearer :)

@jasmussen
Copy link
Contributor

@jasmussen jasmussen commented Sep 28, 2018

It's a good step forward and since the final step is in progress separately, 👍👍

@aduth
Copy link
Member

@aduth aduth commented Sep 28, 2018

I'll defer to others more knowledgeable than I, but I don't necessarily agree with the premise of this pull request in assigning an aspect ratio to an element which is not in-fact of that ratio.

@jasmussen
Copy link
Contributor

@jasmussen jasmussen commented Sep 28, 2018

I'll defer to others more knowledgeable than I, but I don't necessarily agree with the premise of this pull request in assigning an aspect ratio to an element which is not in-fact of that ratio.

If we know for sure it's a video, then it needs SOME aspect ratio, all videos have them. If the video element behaved like an img, the height would be intrinsically applied.

We use this detected aspect ratio to apply a padding that's relatively easily calculated from the dimensions. So as an alternative to css classes we could apply this padding inline. But in the past, inline styles have caused headaches with themes, which is why we went this route.

Copy link
Member

@tofumatt tofumatt left a comment

Additional changes are good to me, thanks!

@notnownikki notnownikki merged commit 58fd2d1 into master Sep 29, 2018
2 checks passed
2 checks passed
codecov/project 48.57% (-0.24%) compared to 8300578
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@youknowriad youknowriad deleted the update/embed-better-aspect-support branch Sep 30, 2018
@mtias mtias added the [Block] Embed label Oct 9, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

5 participants
You can’t perform that action at this time.