Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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: simplify how we register preset metadata #35228
Global Styles: simplify how we register preset metadata #35228
Changes from all commits
e9bdf05
12482fa
dd796b4
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
properties
is missing in the documentation here, but since the purpose of the properties being checked is for the generated.has-$slug-$property
classes, is a separateproperties
array really needed here?Duotone, for example, never sets the
filter
property from settings—that's left up tostyles
to handle. We're only setting the--wp--preset--duotone--$slug
variable from this set of metadata.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
properties
are used exclusively byremove_insecure_properties
(the kses method) and nowhere else. This method was reusing thecss_var_infix
, but that didn't work for duotone because the infix is not the name of the property to be used (filter
) but other thing (duotone
).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.
After this PR,
remove_insecure_properties
understands which property maps to the duotone data (before it testedduotone: value
, now it testsfilter: value
). The second step is to also teach it that the property value can come fromvalue_func
(it assumesvalue_key
for everything). For simplicity, I'll do that in a follow-up PR.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.
My point is that the CSS that needs to be checked in
remove_insecure_properties
is this for duotone:It has nothing to do with the
filter
property. That check should be inremove_insecure_styles
.And this for things like color:
So it makes sense to check the
classes
like before—not a newproperties
key.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 properties array isn't used to generate the CSS, so we're not actually testing the generated CSS by using the
properties
array. The generated CSS is coming fromclasses
.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.
By the way, #35255 is the continuation of this work. It updates
remove_insecure_settings
to consider presets that use thevalue_func
. Welcome reviews :)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.
#35318 is for making
remove_insecure_styles
work with duotone data.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.
Thank you for the well-written explanation! I've also stepped through
remove_insecure_properties
and intosafecss_filter_attr
in a debugger to get a more detailed idea of exactly what is going on.This is the core of what feels weird to me that I was trying to get at. Maybe
safecss_filter_attr
isn't the right tool for what we're trying to do. A function that is aware of the CSS custom properties and doesn't have to substitute CSS properties where the variable is used would be less confusing and could be made to be more robust.We have to add properties in the first place because we know how kses (
safecss_filter_attr
) works internally—it can't handle CSS custom properties. If we wanted to be truly transparent to how kses works, we should be able to pass the properties directly to either kses or a new function that can handle them as they appear in the stylesheet.If you want to talk more about it, I'd be happy to hop on a call and write up a summary for here. I might not be explaining my perspective on this very well. 😅
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.
Not really! We add properties because that's how the CSS vars are going to be used in the classes & styles the engine generates. For example, color presets generate the vars plus the classes:
And they are also expected to be used in the corresponding
theme.json
styles:styles.border.color
,styles.color.background
,styles.color.text
, etc.Those are the properties we need to check for.
We could argue that this info is already in the
classes
key of thepresets_metadata
array. However, not all presets generate classes (e.g. duotone), hence why we need a separateproperties
key for clarity.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.
Couldn't
remove_insecure_properties
keep track of the CSS custom properties that we generate and use, and then check them without needing to manually add theproperties
key?