Previous sibling selectors incorrectly parsed without whitespace

[rockwotj]

trafficstars

I have browser compliant mode turned on and the following CSS is incorrectly parsed:

div+p .foo{width:100vw}

But the following works fine

div + p .foo{width:100vw}

But it seems like when you ask for optimized output for div + p .foo{width: 100vw} you get div+p .foo{width:100vw} which means those rules don't roundtrip properly? It seems to handle ~ and > correctly however?

The error message says:

Was expecting one of:

    "*"
    "."
    ":"
    ":not("
    "@bottom-center"
    "@bottom-left"
    "@bottom-left-corner"
    "@bottom-right"
    "@bottom-right-corner"
    "@charset"
    "@footnote"
    "@import"
    "@left-bottom"
    "@left-middle"
    "@left-top"
    "@media"
    "@namespace"
    "@page"
    "@right-bottom"
    "@right-middle"
    "@right-top"
    "@supports"
    "@top-center"
    "@top-left"
    "@top-left-corner"
    "@top-right"
    "@top-right-corner"
    "["
    "|"
    "}"
    <AT_UNKNOWN>
    <FONTFACE_SYM>
    <HASH>
    <IDENT>
    <KEYFRAMES_SYM>
    <PERCENTAGE>
    <S>
    <VIEWPORT_SYM>

[phax]

I tried to reproduce your issue but failed. There is indeed a case where whitespaces need to be around + and - and this is in the context of math operations. But for this specific case I can't see an issue here - or I might not understand your needs here.... ;-)

[rockwotj]

Okay I was anonymizing the input and apparently this only repros when the selector is u+b.

so here's one that fails for me: u+b .foo{color:red} Sorry for botching the test case there 😞

[rockwotj]

I wonder if the tokenizer is trying to output a unicode token there?

https://github.com/phax/ph-css/blob/master/ph-css/src/main/jjtree/ParserCSS30.jjt#L315

[phax]

Hahaha - good catch. I need to check this - interesting....

[rockwotj]

Ping - is there anything I can do to help here? FWIW we don't allow for face rules where we do this parsing, so we could drop that token type and it would be fine. Or perhaps that rule needs to move up to the parser level?

[phax]

Good question - honestly I don't know. This is a very stupid error and requires quite some work in the lexer, because it is very specific to CSS expressions (declaration values). I simply didn't have the time to do this yet.....

[rockwotj]

Okay if I find the time I'll try and fix this. I think there may need to be a special lexical state for declarations...

[phax]

Yes excatly - but the duplicates are quite high - so a lot is the same for "standard" and "declaration values". Lexical states are e.g. already used for comments.

[stale[bot]]

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.

[phax]

@rockwotj how high are the chances, you will be able to provide something here?

[rockwotj]

Not anytime soon unfortunately 😔

[phax]

Thanks for the swift response - levaing this one open for now