Hey, I don't understand why we're prefixing the styles with html :where(.editor-styles-wrapper) instead of .editor-styles-wapper.

If I'm not mistaken I think it's just to lower the specificity, but I'm also curious to know if that is indeed the case or not 🤔

Yeah, I understand it lowers the specificity but I don't know why. I guess my question is: why the styles loaded through a wp dependency should be any different than the styles loaded via add_editor_styles?

I just used the same thing as #32659. But I guess if we consistently increase the specificity of all styles, this is not necessary. Cc @jasmussen.

This technique is cool, though there's a noticeable delay in the styles being applied. Presumably, because we add the stylesheet in the client after all things have been already loaded and the onLoad event happens even after.

Thinking about how to improve this:

• What if we convert all styles (both link and style) to embedded styles (style) and prefixed them just here, so we don't wait to onLoad to do it?
• Alternatively, would it make sense to add the stylesheets in the server (no passing them through __unstableResolvedContentStyles) and attach to its onLoad event a public function that takes care of prefixing them? While we still rely on the onLoad event here it'll happen earlier because we're not adding it in the client.

The good think here is that we don't have to do any CSS parsing. I talked with @mcsf about the delay. I wonder if we could block the original CSS from applying, maybe by emptying and later refilling it. 🤔
It would be good if we don't have to do any parsing. I was hoping there would be some API to scope link and style tags to a given selector, but that doesn't exist apparently.

This would be ideal: https://css-tricks.com/saving-the-day-with-scoped-css/

Might be something to package as a util, for clarity and visibility.