Update TT1 Blocks to use Gutenberg alignments #236

kjellr · 2021-03-18T15:18:08Z

See #234. This PR is just like #233, but for TT1 Blocks.

This looks great in the editor, but I'm not seeing the new widths reflected in the front end at all. Is there something I'm missing? 🤔

Editor

Before	After

Front-end

Before	After

kjellr · 2021-03-18T15:19:40Z

tt1-blocks/block-templates/index.html

@@ -9,7 +9,7 @@
 		<!-- wp:query-loop -->
 		<!-- wp:post-title {"isLink":true} /-->

-		<!-- wp:post-content {"align":"full"} /-->
+		<!-- wp:post-content /-->


With this in place, posts on the front-end extended beyond the edges of the screen. So I've removed it for now. Should probably re-evaluate once I can get the front-end alignments working right in general though.

you should add { layout: { inherit: true } } to all post content in the templates if they are at the root of templates..

youknowriad

you can also remove the "align-wide" theme flag if it's defined in functions.php

carolinan · 2021-03-22T09:05:40Z

tt1-blocks/block-templates/page-home.html

@@ -3,7 +3,7 @@
 <!-- wp:group {"tagName":"main", "align":"full"} -->
 <main class="wp-block-group alignfull">
 	<div class="wp-block-group__inner-container">


Question, were we not meant to remove the inner containers too?

I think it's safe to remove yes, the deprecation probably triggers here making sure everything works with or without them but yes, it's better to remove.

Thanks, I've removed these in af20e47.

kjellr · 2021-03-22T15:58:52Z

I think this PR is up to date, but it doesn't work as expected:

1. When I set the template parts to "Inherit default layout", all of their inner blocks appear at a default width.

(^ The containing columns block there is supposed to be wide-width.)

2. I'm having trouble finding a combination of "Inherit default layout" settings that works with the main semantic group wrapper.

I think it's because of the issues described in WordPress/gutenberg#29983. TT1 Blocks always uses its Post Content block inside of a Group block, so that it has a main semantic wrapper around everything. Combinations of settings here don't replicate what we'd had before:

Default, nothing set to "Inherit default layout"	Post Content set to "Inherit default layout"	Group Container set to "Inherit default layout"	Group Container and Post Content set to "Inherit default layout"

The second one, Post Content set to "Inherit default layout", is the closest, but the Post Title, Separator, Post Meta, and Comments are also supposed to be wide width, and I don't think we can do that without them living inside a group container that inherits the default layout.

I suppose something like this would work, but it seems overkill:

Mockup	Description
	A: `main` Group container, with no layout settings. B: A nested Group, set to inherit default layout. C: The post content block, set to inherit default layout. D: A nested Group, set to inherit default layout.

And even in that option, you'll notice that the post title ("Widths") is standard width instead of its configured wide width, and the separator below it is full-width instead of its configured wide width. So I'm not sure what's going on there.

youknowriad · 2021-03-22T16:07:49Z

@kjellr Happy to take a look, do we have a demo site or something to check how things are expected to look?

youknowriad · 2021-03-22T16:21:11Z

It seems there was a recent regression in the layout affecting the post editor, I'm fixing it here WordPress/gutenberg#30093

kjellr · 2021-03-22T16:32:50Z

@kjellr Happy to take a look, do we have a demo site or something to check how things are expected to look?

I was just testing locally, but in general, the alignments should match the original Twenty Twenty-One theme. So here's what that page looks like there, for reference:

…le the content area allows full widths

youknowriad · 2021-03-22T16:35:06Z

@kjellr I pushed a fix to the single template which I think do what you want unless I'm missing something?

scruffian · 2021-03-22T16:40:42Z

I think you want to set inherit layout on every template, and then align wide on the children. I notice that there are some unnecessary alignfull attributes in there too...

kjellr · 2021-03-22T17:07:24Z

I pushed a fix to the single template which I think do what you want unless I'm missing something?

It generally does — I noticed that template was missing the main wrapper though. I've added in 86fb5f8. This is the solution I described at the bottom of my comment here though:

Mockup	Description
	A: `main` Group container, with no layout settings. B: A nested Group, set to inherit default layout. C: The post content block, set to inherit default layout. D: A nested Group, set to inherit default layout.

It works, but it's 4 group blocks where we used to have just one. Maybe that's ok, but it seems pretty complicated?

I'm also still seeing some of the alignments act a little wonky in the editor:

Current	Expected

The separator width looks like a theme CSS issue, but the site header and site title should both also be wide.

youknowriad · 2021-03-22T17:10:43Z

It works, but it's 4 group blocks where we used to have just one. Maybe that's ok, but it seems pretty complicated?

It sounds to me that the complication comes from the fact that we want post content's content to allow full width... which means "post-content" can not be wrapped in any div that defines a constrained width.

youknowriad · 2021-03-22T17:20:42Z

For the alignments not applied properly in the editor. It seems there's something going on with the columns block, it doesn't seem to get the data-align attribute on the wrapper when applying an alignment. I'm not sure why exactly, I'll have to debug that further.

kjellr · 2021-03-22T17:23:48Z

It sounds to me that the complication comes from the fact that we want post content's content to allow full width... which means "post-content" can not be wrapped in any div that defines a constrained width.

Yeah, exactly. I expect this scenario to be relatively common. Themes without sidebars usually do want full-width items to appear full width, and they (currently at least) need a wrapper div to implement a semantic main tag. And it's also pretty common for post headers and footers to use a layout/width that's also used by the post content.

For the alignments not applied properly in the editor. It seems there's something going on with the columns block, it doesn't seem to get the data-align attribute on the wrapper when applying an alignment. I'm not sure why exactly, I'll have to debug that further.

Thank you!

youknowriad · 2021-03-22T17:48:39Z

The alignments bugs should be fixed with this PR WordPress/gutenberg#30099

carolinan · 2021-03-23T11:19:40Z

Can you share the block markup that you are testing with?

carolinan · 2021-03-23T11:24:41Z

Please remove the remaining --wp--custom--responsive--aligndefault-width at https://github.com/WordPress/theme-experiments/blob/master/tt1-blocks/assets/css/blocks.css#L187
There is a max-width set for the separator, that overrides the alignwide from theme.json.

scruffian · 2021-03-23T11:55:06Z

The problem with these separator widths removed is that the 100px from theme.css in Gutenberg overrides all the separators so they are all 100px. I think the only way round this is to not use theme styles - removing add_theme_support( 'wp-block-styles' );. What do y'all think?

kjellr · 2021-03-23T12:35:33Z

removing add_theme_support( 'wp-block-styles' );. What do y'all think?

Does that have negative effects elsewhere? I think in general we do want those styles, right?

scruffian · 2021-03-23T12:49:31Z

Does that have negative effects elsewhere?

Probably yes, but I can't think of another solution

kjellr · 2021-03-23T13:22:12Z

I see what you mean. 😞

I just pushed a few additional template updates so that they all use the method from b2fa32b. It's a bunch of extra Group blocks, but it works for now and we can always revise later on.

Everything else appears to be working ok in this PR, so I suggest we try to sort out the separators issue separately? That way at least alignments will work again for folks.

carolinan · 2021-03-23T13:42:40Z

Adding these group blocks -as in understanding they need them- will be complicated for users when they create their own layouts

kjellr · 2021-03-23T13:50:59Z

Yeah, I don't think it's a workable long-term solution. But this brings the theme up to date with Gutenberg in the near term, while we sort that out.

fklein-lu · 2021-03-24T15:31:00Z

It sounds to me that the complication comes from the fact that we want post content's content to allow full width... which means "post-content" can not be wrapped in any div that defines a constrained width.

There are two distinct scenarios here.

The first is editing a template.

In that context it makes sense that containers cannot have blocks that are larger than them. That's the same as when writing HTML: full width means the maximum size is that of the container.

The second is dealing with post content.

The content of a post will always be narrow, because wide paragraphs are unreadable. But still you would want to have images that are larger than the text.

That's a common pattern. Plenty of sites like the New York Times, and even the original Bosco theme have supported for years.

In that case it is inevitable that the wide or large images "break out" of their container. Usually with some clever CSS.

One scenario would be that wide images break out to the right. With full-width breaking out on both sides, but only up until a point.

But let's consider that the rest of the site looks like this, with the navigation wider than the post content, and the header and footer full-width of the browser:

While I do like the approach taken by Gutenberg, it's not as easy as the current implementation. Content width, wide with, and full-width in the context of editing an entire template is not the same as when dealing with post content.

carolinan · 2021-03-24T15:43:47Z

Wide content only breaking out on one side -unless aligned to that side with the block alignment option, is not what I would prefer.

youknowriad · 2021-03-24T15:55:01Z

There are two distinct scenarios here.

I do agree with this and it's exactly why the "layout" config applies to the post editor and not the site editor. In the site editor, you define the containers that support it explicitly

Wide content only breaking out on one side -unless aligned to that side with the block alignment option

I think what's important is that the expectations should be set properly here.

Wide means wide in both sides and you just define the width
Same for full.

This doesn't mean we can't support these side alignments, but these are use cases for different kind of layouts that are different from the "default" layout (which is the only one supported now). It can be achieved later with things like "grid layouts and alignments" or other kind of opinionated layouts.

The Layout API is not yet in a place where we can open it more broadly though. In the first days, we'd only support the default one and I'd like to discourage folks from changing the "meaning"/"semantics" of these things with CSS. Doing that just means potential future breakage.

fklein-lu · 2021-03-24T16:11:08Z

I do agree with this and it's exactly why the "layout" config applies to the post editor and not the site editor. In the site editor, you define the containers that support it explicitly

Right, but re-using the same terms means that this will lead to confusion.

Why not allow theme developers to define their own set of widths, rather then staying with "wide" and "full"? Plus a box to define the width manually as it is now the case.

In that sense the layout controls would work the same as the font size controls for example. Either use a pre-defined width, or define it yourself.

That seems to me a lot clearer then reusing existing terminology and interface elements from the post editor. Plus that "Inherit default layout" toggle is weird from an interface perspective, and it's not super clear what the default actually is. The interface doesn't tell you that at all.

youknowriad · 2021-03-24T16:32:08Z

Why not allow theme developers to define their own set of widths, rather then staying with "wide" and "full"? Plus a box to define the width manually as it is now the case.

Defining your own set of widths is very related to Grid block proposal as well. It's not something that impact the container block only, it impacts controls of the children blocks too that become dependent on the parent. It's a new kind of UI and behavior that doesn't exist in any of the editors. The goal for the first iteration of the layout proposal is to actually fix what already exists (wide/full alignements which a lot of blocks already support) and build the framework pieces that allow more advanced layouts like you suggest. There's time for everything, we can't build everything in one ago, we iterate towards it.

kjellr · 2021-03-25T14:57:41Z

While we sort out those larger questions, would someone mind giving this PR a review? At the moment, TT1 Blocks looks pretty broken while running the trunk branch of Gutenberg. Even if we adjust this system later on, I think it's worthwhile to get this working for now.

youknowriad

This looks good to me. We can iterate if we find things we missed in the refactor.

kjellr · 2021-03-25T15:22:16Z

Thanks! @youknowriad do you know when is this alignments update will be published to the plugin repo? We can make sure to push a new version of TT1 Blocks to the theme repository when that happens.

youknowriad · 2021-03-25T15:33:07Z

yes, next Wednesday

kjellr · 2021-03-25T15:42:09Z

Awesome, thank you!

Update TT1 Blocks to use Gutenberg alignments

bafb68b

kjellr added the bug Something isn't working label Mar 18, 2021

kjellr requested review from youknowriad and scruffian March 18, 2021 15:18

kjellr self-assigned this Mar 18, 2021

kjellr commented Mar 18, 2021

View reviewed changes

Merge branch 'master' into update/tt1-blocks-alignments

521af9b

youknowriad reviewed Mar 19, 2021

View reviewed changes

Remove align-wide theme support.

c0ffaf4

carolinan reviewed Mar 22, 2021

View reviewed changes

Remove group inner containers, add layout inherit:true where applicable.

af20e47

Template cleanup

70a0783

Update the single template to allow the header to be wide aligned whi…

b2fa32b

…le the content area allows full widths

Add missing main group wrapper to the single template.

86fb5f8

MaggieCabrera mentioned this pull request Mar 23, 2021

Twenty Twenty One Blocks: Update alignment rules #104

Closed

mtias mentioned this pull request Mar 23, 2021

Site Editor - Regression - Alignment styles are broken. WordPress/gutenberg#30112

Closed

Remove unnecessary alignfull declarations

21a8e18

remove alignment rules for the separataor

406df13

Update all templates for proper alignment.

28f2782

youknowriad approved these changes Mar 25, 2021

View reviewed changes

kjellr merged commit c234d5d into master Mar 25, 2021

kjellr deleted the update/tt1-blocks-alignments branch March 25, 2021 15:21

bobbingwide mentioned this pull request Apr 9, 2021

Properly implement alignwide and alignfull styling bobbingwide/fizzie#44

Closed

Update TT1 Blocks to use Gutenberg alignments #236

Update TT1 Blocks to use Gutenberg alignments #236

Conversation

kjellr commented Mar 18, 2021

kjellr Mar 18, 2021

Choose a reason for hiding this comment

youknowriad Mar 19, 2021 • edited Loading

Choose a reason for hiding this comment

youknowriad left a comment

Choose a reason for hiding this comment

carolinan Mar 22, 2021

Choose a reason for hiding this comment

youknowriad Mar 22, 2021

Choose a reason for hiding this comment

kjellr Mar 22, 2021

Choose a reason for hiding this comment

kjellr commented Mar 22, 2021

youknowriad commented Mar 22, 2021

youknowriad commented Mar 22, 2021

kjellr commented Mar 22, 2021

youknowriad commented Mar 22, 2021

scruffian commented Mar 22, 2021

kjellr commented Mar 22, 2021

youknowriad commented Mar 22, 2021 • edited Loading

youknowriad commented Mar 22, 2021

kjellr commented Mar 22, 2021 • edited Loading

youknowriad commented Mar 22, 2021

carolinan commented Mar 23, 2021

carolinan commented Mar 23, 2021 • edited Loading

scruffian commented Mar 23, 2021

kjellr commented Mar 23, 2021

scruffian commented Mar 23, 2021

kjellr commented Mar 23, 2021

carolinan commented Mar 23, 2021

kjellr commented Mar 23, 2021

fklein-lu commented Mar 24, 2021

carolinan commented Mar 24, 2021

youknowriad commented Mar 24, 2021 • edited Loading

fklein-lu commented Mar 24, 2021

youknowriad commented Mar 24, 2021

kjellr commented Mar 25, 2021 • edited Loading

youknowriad left a comment

Choose a reason for hiding this comment

kjellr commented Mar 25, 2021 • edited Loading

youknowriad commented Mar 25, 2021

kjellr commented Mar 25, 2021

youknowriad Mar 19, 2021 •

edited

Loading

youknowriad commented Mar 22, 2021 •

edited

Loading

kjellr commented Mar 22, 2021 •

edited

Loading

carolinan commented Mar 23, 2021 •

edited

Loading

youknowriad commented Mar 24, 2021 •

edited

Loading

kjellr commented Mar 25, 2021 •

edited

Loading

kjellr commented Mar 25, 2021 •

edited

Loading