Extend complete styling support on core blocks #63050
Comments
|
I've updated my original comment to include a task list of all the missing functionality. |
|
I think easy wins to start would be the dimension & border controls as they pretty much can apply to any block. A lot of the other design tools like background image or layout are much more complex and don't really apply to everything |
|
I agree that a pragmatic approach is best; the way that the overall development of the blocks has been plans precludes a simpler approach in some cases. Can you expand on your comment, how some features “don’t apply”? |
|
The |
|
How about moving this proposal forward in #43241? There is also a linked sub-issue about individual block support. |
I agree, there are some which might not match with the requirements. I wanted to ensure that all of the specific tool are tracked, so it would be good for a second point-of-view for each control and its applicability for each block. I can then update the initial list. |
|
As mentioned in #43241: I imagine that a revised list would make sense once 6.6 drops. Does the task list belong here or there? I would imagine that having one issue per requirement would lead to them all receiving very little attention in the wider context. |
|
Thanks for kicking this off! Like you, I want to see both styling support completed and items moved out of experimental. For now, let's consolidate. My preference would be to close this issue out and instead update this prior one for continuity: #43241. Alongside the above, there's also work to stabilize typography supports which also helps this broader styling cause: #63001 |
Some blocks deliberately omit a particular block support, for example, the Audio or Post Featured Image blocks and the typography support. You'll find the design tooling tracking issues also indicate this via the 🚫 emoji. The legend on each issue will explain the other uses of emojis in their tables. I've not had a chance to give the proposed list here much of a look but it does appear to retread a lot of old ground. I'd suggest that the existing tracking issues be used as the source of truth and updated with any new blocks and supports e.g. align and shadow.
It's also worth noting that Layout support can't be as broadly adopted as this issue would suggest. A deliberate subset of blocks that were suitable candidates were identified on the Layout tracking issue. Any new blocks or candidates can be added there too.
+1 to closing this issue out in favour of the existing ones. |
|
+1 to the enthusiasm here and to consolidating with the existing tracking issue.
One thing to watch out for with task lists is ensuring that they're easy enough to update in an iterative way. My main concern with a comprehensive list as in this issue description is that it's many pages long, so could be hard to work with at a glance if someone goes to edit it. I'd recommend where possible using and/or updating the existing sub issues in #43241, in part because of:
It can sometimes be difficult to predict how and why a support might be hard to implement for a particular block. I.e. the block might have a particular markup structure or server-rendering that means it isn't very straightforward. So, it can be useful to contain the discussion to an issue that's related to that particular block support. Another approach if there is a particular sub-set of features that folks would like to work on, is to create a more granular task issue of just the particular bit of work you'd like to see land in time for a release. I've tried to do that with #63001 as it seems fairly self-contained while still advancing a set of changes that should hopefully make a positive impact. |
|
Closing in favour of #43241. |
|
Additional comment: an overview of the individual design tasks as they apply to specific core blocks are summarised in #43241 under the sub-heading Tracking Issues for Individual Block Supports. |
What problem does this address?
Based on https://make.wordpress.org/core/2024/06/20/roster-of-design-tools-per-block-wordpress-6-6-edition/, there are still many core blocks for which essential controls are missing. For example link (and state) colours on e.g. the archives block and navigation block, typography on login/logout, read more, navigation submenu, etc.
For this reason, extenders have to continue to use a notable amount of custom CSS, which both needs maintenance, and goes against the principle of being able to control as much as possible through the Styles Editor or theme.json.
What is your proposed solution?
Review the list of block supports in the above linked list and allow users and extenders access to the full range of controls on every block. There are hardly any where it makes sense to suppress options which some extenders and users find necessary.
Specifics
Align
Typography
Color
Dimension
Border
Layout
Gradient
Duotone
Shadow
Background image
PO/BB
(I'm unsure what this relates to: feedback welcome.)
The text was updated successfully, but these errors were encountered: