CSSTidy: add support for css variable definition

[glendaviesnz]

Fixes issue with block validations when css variables used, eg with group block custom color. Although this is fixed in Gutenberg 10.7 for the group block, there are a number of other blocks that support the css vars for custom colours and it may be a few releases before they are are updated.

There has been previous discussion about the removal of css tidy, and given the age of this library that is probably worth looking at - and maybe a more modern and maintained library like https://github.com/wikimedia/css-sanitizer could be investigated, but as previously discussed this is a much bigger project so adding this css var support may still make sense in the short term.

This would also currently allow the use of css vars in the custom css in the customizer - would that be a bad/dangerous thing?

Changes proposed in this Pull Request:

• Modify CSS Tidy library to allow css variable properties - while this is a modification to the underlying 3rd party library, this library hasn't been updated since 2007 and is no longer maintained.

Does this pull request change what data or activity we track or use?

no

Testing instructions:

• Add related patch to sandbox
• In editor code view add a <div style="--base-color: red;color:var(--base-color)">test css var preservation</div>
• Save the page and reload the editor and check that --base-color property has been preserved in editor and front end.

[matticbot]

Caution: This PR has changes that must be merged to WordPress.com
Hello glendaviesnz! These changes need to be synced to WordPress.com - If you 're an a11n, please commandeer and confirm D61884-code works as expected before merging this PR. Once this PR is merged, please commit the changes to WP.com. Thank you!
This revision will be updated with each commit to this PR

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• ⚠️ All commits were linted before commit.
  
• ✅ Add a "[Status]" label (In Progress, Needs Team Review, ...).
  
• ✅ Add testing instructions.
  
• ✅ Specify whether this PR includes any changes to data or privacy.
  
• ✅ Add changelog entries to affected projects
  

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

---

Once your PR is ready for review, check one last time that all required checks (other than "Required review") appearing at the bottom of this PR are passing or skipped.
Then, add the "[Status] Needs Team review" label and ask someone from your team review the code.
Once you’ve done so, switch to the "[Status] Needs Review" label; someone from Jetpack Crew will then review this PR and merge it to be included in the next Jetpack release.

---

Jetpack plugin:

• Next scheduled release: July 6, 2021.
• Scheduled code freeze: June 28, 2021.

[ramonjd]

With $this->settings['preserve_css_variables'] = true; I created a group block on 10.5.4 (current prod).

Source:

<!-- wp:group {"style":{"color":{"link":"var:preset|color|vivid-red"}}} -->
<div class="wp-block-group has-link-color" style="--wp--style--color--link:var(--wp--preset--color--vivid-red)"></div>
<!-- /wp:group -->

Before this patch, the result after save was:

<!-- wp:group {"className":"has-link-color"} -->
<div class="wp-block-group has-link-color"></div>
<!-- /wp:group -->

After this patch the HTML remained intact. 😄

Also checked Gutenberg: v10.7.0-rc.1 with the same result.

This would also currently allow the use of css vars in the custom css in the customizer - would that be a bad/dangerous thing?

Would it make sense to add some unit tests so we can prove that it will pass in various scenarios?

[glendaviesnz]

Would it make sense to add some unit tests so we can prove that it will pass in various scenarios?

Good idea, will try and add some tests.

[ramonjd]

f171c17 updates the regex to accept all alphanumeric variable names separated by _ or -.

Things like --, --_ and --var_ are invalid.

Also updated the tests 👍

[glendaviesnz]

Thanks @ramonjd, the changes tested well for me.

[jeherve]

Thanks for adding some tests! ❤️

[jeherve]

Is there a specific reason while you set to ignore the whole file? It's full of errors at the moment, but maybe we can stick to our coding standards for new code we introduce?

[glendaviesnz]

Yeh, I wasn't sure how to handle it given it was original a 3rd party file, but given it is never going to be updated externally now you are probably right, so have removed the ignore.

[glendaviesnz]

@jeherve Do you think this is something we should run past secops? I can't see how this would open up any sort of xss hole, etc. but is it worth getting a second opinion on it anyway?

[ramonjd]

Do you think this is something we should run past secops? I can't see how this would open up any sort of xss hole, etc. but is it worth getting a second opinion on it anyway?

I have something similar over here: #19993 Will be adding tests but it'd be good to get a 👍 just in case.

[jeherve]

Do you think this is something we should run past secops? I can't see how this would open up any sort of xss hole, etc. but is it worth getting a second opinion on it anyway?

Will be adding tests but it'd be good to get a 👍 just in case.

That'd be my vote as well 👍

[glendaviesnz]

@jeherve, @ramonjd, fyi I have copied secops into the accompanying diff for feedback

[glendaviesnz]

The change that removed this requirement from the group block is now merged in Gutenberg. It turned out that the other blocks that use css vars use var(--main-color) inline, but don't declare the css properties inline (--main-color: red), only the group block was doing this, so closing this for now.