-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Blocks: States #57719
Comments
Thanks for this exploration! I'm a big advocate for introducing "States" to the concept of blocks and like the visual direction laid out here. Something I'm unsure about is how the "viewport specific" styles fit into this from a UI perspective. Yes under the hood the method we use for storing these states may be the same. But I think it would be a better experience to tie the overrides for viewport specific settings to the actual viewport preview setting we already have. It doesn't seem to make much sense to me to change the spacing of a component for a mobile viewport if the component isn't previewed on mobile. Outside of the responsive pieces here I think it will be important for inner blocks / the block lists in general to also be aware of the state a block is in. For example the experimental form block is looking at failure / success states. The query block has no results found as a state etc. So incorparating that into the states functionailty I think will make a lot of sense |
This is very very fascinating and very important! As it can bring along so many new possibilites for creating the layout one wants. What about adding Properties states as a panel? EDIT. |
I personally would start with shipping Responsive Controls. That feature adds much more value to the editor than button states. |
I was just going to mention how important this is and how clearly this could solve a huge foundational solution for #19909 but @paaljoachim beat me to it. This concept along with work being done on inspector panel customization #33891, and the already available Seconded with @fabiankaegy that a way to filter the viewport sizes available to |
Also, let me add, I agree, approaching buttons first IS the right call. |
@mtias Can we have your buy in on this issue? This seems to be foundational for major design tools and could impact the collaboration phase as well. |
Throwing our voice in with the group saying that core/button is crying out for states. I'd also add that for responsive UI we shouldn't ignore container queries. Viewport/media queries should definitely be implemented, but I wonder whether container queries should come first? They seem the more powerful feature to me. |
@davidperezgar David It seems like an easy approach to use the correct device views to also become device editable states. |
Yes, it's the easiest way. I'd add to add the device in the context so the user could see that is for a device layout. |
That is more or less what is outlined in #19909, and it tries even to mitigate some of the challenges that come with that, such as forgetting that a particular block has has an override at a particular breakpoint, which is easy to forget. This is still an option, but a big UI challenge that's not as simple as it might seem. The benefit of using states is that it's block-first vs. breakpoint-first, which would work really well with container queries. That would not only allow us to free from the three preset mobile/tablet/desktop breakpoints and allow any custom container widths presets you could specify, but it would solve the issue where if you insert a pattern that comes with preset queries, it would smartly adapt to any context in which it's inserted. I.e. if you have a pattern meant to be shown in a full width column, which has viewport based media queries applied to it, and then insert that pattern in a 200px wide column, it's going to go splat. Whereas if that was container query based, it would work as intended. |
Continuing my line of thought... |
@jasmussen is states (without UI changes) something that could be added to WordPress soon? This would allow developers to build and extend blocks with it, or experiment with UI ideas. It would also be beneficial if core blocks used CSS variables more extensively, so states could simply set CSS variables to override styles. States really seems like the way to go for responsive explorations etc. |
I do think it can be a good UI affordance for things like animation and even container queries, yes. Whether near term or not is hard to say, sometimes issues that seem simple at a glance turn into rabbit holes when all the edge cases present themselves. I'd tend to think the way this issue can be furthered is to outline, perhaps in Figma prototypes, the most basic of all use cases we can think of, and then get some input from a developer. |
This is very nice, to see some progress on this important issue! I’d like to mention that @mikemcalister made some great and similar suggestions including some cool visuals. He is also using the existing device preview controls as a starting-point for handling state. This was in May 2023. Before I found this issue, I thought about how and where to start with something like state and I came to the same conclusion: The button block with its native states like :active, :focus, :hover or disabled, is the best block to start! |
For future iterations I would love to see state being usable to handle many things from Additionally I can think of state as kind of conditional for the post-template block as well. I would like to be able to define different sets of inner-blocks depending on a taxonomy or the post type of the currently queried object. This could also help to bring back post-formats, I hope. |
Related to hover/focus/current-menu item states, there's a new mockup here that's directly based on the work here. |
What problem are we solving?
Websites are becoming far more dynamic, motion filled and interactive partly due to the evolution of front-end libraries like React and frameworks like NextJS, and motion libraries like Framer Motion as well as the View Transitions API. To remain competitive, we should start thinking about how to empower Gutenberg users to build similar sorts of experiences without needing to code. The Interactivity API has given us a foundation to build upon.
When you think about motion and interactivity a common concept is transitioning from one state to another. For example, an image on your site going from opacity: 0 to opacitiy: 1. There are other needs that follow similar concepts, such as styling a button before hovering and a button after, or how a section displays on desktop vs mobile. Although the navigation overlay spawned this discussion, the “why” behind this work goes beyond a single need. We are attempting to solve multiple problems at once, which brings us on to the proposal.
What strategy does it align with / why is it worth solving?
This a broad initiative that aligns with attracting designers, developers and low/no-code audiences.
What does the solution look like?
This proposal introduces the idea of “states” or “variants” as they known in other design tools like Figma. The idea is that any block, including synced patterns, can define
properties
. Combining property values createstates
. Eachstate
is able to modify its style or contents. To transition between states, you attach abehaviour
to either the block itself or one of its children. A behaviour consists of atrigger
(e.g. “click block”) and anaction
(e.g. “set property a to xyz”). When transitioning between states we can optionally smartly animate between them (e.g. via view transitions API).Animation
animate.mp4
The use of states go beyond interactivity though and could also be a mechanism for providing responsive behaviour per block. Consider a group that has an inner Row block. It has a “Viewport” property by default that emulates a behaviour of “when screen size is < 480 set viewport property to mobile” . We change to the “mobile” property and update the Row to a Stack.
Responsive
responsive.mp4
Button state styling
button.mp4
Navigation overlay
navigation.mp4
Blocks like the navigation overlay can wrap this experience into something a little more user friendly (or hide properties completely)
Use Cases
This creates a level of flexibility that can be used to solve many needs. A few examples:
What's the first thing we ship? (if larger than one release)
To begin to establish the idea of “states”, let’s first look at the button block and its hover, focused, pressed etc states. It may not require the interactivity API but we will be introducing the UX of managing states.
We can follow that up responsive controls and transitions between states (interactivity)
Tasks
I’d like to discuss what pieces of the puzzle are required to unlock this idea. For example, we need interactivity API and possibly the idea of behaviours. What else?
Previous discussion
https://github.com/WordPress/gutenberg/discussions/38108
https://github.com/WordPress/gutenberg/pull/44214#issuecomment-1637762117
The text was updated successfully, but these errors were encountered: