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

Global Styles: Site Edit Integration (FSE) #20061

Closed
wants to merge 13 commits into from

Conversation

ItsJonQ
Copy link

@ItsJonQ ItsJonQ commented Feb 6, 2020

👋 This is still a work in progress!

Description

Screen Shot 2020-02-05 at 7 20 33 PM

This update creates an initial interface for the Global Styles controls as part of the initial Global Styles work.

We're starting off with the simplest implementation.

The purpose is to rig up the various data/render mechanics within the Global Styles system with the FSE experience. We're currently exploring how the user experience will be improved in regards to the controls.

How has this been tested?

  • Enable Full Site Editing and Page Templates under Gutenberg Experiments (in the left sidebar)

Screen Shot 2020-02-05 at 19 23 11

  • Navigate to Site Editor (Beta). Global Styles will be in a sidebar panel on the right

Screen Shot 2020-02-05 at 19 24 24

Changes and notes

GlobalStyles Panel

The GlobalStyles controls are rendered in a Panel within the new FSE edit-site component. This implementation is subject to change. I had added it there just to get started

ColorControl

Part of this change involves adding a new Color picking component, ColorControl. We don't necessarily need to ship both the controls and the new global styles interface. However, this simplified control is much easier to work with compared to the other Color pickers from our current @wordpress/components library.

Getting and Setting data

This still needs to be rigged up. For the initial push, I've just added the UI controls. We still need to resolve, hydrate, update and render the global style values

@nosolosw, @jorgefilipecosta, and I have worked together to build the various pieces.

@karmatosed has helped with initial designs.

cc'ing all you lovely folks so that we can work through this together :)

Thank you!

Todos

  • Connect data + dispatchers to get/set global style values
  • Client side render global style values -> CSS on load and change
  • Update block CSS (e.g. Paragraph, Heading) with global style CSS variables

@ItsJonQ ItsJonQ added [Status] In Progress Tracking issues with work in progress Global Styles Anything related to the broader Global Styles efforts, including Styles Engine and theme.json labels Feb 6, 2020
@ItsJonQ ItsJonQ self-assigned this Feb 6, 2020
@youknowriad
Copy link
Contributor

Do you think we should extract the ColorControl component to its own PR?

@karmatosed
Copy link
Member

Really excited to see this taking shape, thanks for kicking this off @ItsJonQ

@ItsJonQ
Copy link
Author

ItsJonQ commented Feb 6, 2020

@youknowriad I can if that's preferable 👍

The code originally came from my branch here:
https://github.com/WordPress/gutenberg/tree/try/color-picker-ui-update

@ItsJonQ ItsJonQ force-pushed the try/global-styles-site-edit-ui branch from 844102e to 921c99f Compare February 6, 2020 19:58
@ItsJonQ
Copy link
Author

ItsJonQ commented Feb 6, 2020

Heya all!

The latest update I've pushed includes a (mock) rigging of the global style controls with placeholder content on Edit Site. This update helps simulate the experience of setting global styles:

Screen Shot 2020-02-06 at 5 39 41 PM

Demo GIF
https://d.pr/i/0An0Jw

WP GS Environment

Within the Gutenberg Editor, we can't add the wp-gs className onto the html like we can on the front-end of the site. If we do, all h1, h2, ... p elements will be affected. Instead, we must add it to the div that contains all of the rendered Gutenberg blocks. This only targets block rendered elements, rather than h1 or p that may appear in the sidebar.

Note: Non-block rendered Component UI may still be affected, depending on their CSS specificity.

Mock State/Renderer

I've written a mock state manager (wp.data/Redux) and a mock renderer to simulate the live rendering experience. We'll need to replace these with data/actions from wp.data.

Block Components x Variables

I've rigged up the .wp-gs scoped variable styles with the Paragraph and Heading blocks from core.

Placeholder content

For now, I've added h1 -> h6 and a p with lorem ipsum directly in the front-page.html demo template for Edit Site. This is far from ideal, but I think this is a good + simple starting point.


This is still incredibly early! It's a good starting point though!

Very cool to see all of the pieces come together :)

@ItsJonQ ItsJonQ force-pushed the try/global-styles-site-edit-ui branch from 6be771a to cfdd15a Compare February 11, 2020 18:53
@ItsJonQ ItsJonQ requested a review from ellatrix as a code owner February 12, 2020 21:02
@ItsJonQ
Copy link
Author

ItsJonQ commented Feb 12, 2020

@nosolosw + @karmatosed Haiii! I have some updates :)

By the block

I've improved the Global Styles Sidebar/Panel experience in the context of Edit Site. The biggest UX change is that block specific block styles only show when the block is selected (demo below):

Screen Capture on 2020-02-12 at 16-25-24

Note: Global site values like Color and Typography are always there

@wordpress/global-styles

The new updates include a new package, @wordpress/global-styles. That provides the Blocks and Editors (Post Editor and Site Editor) with the pieces they need to interface with the Global Styles system.

These mechanisms were designed to be as agnostic as possible. This will give was maximum flexibility as we work through changes. For example, the controls don't care where they are rendered, whether it's in the Sidebar or otherwise (cc'ing @karmatosed )

This was achieved via the SlotFill system from @wordpress/components, which is works identically to InspectorControls.

Blocks x Global Style Hooks

To make the Controls block specific, I've adapted a similar API pattern as InspectorControl. Below is an example of a custom block using a Global style hook:

import {
  GlobalStylesControls,
  GlobalStylesPanelBody,
  useGlobalStylesState,
} from '@wordpress/global-styles';

function MyBlockEdit( {
    attributes,
    ...etc
} ) {
  const { headingFontWeight, setHeadingFontWeight } = useGlobalStylesState();

  return (
    <>
      <GlobalStylesControls>
        <GlobalStylesPanelBody title={ __( 'MyBlock' ) }>
          <RangeControl
            label={ __( 'Font Weight' ) }
            value={ headingFontWeight }
            onChange={ setHeadingFontWeight }
            min={ 100 }
            max={ 900 }
            step={ 100 }
          />
        </GlobalStylesPanelBody>
      </GlobalStylesControls>
      <InspectorControls>
        ...
      </InspectorControls>
            ...
    </>
  );
}

Note: Not saying this is the definite way to go, but I think it's a good starting point!

export {
default as BlockEdit,
useBlockEditContext,
ifBlockEditSelected,
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Need this piece for the global styles slot/fill

@@ -0,0 +1,3 @@
export function isEditSite() {
Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pretty hack implementation 😅

@johnstonphilip
Copy link
Contributor

This is super cool so far! A couple of my initial thoughts with it:

  • Is there a way we can ensure the styles being changed in this view, are actually in the view? Some of the sliders (like font scale) don't affect anything on my page, though I'm sure they'll affect something, somewhere.
  • Are there plans for handling responsive global styles? That is, global styles that handle CSS media queries for certain screen widths? Certain layouts will require different things to happen at different screen widths, and will require the site owner to define those widths and the global styles that need to exist at that width.

If these have been addressed elsewhere already, my apologies! I am doing my best to track the latest status of everything in the Red Phase!

@ItsJonQ
Copy link
Author

ItsJonQ commented Feb 13, 2020

@johnstonphilip Awesome! Thank you so much for checking it out and providing feedback 😍

Is there a way we can ensure the styles being changed in this view, are actually in the view

Not yet! At the moment, the changes aren't actually saved yet. We're working on bringing in the saving and rendering on the actual site part next 🙌

Are there plans for handling responsive global styles

It's very top of mind for me. However, the ideas I have are very premature. Handling responsiveness is something we need to improve for blocks in general. Changing styles from an aesthetics point of view is one thing (e.g. color), but changing values/behaviour based on layout is another.

If you have any ideas or have seen good examples of this, let's create a Github issue and explore it together :)

If these have been addressed elsewhere already, my apologies! I am doing my best to track the latest status of everything in the Red Phase!

No apologies needed! For global styles updates, I've tried my best to keep current work update to date on the Github project board.

@mtias
Copy link
Member

mtias commented Feb 15, 2020

I like how this is shaping up. It's going to be easy to reason with the levels of fallback: var(--wp-paragraph--color, var(--wp-color--text)).

I agree with splitting the color part away, specially since we need to revise how the picker and the notion of palettes work.

It'd be interesting to connect a line-height control on the paragraph block in subsequent PRs to see how the base style relates to custom modifications.

</EntityProvider>
</DropZoneProvider>
</SlotFillProvider>
<GlobalStylesStateProvider>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does Global Style need to be the outer-most provider?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For this current implementation. Most likely would not once content is provided by @wordpress/data. At the moment, I'm simulating that data flow with a React.Context instance

@johnstonphilip
Copy link
Contributor

I just noticed that custom blocks do not appear to be registered in this Site Edit view.

Screen Shot 2020-02-17 at 11 27 32 AM

If this is something that's part of the WIP and is still coming, ignore this! :)

@mapk
Copy link
Contributor

mapk commented Feb 19, 2020

The biggest UX change is that block specific block styles only show when the block is selected (demo below):

I'll note this one is quite difficult for me to parse. It feels extremely odd to have one block selected, but see global styles change on multiple blocks (even unselected ones). I get that this is a way to surface block-specific global styles, but nevertheless, when I have one specific block selected, I only expect changes to apply to that one block.

Global styles is... well... global. When I enter into that mode, I don't expect to have a particular block selected because I'm ready to change all related content... wherever it may live.

Where I have the most trouble is block-type global styling. I agree that it's a necessary part, and probably the hardest part for getting the UI right. I don't want to derail the work, so let's get some testing around this to see if I'm just being a cantankerous old man on this one. 😉

@karmatosed
Copy link
Member

Just closing a loop from another issue this came up, if we can see about getting all blocks of a type selected when you click one, that might ease. See: #20212 (comment) for context.

@github-actions
Copy link

Size Change: +1.26 kB (0%)

Total Size: 863 kB

Filename Size Change
build/block-editor/index.js 104 kB +14 B (0%)
build/block-library/index.js 112 kB +299 B (0%)
build/block-library/style-rtl.css 7.65 kB +175 B (2%)
build/block-library/style.css 7.65 kB +175 B (2%)
build/blocks/index.js 57.6 kB +6 B (0%)
build/components/index.js 191 kB +560 B (0%)
build/compose/index.js 5.76 kB -3 B (0%)
build/data-controls/index.js 1.04 kB +1 B
build/data/index.js 8.22 kB -5 B (0%)
build/date/index.js 5.36 kB +2 B (0%)
build/dom-ready/index.js 569 B +1 B
build/edit-post/index.js 90.5 kB +6 B (0%)
build/edit-site/index.js 2.75 kB +43 B (1%)
build/edit-widgets/index.js 4.36 kB +1 B
build/editor/index.js 45.1 kB -20 B (0%)
build/format-library/index.js 7.6 kB -2 B (0%)
build/i18n/index.js 3.45 kB +1 B
build/keyboard-shortcuts/index.js 2.3 kB -3 B (0%)
build/media-utils/index.js 4.85 kB +6 B (0%)
build/nux/index.js 3.02 kB +1 B
build/redux-routine/index.js 2.84 kB -1 B
build/rich-text/index.js 14.3 kB +1 B
build/server-side-render/index.js 2.55 kB +2 B (0%)
build/url/index.js 4 kB +2 B (0%)
build/viewport/index.js 1.61 kB +1 B
build/warning/index.js 1.14 kB +1 B
ℹ️ View Unchanged
Filename Size Change
build/a11y/index.js 1.01 kB 0 B
build/annotations/index.js 3.43 kB 0 B
build/api-fetch/index.js 3.39 kB 0 B
build/autop/index.js 2.58 kB 0 B
build/blob/index.js 620 B 0 B
build/block-directory/index.js 6.02 kB 0 B
build/block-directory/style-rtl.css 760 B 0 B
build/block-directory/style.css 760 B 0 B
build/block-editor/style-rtl.css 9.78 kB 0 B
build/block-editor/style.css 9.77 kB 0 B
build/block-library/editor-rtl.css 7.67 kB 0 B
build/block-library/editor.css 7.67 kB 0 B
build/block-library/theme-rtl.css 669 B 0 B
build/block-library/theme.css 671 B 0 B
build/block-serialization-default-parser/index.js 1.65 kB 0 B
build/block-serialization-spec-parser/index.js 3.1 kB 0 B
build/components/style-rtl.css 16.1 kB 0 B
build/components/style.css 16 kB 0 B
build/core-data/index.js 10.5 kB 0 B
build/deprecated/index.js 771 B 0 B
build/dom/index.js 3.06 kB 0 B
build/edit-post/style-rtl.css 8.69 kB 0 B
build/edit-post/style.css 8.68 kB 0 B
build/edit-site/style-rtl.css 2.62 kB 0 B
build/edit-site/style.css 2.62 kB 0 B
build/edit-widgets/style-rtl.css 2.8 kB 0 B
build/edit-widgets/style.css 2.79 kB 0 B
build/editor/editor-styles-rtl.css 327 B 0 B
build/editor/editor-styles.css 328 B 0 B
build/editor/style-rtl.css 4.13 kB 0 B
build/editor/style.css 4.11 kB 0 B
build/element/index.js 4.45 kB 0 B
build/escape-html/index.js 733 B 0 B
build/format-library/style-rtl.css 500 B 0 B
build/format-library/style.css 501 B 0 B
build/global-styles/index.js 2.7 kB 0 B
build/hooks/index.js 1.92 kB 0 B
build/html-entities/index.js 622 B 0 B
build/is-shallow-equal/index.js 711 B 0 B
build/keycodes/index.js 1.68 kB 0 B
build/list-reusable-blocks/index.js 2.99 kB 0 B
build/list-reusable-blocks/style-rtl.css 215 B 0 B
build/list-reusable-blocks/style.css 216 B 0 B
build/notices/index.js 1.57 kB 0 B
build/nux/style-rtl.css 616 B 0 B
build/nux/style.css 613 B 0 B
build/plugins/index.js 2.24 kB 0 B
build/primitives/index.js 1.49 kB 0 B
build/priority-queue/index.js 878 B 0 B
build/shortcode/index.js 1.7 kB 0 B
build/token-list/index.js 1.27 kB 0 B
build/wordcount/index.js 1.18 kB 0 B

compressed-size-action

@ItsJonQ
Copy link
Author

ItsJonQ commented Feb 28, 2020

Closing this PR in favour of #20530 by @nosolosw .

For context, @nosolosw forked this PR and continued work to extend it

@ItsJonQ ItsJonQ closed this Feb 28, 2020
@oandregal oandregal deleted the try/global-styles-site-edit-ui branch March 2, 2020 10:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Global Styles Anything related to the broader Global Styles efforts, including Styles Engine and theme.json [Status] In Progress Tracking issues with work in progress
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants