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

[Mathias Schäffner <mathias.schaeffner@xxxxxxxxxxxxxx>]

Hi, Jonathan

it's great that you focus on handling error messages properly within
your parser.

In the case of CSS let me mention another issue.
There can be color values in CSS, for example like #ff0000 or
rgb(255,0,0) or 'red'.
But when I parse a CSS file, it only returns me something like R=255, G=0, B=0.
So I don't know how the color value was initially in the file.

This is really a problem, when  you would like to write back your
parsed 'model' into a text file.
Because then all color values have the same format, e.g. #ff0000.
But sometimes users want to write explicitly 'red', and it should be
in the file in this format.

So for my project it did a small hack into the batik parser.
Whenever it reads a property, it also stores it as String, the way it
was in the file.
And later I can write these string values into the file.
So there will be again the value 'red' instead of #ff0000.

What do you think about this?
Thanks,

Mathias.


On Thu, Apr 2, 2009 at 7:22 AM, Jonathan Revusky <revusky@xxxxxxxxx> wrote:
> 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
>