[#45] Page blocks and sections #48
Conversation
- Adds TW class for default site max width
- Uses both image & icon cards
- Update cards & buttons to use new window.
- Simple is just Bold, Italic, Underline plus links - Advanced has more options like headings, styles, lists, etc.
Whoops :)
There was a problem hiding this comment.
The heading is always a h1
The description is the "Simple" CKEditor config. It allows Bold, Italic, Underline and Links.
There was a problem hiding this comment.
The heading will be an h1 if there are no prior blocks with h1 tags in them (either the Page Hero and a Heading block). Otherwise it turns into a H2
If the heading block is right before a rich text block, there is slightly less spacing after it, which makes it look like part of the rich text field.
There was a problem hiding this comment.
The "Advanced" CKEditor config contains bold, italic, underline, links, block quotes, lists, and indentation.
There's a basic .rich-text class on the front end that applies stying and spacing to these elements.
There are also four text size styles that can be applied to paragraphs to make them larger / smaller.
Headings & Accessibility
There are no heading tags. The hope is that the Heading page block will be sufficient, giving control over headings without need to add Retcon to the rich text editor. Retcon is a great option if you'd like to add more complexity to the Rich Text field, but I'm hoping to strike a balance between flexibility and simplicity.
| Craft Admin | Front End |
|---|---|
 |
 |
There was a problem hiding this comment.
Has an optional heading field. When the heading is present, it is an h2 while all cards use h3.
If no heading is present, the cards are h2 in order to avoid skipping heading levels.
Icon & Image cards are allowed in the grid.
There was a problem hiding this comment.
This block supports the Advanced CKEditor style.
Both videos and images are supported. Those fields are conditional depending on which ratio option you select.
The media can be on the right or left side.
| Craft Admin | Front End |
|---|---|
 |
 |
There was a problem hiding this comment.
The call to action field has a title, description (simple CKEditor) and an optional button.
If the button text is left empty, and the link field is an element, that value is used.
| <div class="{{ cx({ | ||
| 'pt-64': blocks.first().type.handle not in ['pageHero', 'callToAction'], | ||
| 'pb-64': blocks.last().type.handle not in ['callToAction'], | ||
| }) }}"> |
There was a problem hiding this comment.
There is vertical padding applied to the page builder.
However, if certain full bleed blocks are at the start / end, that padding will be removed.
| {# | ||
| Check if there are previous blocks that have a heading level of 1. This is used | ||
| to determine if the current block should use an h1 or h2 as its root heading level. | ||
| #} | ||
| {% set hasPreviousBlocksWithH1 = previousBlocks | ||
| |map(block => block.type.handle) | ||
| |intersect(['pageHero', 'heading']) | ||
| |length | ||
| %} |
There was a problem hiding this comment.
Logic to determine changes in heading level
| {% set marginBottom = [ | ||
| nextBlock ? "#{block.type.handle} + #{nextBlock.type.handle}" : null, | ||
| block.type.handle, | ||
| 'default', | ||
| ] | ||
| |map(item => marginBottomConfig[item] ?? null) | ||
| |filter | ||
| |first | ||
| %} |
There was a problem hiding this comment.
Would love any thoughts on this logic that nudges the heading block and rich text fields closer together.
Maybe it's too complex and I should just bake a heading field into the Rich Text Block 🤷
The idea is to sequentially check a few different aspects of block handles before.
By checking the most specific combinations first, that should let us add cases where a specific block has unique margins when followed by a specific block AND unique padding for just that block.
Here's an example of that scenario:
{% set marginBottomConfig = {
default: 'mb-64',
'heading': 'mb-40',
'heading + richText': 'mb-32',
} %}Pretending that the block builder populated these values
In the case that heading is followed by richText, that margin will win out.
However, in a different scenario (say heading + cardGrid) there is no matching marginBottomConfig, so the heading config wins.
{% set marginBottom = [
'heading + richText',
'heading',
'default',
]
|map(item => marginBottomConfig[item] ?? null)
|filter
|first
%}
There was a problem hiding this comment.
🤔 this is tricky. My opinion is that this gets into spacing and styling that will be specific to a given design. But I also appreciate that this is here as a ready solution if needed. 🤷
There was a problem hiding this comment.
I wish the Craft link field had link text and new window baked in.
But it's a small price to pay for getting to use stock fields.
templates/_blocks/_cardGrid.twig
Outdated
| </h2> | ||
| {% endif %} | ||
| <div class="grid gap-24 sm:grid-cols-2 md:grid-cols-3 lg:grid-cols-4 lg:gap-48"> | ||
| {% for card in block.cardGrid.eagerly().all() %} |
There was a problem hiding this comment.
Eagerly is soooo nice .
joshuapease
force-pushed
the
jp/45-page-blocks-and-sections
branch
from
8e2dee3 to
c814436
Compare
There was a problem hiding this comment.
👍 this looks good and I think the basic built-in styles make sense. Re: your thoughts about additional flexibility and config, I would recommend leaning toward component simplicity where UI buildout or design-specific modifications can be additive. More specifically to your examples, don't add block background pickers (much of the time UI buildout will handle this). It can be added if needed for a particular site. That'll keep the starter simpler and easier to maintain. Plus, we can always add it in if we see that it's a common need!
| {% set marginBottom = [ | ||
| nextBlock ? "#{block.type.handle} + #{nextBlock.type.handle}" : null, | ||
| block.type.handle, | ||
| 'default', | ||
| ] | ||
| |map(item => marginBottomConfig[item] ?? null) | ||
| |filter | ||
| |first | ||
| %} |
There was a problem hiding this comment.
🤔 this is tricky. My opinion is that this gets into spacing and styling that will be specific to a given design. But I also appreciate that this is here as a ready solution if needed. 🤷
I come back to a general question of the purpose of this starter. For me, it’s very helpful to have this reference of our standard plugins and configurations, but I have trouble seeing the value of adding more than that when I look at the real pipeline of incoming projects and their potential variety of size and shape. Craft excels as a base for implementing bespoke designs and I've never encountered a project where that part of the process can be done more efficiently or cheaply by starting from a base of styles. These are all great and clever additions that might be the way we'd approach a project, but also might not be. I don't think there's such a thing as a universal boilerplate when it comes to components or styles and the more that gets added to this starter, the more friction I feel like it will present when we bring it to a project. |
Totally valid points and certainly true for many types of Craft projects. These blocks aren't really intended to be universal or work for all projects. The primary goal for these blocks (as well as the blueprint components) is to provide the sales team with an optional path to reducing the cost for certain Craft projects. Those savings would really only be realized if sales, design and development choose to work within the constraints of Blueprint (see Docs & Whimsical) These are a few of the constraints/cost savings I had in mind:
What's so great about Tailwind and Alpine is that the cost of discarding a block or component is so minimal. Most everything is colocated in a single file (with the exception of needing to delete an entry type or field). I honestly think the biggest benefits from Blueprint is that it could improve our shared language for building sites. The Blueprint repo provides a common spec that designers and developers can use (component names, props, style variants). It could lead to better conversations like these:
I agree with that feeling too. I certainly don't want the act of deleting unwanted things to outweigh the benefit of having common patterns to start from. As it stands right now... it doesn't seem like it would take more than 15-30 mins to do the following:
After we have a better grasp of what sort of Craft projects are common, we could look into scripting that process (either to eject blueprint, or make it opt-in). All really good points to consider. Happy to chat more in Slack, TTT, or a PL/UI standup (or all three!). |
The nav has a max depth of 3 levels. This simplifies our markup since it doesn't have to be recursive
The desktop and mobile nav markup will be their own partials.
Instead of using a focus trap, we focus on the first element in the sub nav, but allow you to tab out of the list. When focus leaves, we pop the subnav.
Overview
Each the project config files for each block has a comment and screenshots of the Admin / Front End.
Note
One block I haven't made yet is the logo grid block. That one felt a little lower priority than the others. Made a ticket for it here.
Looking for feedback
Flexibility of config
I opted for simplicity in this first round. But was thinking about things like editing column counts, widths (how wide RTE content is, variations of text/media block), spacing between blocks, block background colors, etc.
How essential do y'all feel that is to a starter? Or would that just be adding options that a designer might not even want to build for.
Accessibility / Headings
After chatting with y'all in standup, I took a step back and thought I'd try the simpler option first. Details are in a comment on the heading block.
How to test
Create a directory for your new Craft project
Then move into your directory
Run the following composer create-project command.
It uses this branch as the starter project.
Next, install Craft