-
Notifications
You must be signed in to change notification settings - Fork 182
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
Add a theme that uses the latest block style system + block templates #39
Conversation
bigsite/style.css
Outdated
|
||
.home .entry-content > .wp-block-cover { | ||
height: 100vh; | ||
} |
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.
A good exercise here would be to try to understand why every style rule here is needed, and whether it's something that should be absorbed by block attributes that are missing or something expected to rely on CSS.
"color": "var(--wp--preset--color--valencia)" | ||
} | ||
}, | ||
"core/heading/h1": { |
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'm not sure if I see how this does anything. Removing it does not change anything relating to the output or color of an H1 tag. @jffng Would you be able to help me understand what this is doing? 🙏
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.
Yeah, I haven't been able to get this part to work either (both here and in another theme I tried this with).
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 the API changed since I first opened this PR. Just pushed some changes that should address it, tested on GB 8.3.
colorful/experimental-theme.json
Outdated
"value": "#FFDE69" | ||
}, | ||
{ | ||
"slug": "navy", |
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.
@jffng Could you help me understand why a slug is needed here? If the slug is navy
and that is then used as part of a CSS variable name, I feel like that might defeat the purpose of a CSS variable. To me, the purpose of a variable is that the value van vary. If the value (navy
or 022384
) is used in the name, you can't change the value of that variable without the name becoming redundant. Once I change the value of --wp--preset--color--navy
to something other than #022384
, the word "navy" no longer describes the value.
That makes me wonder if slugs should be completely removed, and automatically generated to create a predictable standard which themes could rely on their stylesheets. They could be named based on their order, for example:
--wp--preset--color--one
--wp--preset--color--two
--wp--preset--color--three
If I am totally misunderstanding something, please let me know!
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.
Totally agree. I’ve gone with primary, secondary, etc in the Go theme (for this same reason).
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.
We also had an issue recently where a popular plugin overwrote the primary and secondary color values, which is often not what we want?
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.
Yeah, for now the slug is only used to generate a CSS variable name, so something more generic would make sense.
The exact names here relate back to this old issue around whether or not to standardize custom color names: WordPress/gutenberg#7553
Some standardization does make sense, and the advent of Global Styles may be a good time to start.
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.
@johnstonphilip thanks for the review!
Re: slugs, that's a fair point. In the case of colors, they could be something generic. I named them as such because it made the example more straightforward to keep my naming straight between the editor, the theme's stylesheet, and the theme config.
That makes me wonder if slugs should be completely removed, and automatically generated to create a predictable standard which themes could rely on their stylesheets
I think I agree. Right now there is no relationship between presets
and styles
in the theme config. It could make sense if there were a set of common CSS variables that Gutenberg used to predictably style core blocks, and themes could override.
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.
popular plugin overwrote the primary and secondary color values
@carolinan out of curiosity, what do you mean? The theme would provide some CSS variables, and an unrelated plugin would overwrite them because they happened to be named the same?
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.
Yes, like this: Yoast/wordpress-seo#15345
Fix styles implementation.
This was a good way to explore an early implementation of the |
This PR adds a minimal theme example whose styles rely the latest iteration of the Global Styles mechanism.
The theme supplies one block template (just an
index.html
that renders the post content), anexperimental-theme.json
, along with the necessaryfunctions.php
file.(Design inspired by Beatriz Fialho)