|Re: [cross-project-issues-dev] CSS Parsers & Eclipse|
From my early experiments, it's quite straightforward to replace the parser, as long as it implements the SAC API (And the Eclipse CSSParser interface). Part of the difficulty is indeed in the selectors/conditions implementation, since Batik CSS implements them (Using a custom "ExtendedSelector/ExtendedCondition" interface). It takes some time to refactor the selector/condition implementation from the Parser to the Engine, but itâs mostly a structural change (The implementation of the selectors/conditions is easily reused)
When the parser doesnât implement the SAC API, itâs a little bit more complicated, since we have to wrap their API into a SAC connector (Or change the engine implementation, which is even worse). But itâs doable (There are not so many concepts in the CSS grammar).
Finally, even with Batik and CSSParser (which implement SAC), you need some of their internal APIs because SAC itself is not really maintained and doesnât expose all the required concepts (Especially for CSS3). So even if the logic is separated from the parser, itâs never straightforward to replace a parser with another.
Ã have you asked if the project would be willing to consider an alternative license ?
There are some additional issues with the CSSParser, which doesnât support some of the concepts we need, and the project seems a little bit less active than the Phloc parser. Itâs a little bit difficult to compare the two parsers since itâs not possible to switch between them seamlessly, and I donât really want to implement both :) Thus my favorite choice for the one which could be used quickly (Supports all the concepts we need, and is already released under a compatible license). But if anyone has an experience with CSS3 Parsers in Java, Iâll be happy to reconsider this (That was also the point of the discussion)
Iâd be somewhat interested from the Platform/UI perspective as Batikâs CSS seems unmaintained, and I think there are some CSS3 selectors that would be useful to bring in. But for us the parser is only part of the issue: the underlying rules engine is the much bigger piece.