Size Change: -497 B (-0.01%)

Total Size: 6.87 MB

_{compressed-size-action}

@ramonjd @aaronrobertshaw @andrewserong I believe you folks have some experience with this system. Does this direction seem viable? Was there a reason that CSS nesting is avoided instead of allowing it to happen?

I went back to @t-hamano's original implementation of processCSSNesting to check and, originally, it was to handle multiple selectors with nested rules.

By the way, I went through the test steps of that PR on this branch and things look good!

Then pseudo element selectors came into the bag. @aaronrobertshaw's PR addressed malformed selectors.

I also went through those test steps on this branch and it LGTM

That's where my knowledge of the history runs dry, though, if you tied me up and threatened my goldfish for an answer, I'd guess that it was also because CSS Nesting was fairly new back in the day (2023) and maybe it couldn't be relied upon.

Also, and I'm guessing, there's no CSSStyleSheet equivalent in PHP, so the parsing logic had to remain the same? I'm looking at process_blocks_custom_css

That said, you mentioned there are possibilities to use CSSStyleSheet or what not, and CSS Nesting is pretty well baked in now. I've smoke tested this PR and it's working pretty well so far 🚀

Also, and I'm guessing, there's no CSSStyleSheet equivalent in PHP, so the parsing logic had to remain the same? I'm looking at process_blocks_custom_css

Oh yeah, CSSStyleSheet handles the following correctly, but the frontend mashes it all inside &::before

&::before { content: 'Foo' };
border-width: 1px;
border-style:solid; border-color:black;

Editor	Frontend

Oh yeah, CSSStyleSheet handles the following correctly, but the frontend mashes it all inside &::before

Right, this only explores the in-editor side of things. Presumably, in PHP we need something similar.

This is another case where we need to deal with CSS. Assumptions and regular expressions are limiting and insufficient. Ticket 63568 is a good example of this, which only needs to deal with CSS strings and identifiers. That's why I suggest:

A PHP-based CSS parser will likely become necessary. There is some prior art for this. WordPress/wordpress-develop#7857, and the php-toolkit contains a CSSProcessor class.

Ultimately, I think that's the answer. There are many places around Core that would benefit from CSS parsing/processing and this is just one more example.

That said, you mentioned there are possibilities to use CSSStyleSheet or what not

I made a typo here, I meant to say CSSProcessor. 👍🏻

This is another case where we need to deal with CSS. Assumptions and regular expressions are limiting and insufficient

Yeah it seems this is coming up more and more. Thank you for donning this t-shirt by the way and getting sweaty with the problem.

There's a problem with this method in the browser. Repeated style declarations are collapsed into whichever one the browser uses, making this a lossy approach.

CSS has two design choices that are relevant here:

• the last declaration wins
• user agents ignore declarations that they can't process

When authoring CSS that allows for progressive enhancement. Well-supported features are used as a baseline, and more modern features are used when available.

The web APIs like CSSStyleSheet and insertRule parse the rules and discard redundant declarations, breaking the possibility of progressive enhancement and using whatever the current browser parses.

For example, consider the CSS in this snippet of HTML:

<style>
li {
  color: rebeccapurple;
  color: oklch( from rebeccapurple L C calc( H * sibling-index() ) );
}
</style>
<ol><li><li><li><li><li><li>

The color property is declared twice. First, with a well-supported rebeccapurple value, then again using a much more complex color including sibling-index() with limited support. Here's what it looks like rendered:

Supported	Unsupported

Unfortunately, this browser's support is reflected in the CSSRule's cssText. We'll run this snippet of JavaScript in the same browsers:

const ss = new CSSStyleSheet();
const css = ss.cssRules[ ss.insertRule( `li {
  color: rebeccapurple;
  color: oklch( from rebeccapurple L C calc( H * sibling-index() ) );
}` ) ].cssText;

And here are the values of css:

The intentional duplicate declaration and progressive enhancement is lost. The result is either the basic version or the enhanced version, neither of which is the desirable result.

It may be viable to use insertRule simply to verify that the input CSS syntax is correct and is exactly 1 rule, but not actually use the processed cssText.