-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Video: Add aspectRatio block support and utilties #67047
base: trunk
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,31 @@ | ||
/** | ||
* Internal dependencies | ||
*/ | ||
import { getInlineStyles } from './style'; | ||
|
||
// This utility is intended to assist where the serialization of the Dimensions | ||
// block support is being skipped for a block but the dimensions related CSS | ||
// styles still need to be generated so they can be applied to inner elements. | ||
|
||
/** | ||
* Provides the CSS class names and inline styles for a block's dimensions support | ||
* attributes. | ||
* | ||
* @param {Object} attributes Block attributes. | ||
* | ||
* @return {Object} Dimensions block support derived CSS classes & styles. | ||
*/ | ||
export function getDimensionsClassesAndStyles( attributes ) { | ||
const { style } = attributes; | ||
|
||
// Collect inline styles for dimensions. | ||
const dimensionsStyles = style?.dimensions || {}; | ||
const styleProp = getInlineStyles( { dimensions: dimensionsStyles } ); | ||
|
||
return { | ||
className: dimensionsStyles.aspectRatio | ||
? 'has-aspect-ratio' | ||
: undefined, | ||
style: styleProp, | ||
}; | ||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -5,6 +5,7 @@ import { | |
RichText, | ||
useBlockProps, | ||
__experimentalGetElementClassName, | ||
__experimentalGetDimensionsClassesAndStyles as getDimensionsClassesAndStyles, | ||
} from '@wordpress/block-editor'; | ||
|
||
/** | ||
|
@@ -25,6 +26,9 @@ export default function save( { attributes } ) { | |
playsInline, | ||
tracks, | ||
} = attributes; | ||
|
||
const dimensionsProps = getDimensionsClassesAndStyles( attributes ); | ||
|
||
return ( | ||
<figure { ...useBlockProps.save() }> | ||
{ src && ( | ||
|
@@ -37,6 +41,8 @@ export default function save( { attributes } ) { | |
preload={ preload !== 'metadata' ? preload : undefined } | ||
src={ src } | ||
playsInline={ playsInline } | ||
className={ dimensionsProps.className } | ||
style={ dimensionsProps.style } | ||
Comment on lines
+44
to
+45
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As long as users don't add There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm not sure I'm following this comment, sorry, @t-hamano. Isn't this code change explicitly about applying a user-selected aspect ratio on a block instance? |
||
> | ||
<Tracks tracks={ tracks } /> | ||
</video> | ||
|
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -4,6 +4,7 @@ | |
video { | ||
width: 100%; | ||
vertical-align: middle; | ||
object-fit: cover; | ||
} | ||
|
||
@supports (position: sticky) { | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm wondering whether we should use the
__experimental
prefix.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good question.
The only reason I see to use experimental here is to advertise to third parties that the public method is subject to change, and should not be relied upon long term.
Is that the case here?
The counter argument is that anything can and will change: should we add
__experimental*
to everything? 😄For my part, I don't see an obvious case for the experimental flag — it's possible folks have followed the naming pattern of other exported hooks in this file without considering it.
If third parties shouldn't be using this API then it could also be exported in the private APIs.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agreed 👍
I believe the other functions (maybe shadow excluded) were created before the private APIs approach solidified.
As part of other separate block support stabilization efforts, these utils are also on my radar to stabilize.