Closed mtias closed 2 years ago
Sharing some thoughts on the current status for infrastructure/ my interpretation of some infrastructure tasks:
Create the concept of implicit attributes for appearance pairing
It seems the style attribute we are using for colors introduced in https://github.com/WordPress/gutenberg/pull/21021 addressed this part we are also using it for lineHeight with success and without the need to register new attributes.
Hook appearance variables to the editor rendering.
It seems this is about making sure styles are regenerated when the structure that holds global style changes. For example, https://github.com/WordPress/gutenberg/pull/20530/ accomplishes this by compiling the styles on GlobalStylesProvider.
Look at style variations as packages of style attribute sets.
We can achieve this by adding a styles structure to theme.json:
{
...
styles: {
‘core/paragraph’: {
‘huge’: {
fontSize: 14,
}
}
}
}
We may also achieve the "Custom User Styles" part of https://github.com/WordPress/gutenberg/issues/7551 by just allowing the user to save the current block style attributes as a customization of the theme.json structure.
At this week's Block-based Themes meeting, the group discussed some of the upcoming design tools in this ticket, and whether they should be opt-in or opt-out for themes. Here are our notes:
theme.json
, it seems ok to have all new design tools be opt-out. add_theme_support()
for them. More details in the meeting notes.
With the first beta version of WordPress 5.7 not very far away I'm sharing this summary after some discussion with @nosolosw specifying what are the tasks we think should be part of v1 and/or that may be part of v1.
These are the tasks we will work on and plan to have ready soon. Are the most prioritary tasks.
Versioning. https://github.com/WordPress/gutenberg/issues/27230
Child theme support. https://github.com/WordPress/gutenberg/issues/25612
(In progress) Padding support on global styles. https://github.com/WordPress/gutenberg/pull/27154
(In progress) Refactor our code and merge it into the core. A PR that started the refactoring https://github.com/WordPress/gutenberg/pull/26803.
(In progress) Improve the way client-side metadata is structured, make sure it matches server metadata shape, and try to avoid metadata duplication. https://github.com/WordPress/gutenberg/issues/25138
Update KSES to accept our link color styles. https://github.com/WordPress/gutenberg/issues/25151 Revive: https://github.com/WordPress/gutenberg/pull/25411
(In progress) Expose a structure in the core that wp-cli can use to know what theme.json strings are translatable. https://github.com/wp-cli/i18n-command/issues/224
Discuss mobile support #24165 and have some double-checking if the current theme.json functionality can work well on mobile.
Tasks we can work on, it would be nice to have but are not a must and are lower priority may or may not be part of v1.
Not part of a first version. Things we may consider in the future.
Nested styles for semantic contexts. For example, apply a specific base font size for things inside a sidebar. https://github.com/WordPress/gutenberg/issues/27233
Allow CSS properties that we don't manage at the moment. E.g: apply a specific CSS property like textShadow. https://github.com/WordPress/gutenberg/issues/27231
Look into the alignment issues https://github.com/WordPress/gutenberg/issues/26633
Responsive styles/media queries (styles depending on window size). https://github.com/WordPress/gutenberg/issues/20244
The first beta of WordPress 5.7 goes out in January, so we need to have a v1 for the UI ready sometime before the first beta.
Typography tools are going to be g2 based (or at least some parts like font size control). So we need to merge (at least parts of) g2 in order to have the typography tools ready.
Extensibility mechanism for 3rd party
It seems the global styles although functional does not provide a good experience, panels inside panels, a gigantic list of panels (one per each block). What is the plan for the other parts of UI? What are the things we should improve on the UI of these other parts to make them ready for the first version?
Navigation between all the different blocks that we can apply global styles to and between the global context.
Color options (text, background, and link).
Color palette editor.
cc: @nosolosw, @shaunandrews, @jasmussen, @ItsJonQ, @mcsf, @youknowriad
Thanks for the summary @jorgefilipecosta here's the questions/feedback I have:
(In progress) Improve the way client-side metadata is structured, make sure it matches server metadata shape, and try to avoid metadata duplication.
Shooting for consistency between client and server consistency is not always good thing. It's better to think of client packages as their own unit in isolation. Sometimes the config that the server has does make sense in the context of a package, sometimes it doesn't. Semantics > consistency. Just something to keep in mind while designing the APIs of the client.
Look into the alignment issues #26633
this is also something I've been thinking of, It's not clear whether I'll have the time to look deeper into it but keep me on the loop. My idea is to first make InnerBlocks provide an API to define the alignments and output the CSS for it without relying on themes to provide that CSS. Once we have that, adding support for this into theme.json is easy.
Responsive styles/media queries (styles depending on window size).
Same here, I wonder if we should start at the block level IMO and see what makes sense as a "style" attribute, and what make sense as UI and expand to theme.json
Are the APIs we offer themes enough to have control about which UI components are surfaced to the user in the global styles sidebar? OR should we expand our API’s? Should our API's allow to specify that the user can change a given style property like line-height at the global styles level, but not at the block level (block inspector).
I still feel this is the missing piece in terms of features.
I see the current "global" config as a way to define a config for all blocks but not as a way to define what UI is available in the global styles panel.
Thank you @jorgefilipecosta, that comment offers a great overview and sums up pretty nicely where we're going. :heart: Are all items in separate issues already? The comment will be lost in all the noise, so should we create issues for any items on that list (or maybe just tag existing issues properly so they're easier to find)?
I second @aristath comment. It would also be great to see them in the FSE project so it's easy to track things visually. And make liberal use of tags, so people can work on priorities. Thanks!
Hi @youknowriad, Regarding alignment issues and responsive styles, I agree with you. These things should be solved at the block level without touching global style mechanics, at least initially. I moved them to a new section, called "Related tasks but that initially will not use theme.json/global styles mechanisms.".
I see the current "global" config as a way to define a config for all blocks but not as a way to define what UI is available in the global styles panel.
Currently, the global config is a way to define what UI is available at the global styles panel. The other blocks inherit it if they don't have a specific config for them.
Basically, before global styles, one could not have control if a feature is enabled or disabled in a specific block. Our API changed that. With our new API, one can also specify if things in a particular block (or even in blocks with specific attributes) are available or not and overwrite what was defined globally. Our API just added block-level controls, but we don't have things like selectors that select multiple blocks, etc., ways to disable inheritance, etc. Themes always need to select each block individually.
How do I enable colors everywhere but only allow changing the main one in the Global styles UI
We don't the concept of "main color". The user can edit, text color, background color, and link color, at the global level and at the level of blocks that support these colors. One can't enable text color but disable background color. All the colors are either enabled or disabled. Besides that, the user can change the color presets, and if there is a color like "primary" used in multiple places, the user changing the preset will change the color in multiple places. It is not possible to say only this preset is editable. Do you think we should change some of these in the first version?
How do I disable line-height choices in all blocks but allow it at the global level.
The current API does not offer a way to select all the blocks. Achieving this would require to enable line-height at the global level, and then explicitly disable it for all the block contexts. I guess it could be done using a PHP filter that loops through all the selectors and injects the setting to disable line-height keeping it enabled for the global context, which is not ideal. I see two options to achieve:
None of these options seem good. Do you have a different idea in mind?
There is a tradeoff between supporting more use cases and making theme.json structure and the engine implementing these rules more complex. I think in a declarative approach, there will always be things that will not be possible to achieve and we should draw a line. I guess we need to decide between what we allow and what we don't allow, and make any required engine updates as soon as possible.
Do you think there is a simple theme.json change we can make that would allow the use cases you referred? Are there other use cases besides the ones you already referred that you think should be possible?
Thank you a lot for looking into this and sharing your insights/questions!
Hi @aristath, @francescamarano, Thank you for your comments! To make things easier to navigate, I updated the comment linking to the issues/PR's and also added more prioritary issues to the Full Site Editing board.
Currently, the global config is a way to define what UI is available at the global styles panel. The other blocks inherit it if they don't have a specific config for them.
And I'm saying it shouldn't be the case, we should have two distinct things (both in theme.json):
(maybe a "global"l key and a "UI" or "*" and "global" or something like that)
These things should be different. Once they are, the use-cases I shared will be solved.
When I was referring to "main" color, for me this was just a custom CSS variable editable on the global styles UI and that you can use as a value of of the palette colors or not, you can also just use it to style some blocks in theme.json directly. (provide default values)
Just chiming in to say https://wordpress.org/plugins/kt-tinymce-color-grid/ is an excellent plugin that works for Classic, Block, and Customizer. It adds CSS variables with the name you choose for each color (e.g. brand-main, brand-secondary, brand-accent, sheepish-white, creamy-gray, deep taupe), and it has import/export functionality.
I hope it can inspire.
Hi @youknowriad, thank you for clarifying your thoughts.
And I'm saying it shouldn't be the case, we should have two distinct things (both in theme.json):
A way to disable and enable things for all blocks (without explicitly listing the blocks) And a way to enable/disable things on the global panel UI (maybe a "global"l key and a "UI" or "*" and "global" or something like that)
I guess we can accomplish these requirements in two possible ways:
Two selectors a "" selector that is inherited by every context (including the global one). Equivalent to our current "global". A global context that just affects the global panel and is not inherited. There is no explicit inheritance of styles so styles would still be defined on "global". "" Selector would just support settings which is the only place where we are inhering things right now.
Keeping everything as it is, but add a new special settings only context called "global-panel". This panel just affects global context settings without any inheritance. On the global context, if this context contains settings it overwrites what was defined in global.
Do you think these solutions are acceptable? Do you have any preferences? Also cc: @nosolosw, in case you have some thoughts.
When I was referring to "main" color, for me this was just a custom CSS variable editable on the global styles UI and that you can use as a value of of the palette colors or not, you can also just use it to style some blocks in theme.json directly. (provide default values).
Well, one can edit presets, they are variables. One can have a preset called the main color. Editing that preset would be equivalent to edit a variable used all around the site. But besides the color presets, and, the link color (which is also a CSS variable), there are no plans as part of Global Styles V1 to have a mechanism that allows someone to expose a UI in the global styles panel that allows controlling the value of a CSS variable. Do you think need to have for V1 something that allows controlling custom CSS variables (besides color presets and link color)?
Just chiming in to say wordpress.org/plugins/kt-tinymce-color-grid is an excellent plugin that works for Classic, Block, and Customizer. It adds CSS variables with the name you choose for each color (e.g. brand-main, brand-secondary, brand-accent, sheepish-white, creamy-gray, deep taupe), and it has import/export functionality.
Hi @cliffordp,
Thank you for bringing this plugin to our attention. It has considerable usage, which means users really want the power of changing color palettes and things like that, so it reinforces that we are working on something relevant. It is also a good test case to make sure what we are doing is back-compatible and does not breaks plugins. E.g: that plugin should still work and the colors users apply with it should still be applied on global styles (unless the user then changes the colors on global styles).
Do you think these solutions are acceptable? Do you have any preferences? Also cc: @nosolosw, in case you have some thoughts.
Yes, I think this is good. I'd love more thoughts on my intuition here though, especially from theme authors, let's not rush implementation.
Do you think need to have for V1 something that allows controlling custom CSS variables (besides color presets and link color)?
Same here, I do think it's a valuable addition especially since you can use this value in different places in theme.json. But I agree it may not be important for V1.
@youknowriad @jorgefilipecosta I've taken your comments here, created an issue to discuss this separately, and added my own thoughts as well. See https://github.com/WordPress/gutenberg/issues/27295
It is time for another update on Global Styles :)
We got some traction on the i18n of theme.json: https://github.com/WordPress/gutenberg/pull/27380 We hope to merge this PR soon. And that should conclude the i18n work of theme.json on the Gutenberg side. It still needs work on wp-cli side to extract the strings. Now we expose a structure that can be consumed.
We also have some updates on the client-side metadata: https://github.com/WordPress/gutenberg/pull/27453 is ready for review. https://github.com/WordPress/gutenberg/pull/27449 was merged. When we merge the remaining PR, that part of the work for v1 is done.
Regarding child theme support, that work was put on on pause as @nosolosw referred:
I've seen there's rapid movement in the FSE/templates area and I believe when that's more settled I can resume this work.
Regarding the question we had on the last update:
Are the APIs we offer themes enough to have control about which UI components are surfaced to the user in the global styles sidebar? OR should we expand our API’s? Should our API's allow to specify that the user can change a given style property like line-height at the global styles level, but not at the block level (block inspector).
There were some discussions on this issue, and an issue for it was created https://github.com/WordPress/gutenberg/issues/27295. Solving this challenge and updating the theme.json shape for this is the biggest priority we have right now. If you have insights for this discussion, please share them on the issue.
The big question we had on the last update was the UI/UX, and on that front, there are important updates. The first version should implement the prototype that is available at https://g2-components.xyz/iframe.html?id=examples-wip-globalstylessidebar--default&viewMode=story#. It will involve enhancing many of the current components we have to offer that UI. The issue to track this UI update is available at https://github.com/WordPress/gutenberg/issues/27473. And the part related to the specific components is available at https://github.com/WordPress/gutenberg/issues/27331. After this update, there are several small enhancements we can make to make the user experience better:
Given that we already have considerable progress on the infrastructure part, the UI is considered a high priority. We will give a bigger focus to the UI work. The only two things considered higher priority are the i18n work and the issue https://github.com/WordPress/gutenberg/issues/27295 already referred.
:wave: Here's the current status for this task.
Latest changes:
What's next?
Expect some issue triage in the coming days, as well as updates to this issue description.
For the people following this task's updates: the issue description has been updated and there's now a third iteration that includes an initial set of tasks to be developed for April's MVP. All the rest has been moved to the backlog or is done.
Update on this: the core feature we wanted for block supports (see https://github.com/WordPress/gutenberg/issues/28913) to be able to absorb more use cases is now working on the buttons block (color hook). There're some loose ends I plan to keep working on in the coming days. There are also more hooks and blocks to support and I listed them as individual tasks on 28913, in case anyone finds time to help with them).
Added two ongoing tasks for internationalization in the issue description. I'm looking at https://github.com/WordPress/gutenberg/issues/28163 these days to see what's left / what needs to be done for 5.8.
Update for this week's core-editor meeting:
Block supports: landed the first implementation that doesn't serialize the block attributes. The overview task lists other properties we should migrate and potential blocks https://github.com/WordPress/gutenberg/issues/28913 This is a good place to start looking at for anyone interested in helping with global styles.
Internationalization. There's going to be some work in the translation areas for theme.json & block supports in the next weeks (@gziolo). See https://github.com/WordPress/gutenberg/pull/28783 and https://github.com/WordPress/gutenberg/pull/29155
theme.json. I'm going to resume work on some of the things we wanted to do for theme.json in the next few days https://github.com/WordPress/gutenberg/issues/28163
There're some changes coming to the theme.json format as per https://github.com/WordPress/gutenberg/issues/29891 I'll update this issue's description and the affected tasks in the next few days.
Update for this week core-editor chat:
This issue description has been updated to focus on the infrastructure parts of global styles, that we aim to ship in 5.8. The UI tasks have been moved to the backlog for clarity but will be re-evaluated at a later point.
This week in global styles:
Ongoing/Next tasks necessary for MVP:
And more:
Just added https://github.com/WordPress/gutenberg/issues/30191 to the list as well (under the theme.json group).
This week's status report: ongoing work for the major tasks necessary for the MVP.
This week's status report:
Shipped
Block Supports: added a gutenberg_block_has_support
helper function and support for padding in dynamic blocks 30322, border for search block https://github.com/WordPress/gutenberg/pull/30227
Fixes: title in the save panel of the site editor 30521, fix for themes without theme.json support but with experimental link color support 30452
Ongoing
Block supports:
Theme.json
This week in global styles:
Landed
Parts of theme.json with elements https://github.com/WordPress/gutenberg/issues/29891
block supports
Ongoing
theme.json with elements https://github.com/WordPress/gutenberg/issues/29891
block supports: add new style properties: border-color, border-styles, border-width https://github.com/WordPress/gutenberg/pull/30124
This week in global styles:
Landed
theme.json with elements https://github.com/WordPress/gutenberg/issues/29891
Block Supports & theme.json properties:
Bugfixes, code quality
Ongoing
theme.json with elements https://github.com/WordPress/gutenberg/issues/29891
Block Supports:
Bugfixes:
Priorities
The priority continues to be shipping https://github.com/WordPress/gutenberg/issues/29891 as soon as possible to unblock related work.
https://github.com/WordPress/gutenberg/issues/28913 is a good issue to look at if you can lend a hand (help with reviews, migrate more blocks, more properties, etc).
Weekly status report for core-editor meeting.
Shipped this week
theme.json
block.json / block supports
Internationalization
KSES
Site editor:
Ongoing
theme.json
block.json / block supports
New style properties
Misc
Priorities
The priority continues to be shipping https://github.com/WordPress/gutenberg/issues/29891 as soon as possible to unblock related work.
https://github.com/WordPress/gutenberg/issues/28913 is a good issue to look at if you can lend a hand (help with reviews, migrate more blocks, more properties, etc).
Status report for core-editor meeting.
Shipped this week:
block.json / block supports:
theme.json
body
selector instead of :root
https://github.com/WordPress/gutenberg/pull/31302Extensibility:
block_editor_settings_all
filter https://github.com/WordPress/gutenberg/pull/31027Site editor:
Ongoing:
block.json / block supports:
theme.json
Priorities
After having landed https://github.com/WordPress/gutenberg/issues/29891 via https://github.com/WordPress/gutenberg/pull/30541 the priority is to tie up the loose ends before preparing the core patch for 5.8.
Worth highlighting is that there're two new issues to switching away from CSS Custom Properties for link https://github.com/WordPress/gutenberg/issues/31488 and font-family https://github.com/WordPress/gutenberg/issues/31489 (see rationale in each issue).
This week report for core-editor.
Shipped this week
block supports
useEditorFeature
to useSetting
https://github.com/WordPress/gutenberg/pull/31587theme.json
experimental-theme.json
to theme.json
https://github.com/WordPress/gutenberg/pull/29981site editor:
Ongoing
block supports:
theme.json
Priorities
Start the merge process for theme.json APIs.
Status report (core-editor):
This week's focus was on getting things ready for Gutenberg 10.7 (landed most of the things we needed, there are a couple in flight) and start the merge process in core (got an initial PR for this).
Shipped this week
block supports:
settings:
Ongoing
block supports:
theme.json
core merge
Priorities
Merge process for theme.json APIS in core.
Status Report (core-editor meeting).
Global Styles and Global Settings have been ported to WordPress core and will be part of the WordPress 5.8 release. The focus now is on polishing and fixing bugs as we find them. The issue description & tasks have been triaged and there're two new sections: "bugfixes" and "docs" with tasks to be worked on in the upcoming weeks.
Now that the 1.0 version of this feature has been shipped and we need to revisit focuses, I thought it'd be a good time to pause these reports while we figure out the next steps. Anything relevant should still be posted here but on an on-demand basis not weekly.
Supported settings & styles that landed core
There's a task above to update this in the docs but wanted to share what we have now.
theme.json
support.color.custom
, color.customGradient
, typography.customFontSize
, typography.dropCap
. Settings that are disabled by default are spacing.customMargin
, spacing.customPadding
, typography.lineHeight
. Units can be filtered.add_theme_support('experimental-link-color')
. It seems that we can keep it in the plugin and remove it when the minimum WordPress version is 5.8.Shipped this week
Port to core:
Block Supports:
theme.json
Misc:
We're shipping a first version of the GS interface in 5.9, so it looks like this issue could be closed. Both for having a sense of progress but also because the activity has already moved to other smaller and more focused issues (designer tools, site editor improvements, framework changes, etc).
I've created https://github.com/WordPress/gutenberg/issues/37550 to track some gaps we still have from the original vision of styles at the framework level.
Really wonderful work and progress here!
This is an overview of the concrete tasks needed to proceed with the project scope of https://github.com/WordPress/gutenberg/issues/9534 (see also https://github.com/WordPress/gutenberg/issues/19611). It operates on three levels, or style origins: local blocks, theme defaults, and global modifications.
First 🌊
Goal: prototype a system that connects the three style origins and demonstrates how it works for a few top-level blocks.
### Infrastructure _Ensure at all times the editor reflects the front faithfully._ - [x] Create the concept of implicit style attributes to control the appearance of the block. #15450 #21021 - [x] Centralize style mappings https://github.com/WordPress/gutenberg/issues/25051 - [x] Migrate existing attributes (`font-size`, `color`) and introduce missing properties (`line-height`, `family`). #22700 - [x] font-size: paragraph (#21153), heading (#21431) - [x] line-height: paragraph (#20775), heading (#21215) - [x] color: paragraph (#21037), heading (#21039) - [x] set colors individually https://github.com/WordPress/gutenberg/issues/24927 - [x] weight https://github.com/WordPress/gutenberg/pull/24978 - [x] family https://github.com/WordPress/gutenberg/issues/23204 - [x] Evolve a `theme.json` specification for controlling the editor and the style attributes of different origins. #22518 #20588 - [x] Merge the different style origins (block, theme, user). #20047 #20290 - [x] Generate front-end styles using the new system. #19883 - [x] Generate editor styles using the new system. #22520 ### Interface _These are the different tools that interact with appearance values._ - [x] Expose global styles tool in `edit-site`. This should be a straightforward rendering of a sidebar in the site editor displaying the global values and palette. #24250 - [x] Allow users to modify some style attributes in the global styles panel. #20367 - [x] colors: link colors (link, hover / focus, active) #21032 - [x] typography: font families, font size, line height. #21030 #21028 #20773 - [x] reset modifications to theme defaults. #20868 - [x] Develop interface components to operate with new attributes. Prior art in font sizes and color panel. #20367 - [x] line-height to Paragraph and Heading inspectors. #20339Second 🌊
Goal: develop all necessary sub-systems.
### Infrastructure - [x] Stabilize: - [x] (one pr remaining to merge) Client: review there's no duplication and improve the way metadata is structured. - [x] Server-client metadata: do not send data we already have https://github.com/WordPress/gutenberg/issues/26802 - [x] Server: consolidate theme.json entity https://github.com/WordPress/gutenberg/issues/26802 - [x] Server: consolidate theme.json processor https://github.com/WordPress/gutenberg/pull/27237 - [x] ~Prepare a core patch for 5.7 (closed)~ https://github.com/WordPress/gutenberg/issues/27506 - [x] theme.json - [x] Consolidate dynamic selectors (selectors for blocks that represent multiple HTML elements, such as heading or list). https://github.com/WordPress/gutenberg/pull/24423 https://github.com/WordPress/gutenberg/pull/26945 - [x] ~Control design tools visibility (superseded)~ https://github.com/WordPress/gutenberg/issues/27295 - [x] Make settings & styles top-level keys https://github.com/WordPress/gutenberg/issues/28163 - [x] Split `global` selector into `defaults` and `root` https://github.com/WordPress/gutenberg/pull/28533 /24165. - [x] Style properties - [x] font-style https://github.com/WordPress/gutenberg/pull/26444 https://github.com/WordPress/gutenberg/pull/26844 - [x] font-weight https://github.com/WordPress/gutenberg/pull/26444 https://github.com/WordPress/gutenberg/pull/26844 - [x] text-decoration https://github.com/WordPress/gutenberg/pull/26059 - [x] text-transform https://github.com/WordPress/gutenberg/pull/26060 - [x] Padding (global UI + theme.json) https://github.com/WordPress/gutenberg/pull/27099 https://github.com/WordPress/gutenberg/pull/27154 - [x] border-radius https://github.com/WordPress/gutenberg/pull/25791 - [x] Presets - [x] Make them translatable via theme.json https://github.com/wp-cli/i18n-command/issues/224 https://github.com/WordPress/gutenberg/pull/28246 - [x] Allow creating presets in contexts other than `global`. https://github.com/WordPress/gutenberg/pull/25768 - [x] Allow creating user-defined color palettes. https://github.com/WordPress/gutenberg/pull/27250 - [x] Allow presets to use other preset variables https://github.com/WordPress/gutenberg/issues/26511 ### Interface - [x] Make editor controls reflect styles, whether they come from theme or user. https://github.com/WordPress/gutenberg/pull/21490 https://github.com/WordPress/gutenberg/pull/22722 https://github.com/WordPress/gutenberg/pull/26783 https://github.com/WordPress/gutenberg/pull/26786 - [x] Reset to theme defaults https://github.com/WordPress/gutenberg/pull/26975Third 🌊
Goal: merge the non UI parts of global styles in WordPress 5.8.
block.json / block supports: - [x] https://github.com/WordPress/gutenberg/issues/28913 Add support for skip serialization to all properties. Core blocks can be migrated iteratively. - [x] https://github.com/WordPress/gutenberg/issues/29616 `border-width`, `border-style`, `border-color` - [x] https://github.com/WordPress/gutenberg/pull/29335 Alignments - [x] https://github.com/WordPress/gutenberg/issues/31488 link color: make it work like layout or duotone. https://github.com/WordPress/gutenberg/issues/25151 Will also fix link color for author roles. theme.json: - [x] https://github.com/WordPress/gutenberg/issues/29891 Changes to theme.json - [x] Versioning theme.json from the theme, implemented as part of https://github.com/WordPress/gutenberg/pull/30541 - [x] https://github.com/WordPress/gutenberg/issues/29568 colors: allow having defaults, theme, and custom - [x] https://github.com/WordPress/gutenberg/issues/29778 Theme authors should be able to use any styles in theme.json independently from the block.json support. - [x] https://github.com/WordPress/gutenberg/issues/24165 Mobile: confirm there are not blockers to make theme.json cross-platform (web & mobile). - [x] https://github.com/WordPress/gutenberg/issues/30191 Use `wp_theme` taxonomy instead of post_name to associate user styles with particular themes. Internationalization: - [x] https://github.com/WordPress/gutenberg/pull/29828 theme.json: customTemplates. - [x] block supports: allow changing UI control labels https://github.com/WordPress/gutenberg/pull/29155 (discarded, instead we rephrased the labels to be more adequate for different contexts) https://github.com/WordPress/gutenberg/pull/30075 Docs: - [x] Update [theme.json docs](https://developer.wordpress.org/block-editor/how-to-guides/themes/theme-json/) to make clear what's part of WordPress 5.8 and what's part of the plugin. https://github.com/WordPress/gutenberg/pull/33131 - [x] Update [theme support docs](https://developer.wordpress.org/block-editor/how-to-guides/themes/theme-support/) to state that link color is now stable and part of Wordpress core, using `theme.json`. The `experimental-link-color` theme support will be deprecated and removed when the plugin requires WordPress 5.8 as the minimum version. https://github.com/WordPress/gutenberg/pull/33162 - [x] Update docs for block supports, including a note about `__experimentalSkipSerialization`. Extensibility: - [x] https://github.com/WordPress/gutenberg/issues/27504 Hooking into the lifecycle of GS: stabilize API and define what sort of hooks do we need. - [x] https://github.com/WordPress/gutenberg/issues/30082 Block editor settings & global styles settings. Bug fixes - [x] Disable/Enable custom colors, gradients, and font sizes https://github.com/WordPress/gutenberg/pull/32200 - [x] Empty color palette should disable the feature https://github.com/WordPress/gutenberg/pull/32225 https://github.com/WordPress/gutenberg/pull/32358 - [x] `settings.color` no longer have the theme colors https://github.com/WordPress/gutenberg/issues/32027 https://github.com/WordPress/gutenberg/pull/32358 - [x] Block presets generate incorrect styles https://github.com/WordPress/gutenberg/issues/31660Fourth 🌊
Follow-ups to WordPress 5.8 release.
Block supports:
theme.json:
Stylesheet:
Performance:
Interface
Backlog
The things listed here don't need to be necessarily implemented, but should be considered.
block.json: nothing planned
theme.json
core/group core/paragraph
. https://github.com/WordPress/gutenberg/issues/28163font
,color
, pagebackground
) can be conceptualized as attributes of a root Site block. #16998 Related: consider global site width and padding #20771Expand to more style properties:
height
https://github.com/WordPress/gutenberg/pull/28409margin
https://github.com/WordPress/gutenberg/pull/25988width
https://github.com/WordPress/gutenberg/issues/31037wp_register_font_family
.Extensibility:
theme.json
configs (including user preferences) as part of exporting templates & template parts https://github.com/WordPress/gutenberg/issues/27941 https://github.com/WordPress/gutenberg/issues/27528Interface:
__experimentalSelector
of the heading block). How is this in the new UI?Iterate on design tools:
Misc: