phil-brown / jcss-parser Goto Github PK

Hi Phil,

thanks for the jCSS-Parser! It works very well and has been very easy to use! 😄

However, there is one strange thing. On parser errors (in my case I had a regular "//" comment that is not allowed in CSS somewhere) the handler.handleError() is correctly called but then immediatly after that a System.exit(0) is performed.

I think this is a bit harsh 😉

Is there a special reason for that or can this be changed into a throw new IOException() or something similar instead?

I've found it on three spots in the CSSParser class here:

https://github.com/phil-brown/jCSS-Parser/blob/master/CSS%20Parser/src/self/philbrown/cssparser/CSSParser.java#L83
https://github.com/phil-brown/jCSS-Parser/blob/master/CSS%20Parser/src/self/philbrown/cssparser/CSSParser.java#L304
https://github.com/phil-brown/jCSS-Parser/blob/master/CSS%20Parser/src/self/philbrown/cssparser/CSSParser.java#L460

I can provide a pull request if your time is limited but just wanted to ask if this has to be that way - although I can't think of a reason, right now.

void

For my project I need to parse the "linear-gradient" CSS rule.

Since jCSS-Parser does not support that directly I need to do that on my own. So I've build my own little parser using the jCSS-Parser classes TokenSequence and Token as its input. This works quite well and I can parse the "linear-gradient" rule pretty well :)

However, with color values like "#fff" or "#ffffff" I've encountered a problem. Since the 'Scanner' class returns the color values as a combination of Token.Number and Token.Identifier - depending on the first character being a number (0-9) or a hexadecimal number beginning with (a-f) - it's a bit difficult to process. Additionally CSS color values could consist of 3 digits or 6 digits too so it's quite hard to parse them correctly.

Especially difficult for the linear-gradient syntax since they can be followed directly by a color stop number too.

Here are some examples:

linear-gradient(#200b30 10%);
linear-gradient(#a0b29f 10%);
linear-gradient(#0aa 10%);

And the way they are separated into tokens by the Scanner:

"#200b30 10%"
102:null "#"
126:200 "200"
127:b30 "b30"
126:10 "10"
138:null "%"

"#a0b29f 10%"
102:null "#"
127:a0b29f "a0b29f"
126:10 "10"
138:null "%"

"#0aa 10%"
102:null "#"
126:0 "0"
127:aa "aa"
126:10 "10"
138:null "%"

The problem is that we get the color values returned as a combination of Token.Number and Token.Identifier. Since a color value could consist of 3 or 6 digits one could concat the Token.attribute values into a String and check it's length to know if the color value has been parsed completely but that is not quite possible in all cases.

In the last example above we get back "0" and "aa". So combined we get the color value "0aa" which is a 3 digit value BUT since it is followed by another number "10" we could "think" it might be a 6 digit color value and continue processing it as a color value into "0aa10" and then run into an error since the following "%" token is not expected in that case.

I hope I make any sense 😉 since it's kinda hard to explain 😄

I think this approach could work if we would get back the whitespace "token" too so that we could find the border between the color value and the next stop number but as far as I see it's not returned as a Token.

I think it might be best if the Scanner would return a Token.Color value directly but I don't understand enough of the CSS spec and the Scanner to really be certain if that's allowed / makes sense at all.

Maybe I'm parsing the color values completely wrong and there is actually a way to read them smarter? In that case I'd be grateful for any hints too 😄