Skip to content
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

Use CSSTree for style transformations (new) #21936

Closed

Conversation

strarsis
Copy link
Contributor

Description

This PR adds the CSSTree parser for wrapping the theme styles into a styles wrapper.

How has this been tested?

I tested this on my local WordPress site.

Types of changes

Checklist:

  • My code is tested.
  • My code follows the WordPress code style.
  • My code follows the accessibility standards.
  • My code has proper inline documentation.
  • I've included developer documentation if appropriate.

@strarsis strarsis force-pushed the css-tree-transform-styles-2 branch from 903d14a to dd91ca2 Compare April 28, 2020 18:26
@strarsis
Copy link
Contributor Author

@youknowriad, @noahtallen: OK, PR is ready. The original structure is preserved.


return raw;
}
import { URL } from 'whatwg-url';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I know we've gone back and forth about this kind of module and we have a @wordpress/url package. @aduth is this correct, should we replace with our own module instead?

@youknowriad
Copy link
Contributor

Can we get a quick sanity checks from theme authors here @kjellr @jasmussen to ensure the editor styles are still working as intended in the editor since this is a big rewrite.

@strarsis did you check if there's any performance impact here (initial loading) good or bad? (nom run test-performance)?

@strarsis
Copy link
Contributor Author

strarsis commented Apr 29, 2020

@youknowriad: Hm, the test-performance script doesn't want to run through on my system (same issue on the master branch):

$ npm run test-performance

> gutenberg@7.9.1 test-performance [...]/gutenberg
> wp-scripts test-e2e --config packages/e2e-tests/jest.performance.config.js

Downloading Chromium r737027 - 123.7 Mb [====================] 100% 0.0s
Chromium (737027) downloaded to [...]/gutenberg/node_modules/puppeteer/.local-chromium/linux-737027
● Validation Error:

  Module @wordpress/jest-console in the setupFilesAfterEnv option was not found.
         <rootDir> is: [...]/gutenberg/packages/e2e-tests
[...]
npm ERR! gutenberg@7.9.1 test-performance: `wp-scripts test-e2e --config packages/e2e-tests/jest.performance.config.js`

The @wordpress/jest-console package seems to be there though.

@jasmussen
Copy link
Contributor

Hello! Thanks for the PR and thanks for the ping.

I'm usually able to check out branches in forks using this process:

git remote add strarsis git@github.com:strarsis/gutenberg.git
git fetch strarsis
git checkout strarsis/css-tree-transform-styles-2 -B css-tree-transform-styles-2

However I'm doing something wrong, as I'm not able to check out and compile this branch, sorry about that. Let me know if you spot my error.

To respond at a more high level though, I'm afraid I wasn't familiar with CSStree — what feedback are you looking for? Should the block editor and editor styles ideally look visually unchanged before and after this PR? Or does it change anything with regards to how editor styles are authored? What would be the impact if/when the block editor lands in an iframe and the DOM continues to be lightened until at one point it may be mostly identical to the frontend?

@strarsis
Copy link
Contributor Author

strarsis commented Apr 30, 2020

@jasmussen: An iframe-based approach to style namespacing hasn't been implemented yet.
For now, this PR should improve the style-wrapping using a CSS parser/AST library (CSSTree).
It also fixes CSS-specific issues like #21569 and #16408 where the currently used parser doesn't support some syntax. Until the new iframe paradigm has been worked out and implemented, fixing the parse issues would be a good step because it can be a blocker in theme development as the styles won't load at all in the editor.

Concerning your branch checkout: I am not sure what went wrong in your case. I use WSL, maybe the line endings accidentally were changed?

@jasmussen
Copy link
Contributor

Thanks for taking the time, and thanks again for the PR. I'm not sure why the branch checkout didn't work, but it seems to me like the best way to test this PR is to verify current editor styles look mostly (exactly?) the same before and after this branch, correct?

As far as iframes go, while it still might be a ways out, it also might be closer than we think. While it's important that the idea of the iframe PR landing should not stop forward momentum — it might not land, after all — it also seems prudent to think of the iframe as a serious possibility, and avoid painting ourselves into a corner if we can. But it sounds like you're saying making this work with an iframed editor should not be a big refactor?

@youknowriad
Copy link
Contributor

it also seems prudent to think of the iframe as a serious possibility, and avoid painting ourselves into a corner if we can. But it sounds like you're saying making this work with an iframed editor should not be a big refactor?

I think we should be prudent about the iframe, even if we merge it at first, the PR there showed that we can't get rid of the non-iframed version quickly since the iframe version breaks blocks that rely on the global "window/document" object.

That said, If ever we go full iframe, this PR and the whole editor styles normalization won't be needed anymore (so just remove the code).

I think this PR is a good PR code wise, avoid the bundled dependency and use a more maintained library. I'd like to check these:

  • Editor styles still look the same (like master)
  • Performance and bundle size. (for some reason the bundle size bot is not triggering here)

@strarsis
Copy link
Contributor Author

strarsis commented May 1, 2020

@youknowriad: How can this be better tested? I also have issues getting the performance test running, even on master. But I use WSL 1 on Windows, there may be subtle differences.

@youknowriad
Copy link
Contributor

Yeah, can't speak about Windows, but once the theme styles are validated properly, I'll help with the performance test.

@strarsis
Copy link
Contributor Author

strarsis commented May 1, 2020

@youknowriad: Ideally there should be some theme styles that can be tested against. I could put in all the WordPress core theme styles (minified) like TwentyTwenty.

@oxyc
Copy link
Member

oxyc commented May 1, 2020

I couldn't get the tests running on macos either. Same error as you but it used to work a few months back.

@strarsis
Copy link
Contributor Author

strarsis commented May 1, 2020

@oxyc: I managed to get it running. You have to invoke some scripts first and then run puppeteer in headless mode with some extra options.
Prepare the workdir: npm run build:packages, npm run wp-env start

Add fields to puppeteer launch options:
packages/scripts/config/puppeteer.config.js:

module.exports = {
        launch: {
                devtools: process.env.PUPPETEER_DEVTOOLS === 'true',
                headless: process.env.PUPPETEER_HEADLESS !== 'false',
                slowMo: parseInt( process.env.PUPPETEER_SLOWMO, 10 ) || 0,
                args: [
"--disable-gpu",
"--renderer",
"--no-sandbox",
"--no-service-autorun",
"--no-experiments",
"--no-default-browser-check",
"--disable-dev-shm-usage",
"--disable-setuid-sandbox",
"--no-first-run",
"--no-zygote",
"--single-process",
"--disable-extensions",
                ],
        },
};

Then run the performance test:
PUPPETEER_HEADLESS=true npm run test-performance

However, while the performance test runs now on master, it fails with:

● Performance › Loading, typing and selecting blocks                                                                                                                                                                                                                                                                                                                                                                                  No node found for selector: .block-editor-inserter__search-input

(packages/e2e-tests/specs/performance/performance.test.js:75)
Related issue: #22038

Also, the e2e/performance tests are currently broken in master because of recent changes in inserter search input markup, see #22045.

@oxyc
Copy link
Member

oxyc commented May 29, 2020

I just tried to test this again but npm run test-performance on master throws random error message that others dont seem to get, just like mentioned in #22045 before.

This time:

No node found for selector: tr[data-slug="gutenberg-test-plugin-disables-the-css-animations"] .activate a

and

Evaluation failed: ReferenceError: wp is not defined

Trying to run the tests by mimicking what travis does (on macos):

nvm install --latest-npm
npm ci
npm run build
npm run wp-env start
npm run test-performance # fail

# this fails with random errors as well
./node_modules/.bin/wp-scripts test-e2e --config=./packages/e2e-tests/jest.config.js --listTests > ~/.jest-e2e-tests
./node_modules/.bin/wp-scripts test-e2e --config=./packages/e2e-tests/jest.config.js --cacheDirectory="$HOME/.jest-cache" --runTestsByPath $( awk 'NR % 4 == 0' < ~/.jest-e2e-tests )

@strarsis
Copy link
Contributor Author

@oxyc: Hm, this error stems from puppeteer/chromium automated testing, when a node can't be found for a selector. But this is on the DOM itself, no CSS involved. The error will also cause the rest of the code failing to load, hence the wp related error afterwards. I think these are issues with the test and changed DOM structure - or a build script that hadn't run and updated the (committed) build artifacts that are used in the automated testing.

@youknowriad
Copy link
Contributor

@oxyc The error you're having is because you're not loading the e2e test plugin on your environment (they are in packages/e2e-tests/plugins

@youknowriad
Copy link
Contributor

also right now on master you can do this to compare two branches ./bin/plugin/cli perf branch1 branch2

@youknowriad
Copy link
Contributor

Sorry for letting this PR stale, I'm still interested in landing this, do you think you can rebase it again?

@strarsis
Copy link
Contributor Author

strarsis commented Jun 2, 2020

@youknowriad: Sure! 🐱

* WordPress dependencies
*/
import { compose } from '@wordpress/compose';
import { map, compose } from 'lodash';
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had an error here when testing. "compose" is on @wordpress/element

Copy link
Contributor

@youknowriad youknowriad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After fixing the compose error, I tried this PR and it seems the styles are not applied properly. I can tell because the styles of the buttons in 2019, for instance, are not correct (they should be blue and not that rounded)

}

return css;
return traverse( css, compose( transforms ) );
Copy link
Member

@oxyc oxyc Jun 13, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This shouldn't use compose since the result of the second transform gets called with the result of the first (undefined), it should just be fed the original arguments, eg:

return traverse( css, over( transforms ) );

But that would change the old traverse api.

@oxyc
Copy link
Member

oxyc commented Jun 13, 2020

With the above fix I'm currently getting:

  ● Performance › Loading, typing and selecting blocks

    expect(jest.fn()).not.toHaveErrored(expected)
    Expected mock function not to be called but it was called with:
    ["Warning: React does not recognize the `%s` prop on a DOM element. If you intentionally want it to appear in the DOM as a custom attribute, spell it as lowercase `%s` instead. If you accidentally passed it from a parent component, remove it from the DOM element.%s isSelected isselected·

But I guess shouldnt actually have affected the results since they already ran? Might be worth checking again once master is running the tests correctly.

If that's true, the initial performance test for Loading time:

3 runs Average time to load Average time to DOM content load
Before 10582ms 10479ms
After 10495ms 10392ms

@strarsis
Copy link
Contributor Author

strarsis commented Jun 13, 2020

I am sorry that I hadn't really responded yet, I am very busy right now.
But from the performance data it looks that the PR would actually increase the performance (though even slightly)?

@oxyc
Copy link
Member

oxyc commented Jun 13, 2020

After fixing the compose error, I tried this PR and it seems the styles are not applied properly. I can tell because the styles of the buttons in 2019, for instance, are not correct (they should be blue and not that rounded)

Found the bug.

Before:

.editor-styles-wrapper .wp-block-button:not(.is-style-outline) .wp-block-button__link

After

.editor-styles-wrapper .wp-block-button:not(.editor-styles-wrapper .is-style-outline) .wp-block-button__link

@oxyc
Copy link
Member

oxyc commented Jun 13, 2020

Here's a fix for the above bug: oxyc@6b746cb

And here's a diff of twentyninenteens styles before and after (looks correct)

https://gist.github.com/oxyc/479a82cda75d92d0f30ba770c8fbc60f#file-after-patch

@oxyc
Copy link
Member

oxyc commented Jun 13, 2020

Tested it with own theme where I first encountered #16408 and found another bug:

 @-webkit-keyframes background-zoom-sm {
-	0% {
+	.editor-styles-wrapper 0% {

Fix: oxyc@1c1590b

So with the following fixes and a fix for the merge artifacts I'd call the styles verified:

@strarsis
Copy link
Contributor Author

@oxyc: Awesome, thanks! I got very little time currently, it is nice that you further looked into it.

@strarsis
Copy link
Contributor Author

strarsis commented Sep 21, 2020

@youknowriad, @oxyc, @noahtallen: Superseded by new PR on top of latest upstream master: #25514

@strarsis strarsis closed this Sep 21, 2020
@strarsis
Copy link
Contributor Author

New editor styles transformation approach using PostCSS is now merged (many thanks @zaguiini)!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants