Add functionality on inner blocks to not include parts of the UI. #18173

jorgefilipecosta · 2019-10-29T20:57:02Z

Description

This PR adds functionality on InnerBlocks that allows disabling parts of the block UI.

Example:

				<InnerBlocks
					allowedBlocks={ ALLOWED_BLOCKS }
					renderAppender={ renderAppender }
					template={ BUTTONS_TEMPLATE }
					__experimentalUIParts={ {
						hasSelectedUI: false,
						hasFocusedUI: false,
						hasHoveredUI: false,
						hasBreadcrumbs: false,
						hasMovers: false,
						hasSpacing: false,
						hasSideInserter: false,
					} }
				/>

By default, all the UI parts are still enabled.

This functionality will be used by buttons block #17352. As a follow-up, we can also refactor social links block to use this functionality, allowing us to remove some CSS hacks the block currently uses.

How has this been tested?

I tested this PR on the buttons block PR #17352. I verified all the removed UI parts don't appear inside the buttons block, and that the editor still behaves as expected.

chrisvanpatten · 2019-10-29T20:58:03Z

VERY excited for this one; can’t wait to try it!

youknowriad · 2019-10-30T09:19:43Z

Any thoughts about inheritance? do we want cascade or not?

simison · 2019-10-31T15:29:37Z

hasBreadcrumbs: false,
hasMovers: false,
hasSpacing: false,
hasSideInserter: false,
By default, all the UI parts are still enabled.

If someday a new UI pattern hasSomeExample is added to Gutenberg, it would be set to visible by default.

Would it be convenient to have hasUI or similar that turns always everything off by default? — or does setting all hasSelectedUI/hasFocusedUI/hasHoveredUI to false already ensure that?

jorgefilipecosta · 2019-11-01T12:31:45Z

Any thoughts about inheritance? do we want cascade or not?

HI @youknowriad, that's an excellent question. My plan, for now, is not to add inheritance.
Imagining the following scenario:
Block (A) uses these flags to remove the UI of its nested blocks, inside we have a Block (B), the block (B) has a columns block inside.

Do we expect the columns block to be different just because it is nested inside the block (B)? I don't think so, I think columns block should look the same.

I expected these flags to be used in situations where parent and child are very connected ( buttons-> button, social icons -> social icon, navigation menu -> navigation item, gallery -> image), and for these cases, it seems inheritance is not needed.

If someday a new UI pattern hasSomeExample is added to Gutenberg, it would be set to visible by default.

Would it be convenient to have hasUI or similar that turns always everything off by default? — or does setting all hasSelectedUI/hasFocusedUI/hasHoveredUI to false already ensure that?

Yes, I guess a flag that is an alias for other flags makes sense. But for now, I would prefer to go this granular path. I think then we may remove granularity as maybe some flag combinations don't make sense. When we decide on the list of flags we will provide, if there are many, I guess some alias flags should be provided.

mtias · 2019-11-02T15:41:29Z

Do we expect the columns block to be different just because it is nested inside the block (B)? I don't think so, I think columns block should look the same.

There's probably cases where you want the parent to force the experience, becoming kind of an editor provider in terms of the experience.

But for now, I would prefer to go this granular path.

It might be fine to let you return false on the whole attribute as a way to disable everything instead of an object. A separate hasUI flag seems it could be more confusing.

jorgefilipecosta · 2019-11-01T18:50:57Z

packages/block-library/src/editor.scss

@@ -53,7 +53,7 @@

 // Provide every block with a default base margin. This margin provides a consistent spacing
 // between blocks in the editor.
-.editor-styles-wrapper [data-block] {
+.editor-styles-wrapper .block-editor-block-list__block.has-spacing > .block-editor-block-list__block-edit > [data-block] {


@jasmussen said:

Is this necessary? I suspect this will cause a lot of editor styles to break because it adds needless extra specificity to editor styles.

We want to only apply the space/margins for blocks in the area that should contain spacing. And this seems to be the way to select these cases. We may also add has-spacing classes to components bellow to avoid the need for a selector with specificity so hight. Do you think that would help?

I needed to decide between:

Add spaces to every block and have another rule (very complex using the not selector) that overwrites the spaces when they are not needed.

Add spaces only when they are needed.

I followed the approach of adding the spaces (margins and paddings) only when they are needed.

As a quick preface, many of these review items happened on a separate PR where I did not have the full context of what you're trying to do here. Now that I do have that context, I applaud you for taking on the task. It's difficult, and many review points need to be thought about in a different way, but I absolutely see the purpose and want to make myself available to help if I can. Notably around spacing I have a great deal of institutional knowledge that might help there.

So we do need to avoid specificity whenever possible. I'd like to try and zoom out a bit here.

We do want to provide a baseline margin to most blocks.

But not all, blocks should be able to opt out.

If that is the goal, can we do something like [data-has-spacing]? For #17267 I was thinking whether it might make sense to have a [data-block-container] as well, to help ambiguate.

The benefit of using these data attributes is that they are entirely optional, and they are added to the innermost div they can be, which means we can avoid the > selector which is very hard to override in CSS.

jorgefilipecosta · 2019-11-01T18:54:42Z

packages/edit-post/src/components/visual-editor/style.scss

 	@include break-small() {
 		// Compensate for side UI width.
-		.block-editor-block-list__block-edit {
+		> .block-editor-block-list__block-edit {


@jasmussen said:

Not sure what this does, but it means all full-wide blocks now have margin left and right of them:

Nice catch It happened because of the specificity increase of .has-spacing. I think if we follow this path we need to test really well and do a style audit to catch these cases.

I would encourage us to think of increasing the style specificity as plan C. If there is anything at all we can do to avoid increasing the specificity, it would be much preferable, as this really has compounding effects.

jorgefilipecosta · 2019-11-01T19:02:50Z

packages/block-editor/src/components/block-list/style.scss

 	}
 }

-.block-editor-block-list__layout .block-editor-block-list__block {
-	position: relative;
+.block-editor-block-list__block .block-editor-block-list__layout.has-spacing {


@jasmussen said:

I definitely emphathise with the complex block paddings. But this PR seems to go a bit farther than necessary in making things work. Perhaps it's worth waiting for #17877 to land before rebasing this on top?

Alternately, and I suspect this is due to the onerous extra UI applied to child blocks, you could snatch the code I wrote for social links, that should allow you to change the margins and paddings just for this one block, while awaiting better improvements than adding a new has-spacing property. Specifically it starts here: /packages/block-library/src/social-links/editor.scss@master#L14

Try the social links block and see how child blocks are well spaced out. If you need my help, feel free to ping, and I'll take a look.

Hi @jasmussen, previously, this PR used precisely the same mechanism of the social link blocks. The reason why I updated this PR was to add a mechanism in the BlockList that allows every block to have a similar UI without the need to write this CSS.

I think the process of applying the margins spacing conditionally to blocks in some areas will always evolve more complex and specific CSS selectors.
I think the spacing flag is the more complex one, and given that a PR is in progress to refactor that part, it may be wise to revert the spacing changes and focus on the other flags for now. And then, after your PR is merged, we create a specific PR to focus on the spacing flag.

The reason why I updated this PR was to add a mechanism in the BlockList that allows every block to have a similar UI without the need to write this CSS.

Wonderful. I entirely missed that goal. It's a noble one.

I think the spacing flag is the more complex one, and given that a PR is in progress to refactor that part, it may be wise to revert the spacing changes and focus on the other flags for now. And then, after your PR is merged, we create a specific PR to focus on the spacing flag.

If I understand this PR correctly, it touches vertical spacing/margins, not horizontal ones. That means it shouldn't necessarily be that affected by #17877. However the rebase might still be gnarly, and given the wide images regressed maybe it will matter after all. In any case, #17877 is approved, I actually just need to know when is a good time to merge it because of the amount of red in the PR.

This PR was rebased and updated. The margin changes were removed. Some flags become unnecessary because of the latest refactors/design changes. The two flags remaining are the ones to disable movers and to disable the selection UI.

youknowriad · 2020-01-02T13:02:04Z

I think this PR might become unnecessary entirely in the new design since the selected UI is removed and the movers are moved to the block toolbar, that said, I'm ok merging this as experimental to unblock the buttons block.

ellatrix · 2020-01-14T11:02:37Z

@jorgefilipecosta I see this has been added to the group block's inner blocks, but why should they not have movers?

jorgefilipecosta · 2020-01-14T22:21:26Z

Hi @ellatrix the issue was solved in #19640.

jorgefilipecosta requested review from ajitbohra, ellatrix, Soean, talldan and youknowriad as code owners October 29, 2019 20:57

simison mentioned this pull request Oct 31, 2019

Gutenboarding: hide block UI via CSS Automattic/wp-calypso#37225

Merged

jorgefilipecosta mentioned this pull request Nov 1, 2019

Add: Buttons block #17352

Merged

jorgefilipecosta force-pushed the add/functionality-on-innerblocks-to-disable-part-of-the-block-ui branch from f931bff to 9c9ae58 Compare November 1, 2019 18:28

youknowriad requested review from aduth and mtias November 2, 2019 10:39

jorgefilipecosta commented Nov 3, 2019

View reviewed changes

mtias mentioned this pull request Nov 6, 2019

More versatile templateLock #8112

Open

Add functionality on inner blocks to not include parts of the UI.

e5c31e8

jorgefilipecosta force-pushed the add/functionality-on-innerblocks-to-disable-part-of-the-block-ui branch from 9c9ae58 to e5c31e8 Compare December 23, 2019 20:40

youknowriad approved these changes Jan 2, 2020

View reviewed changes

jorgefilipecosta merged commit cd01549 into master Jan 2, 2020

simison mentioned this pull request Jan 2, 2020

Gutenboarding: cleanup block UI hiding styles Automattic/wp-calypso#38635

Closed

youknowriad deleted the add/functionality-on-innerblocks-to-disable-part-of-the-block-ui branch January 3, 2020 08:28

youknowriad added this to the Gutenberg 7.2 milestone Jan 6, 2020

ellatrix mentioned this pull request Jan 14, 2020

Block toolbar: fix hasMovers #19619

Merged

6 tasks

jorgefilipecosta mentioned this pull request Jan 14, 2020

Chore: Remove group block test code merged by mistake #19640

Merged

yansern mentioned this pull request Jan 24, 2020

Gutenboarding: page selector is capturing focus Automattic/wp-calypso#38664

Closed

yansern mentioned this pull request Jan 28, 2020

Ability to disable block popover through __experimentalUIParts.hasPopover option. #19922

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Add functionality on inner blocks to not include parts of the UI. #18173

Add functionality on inner blocks to not include parts of the UI. #18173

jorgefilipecosta commented Oct 29, 2019

chrisvanpatten commented Oct 29, 2019

youknowriad commented Oct 30, 2019

simison commented Oct 31, 2019

jorgefilipecosta commented Nov 1, 2019

mtias commented Nov 2, 2019

jorgefilipecosta Nov 1, 2019

jasmussen Nov 4, 2019

jorgefilipecosta Nov 1, 2019

jasmussen Nov 4, 2019

jorgefilipecosta Nov 1, 2019

jasmussen Nov 4, 2019

jorgefilipecosta Dec 23, 2019

youknowriad commented Jan 2, 2020

ellatrix commented Jan 14, 2020

jorgefilipecosta commented Jan 14, 2020

Add functionality on inner blocks to not include parts of the UI. #18173

Add functionality on inner blocks to not include parts of the UI. #18173

Conversation

jorgefilipecosta commented Oct 29, 2019

Description

How has this been tested?

chrisvanpatten commented Oct 29, 2019

youknowriad commented Oct 30, 2019

simison commented Oct 31, 2019

jorgefilipecosta commented Nov 1, 2019

mtias commented Nov 2, 2019

jorgefilipecosta Nov 1, 2019

Choose a reason for hiding this comment

jasmussen Nov 4, 2019

Choose a reason for hiding this comment

jorgefilipecosta Nov 1, 2019

Choose a reason for hiding this comment

jasmussen Nov 4, 2019

Choose a reason for hiding this comment

jorgefilipecosta Nov 1, 2019

Choose a reason for hiding this comment

jasmussen Nov 4, 2019

Choose a reason for hiding this comment

jorgefilipecosta Dec 23, 2019

Choose a reason for hiding this comment

youknowriad commented Jan 2, 2020

ellatrix commented Jan 14, 2020

jorgefilipecosta commented Jan 14, 2020