-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Site Tagline Block #23788
Site Tagline Block #23788
Conversation
Size Change: +220 B (0%) Total Size: 1.14 MB
ℹ️ View Unchanged
|
"align": { | ||
"type": "string" | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think you don't need to add that as an attribute but can just add it to supports
. See for syntax.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See #23788 (comment)
<AlignmentToolbar | ||
onChange={ ( newAlign ) => | ||
setAttributes( { align: newAlign } ) | ||
} | ||
value={ align } | ||
/> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think adding align
to suppports
will give you the AlignmentToolbar
out of the box 🤞
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ockham The difference is that align
in supports
is the block alignment, while in this case it would be the text alignment.
Two major differences, off the top of my head:
- Block alignment also (optionally) supports
wide
andfull
. - Block alignment
left
andright
makes the block floating.
This said, your point makes sense in that we might want this block to support both block (as align
supports
) and text alignment (as textAlign
attribute).
I don't see any other Core block doing the same thing, and I wonder if it's an intentional UX choice (it might be confusing for the user).
A middle ground could be to have align
only support wide, full
. 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Right, thanks for clarifying.
I do think that this has the potential of being quite confusing to the user, so I wouldn't be surprised if it was a deliberate UX choice.
Do blocks that are somewhat comparable to Site Description tend to have either align or text align?
If we do go with text align, let's rename the attribute to textAlign
, to make it easier to distinguish from block align.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The most comparable is arguably Site Title, which indeed only has the text alignment with the align
attribute name.
(It's not a coincidence, I've mostly copied it to build the Site Description block... 😄)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we do go with text align, let's rename the attribute to textAlign, to make it easier to distinguish from block align.
I agree, but I'd love more Gutenberg folks chime in on this.
As far as I can see, only Verse uses textAlign
for text alignment, while all other blocks simply use align
.
5c54a58
to
50ee9d3
Compare
Added support for experimental colors, font size, and line height (introduced in #23007). Basically the Site Tagline block is almost identical to Site Title.
About the output element: I'm wondering if we might even "downgrade" it to a simple Either way, I've chosen not to include the Site Title's level selector (to set it as heading element) following the path laid out by the Twenty themes: the last one using an |
I kinda like that, and I think it's less generic than the |
a1897c4
to
dc82e48
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 👍
Thanks @ockham! I've updated the icon to use the one from the old PR. I've also added a |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I spent a lot of time learning about block.json
and experimental-themes.json
. Not an expert with the Gutenberg metadata interface, but as far as the code goes, everything looks reasonable.
I did notice one curious behavior that affects all blocks that can modify colors (including site-tagline
). To clarify, this seems best addressed in a follow-up PR.
For any block with a background color set as a direct child of a group block, text padding isn't appropriately applied. After some digging, it looks like padding styles are being overwritten by group
block css here on L51-52 and L59-60.
This occurs for me in chrome, firefox, and safari.
I'll make a separate issue for this in Gutenberg if that sounds good to you @Copons
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jeyip I'm not sure, let's ask @vindl! 🙂 One thing about this kind of visual issues that I didn't think of mentioning earlier (I haven't checked the issue yet, btw): they might be caused by the theme's own editor style, in which case Gutenberg might not be at fault. If this is the case, we have a few options. For example:
For experience, styling nested blocks in the editor is a major pain, especially when we go out of our way to customize the blocks margins. |
So this feature is planned to be released with a near future Gutenberg release? |
(see my response on #24246) |
Description
Replaces #18241
Add a Site Tagline (aka Site Description) block for the Site Editor.
It supports colors, font size, and line height out of the box.
How has this been tested?
Tested in the Site Editor, on both Firefox 78 and Chrome 83 on macOS 10.15.5.
Screenshots
Types of changes
New feature (non-breaking change which adds functionality)
Checklist: