Missing validation message to custom CSS input

[afercia]

Description

This appears to be a regression in trunk introduced in #49521

The validation messages for custom CSS introduced in #47132 no longer work.

The validation relied on the 'internal' CSS parser that was removed in #49521 in favor of postCSS.

While I understand the benefit of switching to postCSS, I'm a little surprised such an impactful change has been merged without double checking all the internal usages of the block editor utility transformStyles. For the future, I'd like to recommend to make such changes be reviewed by contributors who have a larger overview and knowledge of the editor features.
Cc @youknowriad @zaguiini @jsnajdr @strarsis

Step-by-step reproduction instructions

• Go to the Site editor > Styles > More > Additional CSS
• Add this in the Additional CSS textarea: body {background: red;}
• Save.
• Edit the textarea again and remove the closing bracket }.
• Move focus away from the textarea.
• Observe no validation message is shown.
• Observe your browser dev tools console, you should see a message Uncaught CssSyntaxError: <css input>:1:1: Unclosed block
• Test on WordPress 6.4 and repeat the steps above.
• Observe that a red 'i" icon appears at the bottom right of the textarea.
• Observe that hovering the icon, a tooltip appears with an error message.
• Observe your browser dev tools console, you should see a message like Error while traversing the CSS: Error: undefined:1:22: missing '}'

Screenshots from WordPress 6.4 (expected behavior):

Screenshots, screen recording, code snippet

No response

Environment info

No response

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

[afercia]

Aside: The validation message as implemented in #47132 is not accessible.

• No audible feedback is provided.
• The icon is just an SVG icon wrapper in a focusable div element.
• The focusable div element has no labeling and no ARIA role, it's just a silent tab stop.
• It should not be a focusable div in the first place.

I disagree with the design feedback provided in #47132. Instead of adopting single-use 'ad hoc' design inspired to other tools (Codepen in this case), we should just reuste the editor components. They aim to be accessible and reusable, whilc 'ad hoc' designs defeat the purpose of usability, accessibility and maintenance. I'd aruge ad-hoc implementations also defeat the purpose of reusable components in the first place.

[afercia]

Note: Some E2E tests for the custom CSS validation messages would have been nice and would have allowed to catch this issue earlier.

[zaguiini]

While I understand the benefit of switching to postCSS, I'm a little surprised such an impactful change has been merged without double checking all the internal usages of the block editor utility transformStyles.

It was tested, but it's hard to grasp all the places where it's being used. Indeed, there are most tests right now than before because of checking. Unfortunately it wasn't 100% checked, apparently.

One good action would be to introduce a new test case where invalid CSS is passed so that we can prevent this bug in the future.

Looking at the code, it looks like the fix would be to wrap the post CSS call with a try-catch block.

[strarsis]

Yes, this is a good opportunity for adding missing tests!

[Marc-pi]

good catch, took me a while to spot the error, thanks to this issue !!!
see woocommerce/woocommerce-blocks#11730
indeed, i do confirm that the error highlighter is missing,
the codeMirror feature is indeed missing see this PR #53380