-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Global Styles: Fix Separator block color use #67269
base: trunk
Are you sure you want to change the base?
Changes from all commits
3aae7d5
27ece0c
e71fd97
ba610d7
4074641
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,3 @@ | ||
https://github.com/WordPress/wordpress-develop/pull/7927 | ||
|
||
* https://github.com/WordPress/gutenberg/pull/67269 |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -8,6 +8,13 @@ | |
border-bottom: none; | ||
} | ||
|
||
// 0-2-0 specificity required to enforce block instance | ||
// color selections over global styles. | ||
.wp-block-separator.has-background, | ||
.wp-block-separator.has-text-color { | ||
border-color: currentColor; | ||
} | ||
Comment on lines
+11
to
+16
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Just so I understand:
The CSS rule above addresses this issue for me in the editor and frontend:
Do block style variation global styles need the same treatment? 🤔
The background color is set, but the theme.json border color still affects the appearance. Here's what I'm seeing in in the frontend: :root :where(.wp-block-separator.is-style-wide--2) {
background-color: #00ff40;
}
:root :where(.wp-block-separator) {
}
:root :where(.wp-block-separator) {
border-color: currentColor;
border-width: 0 0 1px 0;
border-style: solid;
color: var(--wp--preset--color--contrast);
} |
||
|
||
// Dots block style variation | ||
:root :where(.wp-block-separator.is-style-dots) { | ||
text-align: center; | ||
|
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.
Noticed over here: #57297 (comment)
What do you think we should do about gradients? If anything at all?
They are applied to the
background
prop, but don't really have any effect. Andlinear-gradient
is invalid forcolor
andborder-color
anyway as far as I see 🤔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'll dig into this one tomorrow and see if there's anything we can smooth out.
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've spent some time on an archaeological dig today around the addition of gradient support to the Separator block.
The TL;DR is that I believe it was simply mistakenly added. It wasn't referred to at all on the original PR and doesn't appear to have been tested in any way either. From what I can tell gradients have been broken since their adoption.
So...here's the long version of my current understanding 😅
background
CSS propertyhr
element will inheritcurrentColor
for itscolor
CSS valuebackground
color
property effectively masking any gradient applied herebackground
property has alinear-gradient
value at all, copying that toborder-color
orcolor
results in an invalid CSS rule and falls back tocurrentColor
gradient
isn't retrieved and processed like thebackgroundColor
valuecustomColor
is determined it only takes into accountstyle.color.background
forgetting aboutstyle.color.gradient
linear-gradient
while it sort of works the//
characters don't get the gradient and hovering the block in the editor breaks the//
onto separate lineshr
element to not use border or color, give it a height or padding and then apply any background style including gradients.At the end of all of that, I'm not sure if this is fixable to a degree where the Separator block could reliably have gradients applied to it. If it was "fixed" it might only be for use cases where the Separator block has had its default styles overridden or has a block style that makes
color
transparent, removesborder
, and gives it a visible height.I'd like to see gradient support removed from the block. Given its current broken state and that it has been that way since its inception, I don't think there's much of a backwards compatibility argument to be made. Removing the gradients support at least lowers complexity and maintenance burden moving forward.
What do you think @ramonjd?
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.
Amazing digging, thank you!
+1
In any case, since it's a long-standing issue, and doesn't affect the intention of this PR it's a "tomorrow" thing.
I appreciate the time you spent researching. It'll be useful to whoever picks it up.
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 removing support it should only be deleting a single line from the block.json. Despite that, still worth a separate PR to debate and document the decision. I'll spin that up after I work through the possible follow-up for the issue Dan flagged below.