FSE Program: The Media Experience and Its Future in WordPress – WP Tavern

Justin Tadlock
The FSE Outreach Program is back with another round of testing. Anne McCarthy asks for volunteers to test and provide feedback on media-related features in WordPress. Anyone is welcome to contribute, and feedback is open until February 23.
This round of the program includes two tasks. The first has users explore today’s media-related experience. The second asks what they would like to see in the future.
“Like last time, the focus of this exploration is to think with a more long term, ‘wishful thinking’ perspective in order to gather useful insights that will help inform the design of media related experiences going forward,” wrote McCarthy in the announcement.
As always, I dove right in with the hope that any discovery would make its way upstream to help mold the future experience.
I altered this task slightly. The call for testing asks that volunteers explore what is currently possible with the core media-related blocks. However, I work with these every day, so I know most of the ins and outs of the system.
Instead, I explored the WordPress photo directory — my favorite place on the internet right now — and see what new images have landed. I visit Pexels, Pixabay, and Unsplash far less often these days, and I am sure that I can do away with them altogether as the directory gets more CC0-licensed media.
I downloaded a picture of a giraffe by Marcus Burnette. Then, I attempted to add a couple of different Scotch-tape/Polaroid effects via custom block styles. The following is a screenshot of one of them:
I am happy that I went off-path in this stage of the exploration. I learned a lot about the inner workings of blocks in the editor and that styling the ::after pseudo-element is problematic. WordPress uses it to add a blue border around selected elements. So, I just wiped that out, at least for my custom styles. I am 100% sure that will come back to bite me at some point.
WordPress has come a long way in balancing the block-editing experience for users and allowing theme authors to style a WYSIWYG canvas. However, there will likely always be these edge cases where the two will be at odds.
Since I was already there tinkering around in the editor, I tested various combos of custom block styles and duotone filters:
It is hard to remember that there was a time when this was impossible in WordPress.
The second task of the exploration calls for volunteers to think about the long-term picture. What features do you want to see? How can the experience be improved?
Quickly moving up the ranks of my wish list is WordPress Photos integration. Now that the directory is nearing 1,000 images after less than two months into its soft launch, it is clear the community is backing the project. Finding images without ambiguous licensing terms goes hand in hand with WordPress’s vision of an open web. Users merely need easy access to them.
When laying out an idea for a theme design earlier this week, I realized how much I wanted to see more image filters. One of the patterns I was working on included a comic, watercolor-like background image. I grabbed a photo by Patrick Boehner — yes, once again, it was from WordPress photos. In a minute or so, I had imported it into GIMP and applied the “waterpixels” filter to it.
There was a distinct style I was going for with the design, but users cannot easily recreate it from within WordPress. It may be possible to implement this filter via a custom block style, and I may very well attempt it if this particular theme idea ever comes to fruition.
However, I would like to see a range of filters available to users. If this is too much for core, perhaps a standard filter-registration system for developers might be in order. This is just me thinking out loud at the moment. I do not know what that system would look like, but it is on my mind. I have little doubt that some user out there is thinking the same.
The addition of existing block design controls would also help. Implementing the border options across the range of media-related blocks is low-hanging fruit. Captions should be a dedicated block with a range of typography and color controls. Padding and background color options for the <figure> wrapper around images would allow users to “frame” their photos:
Outside of the previous ideas, there is at least one obvious wish-list item. I want to use my post’s featured image in any image-related block. I have long requested the ability to drop them inside of a Cover, for example.
There are less-obvious ideas too. It may be time that we rethink the concept of a featured “image.” In my previous life as a full-time theme designer, one of the scripts I had built and shaped over the years was a “media grabber.” Essentially, it allowed theme authors to get audio or video from the post content and display it in various places, such as alongside excerpts on the homepage.
There is no longer an easy way to use that PHP script in block-based HTML theme templates. It would require a third-party block plugin (none exist as far as I know) or a core feature.
Hey man, how to get the “tape” custom block image?
I’ll see about packaging that as a Gist or something when I get a chance. My CSS mostly uses custom properties, so I’d have to replace all those values for general use.
any news on this release on github? Thank you
I wrote a tutorial instead:
Building a “Scotch Tape” Image Block Style

I think it’s worth noting that even if the photo is CC0 licensed, users are still taking a risk by using the photo on their website if the photo was:
uploaded by someone else other than the copyright holder
contains an identifiable person who has not signed a model release
Was take on/of property that requires a property release.
Those are the filters I want to see added to WordPress Photos asap.
Unsplash also ran into this problem with some very high profile “misuses” due to these issues. I really hope WordPress Photos doesn’t make the same mistake.
Faces of people are not allowed, according to the guidelines. That should handle most cases for model releases, at least.
Ah! I did not see that. Awesome.
How are “custom properties” added to blocks? Can I add options that would be available in CSS but aren’t in the block’s styles?
Justin! Thanks as always for diving in and making each task your own. I sometimes loathe making these sorts of things so… specific. I much prefer folks get inspired and take the exploration in their own direction so thanks for doing just that.
Like you, I am loving seeing the WordPress photo directory grow. I submitted a photo right before writing this. I’m a long time Pexels user so, the second I can start filing feature requests, I plan to go wild sharing what I’d love to see in the long term.
Since you were playing around with duotone, I’d be curious to have your thoughts on this issue I opened in light of Paal’s feedback on the exploration: https://github.com/WordPress/gutenberg/issues/38556
However, I would like to see a range of filters available to users. If this is too much for core, perhaps a standard filter-registration system for developers might be in order.
I totally agree with your take of things there. For now, I’m going to highlight this in my recap summary post but not yet open an issue for it as a feature request.
Implementing the border options across the range of media-related blocks is low-hanging fruit. Captions should be a dedicated block with a range of typography and color controls. Padding and background color options for the wrapper around images would allow users to “frame” their photos:
To quickly connect some dots on these rapid fire items:
– Border options: https://github.com/WordPress/gutenberg/issues/21540
– Captions as an inner block: https://github.com/WordPress/gutenberg/pull/31823
For framing, can you say more about the intent there over using the border options? I want to be sure I understand the distinction.
I want to use my post’s featured image in any image-related block. I have long requested the ability to drop them inside of a Cover, for example.
Big yes. Right next to this top request (which is covered nicely in the rethinking featured images issue you link to) is the constraining featured images to a ratio: https://github.com/WordPress/gutenberg/issues/35524
Thanks for these interesting thoughts and neat examples. As a photo lover, it makes me excited to think about what could be possible just reading over your response!
Since you were playing around with duotone, I’d be curious to have your thoughts on this issue I opened in light of Paal’s feedback on the exploration: https://github.com/WordPress/gutenberg/issues/38556
The popover not persisting between actions has been the biggest annoyance with it. I think I’ve just learned to live with it, so it’s been something I’ve largely ignored.
I use top-toolbar mode, so the popover covering the image has been a non-issue for me.
For framing, can you say more about the intent there over using the border options? I want to be sure I understand the distinction.
Sure. Here’s a clearer example from a custom frame block style:
Photo with padding and white background and black border in the WP editor.
Notice the image wrapper has some padding and a white background, creating a sort of “border” of its own (sort of like a matte in a photo frame). Then, there’s the actual black border around the outside.
For users to create this, they would need to have options on the <figure> wrapper for border, background, and padding.
Compare the above to just a bordered image:
Photo with black border in the WP editor.
For users to create this, they would need to have an option on the <img> element for a border.
And, I’m not even getting into box-shadow and outline possibilities yet. 🙂 Right now, I’d be happy to get some extra stuff in to cut back on variations of custom block styles.
I like the FSE and all the new features coming to wordpress/gutenberg, but I can’t shake the feeling they are always focusing on the wrong, flashy thing.
What’s the point of having beautiful duo-tone images when you can’t properly make them responsive? What’s the point of a TEMPLATE EDITOR when you can’t have flexible/responsive containers?
It’s not a hate on this specific experiment, but the lack of discussion around basic stuff that will impact more complex blocks.
What’s your opnion about this?
On the topic of media/images, they are already responsive. At least that has been my experience. Have you hit a specific issue? Or, is there an enhancement that you’d like to see? If so, have you opened a ticket or does one already exist?
Container-type blocks are also responsive out of the box. However, the are not as flexible as they could be, and I know there are some open tickets to enhance the tools around those. Wide adoption of CSS container queries from all browsers would certainly help with this too. Again, it helps to talk about specifics, the varying methods used to accomplish those specific things, and what the best direction for core is. There is no shortage of discussion around this.
As for which feature should garner the most focus, everyone has a different opinion on that. But, in general, I wouldn’t put some features on hold because others are still in-progress.
I was talking about containers, like I said, no hate on the media or other updates. I also agree focus is subjective, but a IMO a template editor needs to be able to template well before doing flashy stuff. There are a ton of github issues around this but not really any progress. One quick example of basic design that is impossible right now: You have 6 items, in desktop you want 3 columns, tablet 2 columns and mobile 1 column. You would need to have two 3-column rows that would break to 2-1-2-1 rows in tablet media query and look tottaly broken.
I definitely agree that the Columns block needs some sort of controls for adapting to screen size. The layout you describe would require registering a custom block style at the moment if meant to be optional and not the default (just custom CSS for that). Not impossible for a developer to build, but users are out of luck if their theme author doesn’t add it in. Or, they have to find a third-party plugin.
I just disagree that all layout types need to be supported in a beta release or that related options need to be rushed. Make the wrong decision and you create legacy baggage that you’re supporting for years. It’s OK to let third-party developers extend the platform with a wider range of tools first. So many of WordPress’s greatest features were done years ahead of landing in core and were refined over and over.
On that note, I highly recommend the Layout Grid Block if you want tighter control over column-based layouts.
Enter your email address to subscribe to this blog and receive notifications of new posts by email.


WordPress Tavern is a website about all things WordPress. We cover news and events, write plugin and theme reviews, and talk about key issues within the WordPress ecosystem…
© All Rights Reserved. Powered by WordPress, hosted by Pressable

source

Registered for Cape Town Website Design Agency