Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Adds basic dimension controls to Group Block #16730
Following multiple requests, this is being broken up into separate PRs.
Adds dimension controls to the Group Block via a new
Please note: this PR aims to implement the basic feature set for dimension controls. More complex UI will be added at a later date. For a more detailed explanation see this comment.
How has this been tested?
Manually for now.
Types of changes
New feature (non-breaking change which adds functionality)
Based on #13363 (comment)
Some design feedback:
@SchneiderSam Thanks for your opinion. I assume by "strange" you mean that it wasn't immediately clear to you why the arbitrary values had been selected over absolute units?
Imagine you are a Theme designer. You craft your CSS with spacing that is perfect for the design. You want to ensure that is consistent throughout your Theme, even if the page layout is being created by the end-user in the Block Editor.
With the approach I've taken here, when a size is selected only classes are added to the Block in the DOM. This affords the Theme creator the opportunity to provide custom sizes in CSS that are suitable for their Theme. If they opt not to do this then sensible defaults are provided.
With the pixels approach, we're locking users of the Block into absolute values and asking them to make a lot of decisions that they'd probably prefer not to have to make. It could also lead to an inconsistent visual experience.
I completely agree. This is why I've selected this approach for the first pass at adding this control. Average users (whoever they are!) will likely be grateful to receive a series of predefined options rather than having to make their own choices. I'm looking to cater to them first, which also serves to keep this PR simple and easily comprehensible, this increasing the changes it will be accepted and merged.
I take your point. As a power-user, you want precise control which this approach doesn't currently provide.
Please consider however, that at this point we're introducing a new feature with a totally new UI. As a result, I'm keen to avoid overcomplicating this PR or increasing its scope.
If this UI ships, in the future, I imagine we will want to enhance it with an "advanced" option which will afford power users the ability to
Ultimately, there's a lot of things we could look to do. However, for now, I'm hoping you will agree that keeping things simple and focus on the 90% of users will afford us the best opportunity of getting this PR merged. We can iterate from there.
Once again, I want to say how much I really appreciate you taking the time to provide feedback.
@drw158 Thanks for your feedback! All good stuff. I'll look at updating it tomorrow.
Note that there are tooltips for each option with the full text available.
I agree that
What about a No with a tooltip of None.
@drw158 I've fixed the below based on your feedback:
Here's a screenshot for reference:
Hi, I have some thoughts to share on this.
I agree predefined options are a good start and specifying absolute values as stated can be added as an advanced option later.
But I think the option to specify those predefined options for each "side" individually should also be there from the start.
A lot of themes have full-width sections where only padding on the top and bottom is needed.
And also sometimes different values are used on the top and bottom.
I would plus one this as it's getting huge. I also agree with the selection of sizes. Overall this feels a lot to take in visually and I think there should be a step back to consider what this would be like for someone coming to it. Are they going to understand all these settings? Are we using the right terms?
A prime example of how much this becomes is when you show all devices and this is what see on my 13 inch screen (I would have to scroll):
I was very confused by the following icon and it didn't seem to do anything.
Overall there is some key spacing to adjust and this demonstrates visually how this is all a lot:
@mtias Thanks for this. Much appreciated.
Yep, that makes sense. I'm starting to think this might be a good way to reduce the visual noise of the UI.
The main downside I can see is that it would require x2 clicks to toggle between different sizes. It is nice to be able to just click around and see the Block update in real time. The dropdown will mean a lot of clicks to experiment with different sizes.
On balance however, I suspect we'll end up going with the dropdown for the reasons you've stated.
@mtias Can I confirm you're recommending
@karmatosed I agree. As a non-designer, I'd definitely value and appreciate guidance from more visually talented folks.
I agree and this is the moment to do that. I've demonstrated one implementation based on @kjellr's visuals. I'd love to receive alternative suggestions and options.
It's certainly something to consider. I agree there is a lot to take in. However, having everything open is something of an advanced use case. Indeed, I'm not sure it is that terrible to see a lot of controls, especially as they are clearly labelled and divided up.
I also think it's preferable for controls to visible by default rather than (unnecessarily) hiding the responsive UI controls behind toggles/switches as some other Block frameworks do. I'd rather the "noise" than make the UI overly complex or unintuitive.
We could reduce the noise by adopting the dropdown/select approach that @mtias suggests. Please see my comments on that above.
Other than that, do you have any alternatives we could try to reduce the visual noise? Much appreciated.
I think you're looking at an out of date branch. Pull down the latest changes to see the updates.
You will see that - as per @drw158's comments - the reset UI is now clearly labelled and only active once a size is selected. I agree it was previously confusing
Also, happy to fine-tune the spacing and alignment once the core UI has been agreed. Based on previous experience, I'm sure you'll understand that I'm disinclined to commit time to fine-tuning UI that hasn't got general approval from the community. I agree this is important to get right however
Thanks for taking the time to feedback. It's much appreciated.
Whilst yes to interact would be advanced it was pretty easy and pretty much an expected interaction pattern got me to them all being open. In this case I am not sure it is clear how things are labelled and divided up, so that is absolutely something to work on.
I pulled a few hours ago but can do again.
@bharath Thanks for this. I understand why you bring it up. It's difficult to balance ideal functioning vs essential functionality. I feel we should be able to introduce this fairly easily in future PRs once the initial implementation is complete. Again, it's about not over-complicating the initial implementation (I say this as the person who has a PR with 19 files changed!
@mtias What say you to this?
Select based UI
Button Group based UI
Do you feel this is an improvement?