Strict parsing mode exception with whitespace-only CSS

[JakeQZ]

In the following test, only the empty string passes:

    public function provideEmptyCss()
    {
        return [
            'empty string' => [''],
            'space' => [' '],
            'newline' => ["\n"],
            'carriage return' => ["\r"],
            'tab' => ["\t"],
            'Windows line ending' => ["\r\n"],
            'comment' => ['/**/'],
        ];
    }

    /**
     * @test
     *
     * @dataProvider provideEmptyCss
     */
    public function parsesEmptyCssInStrictMode($css)
    {
        $oParser = new Parser($css, Settings::create()->beStrict());

        self::assertSame('', $oParser->parse()->render());
    }

The others fail:

Sabberworm\CSS\Parsing\UnexpectedEOFException: Next token was expected to have 1 chars. Context: “”. [line no: 1]

D:\Data\dev\PHP-CSS-Parser\src\Parsing\ParserState.php:279
D:\Data\dev\PHP-CSS-Parser\src\RuleSet\DeclarationBlock.php:58
D:\Data\dev\PHP-CSS-Parser\src\CSSList\CSSList.php:146
D:\Data\dev\PHP-CSS-Parser\src\CSSList\CSSList.php:82
D:\Data\dev\PHP-CSS-Parser\src\CSSList\Document.php:35
D:\Data\dev\PHP-CSS-Parser\src\Parser.php:58
D:\Data\dev\PHP-CSS-Parser\tests\ParserTest.php:90

The lenient-mode equivalent test passes fine, however.

[amenk]

We seem to run into this problem on Magento 2.4.8

We are using this patch now. Disclaimer: It's via Claude Opus 4.8 - maybe it's helpful for others

@package sabberworm/php-css-parser
@level 3
@see https://github.com/MyIntervals/PHP-CSS-Parser/issues/349

Fix UnexpectedEOFException on comment-only CSS in strict parsing mode

In strict (non-lenient) parsing mode, CSS that contains nothing but comments —
e.g. a theme whose email-inline.css compiles to only a
"/*# sourceMappingURL=... */" sourcemap reference — makes parseList() consume the
trailing comment as whitespace and then still call parseListItem() at end of
input, which throws UnexpectedEOFException.

Magento enables emogrifier debug mode (= strict parsing) in developer mode, so
this aborts transactional-email CSS inlining and prepends a "CSS inlining error"
to every email body. Emogrifier only trims whitespace (sabberworm issue #349),
so comment-only CSS still triggers it.

Fix: re-check for end of document after consuming leading whitespace/comments,
before attempting to parse the next list item. Mirrors the behaviour for
whitespace-only input.

--- vendor/sabberworm/php-css-parser/src/CSSList/CSSList.php
+++ vendor/sabberworm/php-css-parser/src/CSSList/CSSList.php
@@ -78,6 +78,12 @@
         $aComments = [];
         while (!$oParserState->isEnd()) {
             $aComments = array_merge($aComments, $oParserState->consumeWhiteSpace());
+            // Trailing whitespace/comments may consume the rest of the input; re-check for
+            // end of document before attempting to parse another list item, otherwise
+            // comment-only CSS throws UnexpectedEOFException in strict parsing mode.
+            if ($oParserState->isEnd()) {
+                break;
+            }
             $oListItem = null;
             if ($bLenientParsing) {
                 try {

[JakeQZ]

I'll implement a fix (maybe not exactly as suggested by Claude) with some tests as outlined in the OP. Have added #1592 for a refactoring of tests to go in first.

[JakeQZ]

I determined (what I think is) a neater solution than Claude did - #1593. (So I'm not out of a job yet - and can Claude write decent unit tests? That said, he/she/they did pinpoint the area of code to fix, which was useful.)

[amenk]

Thanks a lot for the quick, correct, fix.
(It can write more or less decent unit tests, too.
But, like you, I am always happy to correct it's "decisions" - to prove that I am not out of my job, yet 😉)

[oliverklee]

So I'm not out of a job yet - and can Claude write decent unit tests?

On a related note, I'm currently preparing a talk "Generative AI, ethics and sustainability" for FrOSCon 2026 and some user group meetups and barcamps. One of my points concerning sustainability will be that it's very easy to create unmaintainable, inconsistent, insecure code using generative AI fast. So it needs lots of guidance and handholding to create maintainable code, which means that the bottleneck is the human brain, not the non-deterministic code generator, and that writing the code is not the main effort, but maintaining the codebase (and keeping it maintainable).