Community
Participate
Working Groups
It would be nice to update the CSSEngine to use a CSS3 Parser. The current Batik CSS parser only supports CSS 2.1, and hasn't been updated since 2008 Papyrus is already investigating CSS3 Parsers: Bug 455196 The main candidates I found are CSSParser (http://cssparser.sourceforge.net/) and Phloc CSS (https://code.google.com/p/phloc-css/). Phloc CSS seems to support more concepts, and is released under a compatible license, but it doesn't implement the W3C SAC API. CSSParser implements the API, but is released under LGPL and doesn't support all CSS3 concepts. A Phloc-to-SAC connector has been successfully implemented in Papyrus (It is incomplete, but covers (almost) all the traces required for Papyrus - which may be slightly different than the traces required for E4, although not "too different". I think it can easily be completed) Initial discussion on the cross-project Mailing List: https://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg11642.html
Just curious how they performance is, compared with batik. We have currently CSS-engine (not parser related) related performance issues in UI, I just fear that we introduce even worse issues with the new parser :-).
> Just curious how they performance is, compared with batik. We have currently CSS-engine (not parser related) related performance issues in UI, I just fear that we introduce even worse issues with the new parser :-). If I remember, CSS is parsed one time and it is putted in cache. It's the compute of the CSS which is done every time.
> Just curious how they performance is, compared with batik. We have currently CSS-engine (not parser related) related performance issues in UI, I just fear that we introduce even worse issues with the new parser :-). The Papyrus prototype implementation currently uses two parsers, as explained in Bug 455196 Comment 2, so it definitely hurts the performances. I haven't verified how Phloc alone performs, yet (And I didn't test big stylesheets either). But I do know that in Papyrus, stylesheets are parsed only once, so Parser is never the bottleneck. I'm not sure how E4 handles since, but I suspect it parses the stylesheet only once as well, so I'm not too worried.
This is a really interesting topic: for RCP and other renderers. Is there any news on this? To investigate, we need to know the current architecture. Do we have any architectural design document explaining how the current CSS parser works, and how it affects the application display?
(In reply to Patrik Suzzi from comment #4) > Do we have any architectural design document explaining how the current CSS > parser works, and how it affects the application display? Unfortunately, I don't think we have any architectural design document
Hi everybody, The E4 CSS engine comes from my old project TK-UI http://tk-ui.sourceforge.net/user-guide/cssengine.html I have drawn an architecture schema at http://tk-ui.sourceforge.net/user-guide/cssengine/architecture.html Explanation is in frensh, but with google translate https://translate.google.fr/translate?hl=fr&sl=fr&tl=en&u=http%3A%2F%2Ftk-ui.sourceforge.net%2Fuser-guide%2Fcssengine%2Farchitecture.html you can (I hope) understand something. Hope it will help you. Regard's Angelo
We did little progress in Papyrus on this topic Two CQs have been reported to include the Phloc CSS3 parser: CQ 9316, CQ 9317. For now, they have been withdrawn due to minor legal issues (Minor to solve, but blocking until solved) and lack of time/effort on our side We also have a branch in Papyrus, providing new implementations based on this parser for the CSS Matchers. I may be able to revive this if there is interest. Papyrus is based on the E4 CSS Engine, but there are many differences in the architecture, so I don't know much about E4 CSS. Still, replacing the Parser shouldn't have a huge impact on the overall architecture (And most/all APIs are internal I think - they would need to be changed because IIRC Batik/CSS is exposed in these internal interfaces)
(In reply to Angelo ZERR from comment #6) > The E4 CSS engine comes from my old project TK-UI > http://tk-ui.sourceforge.net/user-guide/cssengine.html > > I have drawn an architecture schema at > http://tk-ui.sourceforge.net/user-guide/cssengine/architecture.html > > Hope it will help you. It does, thank you very much! (In reply to Camille Letavernier from comment #7) > We did little progress in Papyrus on this topic > > Two CQs have been reported to include the Phloc CSS3 parser: CQ 9316, CQ > 9317. For now, they have been withdrawn due to minor legal issues (Minor to > solve, but blocking until solved) and lack of time/effort on our side > > We also have a branch in Papyrus, providing new implementations based on > this parser for the CSS Matchers. I may be able to revive this if there is > interest. Papyrus is based on the E4 CSS Engine, but there are many > differences in the architecture, so I don't know much about E4 CSS. Still, > replacing the Parser shouldn't have a huge impact on the overall > architecture (And most/all APIs are internal I think - they would need to be > changed because IIRC Batik/CSS is exposed in these internal interfaces) As Papyrus is based on E4 CSS, it would be good to benefit of the improvements back in E4 CSS.
To revive this properly and have more contributors helping, we should add a wiki page explaining: 1. Theory: 1.a How the CSS Engine Works 1.b major features and limitations 2. Examples: 2.a Links to best practices for CSS parsing 2.b Deprecate the examples that are not actual About the existing links, I found a number of wiki pages. Please help me in identify the documents that are outdated. 3. Which are still actual and which outdated? 3.a https://wiki.eclipse.org/Eclipse4/CSS 3.b https://wiki.eclipse.org/E4/CSS 3.c https://wiki.eclipse.org/E4/CSS/SWT_Mapping 3.d https://wiki.eclipse.org/Eclipse4/RCP/CSS
> As Papyrus is based on E4 CSS, it would be good to benefit of the improvements back in E4 CSS. Definitely; that was the original idea. However, due to calendar constraints (I've been working on this just before Mars SR0, targeting an initial release in Mars SR1 - which wasn't an option for replacing an important component in the platform), and various other things (IP, convenience), this work was done in the context of Papyrus (And never actually completed) I don't know much about the engine in general; my work was limited to the Parser (With limited impact on the Engine). And since Papyrus uses its own Engine, my knowledge of the E4 one is limited. In general, however, it should be possible to replace a parser without affecting the Engine "too much" (IIRC some changes were required in the API, because the evaluation of CSS Matchers is partly implemented in Batik, and partly in E4. So I had to reimplement them entirely) CSS Editors should be considered as well: E4 provides an XText implementation of CSS2, E(fx)clipse an XText implementation of CSS3, and Papyrus cloned/forked the E(fx)clipse editor (Because it contained fx-specific content assist and validation). And then there is the non-XText CSS Editor from... WTP I think? Of course, all XText-based editors are incompatible with each other, and installing more than one causes chaos :) (The last one doesn't have compatibility issues) I don't know about the E4 CSS Editor (Mentioned here: https://wiki.eclipse.org/Eclipse4/CSS#Editing_the_CSS_in_eclipse), but the ones from E(fx)clipse and Papyrus both contain tool-specific additions (Completion, validation). Editors might be slightly off-topic though (But it's still good to keep this in mind when migrating to CSS3; current CSS2 editors won't work)
If someone wants to work on this, please reopen. I have seen updates of Batik in the past, so maybe we get CSS3 from Batik soon (or have already gotten it).
