Try content only editable content fields with DataForm#73186
Try content only editable content fields with DataForm#73186andrewserong wants to merge 61 commits intotrunkfrom
Conversation
- Pass paneId to tools panel items so that reset works. - set shownByDefault consistently.
andrewserong
force-pushed
the
add/content-only-inspector-fields
branch
from
7a18611 to
5cb023e
Compare
|
Thanks for working on this, just took it for a quick spin and I'm still seeing the kebab menu, and the main difference seems to be that there's now a "Content" label before the input fields, is that correct? 
Just to add a little context, DataForm I see as becoming the singular component that replaces the document inspector, and many similar panels that are commonly "a sequence of controls". The purpose is more about reusing and refining that single component, than about the visuals, in fact I hope we can improve the visuals and the behavior of the DataForm perhaps in the 7.0 phase. It's already being used in the experimental QuickEdit panel, and showing both potential and shortcomings there. E.g. perhaps "slug" is a field you edit right there, inline, rather than in a flyout. But if we think of the DataForm as a single component that will be used in at least those three places—QuickEdit, post/page inspector, and in this contentOnly panel, what changes do we need to make to the DataForm to unify across those three? We will likely need some design work that considers this (CC @WordPress/gutenberg-design to put it on the radar), but we'll basically need to thread the needle between all those three. Not sure if that's helpful at this point, but just wanted to clarify that by employing DataForm the hope is we'll get some features like the flyouts for free, but also that we'll likely need to massage the DataForm component itself in the process. Which should be fine since, as far as I'm aware, only the QuickEdit experiment uses it so far. Notably it doesn't have the kebab menu. |
|
Isn't the idea that DataForm is agnostic of any specific context and usable for all forms? Panels like this one, the document Inspector, or the quick edit panel feel like a higher level abstraction to me. |
|
Oh, thank you for taking a look at this early experimental PR, folks! The goal with this PR was more from the code-quality side of things to see whether the existing design could be achieved with DataForm instead, which I believe we've managed to prove out now.
So yes, I mostly wanted to see if we could use DataForm as the underlying structure to achieve the current design, but it also means by ditching ToolsPanel we could achieve any different kind of design we like, too. I'll likely close out this PR as it was an early timeboxed experiment (with Claude) to see if it was possible to achieve, but it'll help inform doing it properly (tracked in #73261) |
|
Closing this one out for now, it'll be easier to create a fresh PR I reckon, now that #71730 has landed in trunk. |
|
I iterated a new design and shared it in #73466. It proposes using DataForm in a similar manner but in a different surface. |
5 participants
What?
Branched from #71730
Try out using DataForm in the editable content fields PR. This PR points to that PR's branch instead of trunk. This PR is largely a collaboration 😄 with Claude, so I haven't reviewed the code closely. Note that this PR currently duplicates controls a bit, and they need tidying. This is really a proof of concept right now, so my goal here is to gauge how this looks/feels before putting too much time in it.
It's really just to see how we might use DataForm with a header that resembles the ToolsPanel without actually using the ToolsPanel. I'm quite sure this PR is broken in many ways.
Why?
To see how we might work with DataForm even if we don't (yet) have field controls for things like Media, Link, and RichText.
How?
Testing Instructions
Take it for a spin with the content only experiment enabled and have a play around. I believe drilldown is broken.
Testing Instructions for Keyboard
Screenshots or screencast
2025-11-12.18.13.28.mp4