Size Change: +1.81 kB (0%)

Total Size: 1.17 MB

_{compressed-size-action}

There's a lot of options, but it actually feels pretty easy to use.

I took a stab at some new icons (you can find them in Figma), opting to use less of the rounded rects:

I wonder about the width and alignment options. I think maybe we could remove the Wide and Full options. I'd be nice to support a custom width similar to the Spacer block's height.

@shaunandrews Icons now updated, and I've added support for resizing the width.

Latest:

Marking this one as ready for review since all the editor and front end rendering is now working for button, label, and width options. I think separating color, border, and spacing settings into a separate PR makes sense?

• I added the Search block to a Navigation block and found that while I can reduces the width with the drag handle, I'm unable to increase the width.
• When I deselect the block, the drag handle (the dot thing) remains visible. In fact, I can't seem to find a way to get rid of it without a page refresh.
• I think there will need to be a minimum width, or it might be interesting to have it automatically switch to button-only when the width doesn't allow any other options.
• I know you've mostly been focused on the editor functionality, but I expected the button to look like a Buttons block — even though I know it doesn't really act like a separate block.

@shaunandrews The first three items should be fixed now. The minimum width is set at 220px.

For the button to inherit the styles of the theme, I'd need to include the class wp-block-button__link on the button. This isn't actually a button block, but it is a button, so I wonder if this is still okay?

I think the separators should be removed in the toolbar since these are all similar block level operations

The width control could probably also offer the percentages segmented control we use in images etc?

This is great!
The only thing that sort of bugs me is the fact that width is defined as a number, and forces the use of pixels... It would be preferable if users were able to pick the units they want - or even better be allowed to enter complex values in a plain text field so they can enter values like calc(100% - 10em). Otherwise, this is a great improvement!

The unit input component should already allow to change to any unit (em, rem, vw, %) though it doesn't support more complex calculations. Once theme.json is properly deployed, it should also allow declaring preferred default units for themes and such, so that things default to the right context.

@mtias The image block converts the percentage into a pixel value when selected. I would expect if I selected a percentage value for this block that it would be an actual percentage for width. In this case it probably makes sense to remove the pixel width value when a percentage is selected, or remove a percentage selection when the width is manually adjusted. Thoughts?

Or I suppose it could also change the unit input component to percentage.

I suppose it could also change the unit input component to percentage.

That was my first thought:

Yes :)

@shaunandrews What would the reset button do on your graphic above?

Rebased to fix merge conflicts. 👍

Pinging @afercia to check out and make sure all the variations here make sense, accessibility-wise.

Thanks for the ping.

I don't think WordPress should ever allow users to remove everything and produce an input field like the following one:

which has no visual label, no button, no placeholder text, nothing that can visually identify this input like a search input.

Instead, WordPress should make sure the content it produces is semantic and accessible. Giving so much power to users opens the door to potential abuse and I'm not sure this is okay.

More importantly, when removing the label I would expect the <label> element on the front end to be visually hidden (as it was the case before this change). Instead, it's now completely removed from the HTML. This is a serious regression and it's not acceptable because it produces an unlabelled element which will be announced by assistive technology only as "edit text". Form elements must always be labelled.

I'll propose the accessibility team to discuss this change in the next weekly meeting. For now, I'd like to point out that I'm a bit disappointed this PR and the related issues weren't marked with the Accessibility label nor anyone pinged the accessibility team for some quick feedback. When changing important parts of the UI and especially anything related fo form controls an accessibility audit should be required. Not sure this is the best way to improve collaboration between teams.

What is the expected behaviour when in "button only" mode?

@scruffian Good point - Chandrika and I wondered the same thing, when working on the User documentation for it. Added new issue #27329

The idea was to follow up with a full screen or slide out search option using the button only mode, but this hasn't been done yet. For scenarios like including a search icon in a navigation block.

@apeatling it felt like an artifact of a future idea. Maybe you can remove it for 5.6 and finish it after wards?