Class selector not supported inside :where about ph-css

[brbog]

Thanks, I got the code working and tried putting my test snippet inside a "issue88.css"-file (not sure which directory would be correct though) and at the end of CSSReader30FuncTest.testSpecialCasesAsString() (seemed like the better option as is was easier to debug).

    // Issue 88
    sCSS = ":where(.some-tile:not(.preserve-color))>*{color:#161616}";
    aCSS = CSSReader.readFromStringReader (sCSS, aReaderSettings);
    assertNotNull (aCSS);
    assertEquals (":where(.some-tile:not(.preserve-color))>*{color:#161616}", new CSSWriter (aWriterSettings).getCSSAsString (aCSS));

I'm guessing that the solution lies inside src/main/jjtree/ParserCSS30.jjt file inside void pseudo() : {} where the part:

  | LOOKAHEAD( <FUNCTION> )
    <FUNCTION> { jjtThis.appendText (token.image); }
    ( <S> )*
    ( expr() )?
    <RROUND>  // do not append because of expression!

should look more like:

void negation() : {}
{
  <FUNCTION_NOT> { jjtThis.setText (":not("); }
  ( <S> )*
  ( selector ()
    ( <S> )*
    ( <COMMA>
      ( <S> )*
      selector()
      ( <S> )*
    )*
  )?
  <RROUND>
}

(with the selector () part).
Either that or different extra functions are needed for ":where()", ":is()", and ":has()" which have different semantics than the other pseudo elements like ":hover".

As I'm not really knowledgeable about JavaCC and I suspect this might be a rather more involved fix, I'll probably won't be able to do much more at this point? (sorry)

Update: changed "issue107" to "issue88" (107 was for another project).

[phax]

Well, the CSS grammar is constantly evolving, and it seems like the support for :where needs improvement.
Relevant links:

• https://drafts.csswg.org/selectors/#zero-matches
• https://developer.mozilla.org/en-US/docs/Web/CSS/:where

Edit: the parser itself is generated, and you need to add target/generated-classes into your build path, to get the generated classes too

[phax]

Thanks for going so far - I will see what I can do, even though my resources for this are currently quite limited :/

[brbog]

No problem, that's normal :-).

I was trying to ignore the error (I'm only interested in url content) and played around with:

		final CSSReaderSettings result = new CSSReaderSettings().setCSSVersion(ECSSVersion.LATEST);
		// When parsing fails null is returned by the framework and NullPointerExceptions can arise later on.
		result.setCustomExceptionHandler(new ThrowingCSSParseExceptionCallback());
		// Not needed for our purposes for now:
		// result.setCustomErrorHandler(new ThrowingCSSParseErrorHandler());
		// result.setInterpretErrorHandler();

But only the ExceptionHandler is called in this case (so none of the ErrorHandlers). I expect this sort of "problem handling" to be generated by JavaCC, so I'll probably need to do some preprocessing on failing css files to tweak them in a way that the parser won't choke on its content.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.