-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Responsive blocks & intrinsic web design #34641
Comments
Although I love the idea of using responsive text and context aware development, I feel this should be handled by theme developers and not in core. My concerns are that this will be very opinionated and will likely result more debt that theme developers will need to unravel, remove, or override these styles on a regular basis in custom builds. This also assumes that the solutions provided will match a majority of visual design solutions, which I am not confident it will. I suggest leave responsive text and context aware development handling up to theme developers in core. If, however, we enable responsive text (or other context aware development), have it optional and easily removed by theme.json. Roadmap to leverage container queries (also by theme developers) as an additional holistic solution. |
I do think typography is a step too far for the core plugin, but intrinsic layout styles for stock blocks would be far better than the current ones since they will work in more contexts without theme authors needing to fight them. When doing custom theme development on projects with the block editor I've ended up disabling the stock editor styles entirely in order to replace them with intrinsic layouts. |
Gutenberg already crossed these thresholds - these things need to be there, and they should be extendable by theme developers and ready-to-go for end-users. Right now we still have all of the negatives you listed but none of the controls we need (and have in other platforms). |
The next step here should begin by having access to setting width on nested group blocks, so we can represent columns by a row + stacks. I'd love to explore min/max values for these width elements. |
And I also want to mention the |
I agree 100% that intrinsic design is the way forward...
Last year I did an experiment with intrinsic styles for columns... (#33330) |
@jasmussen I'm trying to assimilate some of the justifications here, and I believe I'm 95% on board with intrinsic design, but I can not help but notice that your original CodePen's have I see there is discussion in #44557 but nothing in progress. 🤔 |
Grid can come to the editor, but it wouldn't be the preriquisite for intrinsic behaviors, nor even the only implementation thereof. I would think the "allow wrapping" feature built into the Row block, as well as fluid typography, are two existing examples of this. The width behaviors linked in this thread (#45364) represent another. It's also worth reiterating, that intrinsic behaviors do not preclude queries, it can all coexist. One idea is for grid, when enabled, is to subsume content, wide, and full alignments. I've seen that working in a couple of older branches that explored it. But grid as applied across the whole editor (as opposed to just as part of a single block, such as how Row and Stack apply flex) comes with a couple of tradeoffs, including the breaking of margin collapsing. This isn't something we can't work with, the owl selector ( |
A new option for gallery block seems like a good fit since it would allow more carefully art-directed sets of photos. |
I totally forgot about this challenge and its implications in layout and how it could interact with the expectations of builders. Thanks for enlightening me.
Heard. 👍
Yeah, Row block is coming along nicely. 🤘 |
While I really like intrinsic design, I think it solves 99% of situations, making responsive controls useless. However, there are still 1% of situations where having different designs on mobile and desktop is necessary. Maybe classic responsive controls are not necessarily required, but I think that having the ability to show/hide elements based on viewport size is the bare minimum to achieve more complex designs. Here is an example: To achieve that, I had to use the plugin Responsive Block Control plugin and have two different product photos, one showing on mobile and one on desktop. In this issue I listed other use cases where responsive controls (at least show/hide based on viewport size is required): #50431 |
CSS Container Queries are finally here (well supported in all relevant browsers)! |
For the padding, you could use something like this:
That is actually something that should be avoided at all costs if possible... Mobile and desktop should always have the same options and experience. It's not just about user-experience, it's also about accessibility. Showing different elements depending on the viewport is the worst-case scenario. |
That's exactly the point.
I'm not saying that core needs to include any possible option out there, however, any WordPress pagebuilder and any pagebuilder platform supports some kind of responsive controls.
I build landing pages for clients who often want to add many details, assets, long paragraphs etc. |
@tomxygen absolutely, the intrinsic design principles are a useful lens to design the bulk of the features and layout tools in a sustainable way, but it doesn't capture everything you might want to do, like the ability to hide something on mobile or viceversa. The challenge is finding a way to introduce more specific responsive tools without drastically reducing the usability of the editor as a whole for the most common use cases. Most libraries that add breakpoint controls are adding them on per-property basis, which can easily result in people not knowing what is being applied or being overwhelmed by options. There are plugin tools like "block visibility" that can bridge some of those gaps until we have the space and bandwidth to do something in core that can be sustainable. For example, one idea that has been discussed a few times is allowing edits done while viewing "mobile" to be applied to that breakpoint alone. The amount of edits you can do would be naturally limited to things that are expressive (for example, removing a block could become "hide this block" when in that context). It could be an option to explore. |
I really like this idea and I think it deserves further exploration. |
Hey @mtias
Any chance you could link this discussion? |
Yes, this issue captures the essence of it: #19909. |
Thank you Matias. A native and iterative approach to responsive control in WordPress by OllieWP. As many of us agree that, while intrinsic design is cool and works very well, responsive controls are sometimes needed for more advanced styling.
Also, this is an interesting reading on Twitter. ![]() I think that a first exploration of this issue may greatly improve Gutenberg ad a pagebuilder/interface. |
Is there any effort to introduce responsive controls? Simple things as having text centred on small screens and left aligned on bigger screens is not possible at the moment. And that is just the tip of the iceberg, when you are working to a specific design for different screen sizes. |
I'll keep using Elementor or other software for page building, if Gutenberg doesn't offer Custom CSS per post (not just per block!). Also, yes, having to use third party plugins to gain responsive controls, is indeed annoying. |
In the Preliminary Road to 5.9 post, intrinsic web design principles are outlined as a potential path forward for providing basic responsive defaults to blocks:
To distill that a bit, a lavish pattern featuring multiple columns and complex layouts might look great if inserted in a sufficiently wide theme, but it might fall apart if inserted in contexts or layouts that are narrow. Media queries (#19909) that look only at the viewport width will fail to provide good fallback views for patterns inserted into columns. Even in cases where media queries would work as intended, it might add undue complexity for basic behaviors that feel like they should be built in:
If we look at what intrinsic tools we have available, notably things like CSS grid
autofit
andminmax
as well asclamp
based algorithms, we can get quite far. The following 3 column layout collapses to 1 column when the container (or the viewport) is <480px wide:Using
clamp
we can provide min/max values for font sizes:We can create columns that stack on their own as individual columns go below a certain minimum size:
The above examples can be tinkered with in this Codepen.
Ultimately the motivation isn’t necessarily to rid ourselves of media queries entirely, but rather to explore the question: how much can a single block pattern do to be responsive out of the box? A welcome side-effect, potentially, is a vastly simplified UI for editing. Media- or container-queries could be seen as a progressive enhancement on built-in intrinsic behaviors.
If we can refactor blocks to have intrinsic responsivness built-in, it's likely that we would need to evolve the design tools to accommodate some configuring of values:
These ideas need some visual exploration.
The text was updated successfully, but these errors were encountered: