Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Block Styles Breakdown #20331

Closed
75 of 82 tasks
mtias opened this issue Feb 20, 2020 · 36 comments
Closed
75 of 82 tasks

Block Styles Breakdown #20331

mtias opened this issue Feb 20, 2020 · 36 comments
Labels
[Feature] Design Tools Tools that impact the appearance of blocks both to expand the number of tools and improve the experi Global Styles Anything related to the broader Global Styles efforts, including Styles Engine and theme.json [Type] Overview Comprehensive, high level view of an area of focus often with multiple tracking issues

Comments

@mtias
Copy link
Member

mtias commented Feb 20, 2020

This is an overview of the concrete tasks needed to proceed with the project scope of #9534 (see also #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.

Interface

These are the different tools that interact with appearance values.

Second 🌊

Goal: develop all necessary sub-systems.

Infrastructure

Interface

Third 🌊

Goal: merge the non UI parts of global styles in WordPress 5.8.

block.json / block supports:

theme.json:

Internationalization:

Docs:

Extensibility:

Bug fixes

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:

@mtias mtias added the Global Styles Anything related to the broader Global Styles efforts, including Styles Engine and theme.json label Feb 20, 2020
@karmatosed karmatosed added this to To do in Global Styles: 🔴Red Phase via automation Feb 20, 2020
@ItsJonQ ItsJonQ moved this from To do to Quick Links in Global Styles: 🔴Red Phase Feb 21, 2020
@mtias mtias added the [Feature] Design Tools Tools that impact the appearance of blocks both to expand the number of tools and improve the experi label Mar 9, 2020
@jorgefilipecosta
Copy link
Member

jorgefilipecosta commented May 7, 2020

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 #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, #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 #7551 by just allowing the user to save the current block style attributes as a customization of the theme.json structure.

@kjellr
Copy link
Contributor

kjellr commented Oct 9, 2020

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:

  • If a theme has theme.json, it seems ok to have all new design tools be opt-out.
  • Otherwise, if the feature is expected to “just work” with themes without breaking something, it’s probably ok to enable it by default. Otherwise, they should be opt-in.
  • If these are “editor” features, and not something the theme needs to explicitly build in support for, then it may be confusing to use add_theme_support() for them.
  • We should keep in mind that if users move between block-based themes and non-block-based themes, it will likely be confusing for seemingly unrelated features to turn on and off.

More details in the meeting notes.

@jorgefilipecosta
Copy link
Member

jorgefilipecosta commented Nov 23, 2020

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.

  • Create a JSON schema specification for theme.json. Developers can use the schema to validate if their theme.json files are correct and easily locate errors. Improving the developer experience of using theme.json. We can use the scheme in the core to remove invalid paths etc. Add type validation and/or theme.json schema #26955

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?

  • 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).
  • If a block does not support something like line-height, but the theme specifies a line-height for that block. Should we output a line-height style anyway?
  • What are the controls that are available per block? Which blocks by default have font size available? Which have text color? Which have line-height?

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.

  • 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

@oandregal
Copy link
Member

This week's status report:

Shipped

Ongoing

@oandregal
Copy link
Member

This week in global styles:

Landed

Ongoing

@oandregal
Copy link
Member

This week in global styles:

Landed

theme.json with elements #29891

Block Supports & theme.json properties:

Bugfixes, code quality

Ongoing

theme.json with elements #29891

Block Supports:

Bugfixes:

Priorities

The priority continues to be shipping #29891 as soon as possible to unblock related work.

#28913 is a good issue to look at if you can lend a hand (help with reviews, migrate more blocks, more properties, etc).

@oandregal
Copy link
Member

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 #29891 as soon as possible to unblock related work.

#28913 is a good issue to look at if you can lend a hand (help with reviews, migrate more blocks, more properties, etc).

@oandregal
Copy link
Member

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 #29891 via #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 #31488 and font-family #31489 (see rationale in each issue).

@oandregal
Copy link
Member

oandregal commented May 12, 2021

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
Copy link
Member

oandregal commented May 19, 2021

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
Copy link
Member

oandregal commented May 26, 2021

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.

  • The following settings & styles are still experimental and only work with the plugin: border, font-family, font-style, font-weight, text-decoration, text-transform. The rest are part of WordPress core now, so they work without the plugin as well.
  • Layout is enabled for themes with theme.json support.
  • The default theme.json settings we landed in core work like this:
    • If the settings had a corresponding theme support, it works the same as before. Settings that are enabled by default are 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.
    • Link color is stable, landed into 5.8, and it's disabled by default. Need to make a decision on what to do with the existing 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:

@oandregal
Copy link
Member

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
Copy link
Member

oandregal commented Dec 21, 2021

I've created #37550 to track some gaps we still have from the original vision of styles at the framework level.

@mtias
Copy link
Member Author

mtias commented Dec 21, 2021

Really wonderful work and progress here!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Design Tools Tools that impact the appearance of blocks both to expand the number of tools and improve the experi Global Styles Anything related to the broader Global Styles efforts, including Styles Engine and theme.json [Type] Overview Comprehensive, high level view of an area of focus often with multiple tracking issues
Projects
No open projects
Development

No branches or pull requests

9 participants