Issue Description
Since we switched to using the WordPress recommended way of including editor styles in our themes in 10up/wp-scaffold#69 we've encountered quite a few issues related to the CSS parser that WordPress uses in order to scope the editor styles to the .editor-styles-wrapper class. The parser chokes whenever there is invalid CSS in the dist bundle. This may be caused by things like invalid postcss that doesn't get compiled correctly, therefore leaving invalid CSS in the bundle. The browser fails gracefully here and just ignores the invalid rule. But the parser in Core fails completely and therefore the editor styles don't load at all.
Additionally, there are some instances where perfectly valid CSS causes the parser to fail. There is an open issue in the Gutenberg Repository to track these issues in order to hopefully improve this parser in the future: WordPress/gutenberg#40444
Currently, it is rather difficult for engineers to actually spot these issues though since they can start to happen whenever new CSS is authored / any of the CSS is modified. Some of these issues also only manifest themselves when the CSS gets minified because of changes to the whitespace in the file.
Proposed solution
In order to make it easier for engineers to catch these issues, we could add a new flag to toolkit which would run the final CSS bundle through the WordPress CSS parser. This would allow us to catch these issues directly in the console and also it would fail any CI builds if the CSS is causing issues.
Currently, the WordPress CSS parser does not get exported. So initially we would need to manually copy over the parser. But we should raise an issue with Core to hopefully export the parser so we can use it and directly inherit any changes that may be applied in the future.
Issue Description
Since we switched to using the WordPress recommended way of including editor styles in our themes in 10up/wp-scaffold#69 we've encountered quite a few issues related to the CSS parser that WordPress uses in order to scope the editor styles to the
.editor-styles-wrapperclass. The parser chokes whenever there is invalid CSS in the dist bundle. This may be caused by things like invalid postcss that doesn't get compiled correctly, therefore leaving invalid CSS in the bundle. The browser fails gracefully here and just ignores the invalid rule. But the parser in Core fails completely and therefore the editor styles don't load at all.Additionally, there are some instances where perfectly valid CSS causes the parser to fail. There is an open issue in the Gutenberg Repository to track these issues in order to hopefully improve this parser in the future: WordPress/gutenberg#40444
Currently, it is rather difficult for engineers to actually spot these issues though since they can start to happen whenever new CSS is authored / any of the CSS is modified. Some of these issues also only manifest themselves when the CSS gets minified because of changes to the whitespace in the file.
Proposed solution
In order to make it easier for engineers to catch these issues, we could add a new flag to toolkit which would run the final CSS bundle through the WordPress CSS parser. This would allow us to catch these issues directly in the console and also it would fail any CI builds if the CSS is causing issues.
Currently, the WordPress CSS parser does not get exported. So initially we would need to manually copy over the parser. But we should raise an issue with Core to hopefully export the parser so we can use it and directly inherit any changes that may be applied in the future.