prepare 0.9.30 release
update dependencies
unknown rule values are printed as ems instead of em
-delete-
-delete-
Hi, having some trouble with parseSelectors. Mostly following the example in the documentation: InputSource source = new InputSource(new StringReader(css)); CSSOMParser parser = new CSSOMParser(new SACParserCSS3()); SelectorList selectorList = parser.parseSelectors(source); Where css is a simple string eg div { background-color: black; } But while parser.parseStyleSheet operation is working, parseSelectors always returns null whatever css i try. To explain a bit more my use case, i'm trying to parse...
Hi, having some trouble with parseSelectors. Mostly following the example in the documentation: InputSource source = new InputSource(new StringReader(css)); CSSOMParser parser = new CSSOMParser(new SACParserCSS3()); SelectorList selectorList = parser.parseSelectors(source); Where css is a simple string eg div { background-color: black; } But while parser.parseStyleSheet operation is working, parseSelectors always returns null whatever css i try. Any tips ?
Any updates or insights about what version to use? Especially since the version numbers have a big difference. Is this verison here on Sourceforge still an actively developed one or does the focus shift to the github version? It would be great to get at least an idea. Thx
Hi, since there exists on github CSSParser with HtmlUnit (https://github.com/HtmlUnit/htmlunit-cssparser) I recongize that the classes are not compatible to each other. The code for inlining CSS won't work nor if I want to use the individual CSSParseException (from the Introduction). Is there a migration guide? Is the current repro updated as well? thx leo
Hi RBRi, the link with the HTML-Unit works - if I remove the dot in the link :-) Anyway - this raises the first question: Which one to use? Either here from Sourceforge or the one from Github? About the message: Yeah the hint to the customized error eases the pain; but the URI remains null. If the URI would provide at least the attribute-name than it would be quite usable. thx
There is some documentation about customizing the error handling- see http://cssparser.sourceforge.net/gettingStarted.html Can you please check if this does the job for you - CSSParseException has getColumnNumber() getLineNumber() and getURI() as additional properties to CSSException.
Hi LeO, thanks for you interest in CSSParser and the bug report. The error messages are more or less generic because CSSParser uses JavaCC for the parser construction. Will have a look if i can make at least the numbers more obvious. BTW: there is a bit mor 'modern' version of the CSSParser used by HtmlUnit available at https://github.com/HtmlUnit/htmlunit-cssparser. If i can find a way to improve the error msg i will implement it for both.
Just a tiny remark to my last one: We want to use the CSSparser in our project since it looks very, very promising. Since we have different libs included an exception is always hard to track if one doesn't know the source. In my scenario I didn't know if the Error was raised by Jsoup or CSSparser. So my suggestion would be: CSSParser Error at position: line 2: character: 16; attribute name: 'font-family'
Just a tiny remark to my last one: We want to use the CSSparser in our project since it looks very, very promising. Since we have different libs included an exception is always hard to track if one doesn't know the source. In my scenario I didn't know if the Error was raised by Jsoup or CSSparser. So my suggestion would be: CSSParser Error at position: line 2: character. 16; attribute name: 'font-family'
well - agreed 😊 if I understand the magic numbers 2:16. but why not make it more explicit, i.e Error at osition: line 2: character. 16; attribute name: font-family i have a SQL editor mentioning only the position - when all lines are concatenated. I never know where the error is since i have no clue how the string internally looks like and if there is some additional formatting done. therefore I don't really trust chars positions. anyway - if you think the magic of 2:16 is broadly understood outside...
The 2:16 mean that the Error is in Line 2 Character 16 so i believe the Error Message ist quite detailed
Incorrect attributes - improved error message would be helpful
update dependencies and enforce maven/java version
tag version 0.9.29
improved deploy process
small javadoc fixes
prepare 0.9.29 release
new CSSFormat setting useSingleQuotes to force the usage of single quotes instead of double quotes
Single quote replaced by double quotes
Sorry this was forgotten somehow. The next release will include this.
Hi, From what I'm seeing in my tests, when a calc() with a sub-expression is processed, like: calc((-3em)*2) the (-3em) part is classified as a function (SAC_FUNCTION) instead of SAC_SUB_EXPRESSION. The problem is that the first operand (the -3em in that example) returns a null identifier (SAC_IDENT with value null) when getPreviousLexicalUnit() is called on it, and my Object Model breaks there during a verification process. I have a similar issue when a var() function is found inside a calc(). Moreover,...
tag
prepare 0.9.28 release
jdk 1.8
Patch proposal for calc()
Aganin thanks, releae is on the way
fully support calc syntax
done with 0.9.28
Hi, would it be possible to publish a 0.9.28 release based on this patch on Maven Central?
Thank you very much! The most recent version fixes all warnings and errors in my test case, and all the rules are imported successfully. Would it be possible to build a release and publish it on maven central, so we can officially use the new version without the SNAPSHOT suffix?
Ok, next incarnation is online.
Verdammt - will have a look at this tomorrow. Sorry did it in a hurry...
empty fallback value support
add rem support
fix recursion
Here is another patch that adds support for the "rem" dimension. The patch deprecates the previous one, as it contains the stackoverflow fix and some more test cases. The only thing left in the tailwind.ui CSS is the empty custom property declaration: var(--my-value, ). I added a (failing) test that demonstrates the error; sadly I was not able to find a solution. With "rem" support, the number of import errors is down to about 10, which is really awesome because we are very close to have the full...
Verdammt - will have a look at this tomorrow. Sorry did it in a hurry... Am 29. September 2020 21:42:04 MESZ schrieb Christian Morgner cmorgner123@users.sourceforge.net: Hi, thanks again and sorry for keeping you busy.. :( It seems that the merge accidentially removed the @Test annotation of the var() tests. That alone wouldn't be so bad, but your changes to the patch for the grammar seem to introduce an endless recursion that results in a Stack Overflow, and the tests do not catch it because they...
Hi, thanks again and sorry for keeping you busy.. :( It seems that the merge accidentially removed the @Test annotation of the var() tests. That alone wouldn't be so bad, but your changes to the patch for the grammar seem to introduce an endless recursion that results in a Stack Overflow, and the tests do not catch it because they are disabled by accident: Exception occurred in target VM: java.lang.StackOverflowError: at java.lang.Math.min(Math.java:1528) at java.util.Arrays.copyOf(Arrays.java:3748)...
patch is applied
document var support
support var
Looks good, will merge this later today.
Great, thank you for the update again! I tested the current version against my CSS test case (which is minified Tailwind UI CSS (https://tailwindui.com)). I found some empty rules where I expected custom properties and var() expressions, so I added grammar rules for that. The grammar is much simpler, and I think I was more successful this time. (I added more test cases as well.) You can find the changes in the attached diff, which should add support for custom properties and the var() function. Please...
Ok, hope have finally fixed the parser, now many more tests passing. Your tests are also merged. Maybe you can try to find a case where the parser stil not works correct.
next parser update and more tests
Thanks, will update the parser (again)
Thank you very much for the update! I have attached a diff with the test cases I was trying to resolve. Some of them still don't work, but I haven't managed to find a solution :( For example, there is a problem with calc(100% / 3 - 40px) where the / 3 part is parsed correctly, but doesn't appear in the final result. I wasn't able to resolve the problem, but it seems that the nextLexicalUnits "/" and "3" are overwritten when adding "-" after exiting calcProduct(). I also included a test case for CSS...
With the last commit i have changed | < FUNCTION_CALC: <c_letter> <a_letter> <l_letter> <c_letter> <lround> ></lround></c_letter></l_letter></a_letter></c_letter> into | < FUNCTION_CALC: "calc" <lround> ></lround> Not using the x_letter definitions simplifys the lexer - this gives you some room for more lexer rules (there is a tradeoff, not all escaped writings of calc are supported by using this - but i guess nobody will escape letters inside 'calc').
Have done another minor update
Have done another minor update On Sun, 27 Sep 2020 13:30:11 -0000 Christian Morgner wrote: Hi, I just saw that you already merged my initial patch proposal and improved the grammar a lot more than I was able to. Thanks a lot! :) I will happily provide some more test cases, probably later today / this evening. [patches:#11] Patch proposal for calc() Status: open Group: none Created: Sat Sep 26, 2020 03:42 PM UTC by Christian Morgner Last Updated: Sun Sep 27, 2020 12:49 PM UTC Owner: nobody Attachments:...
more updates on calc - use an empty function as block scope
Hi, I just saw that you already merged my initial patch proposal and improved the grammar a lot more than I was able to. Thanks a lot! :) I will happily provide some more test cases, probably later today / this evening.
Hi, I'm working on a better grammar that is closer the the specification and supports parentheses. I also added test cases, but I have not managed to get the grammar working yet, so I need some more time. I'm not sure what you mean by "have spend some time to rewrite the calc parser based on the spec."... do you have spent some time, or should I spend some more time (as I'm currently doing)?
edited: Hi, I just saw that you already merged my initial patch proposal and improved the grammar a lot more than I was able to. Thanks a lot! :) I will happily provide some more test cases, probably later today / this evening. previous message: Hi, I'm working on a better grammar that is closer the the specification and supports parentheses. I also added test cases, but I have not managed to get the grammar working yet, so I need some more time. I'm not sure what you mean by "have spend some time...
Hi, I'm working on a better grammar that is closer the the specification and supports parentheses. I also added test cases, but I have not managed to get the grammar working yet, so I need some more time. I'm not sure what you mean by "have spend some time to rewrite the calc parser based on the spec."... do you have spent some time, or should I spend some more time (as I'm currently doing)?
add another code optimization
The size of the genrated code is a real problem with JavaCC, so far i have no idea how to fix that. There are already issues open for Javacc to split the generated methods but i guess there is noone working on that.
Hi Christian, have spend some time to rewrite the calc parser based on the spec. It will be great if you can write more test cases for the clalc parser (e.g. negative values, devide by dimensions, whitespace at various places).
rewritten calc() parser based on the spec;
jdk 1.8 & update JavaCC
update year
update year
update year
Thanks for the quick response! :) Do you mean parentheses inside of a calc expression? If yes: I will try to add support for that as well. What do you think about support for variables and the var() function? I wasn't able to get that working because JavaCC creates uncompilable code (code too large for try statement), so maybe you have a hint?
initial calc() support added
Many thanks, looks good. Will merge this soon. Looks like '()' are not supported by your patch ? Will be great if you can add this also.
Hi, I just submitted a patch that adds experimental support for calc(): https://sourceforge.net/p/cssparser/patches/11/ Best, Christian
Patch proposal for calc()
CSS parser is returning an error for #RGBA and #RRGGBBAA hex color values