Re: [e4-dev] CSS Engine and CSS3 SAC Parser with FreeCC?

[Kevin McGuire <Kevin_McGuire@xxxxxxxxxx>]

Good error reporting tracing back to
the source location is a definite must.  Code completion would also
be nice.

Another technical direction worth considering
is to use XText (http://wiki.eclipse.org/Xtext).  Tom Schindl and
others were doing some preliminary hacking on an XText based CSS parser
at EclipseCon.  It looked promising although there's some oddness
with the CSS grammar that will cause extra work.

With the XText route you get very good/easy
support for source level markers and code completion.  You also get
an EMF model which has some advantages wrt standardization and tooling.
 I don't know FreeMarker so can't compare one vs. the other.  For
this community, XText might allow a wider set of contributors since I'm
thinking more people here know about XText than know about FreeMarker.
 Finally, if we really wanted to dream, the XText route could allow
a more general EMF styling model, with CSS just being one source format,
but allowing more powerful styling expressions in some other non-CSS or
modified CSS markup.

In any case, my e4 0.9 CSS parser/engine
goals are:

1) Smaller parser footprint
2) CSS2 
3) Easier ability to extend engine to
support custom widget properties and pseudo classes (Angelo has proposal
for this, see discussion in https://bugs.eclipse.org/bugs/show_bug.cgi?id=262855
for example)
4) Better error reporting

Regards,
Kevin

Jonathan Revusky <revusky@xxxxxxxxx>
Sent by: e4-dev-bounces@xxxxxxxxxxx

04/02/2009 01:22 AM

Please respond to
E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>

To	E4 Project developer mailing list <e4-dev@xxxxxxxxxxx>
cc
Subject	Re: [e4-dev] CSS Engine and CSS3 SAC Parser with FreeCC?

On Mon, Mar 23, 2009 at 9:18 PM, Mathias Schäffner
<mathias.schaeffner@xxxxxxxxxxxxxx> wrote:
> Hi,
>
> I think it's a great idea having a new CSS Parser, so that we don't
> depend on the Batik implementation anymore.
> Would be easier to maintain it and to implement new features that
we
> would like to have because of some Eclipse projects that use a CSS
> parser.
>
> CSS3 is a great step forward.
> But I'm more interested in some other features.

Hi Mathias,

Sorry to have taken so long to respond to this.

>
> 1. Correct handling of comments within a CSS file

> 2. Getting information (line and column number) where a rule or
> property occurs in the file

Yes! Definitely!

Really, for me, this is not an issue specifically in writing the CSS3
parser, but rather, it is something that pervades my work in the
parser space, my work on FreeCC and also FreeMarker. (In the case of
FreeMarker, the superior error messages that it generates are
frequently cited as a big advantage over competing templating tools.)

I find that the whole question of maintaining location information and
generating good error messages that allow you to trace back to the
point of error, this is something that is not really addressed
adequately in most existing tools. My own theory about why this is is
that this whole parser generation space is very dominated by
academic/theoretical considerations over pragmatic ones. So, you know,
from the theoretical viewpoint, what the parser does with incorrect
input is basically beside the point. Your parser rejects incorrect
input and that's that.

However, as a practical question, what a parser (and consequently a
compiler or interpreter) does with incorrect input is very important,
because a tool providing a clear message about what was wrong and the
location where it was wrong is a huge factor in a tool's usability.

So, you see, a basic goal in FreeCC development is that any parser you
develop with FreeCC will almost automatically (or at least with
minimal extra effort on the part of the developer) provide very good
error message feedback. And, of course, my idea in the conversation
with Angelo Zerr, was that the CSS3 parser would kind of be a showcase
for how to use FreeCC, so this kind of issue will be very central.

Anyway, I am sorry to have been so slow to respond. It is probably
because I am a bit embarrassed at having been so slow to get the CSS3
parser going and I don't like talking too much about things that are
vapour. Certainly I'll be much more vocal when there is actually some
initial beta that you guys can try out.

Thanks,

Jonathan Revusky
--
lead developer, FreeMarker project, http://freemarker.org
FreeCC Parser Generator http://code.google.com/p/freecc



>
>
>> Hi,
>>
>> Today we have several SAC Parser implementation available (Batik,
Flute,...).
>> E4 CSS engine is today based on Batik SAC implementation, I think
for IP reason.
>>
>> Problem is that SAC Parser implementation manage only CSS2, not
CSS3.
>> You can find CSS3 features at http://www.w3.org/TR/css3-selectors/
>>
>> Why CSS3? Because it gives some features like :
>>
>> * nth-child : which is very interesting to set CSS  style
into row of SWT Table (eg : set a color to a particulary row like set blue
color on odd row and set red color even row). Ex :
>>
>> TableItem:nth-child(odd) {
>>    color:blue;
>> }
>>
>>
>> TableItem:nth-child(even) {
>>    color:red;
>> }
>>
>> * use namespace to disting CSS style for SWT Label and Custom
Label. Ex :
>>
>> @namespace custom "com.mycompany.widgets"
>>
>> Label {
>>    color:red;
>> }
>>
>> custom|Label {
>>    color:blue;
>> }
>>
>>
>> With CSS2 SAC Parser, we cannot manage thoses cases. I think it's
shame.
>> So I think it's time to think about CSS3 SAC Parser implementation.
>>
>> I don't know if Batik is interesting to support CSS3 SAC Parser,
but I know that Jonathan Revusky, one creator of famous Freemarker project
is perhaps interesting to implement CSS3 SAC Parser with her new project
FreeCC which is Parser (it's a fork of JavaCC).
>>
>> What do you think about the idea to implement CSS3 SAC Parser
with FreeCC?
>>
>> Regards Angelo
> _______________________________________________
> e4-dev mailing list
> e4-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/e4-dev
>
_______________________________________________
e4-dev mailing list
e4-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/e4-dev