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: Caption element UI controls #44094

Closed
wants to merge 8 commits into from

Conversation

MaggieCabrera
Copy link
Contributor

@MaggieCabrera MaggieCabrera commented Sep 12, 2022

What?

Add caption elements to the list of elements that can be customized in the Global Styles UI.
Closes #44071

Why?

So far, this could only be achieved via theme.json, now we can control these elements with Global Styles too.

How?

Adding captions to the list of elements in the color and typography sections of Global Styles

Testing Instructions

I'm using emptytheme with the following in theme.json:

	"styles": {
		"elements": {
			"caption": {
				"color": {
					"background": "red",
					"text": "yellow"
				},
				"typography": {
					"fontWeight": "bold",
					"fontStyle": "italic",
					"lineHeight": "2",
					"fontSize": "30px"
				}
			}
		}
	}

Go to global styles and change typography and color settings for the captions. Check that the frontend matches what you see on the editor.

Screenshots or screencast

Screen.Capture.on.2022-09-15.at.16-27-26.mp4

@MaggieCabrera MaggieCabrera changed the title started interface to edit caption colors in Global Styles Global Styles: Caption element UI controls Sep 12, 2022
@MaggieCabrera MaggieCabrera self-assigned this Sep 12, 2022
@MaggieCabrera MaggieCabrera added the Global Styles Anything related to the broader Global Styles efforts, including Styles Engine and theme.json label Sep 12, 2022
@github-actions
Copy link

github-actions bot commented Sep 12, 2022

Size Change: +226 B (0%)

Total Size: 1.28 MB

Filename Size Change
build/edit-site/index.min.js 58.1 kB +213 B (0%)
build/edit-site/style-rtl.css 8.37 kB +6 B (0%)
build/edit-site/style.css 8.36 kB +7 B (0%)
ℹ️ View Unchanged
Filename Size
build/a11y/index.min.js 982 B
build/annotations/index.min.js 2.76 kB
build/api-fetch/index.min.js 2.26 kB
build/autop/index.min.js 2.14 kB
build/blob/index.min.js 475 B
build/block-directory/index.min.js 7.09 kB
build/block-directory/style-rtl.css 990 B
build/block-directory/style.css 991 B
build/block-editor/default-editor-styles-rtl.css 378 B
build/block-editor/default-editor-styles.css 378 B
build/block-editor/index.min.js 168 kB
build/block-editor/style-rtl.css 15.8 kB
build/block-editor/style.css 15.8 kB
build/block-library/blocks/archives/editor-rtl.css 61 B
build/block-library/blocks/archives/editor.css 60 B
build/block-library/blocks/archives/style-rtl.css 90 B
build/block-library/blocks/archives/style.css 90 B
build/block-library/blocks/audio/editor-rtl.css 150 B
build/block-library/blocks/audio/editor.css 150 B
build/block-library/blocks/audio/style-rtl.css 122 B
build/block-library/blocks/audio/style.css 122 B
build/block-library/blocks/audio/theme-rtl.css 126 B
build/block-library/blocks/audio/theme.css 126 B
build/block-library/blocks/avatar/editor-rtl.css 116 B
build/block-library/blocks/avatar/editor.css 116 B
build/block-library/blocks/avatar/style-rtl.css 84 B
build/block-library/blocks/avatar/style.css 84 B
build/block-library/blocks/block/editor-rtl.css 161 B
build/block-library/blocks/block/editor.css 161 B
build/block-library/blocks/button/editor-rtl.css 482 B
build/block-library/blocks/button/editor.css 482 B
build/block-library/blocks/button/style-rtl.css 523 B
build/block-library/blocks/button/style.css 523 B
build/block-library/blocks/buttons/editor-rtl.css 337 B
build/block-library/blocks/buttons/editor.css 337 B
build/block-library/blocks/buttons/style-rtl.css 332 B
build/block-library/blocks/buttons/style.css 332 B
build/block-library/blocks/calendar/style-rtl.css 239 B
build/block-library/blocks/calendar/style.css 239 B
build/block-library/blocks/categories/editor-rtl.css 84 B
build/block-library/blocks/categories/editor.css 83 B
build/block-library/blocks/categories/style-rtl.css 100 B
build/block-library/blocks/categories/style.css 100 B
build/block-library/blocks/code/editor-rtl.css 53 B
build/block-library/blocks/code/editor.css 53 B
build/block-library/blocks/code/style-rtl.css 121 B
build/block-library/blocks/code/style.css 121 B
build/block-library/blocks/code/theme-rtl.css 124 B
build/block-library/blocks/code/theme.css 124 B
build/block-library/blocks/columns/editor-rtl.css 108 B
build/block-library/blocks/columns/editor.css 108 B
build/block-library/blocks/columns/style-rtl.css 406 B
build/block-library/blocks/columns/style.css 406 B
build/block-library/blocks/comment-author-avatar/editor-rtl.css 125 B
build/block-library/blocks/comment-author-avatar/editor.css 125 B
build/block-library/blocks/comment-content/style-rtl.css 92 B
build/block-library/blocks/comment-content/style.css 92 B
build/block-library/blocks/comment-template/style-rtl.css 187 B
build/block-library/blocks/comment-template/style.css 185 B
build/block-library/blocks/comments-pagination-numbers/editor-rtl.css 123 B
build/block-library/blocks/comments-pagination-numbers/editor.css 121 B
build/block-library/blocks/comments-pagination/editor-rtl.css 222 B
build/block-library/blocks/comments-pagination/editor.css 209 B
build/block-library/blocks/comments-pagination/style-rtl.css 235 B
build/block-library/blocks/comments-pagination/style.css 231 B
build/block-library/blocks/comments-title/editor-rtl.css 75 B
build/block-library/blocks/comments-title/editor.css 75 B
build/block-library/blocks/comments/editor-rtl.css 840 B
build/block-library/blocks/comments/editor.css 839 B
build/block-library/blocks/comments/style-rtl.css 637 B
build/block-library/blocks/comments/style.css 636 B
build/block-library/blocks/cover/editor-rtl.css 612 B
build/block-library/blocks/cover/editor.css 613 B
build/block-library/blocks/cover/style-rtl.css 1.57 kB
build/block-library/blocks/cover/style.css 1.55 kB
build/block-library/blocks/embed/editor-rtl.css 293 B
build/block-library/blocks/embed/editor.css 293 B
build/block-library/blocks/embed/style-rtl.css 410 B
build/block-library/blocks/embed/style.css 410 B
build/block-library/blocks/embed/theme-rtl.css 126 B
build/block-library/blocks/embed/theme.css 126 B
build/block-library/blocks/file/editor-rtl.css 300 B
build/block-library/blocks/file/editor.css 300 B
build/block-library/blocks/file/style-rtl.css 253 B
build/block-library/blocks/file/style.css 254 B
build/block-library/blocks/file/view.min.js 346 B
build/block-library/blocks/freeform/editor-rtl.css 2.44 kB
build/block-library/blocks/freeform/editor.css 2.44 kB
build/block-library/blocks/gallery/editor-rtl.css 948 B
build/block-library/blocks/gallery/editor.css 950 B
build/block-library/blocks/gallery/style-rtl.css 1.53 kB
build/block-library/blocks/gallery/style.css 1.53 kB
build/block-library/blocks/gallery/theme-rtl.css 108 B
build/block-library/blocks/gallery/theme.css 108 B
build/block-library/blocks/group/editor-rtl.css 394 B
build/block-library/blocks/group/editor.css 394 B
build/block-library/blocks/group/style-rtl.css 57 B
build/block-library/blocks/group/style.css 57 B
build/block-library/blocks/group/theme-rtl.css 78 B
build/block-library/blocks/group/theme.css 78 B
build/block-library/blocks/heading/style-rtl.css 76 B
build/block-library/blocks/heading/style.css 76 B
build/block-library/blocks/html/editor-rtl.css 327 B
build/block-library/blocks/html/editor.css 329 B
build/block-library/blocks/image/editor-rtl.css 880 B
build/block-library/blocks/image/editor.css 880 B
build/block-library/blocks/image/style-rtl.css 627 B
build/block-library/blocks/image/style.css 630 B
build/block-library/blocks/image/theme-rtl.css 126 B
build/block-library/blocks/image/theme.css 126 B
build/block-library/blocks/latest-comments/style-rtl.css 284 B
build/block-library/blocks/latest-comments/style.css 284 B
build/block-library/blocks/latest-posts/editor-rtl.css 213 B
build/block-library/blocks/latest-posts/editor.css 212 B
build/block-library/blocks/latest-posts/style-rtl.css 463 B
build/block-library/blocks/latest-posts/style.css 462 B
build/block-library/blocks/list/style-rtl.css 88 B
build/block-library/blocks/list/style.css 88 B
build/block-library/blocks/media-text/editor-rtl.css 266 B
build/block-library/blocks/media-text/editor.css 263 B
build/block-library/blocks/media-text/style-rtl.css 507 B
build/block-library/blocks/media-text/style.css 505 B
build/block-library/blocks/more/editor-rtl.css 431 B
build/block-library/blocks/more/editor.css 431 B
build/block-library/blocks/navigation-link/editor-rtl.css 705 B
build/block-library/blocks/navigation-link/editor.css 703 B
build/block-library/blocks/navigation-link/style-rtl.css 115 B
build/block-library/blocks/navigation-link/style.css 115 B
build/block-library/blocks/navigation-submenu/editor-rtl.css 296 B
build/block-library/blocks/navigation-submenu/editor.css 295 B
build/block-library/blocks/navigation/editor-rtl.css 2.02 kB
build/block-library/blocks/navigation/editor.css 2.03 kB
build/block-library/blocks/navigation/style-rtl.css 2.17 kB
build/block-library/blocks/navigation/style.css 2.16 kB
build/block-library/blocks/navigation/view-modal.min.js 2.78 kB
build/block-library/blocks/navigation/view.min.js 443 B
build/block-library/blocks/nextpage/editor-rtl.css 395 B
build/block-library/blocks/nextpage/editor.css 395 B
build/block-library/blocks/page-list/editor-rtl.css 363 B
build/block-library/blocks/page-list/editor.css 363 B
build/block-library/blocks/page-list/style-rtl.css 175 B
build/block-library/blocks/page-list/style.css 175 B
build/block-library/blocks/paragraph/editor-rtl.css 174 B
build/block-library/blocks/paragraph/editor.css 174 B
build/block-library/blocks/paragraph/style-rtl.css 279 B
build/block-library/blocks/paragraph/style.css 281 B
build/block-library/blocks/post-author/style-rtl.css 175 B
build/block-library/blocks/post-author/style.css 176 B
build/block-library/blocks/post-comments-form/editor-rtl.css 96 B
build/block-library/blocks/post-comments-form/editor.css 96 B
build/block-library/blocks/post-comments-form/style-rtl.css 493 B
build/block-library/blocks/post-comments-form/style.css 493 B
build/block-library/blocks/post-date/style-rtl.css 61 B
build/block-library/blocks/post-date/style.css 61 B
build/block-library/blocks/post-excerpt/editor-rtl.css 73 B
build/block-library/blocks/post-excerpt/editor.css 73 B
build/block-library/blocks/post-excerpt/style-rtl.css 69 B
build/block-library/blocks/post-excerpt/style.css 69 B
build/block-library/blocks/post-featured-image/editor-rtl.css 586 B
build/block-library/blocks/post-featured-image/editor.css 584 B
build/block-library/blocks/post-featured-image/style-rtl.css 315 B
build/block-library/blocks/post-featured-image/style.css 315 B
build/block-library/blocks/post-navigation-link/style-rtl.css 153 B
build/block-library/blocks/post-navigation-link/style.css 153 B
build/block-library/blocks/post-template/editor-rtl.css 99 B
build/block-library/blocks/post-template/editor.css 98 B
build/block-library/blocks/post-template/style-rtl.css 282 B
build/block-library/blocks/post-template/style.css 282 B
build/block-library/blocks/post-terms/style-rtl.css 96 B
build/block-library/blocks/post-terms/style.css 96 B
build/block-library/blocks/post-title/style-rtl.css 100 B
build/block-library/blocks/post-title/style.css 100 B
build/block-library/blocks/preformatted/style-rtl.css 103 B
build/block-library/blocks/preformatted/style.css 103 B
build/block-library/blocks/pullquote/editor-rtl.css 135 B
build/block-library/blocks/pullquote/editor.css 135 B
build/block-library/blocks/pullquote/style-rtl.css 326 B
build/block-library/blocks/pullquote/style.css 325 B
build/block-library/blocks/pullquote/theme-rtl.css 167 B
build/block-library/blocks/pullquote/theme.css 167 B
build/block-library/blocks/query-pagination-numbers/editor-rtl.css 122 B
build/block-library/blocks/query-pagination-numbers/editor.css 121 B
build/block-library/blocks/query-pagination/editor-rtl.css 221 B
build/block-library/blocks/query-pagination/editor.css 211 B
build/block-library/blocks/query-pagination/style-rtl.css 282 B
build/block-library/blocks/query-pagination/style.css 278 B
build/block-library/blocks/query-title/style-rtl.css 63 B
build/block-library/blocks/query-title/style.css 63 B
build/block-library/blocks/query/editor-rtl.css 439 B
build/block-library/blocks/query/editor.css 439 B
build/block-library/blocks/quote/style-rtl.css 213 B
build/block-library/blocks/quote/style.css 213 B
build/block-library/blocks/quote/theme-rtl.css 223 B
build/block-library/blocks/quote/theme.css 226 B
build/block-library/blocks/read-more/style-rtl.css 132 B
build/block-library/blocks/read-more/style.css 132 B
build/block-library/blocks/rss/editor-rtl.css 202 B
build/block-library/blocks/rss/editor.css 204 B
build/block-library/blocks/rss/style-rtl.css 289 B
build/block-library/blocks/rss/style.css 288 B
build/block-library/blocks/search/editor-rtl.css 165 B
build/block-library/blocks/search/editor.css 165 B
build/block-library/blocks/search/style-rtl.css 409 B
build/block-library/blocks/search/style.css 406 B
build/block-library/blocks/search/theme-rtl.css 114 B
build/block-library/blocks/search/theme.css 114 B
build/block-library/blocks/separator/editor-rtl.css 146 B
build/block-library/blocks/separator/editor.css 146 B
build/block-library/blocks/separator/style-rtl.css 234 B
build/block-library/blocks/separator/style.css 234 B
build/block-library/blocks/separator/theme-rtl.css 194 B
build/block-library/blocks/separator/theme.css 194 B
build/block-library/blocks/shortcode/editor-rtl.css 464 B
build/block-library/blocks/shortcode/editor.css 464 B
build/block-library/blocks/site-logo/editor-rtl.css 490 B
build/block-library/blocks/site-logo/editor.css 490 B
build/block-library/blocks/site-logo/style-rtl.css 203 B
build/block-library/blocks/site-logo/style.css 203 B
build/block-library/blocks/site-tagline/editor-rtl.css 86 B
build/block-library/blocks/site-tagline/editor.css 86 B
build/block-library/blocks/site-title/editor-rtl.css 116 B
build/block-library/blocks/site-title/editor.css 116 B
build/block-library/blocks/site-title/style-rtl.css 57 B
build/block-library/blocks/site-title/style.css 57 B
build/block-library/blocks/social-link/editor-rtl.css 184 B
build/block-library/blocks/social-link/editor.css 184 B
build/block-library/blocks/social-links/editor-rtl.css 674 B
build/block-library/blocks/social-links/editor.css 673 B
build/block-library/blocks/social-links/style-rtl.css 1.4 kB
build/block-library/blocks/social-links/style.css 1.39 kB
build/block-library/blocks/spacer/editor-rtl.css 322 B
build/block-library/blocks/spacer/editor.css 322 B
build/block-library/blocks/spacer/style-rtl.css 48 B
build/block-library/blocks/spacer/style.css 48 B
build/block-library/blocks/table/editor-rtl.css 494 B
build/block-library/blocks/table/editor.css 494 B
build/block-library/blocks/table/style-rtl.css 611 B
build/block-library/blocks/table/style.css 609 B
build/block-library/blocks/table/theme-rtl.css 190 B
build/block-library/blocks/table/theme.css 190 B
build/block-library/blocks/tag-cloud/style-rtl.css 251 B
build/block-library/blocks/tag-cloud/style.css 253 B
build/block-library/blocks/template-part/editor-rtl.css 235 B
build/block-library/blocks/template-part/editor.css 235 B
build/block-library/blocks/template-part/theme-rtl.css 101 B
build/block-library/blocks/template-part/theme.css 101 B
build/block-library/blocks/text-columns/editor-rtl.css 95 B
build/block-library/blocks/text-columns/editor.css 95 B
build/block-library/blocks/text-columns/style-rtl.css 166 B
build/block-library/blocks/text-columns/style.css 166 B
build/block-library/blocks/verse/style-rtl.css 87 B
build/block-library/blocks/verse/style.css 87 B
build/block-library/blocks/video/editor-rtl.css 691 B
build/block-library/blocks/video/editor.css 694 B
build/block-library/blocks/video/style-rtl.css 174 B
build/block-library/blocks/video/style.css 174 B
build/block-library/blocks/video/theme-rtl.css 126 B
build/block-library/blocks/video/theme.css 126 B
build/block-library/classic-rtl.css 162 B
build/block-library/classic.css 162 B
build/block-library/common-rtl.css 1.02 kB
build/block-library/common.css 1.02 kB
build/block-library/editor-elements-rtl.css 75 B
build/block-library/editor-elements.css 75 B
build/block-library/editor-rtl.css 11.2 kB
build/block-library/editor.css 11.2 kB
build/block-library/elements-rtl.css 54 B
build/block-library/elements.css 54 B
build/block-library/index.min.js 192 kB
build/block-library/reset-rtl.css 478 B
build/block-library/reset.css 478 B
build/block-library/style-rtl.css 12.3 kB
build/block-library/style.css 12.3 kB
build/block-library/theme-rtl.css 719 B
build/block-library/theme.css 722 B
build/block-serialization-default-parser/index.min.js 1.12 kB
build/block-serialization-spec-parser/index.min.js 2.83 kB
build/blocks/index.min.js 49.8 kB
build/components/index.min.js 202 kB
build/components/style-rtl.css 11.3 kB
build/components/style.css 11.3 kB
build/compose/index.min.js 12.2 kB
build/core-data/index.min.js 15.5 kB
build/customize-widgets/index.min.js 11.3 kB
build/customize-widgets/style-rtl.css 1.38 kB
build/customize-widgets/style.css 1.38 kB
build/data-controls/index.min.js 653 B
build/data/index.min.js 8.08 kB
build/date/index.min.js 32.1 kB
build/deprecated/index.min.js 507 B
build/dom-ready/index.min.js 324 B
build/dom/index.min.js 4.7 kB
build/edit-navigation/index.min.js 16.1 kB
build/edit-navigation/style-rtl.css 3.99 kB
build/edit-navigation/style.css 4 kB
build/edit-post/classic-rtl.css 546 B
build/edit-post/classic.css 547 B
build/edit-post/index.min.js 31.7 kB
build/edit-post/style-rtl.css 7.13 kB
build/edit-post/style.css 7.13 kB
build/edit-widgets/index.min.js 16.7 kB
build/edit-widgets/style-rtl.css 4.34 kB
build/edit-widgets/style.css 4.34 kB
build/editor/index.min.js 41.7 kB
build/editor/style-rtl.css 3.62 kB
build/editor/style.css 3.61 kB
build/element/index.min.js 4.68 kB
build/escape-html/index.min.js 537 B
build/experiments/index.min.js 868 B
build/format-library/index.min.js 6.95 kB
build/format-library/style-rtl.css 571 B
build/format-library/style.css 571 B
build/hooks/index.min.js 1.64 kB
build/html-entities/index.min.js 448 B
build/i18n/index.min.js 3.77 kB
build/is-shallow-equal/index.min.js 527 B
build/keyboard-shortcuts/index.min.js 1.78 kB
build/keycodes/index.min.js 1.83 kB
build/list-reusable-blocks/index.min.js 2.13 kB
build/list-reusable-blocks/style-rtl.css 835 B
build/list-reusable-blocks/style.css 835 B
build/media-utils/index.min.js 2.93 kB
build/notices/index.min.js 963 B
build/nux/index.min.js 2.06 kB
build/nux/style-rtl.css 732 B
build/nux/style.css 728 B
build/plugins/index.min.js 1.94 kB
build/preferences-persistence/index.min.js 2.22 kB
build/preferences/index.min.js 1.33 kB
build/primitives/index.min.js 933 B
build/priority-queue/index.min.js 1.58 kB
build/react-i18n/index.min.js 696 B
build/react-refresh-entry/index.min.js 8.44 kB
build/react-refresh-runtime/index.min.js 7.31 kB
build/redux-routine/index.min.js 2.74 kB
build/reusable-blocks/index.min.js 2.21 kB
build/reusable-blocks/style-rtl.css 256 B
build/reusable-blocks/style.css 256 B
build/rich-text/index.min.js 10.6 kB
build/server-side-render/index.min.js 1.77 kB
build/shortcode/index.min.js 1.53 kB
build/style-engine/index.min.js 1.46 kB
build/token-list/index.min.js 644 B
build/url/index.min.js 3.61 kB
build/vendors/inert-polyfill.min.js 2.48 kB
build/vendors/react-dom.min.js 38.5 kB
build/vendors/react.min.js 4.34 kB
build/viewport/index.min.js 1.08 kB
build/warning/index.min.js 268 B
build/widgets/index.min.js 7.21 kB
build/widgets/style-rtl.css 1.18 kB
build/widgets/style.css 1.19 kB
build/wordcount/index.min.js 1.06 kB

compressed-size-action

Copy link
Contributor

@scruffian scruffian left a comment

Choose a reason for hiding this comment

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

Thanks for working on this. Everything worked as expected in my testing.

I noticed that to add colors require a lot of new (probably duplicated) code, whereas adding typography just works. Is it possible to abstract the way that colors works in the same way that typography has been, so that we don't need to duplicate all this code every time we add a new element?

@mtias
Copy link
Member

mtias commented Sep 18, 2022

One thing we need to support for global captions is text alignment.

@MaggieCabrera
Copy link
Contributor Author

One thing we need to support for global captions is text alignment.

Looks like some settings are missing from this panel, but that might be covered by #44180

@MaggieCabrera
Copy link
Contributor Author

Thanks for working on this. Everything worked as expected in my testing.

I noticed that to add colors require a lot of new (probably duplicated) code, whereas adding typography just works. Is it possible to abstract the way that colors works in the same way that typography has been, so that we don't need to duplicate all this code every time we add a new element?

I'm working on this and I noticed that the links element implemented pseudoelements but the same was not done for the buttons, abstracting the component will help with that and solve it for future elements. It will make this PR a bit wider in scope but I hope it will still be easy to test when I'm done. I can split it if needed.

@MaggieCabrera
Copy link
Contributor Author

MaggieCabrera commented Oct 14, 2022

Looks like the headings and links need a bit more work to use the new component I included here, so we better cover them in a follow up. This PR should be good to test. We must ensure that button, text, and caption all work as intended in GS, both with theme.json values and user changes.

This is the theme.json I used to test while using emptytheme:

         "styles": {
		"color": {
			"background": "red",
			"text": "yellow"
		},
		"elements": {
			"caption": {
				"color": {
					"background": "red",
					"text": "yellow"
				},
				"typography": {
					"fontWeight": "bold",
					"fontStyle": "italic",
					"lineHeight": "2",
					"fontSize": "30px"
				}
			},
			"button": {
				"color": {
					"background": "red",
					"text": "yellow"
				}
			},
			"link": {
				"color": {
					"text": "pink"
				}
			}
		}
	}

Copy link
Contributor

@scruffian scruffian left a comment

Choose a reason for hiding this comment

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

LGTM. It might be worth getting another +1 from someone else...

Copy link
Contributor

@andrewserong andrewserong left a comment

Choose a reason for hiding this comment

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

This is very cool @MaggieCabrera! It's testing well for me, too. I just left some nit-picky comments in the ScreenColorElement component. They're very much just some thoughts I had about how the code is organised, so not a blocker for landing this PR, and could potentially also be code quality changes to be explored separately if need be.

In terms of using the feature, I think it's a great idea exposing the controls for the Caption element. One concern I have is about being able to adjust the background color. In a theme that doesn't provide pleasing padding for the figcaption element (like TT2), when I apply a background color, I immediately wanted to then also be able to adjust the padding of the caption, as without that control, I found it hard to make the caption look pleasing:

image

I suppose part of the challenge with background colors for the Image block is that there is a space between the caption and the image, so depending on the styling someone is going for, they might either want to be able to remove that space between the caption and the image, or they might want the background color to be applied to the parent figure element instead so that it naturally captures the background of both the image and the caption 🤔

Other than those fiddly issues surrounding the background color, the text color and typography controls were all testing nicely for me! ✨

supports.includes( 'color' ) &&
isTextEnabled &&
( solids.length > 0 || areCustomSolidsEnabled );
textColorElementSelector = 'color.text';
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this the only place we mutate textColorElementSelector? If so, would it work to do the calculation when we define that variable, and switch to a const?

Alternately, what if we moved the selector to be a key of the element in the elements object above (so, elements.text.textColorElementSelector?

isTextEnabled &&
( solids.length > 0 || areCustomSolidsEnabled );
textColorElementSelector = 'color.text';
isBackgroundEnabled = false;
Copy link
Contributor

Choose a reason for hiding this comment

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

Similarly if we are hard-coding particular elements to disable certain features, would it work to add it to the elements object?

Comment on lines +50 to +71
switch ( element ) {
case 'button':
hasElementColor =
supports.includes( 'buttonColor' ) &&
isBackgroundEnabled &&
( solids.length > 0 || areCustomSolidsEnabled );
break;
case 'text':
hasElementColor =
supports.includes( 'color' ) &&
isTextEnabled &&
( solids.length > 0 || areCustomSolidsEnabled );
textColorElementSelector = 'color.text';
isBackgroundEnabled = false;
break;

default:
hasElementColor =
supports.includes( 'color' ) &&
( solids.length > 0 || areCustomSolidsEnabled );
break;
}
Copy link
Contributor

Choose a reason for hiding this comment

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

This is potentially a little nit-picky, and it doesn't have any impact on the overall functioning of this code, so feel free to ignore this comment!

Some of the global styles files get complex pretty quickly as we add additional elements and controls, and looking at the changes here made me think of a couple of small changes that might improve readability. Is there an opportunity here to add a useHasElementColor hook to this file, similar to how the border-panel.js and dimensions-panel.js files have a bunch of useHas hooks?

We could then potentially swap out the switch statement to use that hook, where the internals might be a shorter series of if statements:

	if ( solids.length > 0 || areCustomSolidsEnabled ) {
		if ( element === 'button' ) {
			hasElementColor =
				supports.includes( 'buttonColor' ) && isBackgroundEnabled;
		} else if ( element === 'text' ) {
			hasElementColor = supports.includes( 'color' ) && isTextEnabled;
		} else {
			hasElementColor = supports.includes( 'color' );
		}
	}

Ideally ScreenColorElement would then either get its settings via calling other hooks, or do a look-up to the elements object.

My feedback here is very much influenced by my personal preference that I find switch statements challenging to read, so definitely not a blocker to this PR landing.

Copy link
Contributor

Choose a reason for hiding this comment

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

Breaking this into a separate hook sounds good to me 👍

Along with making it easier to grok. It might open the door for writing tests as well, should we ever desire them.

My feedback here is very much influenced by my personal preference that I find switch statements challenging to read

For me, I think it might be the nested and repeated check for ( solids.length > 0 || areCustomSolidsEnabled ) that lowers the readability more so than the switch. That's just another personal opinion or preference though 🙂

@andrewserong
Copy link
Contributor

I've added a couple more folks as reviewers (Glen and Aaron), but just as an FYI / for visiblity since there's been previous conversations about background colors, spacing, and the Image block 🙂

@aaronrobertshaw
Copy link
Contributor

Thanks for the heads up on this one @andrewserong, and all the work to date @MaggieCabrera 👍

I'll endeavour to give it a look through Monday.

For now, though, the first thing that came to mind were some discussions around captions becoming their own standalone block. There was also a PR opened for this a while back #31823. There could still be an argument for both this PR's caption elements and the standalone block, e.g. for the user to be able to style individual captions vs also being able to blanket target captions in 3rd party blocks.

Captions were also raised in the issue tracking typography block support adoption. Depending on the consensus here that might need updating to state we won't be adopting typography supports for the caption-related blocks.

Copy link
Contributor

@aaronrobertshaw aaronrobertshaw left a comment

Choose a reason for hiding this comment

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

Thanks for the great work on this @MaggieCabrera 👍

In general, this is testing pretty nicely for me.

Like @andrewserong I was caught out a bit by the gap between the image and its caption when setting a background color. FWIW, in the editor, the resizable box handle appears to slightly exacerbate the size of the gap compared to other embed blocks. That's not an issue for this PR but something we might need to iron out in follow-ups.

In terms of padding within the caption, line height only helps us with vertical spacing, we still have problems with left or right-aligned captions.

For example:
Screen Shot 2022-10-24 at 7 51 06 pm

The need for padding support is probably another argument in favour of refactoring our blocks' captions into their own standalone blocks. Then they can have spacing supports as well as typography and color.

I'd still see a role for the caption within the Elements API, but that might be reduced to:

  1. Only temporarily being the primary means of configuring caption styles
  2. Once we have standalone caption blocks, we'd recommend the caption element only for basic styling of captions added via 3rd party blocks etc that don't themselves use the new caption block.

Having two approaches with considerable overlap might introduce its own problems, but I suspect they'd be manageable with the right selector for the standalone caption block. We also have a precedent with the heading element and block.

The only other issues I encountered were around a theme author wishing to disable color controls.

When disabling text color controls via theme.json, it still shows regardless within the captions element panel but not the other elements. Even if it did omit the text control as it does with background when it is disabled, we'd end up with an empty panel and no back navigation.

The empty panel issue isn't unique to this PR, though, it happens for the other color panels on trunk. We might need checks to skip rendering the initial colors option or individual elements.

This might be suited to a separate follow-up to allow for a more focused discussion on the desired approach and unblock this PR.

Happy to hear everyone else's thoughts on this one.

Here's what I see when switching from enabled color UI to disabled.

Enabled Disabled
Screen.Recording.2022-10-24.at.8.07.42.pm.mp4
Screen.Recording.2022-10-24.at.8.08.05.pm.mp4

Comment on lines +50 to +71
switch ( element ) {
case 'button':
hasElementColor =
supports.includes( 'buttonColor' ) &&
isBackgroundEnabled &&
( solids.length > 0 || areCustomSolidsEnabled );
break;
case 'text':
hasElementColor =
supports.includes( 'color' ) &&
isTextEnabled &&
( solids.length > 0 || areCustomSolidsEnabled );
textColorElementSelector = 'color.text';
isBackgroundEnabled = false;
break;

default:
hasElementColor =
supports.includes( 'color' ) &&
( solids.length > 0 || areCustomSolidsEnabled );
break;
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Breaking this into a separate hook sounds good to me 👍

Along with making it easier to grok. It might open the door for writing tests as well, should we ever desire them.

My feedback here is very much influenced by my personal preference that I find switch statements challenging to read

For me, I think it might be the nested and repeated check for ( solids.length > 0 || areCustomSolidsEnabled ) that lowers the readability more so than the switch. That's just another personal opinion or preference though 🙂

const [ color ] = useStyle( 'elements.caption.color.text', name );
const [ bgColor ] = useStyle( 'elements.caption.color.background', name );

if ( ! hasSupport ) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Should we also skip the panel if a theme author has chosen to disable text and background color controls in Global Styles?

I appreciate this follows the other elements that miss this as well. So it would likely be better as a follow-up.

@MaggieCabrera
Copy link
Contributor Author

There's something I don't understand here:

The need for padding support is probably another argument in favour of refactoring our blocks' captions into their own standalone blocks. Then they can have spacing supports as well as typography and color.

Can't we do exactly that but as an element? The button element supports spacing settings in theme.json, and probably the caption does as well, we just need to surface that to the UI, I don't see the need to make them blocks for that.

@aaronrobertshaw
Copy link
Contributor

Can't we do exactly that but as an element? The button element supports spacing settings in theme.json, and probably the caption does as well, we just need to surface that to the UI, I don't see the need to make them blocks for that.

That's correct, it could be styled via theme.json directly, and as you note, there isn't currently a UI for padding for elements in the Global Styles sidebar unless I missed it.

What happens when a user wishes to override a style for a particular caption? They can't edit the theme.json, and the elements UI in Global Styles would only work across the board or for all instances of a given block type.

If captions were a block, we'd get all the UI in Global Styles for free and fill the gap for end users.

@MaggieCabrera
Copy link
Contributor Author

That's correct, it could be styled via theme.json directly, and as you note, there isn't currently a UI for padding for elements in the Global Styles sidebar unless I missed it.

Yeah, it's on our radar to add the option

What happens when a user wishes to override a style for a particular caption? They can't edit the theme.json, and the elements UI in Global Styles would only work across the board or for all instances of a given block type.

If captions were a block, we'd get all the UI in Global Styles for free and fill the gap for end users.

I see what you mean, I hadn't thought of that. If you think that's a use case that merits adding the new block then I think having the element as well is going to be a bit redundant and probably confusing if the theme.json alters one but not the other.

@scruffian
Copy link
Contributor

This was a question we considered previously for the button block/element, and this comment by @mtias is helpful.

I think if we apply those same criteria to the case of captions it doesn't make sense to have them as inner blocks.

@aaronrobertshaw
Copy link
Contributor

If you think that's a use case that merits adding the new block, then I think having the element as well is going to be a bit redundant and probably confusing if the theme.json alters one but not the other.

There would definitely be overlap, but it wouldn't be completely redundant. This was part of what I was referring to earlier. even with an inner block option for captions, you could still have a more complex block or 3rd party blocks that include a caption that isn't leveraging the new block. That could still be targeted via the caption element. As noted earlier, there's a precedent with this and the heading block/element.

This was a question we considered previously for the button block/element, and #39463 (comment) by @mtias is helpful.

Thanks @scruffian, appreciate the extra background.

I think if we apply those same criteria to the case of captions it doesn't make sense to have them as inner blocks.

There have been a few things coming up around captions and a potential block that might make this a slightly different situation.

  • There have been requests to be able to move the caption above or below images.
  • We could benefit from having some logic in a caption block e.g. being able to render or style differently based on context, such as when within a gallery image with a border-radius.
  • The possibility of block styles for captions was floated as well

So for me, some of the benefits of implementing a caption block would be:

  • Users can move the caption above or below an item on a case-by-case basis
  • Allows users to override individual caption styles
  • Provides more control via easier opt-in to all block supports
  • Allows us to add some logic to captions.
    • e.g. gallery images noted above and removing the need for hacky CSS class injection to overcome overlay styling of captions.
  • Block styles could be leveraged to allow users to select overlay captions outside of the gallery
  • Will make typography support on some existing blocks easier.
    • e.g. Table block's typography support bleeds into caption styles at present, and the elements UI & RichText component don't give us sufficient control to be able to override some styling.

I appreciate not everyone might value all those points the same. I do believe they are all worth considering on their own merit, separate to the decision on the button element vs inner block for the Search block.

If we can address all of the above without a block, I'd be happy with that. It's not clear to me at the moment though how that would be possible.

Thanks for the discussion towards trying to make sure we cover all bases for captions 🙇

@andrewserong
Copy link
Contributor

Great discussion here!

I think if we apply those same criteria to the case of captions it doesn't make sense to have them as inner blocks.

If we go the route of treating captions in image and gallery blocks as elements, what's the path forward for adding padding, typography, color controls at the individual element level within the block editor? One of the things with the Button block is that it can be styled both via the elements approach in theme.json but also at the individual block level.

It'd be great to be able to click on a figcaption in the editor for a single instance of a gallery or an image and adjust all the block supports that we'd like to have for the caption, along with text alignment etc. Whether that's via the elements API or the block API is probably irrelevant from a user perspective, but it's good that we already have the ability to select and rearrange blocks via the APIs for blocks, so having a caption block sounded like a pretty good way to achieve that to me. Also if it were to be a block, it could be built in quite a lightweight / locked down way, that mightn't have some of the legacy issues or complexity of the Button block.

All that said, given the relationship between elements and the Button block works pretty well, I don't think of it as a blocker for this PR which is about controlling the display of captions globally. It'd be great to see if we can get padding support added though, so that the spacing with a background color applied can be controlled.

@mtias
Copy link
Member

mtias commented Oct 26, 2022

There have been requests to be able to move the caption above or below images.

Where are these requests out of curiosity?

@aaronrobertshaw
Copy link
Contributor

Where are these requests out of curiosity?

It did come up recently in an internal discussion, although my memory is failing me on the specifics of that conversation now, sorry. Even checked with the team, but only vague recollections were voiced there to.

The ability to move the caption was floated in the PR trialling a caption block, though.

Within Gutenberg there are a couple of issues related to moving the caption for the Table block:

My recollection might also have been influenced from seeing the range of WordPress support forum posts asking things like how to move a caption "over", "above", or "on top" of images but meaning to overlay them on the image. Maybe a Block Style might allow for this, or even an on hover caption display, to be implemented once but leveraged across all images, galleries and embeds.

While going on a quick dig through Gutenberg issues for ones related to "captions" the results get swamped pretty quickly by requests for better control over caption alignments. Would an inner block help offer better alignment control for captions as well?

Some issues related to caption alignment include:

Hopefully, that all helps some in evaluating whether a caption block is worth it.

@mtias
Copy link
Member

mtias commented Oct 26, 2022

Indeed, I don't think there's a compelling argument for reordering. Overlaid captions can be a style, but it actually makes the point that it should not be treated as a block given an overlaid caption doesn't make sense for tables.

We should probably allow switching between overlaid or not for the image block alone, and use it by default on galleries.

All in all the caption is not an independent unit nor something that needs ordering flexibility to warrant being a block with all the impact it carries (selection, display in list view, breadcrumb, etc).

Would an inner block help offer better alignment control for captions as well?

Not really, since we are just dealing with text alignment which can be handled just fine by it being an element.

@aaronrobertshaw
Copy link
Contributor

Sounds like an element is the preferred option 👍

Should we extend the RichText component for captions so individual blocks can tweak all that gets set at the Global Styles level? Or restricting at all what's configurable for captions via global styles?

With the current approach, users wouldn't be able to override font family, font size, line height, and some font weights.

Do we also still see value in providing spacing control for the captions at both global styles and individual block levels?

@richtabor
Copy link
Member

With the current approach, users wouldn't be able to override font family, font size, line height, and some font weights.

As long as you can style captions within the Site Editor—the same typographic supports we use for Headings/Paragraph— we're good imo.

Do we also still see value in providing spacing control for the captions at both global styles and individual block levels?

I don't think this is necessary. Typography settings in Global Styles do not allow for Layout > Dimensions currently. I know captions are a bit different as there is not a block to manipulate the dimensions further, but I don't think this should be a blocker.


I'll take this for another spin if we get the merge conflicts cleared up, and the PR updated with trunk. 🚀

@MaggieCabrera
Copy link
Contributor Author

I'll take this for another spin if we get the merge conflicts cleared up, and the PR updated with trunk. 🚀

Sorry, it's been a while! A lot has changed since I worked on this and I think the rebase is a bit of an ordeal, so I'm gonna try and re make this PR again to make sure we don't lose any changes made since we opened this PR, will update here with my work

@MaggieCabrera
Copy link
Contributor Author

I'm sorry to move the conversation over to #49141 but I think it was best, since a lot has changed around GS since this PR opened. The new PR is more or less at the same spot this one was with a few minor bits of feedback applied to it from the discussions on this one. Please let me know what else I can do to improve it, and we can get it in and follow up with maybe adding padding controls to the element too on a separate PR.

@MaggieCabrera
Copy link
Contributor Author

Solved in #49141

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
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Global Styles: add Caption element UI controls
6 participants