search

WordPress / gutenberg

The Block Editor project for WordPress and beyond. Plugin is available from the official repository.
https://wordpress.org/gutenberg/
Other
10.48k stars 4.18k forks source link

Block Styles Breakdown #20331

Closed mtias closed 2 years ago

mtias commented 4 years ago

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.

Screenshot 2020-03-11 at 19 59 19

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. #20339

Second 🌊

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/26975

Third 🌊

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/31660

Fourth 🌊

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

Expand to more style properties:

Extensibility:

Interface:

Iterate on design tools:

Misc:

jorgefilipecosta commented 4 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.

kjellr commented 4 years ago

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:

More details in the meeting notes.

jorgefilipecosta commented 3 years ago

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.

What we will do next?

These are the tasks we will work on and plan to have ready soon. Are the most prioritary tasks.

What we can do next?

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.

Things for the future

Not part of a first version. Things we may consider in the future.

Related tasks but that initially will not use theme.json/global styles mechanisms.

What decisions do we need to do?

What’s next on the UI/UX side?

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.

cc: @nosolosw, @shaunandrews, @jasmussen, @ItsJonQ, @mcsf, @youknowriad

youknowriad commented 3 years ago

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.

aristath commented 3 years ago

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)?

francescamarano commented 3 years ago

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!

jorgefilipecosta commented 3 years ago

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!

jorgefilipecosta commented 3 years ago

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.

youknowriad commented 3 years ago

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)

cliffordp commented 3 years ago

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.

jorgefilipecosta commented 3 years ago

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:

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)?

jorgefilipecosta commented 3 years ago

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).

youknowriad commented 3 years ago

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.

oandregal commented 3 years ago

@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

jorgefilipecosta commented 3 years ago

It is time for another update on Global Styles :)

Updates on the must-have items

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.

Design tools visibility discussion

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.

UI/UX

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.

oandregal commented 3 years ago

: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.

oandregal commented 3 years ago

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.

oandregal commented 3 years ago

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).

oandregal commented 3 years ago

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.

oandregal commented 3 years ago

Update for this week's core-editor meeting:

oandregal commented 3 years ago

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.

oandregal commented 3 years ago

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.

oandregal commented 3 years ago

This week in global styles:

Ongoing/Next tasks necessary for MVP:

And more:

oandregal commented 3 years ago

Just added https://github.com/WordPress/gutenberg/issues/30191 to the list as well (under the theme.json group).

oandregal commented 3 years ago

This week's status report: ongoing work for the major tasks necessary for the MVP.

oandregal commented 3 years ago

This week's status report:

Shipped

Ongoing

oandregal commented 3 years ago

This week in global styles:

Landed

Ongoing

oandregal commented 3 years ago

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).

oandregal commented 3 years ago

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).

oandregal commented 3 years ago

Status report for core-editor meeting.

Shipped this week:

block.json / block supports:

theme.json

Extensibility:

Site 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).

oandregal commented 3 years ago

This week report for core-editor.

Shipped this week

block supports

theme.json

site editor:

Ongoing

block supports:

theme.json

Priorities

Start the merge process for theme.json APIs.

oandregal commented 3 years ago

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.

oandregal commented 3 years ago

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.

Shipped this week

Port to core:

Block Supports:

theme.json

Misc:

oandregal commented 2 years ago

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).

oandregal commented 2 years ago

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.

mtias commented 2 years ago

Really wonderful work and progress here!