Testing: Page building improvements

[jimsafley]

We’ve added quite a few new features to the page building interface. With these features, we hope to give users more control over page building without the need to modify the HTML or CSS of their themes.

Layout (page and block)

Above the blocks, you'll notice the new page layout controls. The controls include a "Layout" select, where users can select between two layouts:

• Normal flow: This is the default, legacy page layout—blocks stacked on top of one another.
• Grid: This is the new page layout—blocks positioned in a grid, leveraging CSS grid. Much of the layout variety in custom websites come from some kind of grid framework. This new layout opens up the possibilities for organized and structured content presentation with Omeka S, without the user having to know any code.

When the user selects "Grid" the page layout controls will include a "Columns" select, and each block will include a "Position" select and a "Span" select in their headers.

• Columns (1-12): Select how many columns the grid will have on the page.
• Position (auto, 1-n): Select the column position that the block will begin on the row. The possible positions depend on the selected span. Users cannot position a block in a way that exceeds the number of columns. The "auto" option places the block in its natural position, depending on the surrounding context. In most instances, users will select auto position because blocks will span continuously on a row, with no empty columns. Users will select a numbered position in the event they want empty columns somewhere in the row.
• Span (1-n): Select how many columns the block will span in the row. The possible spans depend on the selected columns. If users span a block in a way that exceeds the number of columns, the block will fall to the next row.

We've added a "Restore" button to the page layout controls that restores the saved state of the layout. Setting a grid can be complicated, so users will likely want to restore the previous state without having to reload the page and possibly lose other settings in the process.

To help users visualize the layout without having to save the form and view the public page, we've added "Preview layout" buttons that open a sidebar containing a simplified, visual representation of the layout. The page layout controls and each block header have a preview button. When a user clicks a preview button on a block, the preview sidebar opens with that block highlighted.

Layout configuration (page and block)

To provide even more options for page builders, we've added "Configure layout" buttons that open a sidebar containing a configuration form. These settings affect the style of the layout in multiple ways (see below for the list of configuration settings). The page layout controls and each block header have a configure button. The "Page layout configuration" form includes the following settings:

• Template: This allows theme developers to provide prebuilt custom views to their content collaborators through the admin interface.
• Column and row gap: These options allow control over uniform spacing within a grid layout. These options are not visible in the normal flow layout.

The "Block layout configuration" form includes the following settings:

• Template: This option is similar to the template configuration offered for the page. Theme developers enable custom block options for their collaborators via the page builder interface.
• Class: Sometimes a block does not need a full template to change its look. This text field takes CSS classes to apply block styles made by the theme developer.
• Alignment: This set of configurable options allows for granular control of how block content appears within the flow of the page. This is especially useful for the normal flow page layout, where the content all exists within a single column and relies on wrapping text around featured content areas for visual interest.
  • Block alignment: This controls the block’s layout placement.
    • Default: The block takes the full width of the page with its contents left-aligned.
    • Float left: The block is aligned to the left, but inline content may wrap and flow around it. It occupies a third of the content area width at most.
    • Float right: The block is aligned to the right, but inline content may wrap and flow around it. It occupies a third of the content area width at most.
    • Centered: The block takes up the full width of the page with its contents centered.
  • Text alignment: This controls the block’s text content justification. It offers left, right, centered, and justified.
• Constraints: Some block content needs greater control over their sizing within the context of the page. These inputs take most units valid in CSS.
  • Maximum width: The block stops growing horizontally at this size. This would be useful for something like a callout or featured content structured with an HTML text block.
  • Minimum height: The block must take up at least this amount of vertical space. This can be useful for sizing a decorative heading with a background image, where the user wants to see much more of the background image than the text size allows.
• Padding: This setting allows for spacing between text content and its container. It is particularly useful if the block has a background color or image configured. There are fields for controlling the padding on the top, right, bottom, and left sides of the block. These inputs take most units valid in CSS.
• Background: Many themes can be tailored to a project simply through color and imagery. Configurable backgrounds help with this.
  • Color: This field takes a 3- or 6-digit hexadecimal color code to set as the background.
  • Image: Users can upload a background image for the block.
    • Vertical anchor position: The image starts from the top, bottom, or center.
    • Horizontal anchor position: The image starts from the left, right, or center.
    • Size: By default, the background image appears at its inherent size and tiles. It can be sized to either cover the whole container, or be contained fully by the width or height of the block. The background image is set to not tile when either cover or contain are selected.

Block groups

In addition, we've added a new, special "Block group" block. Block groups are one way to ensure that related blocks with different content types can sit with each other on the page. Within a robustly populated page builder interface, block groups allow for easier reordering of related content.

Users can add a block group using the "Add block group" button in the "Add a new block" sidebar header. Once the block group is on the page, users may drag-and-drop blocks into the group. A block group cannot contain other block groups. Users may also drag-and-drop groups up and down the page. Collapsing a block group will collapse all child blocks.

Similar to standard blocks, users may configure the block group layout. The configuration form contains a subset of the normal form, including class, padding, and background. Users can provide a theme-specific class that styles all the blocks within the block group the same way. They can also provide a background image for a group of related blocks.

Migration

Note that we’ve migrated a few block settings to block layout settings. Blocks that had a "Class" setting (HTML) should now have a corresponding "Class" block layout setting. Blocks that had an "Alignment" setting (Asset, Media) should now have a corresponding "Block alignment" block layout setting, with ones set to a "center" alignment converted to a center "Text alignment" block layout setting. Please make sure to test this migration by setting a class to the HTML block, and an alignment to Asset or Media blocks prior to updating.

[allanaaa]

I haven't tested it yet, but - with the new CSS grid elements, has anyone checked to see if the CSS Editor module can point to them all?
I think all of these should be included (other than the experimental ones): https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_grid_layout#properties

[allanaaa]

Doing some settings comparisons on grid (3 columns):

http://dev.omeka.org/amayer/amayer-s/omeka-s/s/my-omeka-s-site/page/my-grid-page

1. The text-alignment isn't doing anything. I can see the class block-layout-alignment-text-right and block-layout-alignment-text-center in the code, but no corresponding CSS is applying.
2. The page title at the top, with the background image, isn't actually spanning all 3 columns; its width is being set by its contents rather than the available space, so the background image isn't displaying as I would expect (I know I have it set to center alignment, but I would think span-3 would override that - and if it was basing its width on the center-alignment it would still be 248 pixels wide, right?).
   2b. The last one is also set to span all 3 columns, but is only as wide as its max setting, so that's working as expected, and when I remove that max-width it behaves like I would expect the top title to. It's set to float left, which looks like it's being overridden by the span-3. So I can't tell why these two are behaving differently.
3. H2 has a margin-bottom of 24px, which we probably want to get rid of in this page-title context.
4. I'm not clear on why the title in the grey box has a left margin. Generally, I'm not sure if we should have any margin by default - since we have the Column Gap and Row Gap settings now....
   4b. ... Which are in pixels, I imagine. Can the admin interface say "Column gap (in pixels)" and "Row gap (in pixels)"?
5. It looks like, where a margin is being assigned, it's at "1rem" which is calculating to 16 pixels - I think this should match the gap settings (currently 10px on my page). Maybe I just need it clarified for me how the user-set gaps are being inputted into the code. Other blocks on the page seem to respect the gap settings without using margins.
6. The presence of a Block Group shouldn't have any effect on the row and column gaps, right? There should be empty space between the two page titles that are currently touching?
7. Should there be empty space under the last page title, before the end of the block group (the light grey background)? Is that considered a row gap, or should the group end exactly where the last item ends?

[kimisgold]

The text-alignment isn't doing anything. I can see the class block-layout-alignment-text-right and block-layout-alignment-text-center in the code, but no corresponding CSS is applying.

I don't know where these styles went, but they're back in now.

The page title at the top, with the background image, isn't actually spanning all 3 columns; its width is being set by its contents rather than the available space, so the background image isn't displaying as I would expect (I know I have it set to center alignment, but I would think span-3 would override that - and if it was basing its width on the center-alignment it would still be 248 pixels wide, right?).

We currently center blocks with the selector .block-layout-alignment-block-center with the rule margin: auto. This is what causes the container to shrink to the block's maximum content width, so that it can put an equal amount of space on either side of the block. If the block's content wraps, it takes up the full width of all 3 columns. This all makes sense to me: the block is centered within the span of 3 columns, which is most apparent if the block content is smaller than the 3 columns. If you want to take up the full span of the 3 columns, set the block alignment to default. If you want to center the text of a page title block with a background filling the full width of 3 columns, use text alignment center (which should now be fixed) and default block alignment.

2b. The last one is also set to span all 3 columns, but is only as wide as its max setting, so that's working as expected, and when I remove that max-width it behaves like I would expect the top title to. It's set to float left, which looks like it's being overridden by the span-3. So I can't tell why these two are behaving differently.

CSS float operates differently from margin: auto in combination with grid-columns in a way I didn't expect. For consistency with how centered block alignment works, I would want to add width: max-content.

I'm not clear on why the title in the grey box has a left margin. Generally, I'm not sure if we should have any margin by default - since we have the Column Gap and Row Gap settings now....

The left margin is because the block is floated right. The column and row gaps are specific to grid layout. It might be that the float styles don't really make sense within a grid context...

4b. ... Which are in pixels, I imagine. Can the admin interface say "Column gap (in pixels)" and "Row gap (in pixels)"?

Fixed.

H2 has a margin-bottom of 24px, which we probably want to get rid of in this page-title context.

Maybe more specifically if the page title block has a background?

It looks like, where a margin is being assigned, it's at "1rem" which is calculating to 16 pixels - I think this should match the gap settings (currently 10px on my page). Maybe I just need it clarified for me how the user-set gaps are being inputted into the code. Other blocks on the page seem to respect the gap settings without using margins.

The gap settings are being set as inline styles on the grid container, and affect first level children of that container. It's difficult for me to imagine how to implement taking the user-submitted gap value and applying it to everywhere we're setting margin: 1rem, but I'll think on it.

The presence of a Block Group shouldn't have any effect on the row and column gaps, right? There should be empty space between the two page titles that are currently touching?
Should there be empty space under the last page title, before the end of the block group (the light grey background)? Is that considered a row gap, or should the group end exactly where the last item ends?

This is a result of block groups distancing their children from the grid container that has the inline style for the gaps. Much easier to fix though.

[allanaaa]

The left margin is because the block is floated right. The column and row gaps are specific to grid layout. It might be that the float styles don't really make sense within a grid context...

Yeah, I agree with this. Simplifying the options in the admin side sounds good to me.

H2 has a margin-bottom of 24px, which we probably want to get rid of in this page-title context.

Maybe more specifically if the page title block has a background?

Also agreed!

[allanaaa]

I'm now getting something funny that might be because of block groups, and seems to be some sort of unintended effect of the HTML block?

The two page titles have the same settings now (besides one bg image and one bg colour). The second one is inside a block group (light grey) and isn't behaving the same way as the first one, above the block group.

Oddly, if I change the HTML block (dark grey) to span-2 (out of 3) instead of span-3, I get this instead?

Neither is correct: the blue page title should be span-2 no matter what.

The HTML block is now also supposed to span 2 and doesn't seem to be getting the correct width. There are no margins being added or anything, it just suddenly is slightly narrower than it was, but not as narrow as I'd expect.

[allanaaa]

The problem above was fixed by a commit by @zerocrates yesterday.

Can we set the margin-top on <p> to 0? It's a small quibble but if users can set padding inside the HTML blocks there's no reason to have any margin-top there.

On a normal flow page the text lines up next to a floating object like this:

But on a grid page it has all this extra whitespace:

I also want a margin-bottom that doesn't apply to the last <p>:

p {
margin-top:0;
&:not(:last-child)  {
margin-bottom: 16px;
}
}

ETA: .preview-block also has a top margin I would get rid of. I'm not sure you need that wrapping div at all, surely that can all be done by .block-browsePreview at the block level?

[sharonmleon]

In testing the migration of the blocks from 4.0.4 to 4.1, with a media embed block that was set to align center, in the migrated instance the alignment is copied both to the Block Alignment and the Text Alignment. In contrast, a media embed block that was floated right only transfered the alignment to the Block Alignment, and the Text Alignment remains Default.

The block that was Item Showcase successfully converts to Media Embed with alignment for the block and the text set to default.

[kimisgold]

@allanaaa Your margin fixes should be in now, ready for a look.

[allanaaa]

Which margin fixes precisely are in this? I've mentioned a lot of margins so far :(

It looks like you've split up the normal and grid so that the normal floats get margins, and the grid blocks don't have any margins, which is great.

This line following is overriding the margins you've set in normal, though:

.page-layout-normal .block {
  margin:1rem 0;
}

Blocks in normal are picking up some grid code now:

It also looks like you've added top and bottom margins to center-aligned normal blocks? I don't think these or default blocks need any top margins.

[kimisgold]

Which margin fixes precisely are in this? I've mentioned a lot of margins so far :(

The hope was that it covered all mentioned, but mainly excess top and bottom margins for children of html blocks, inconsistent block margins, and floated element margins appearing in grid.

This line following is overriding the margins you've set in normal, though:

I've made the selectors more specific, so those alignment-specific margins should be taking now.

Blocks in normal are picking up some grid code now.

These grid styles are specific to media embed's horizontal layout. They're our default styles for presenting a sort of gallery view of multiple item attachments.

[allanaaa]

Blocks in normal are picking up some grid code now.

These grid styles are specific to media embed's horizontal layout. They're our default styles for presenting a sort of gallery view of multiple item attachments.

Ah. It's having unintended consequences on the width of the floating block. It's supposed to be as small as its content, not always at the max-width of 33%. Specifically the line width: 100vw is the culprit, I think.

[zerocrates]

On the question about wrapping divs inside blocks like the preview, I decided for the moment to keep them.

You're right that for many/most they're not really needed anymore now that the page is just wrapping a div around each block, but I chose to keep the old ones just to try to avoid problems where existing themes might be targeting the classes used with those old wrappers.

[allanaaa]

Paragraphs and headers still have margin-tops that are having inconsistent effects; sometimes collapsing with others, sometimes not.

I would just add

p, h1, h2, h3, h4, h5, h6 {
margin-top:0;
}

and be done with it.

[allanaaa]

A block in grid will make itself the same height as the block beside it - which I think is not ideal for background-drawing purposes?:

I would want the background colour or image to sit nicely around the content, rather than extend down into a whole bunch of empty space.

But, I realize this is a complicated ask, and a design choice, and one you can sometimes solve with CSS Editor, depending on if there's a div inside the block to point to (yes in media embeds and item carousels, no in html blocks and page titles). I'm not sure which to do by default, or if adding a setting would be unnecessarily complicating the interface. Perhaps we just want classed wrapper divs inside the blocks that don't have them yet (which contradicts what I was talking about two hours ago). I'm not a grid expert yet, though, so I'm mentioning this just in case there's a really good fix.

[allanaaa]

Would you consider adding positions and span settings to block groups?

[zerocrates]

A CSS answer to your problem of backgrounds undesirably extending that doesn't require an inner div: set align-self: start on the block div.

[kimisgold]

Would you consider adding positions and span settings to block groups?

It's possible pending further user feedback from this initial feature release. The amount of development it would take is outside the scope of the 4.1 release.

[allanaaa]

In Normal flow, a block at the end of the page, with a right alignment, is sitting outside the "blocks" and "blocks-inner" divs:

[allanaaa]

A CSS answer to your problem of backgrounds undesirably extending that doesn't require an inner div: set align-self: start on the block div.

Is this something simple enough that we could make it a toggle somewhere in the admin side? The actual size of the grid element doesn't matter, since nothing else can go in that space anyways, so it's really just a visual setting when you're using backgrounds.
Or just suggest it in the docs for use with CSS Editor?

[kimisgold]

Is this something simple enough that we could make it a toggle somewhere in the admin side? The actual size of the grid element doesn't matter, since nothing else can go in that space anyways, so it's really just a visual setting when you're using backgrounds. Or just suggest it in the docs for use with CSS Editor?

It would probably make for a good layout setting. I'll make a feature issue for it so we can plan to include it in maybe 4.2.

[allanaaa]

The page date/time block is picking up some unintended CSS on the The Daily theme:

[allanaaa]

The breadcrumb nav needs a bottom margin, probably just blanket across the core rather than in each theme. But the only one missing it is The Daily:

[kimisgold]

I think we've covered everything in this issue and released the feature in 4.1. If there are any remaining problems to address or new related issues, we should separate them out into their own issue for readability.