Re: [e4-dev] Foundation of a CSS-Editor for e4 and general discussion to

[Angelo zerr <angelo.zerr@xxxxxxxxx>]

Hi Tom,

Thank a lot for your work. When I created CSS engine, I would like CSS Tooling, that's very cool that you have started something with XText. For your information E4 CSS Engine use SAC parser interface to parse CSS styles. So you can use any SAC parser implementation (flute, batik....for E4 Batik is used).

After SAC structure are used to build w3c CSSStyleSheet interface which are the result of the computed CSS styles (eg:  org.w3c.dom.css.CSSStyleSheet).

So I think if you want use CSS XText structure, perhaps you could implement SAC interface? It could be very cool to implement SAC Parser to manage CSS3 (ex : to manage odd/evenrow in table http://www.w3.org/TR/css3-selectors/#nth-child-pseudo).

Regards Angelo

2011/6/25 Tom Schindl <tom.schindl@xxxxxxxxxxxxxxx>

Hi,

Tooling:
--------
As part of my work creating a CSS-Editor for JavaFX-Syntax[1] I've
created the foundation for a very generic CSS-Editor infrastructure one
can use to add ones own special attributes.

If you agree I'd like to move this code into e4 and add support for our
CSS-Syntax / Attributes - I think we need tooling to help people to
master our none standard CSS-Extension Syntax.

The tooling is built around Xtext 2.0 which means this is going to be a
hard dependency for the tooling.

A nice side effect is that Xtext creates a semantic in memory EMF-Model
of the CSS which could be (at least in theory) used as a replacement of
the current CSS-Parsers but I have not taken a look into the whole
CSS-Implementation internals to understand what would be need to replace
the current system with this one.

Our CSS Syntax:
---------------
Our usage of none standard CSS-Extension Syntax is a problem I've
noticed because other vendors like Mozilla, Webkit to name some follow a
naming scheme when adding attributes not defined in the CSS-Standard and
so does for example JavaFX.

The naming scheme to follow when adding extra stuff is by starting the
attribute with '-' afterwards the vendor (webkit,moz,fx) and afterwards
the attribute name. I think we should also follow that rule so our
attributes should look like this:

tab-renderer          => -swt-tabrender
unselected-tabs-color => -swt-unselected-tabs-color

Another thing I notice by feeding our CSS-Stylesheets into the my editor
is that our CSS-Files are invalid at least they are not CSS 2.1 (if you
look at the BNF [2]).

So things like:
.MTrimmedWindow.topLevel
.MTrimBar#org-eclipse-ui-main-toolbar

Are not valid constructs - I'm not 100% sure what those two selectors
are supposed to do but they clearly show that we need tooling to master
the CSS-Files to not produce invalid stuff.

Last but not least when looking at our gradient definitions I'd like to
suggest that we are aligning ourselves with the CSS3 definition of it [3]

Tom


[1]http://tomsondev.bestsolution.at/2011/06/24/introducing-efxclipse/
[2]http://www.w3.org/TR/CSS21/grammar.html
[3]http://dev.w3.org/csswg/css3-images/#linear-gradients
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev