RE: ACTION-516 [CTF] Evaluate how hard it would be to produce XML out of CSS stylesheets using SAC

Hi folks,

Miguel and I are working in our CSS action 515 -implement the CSS stuff
(removing JXCSS, implement validation, and use SAC for test
implementation)
and we hope having some updates at the end of this week.

A summary of these changes:
*CSS grammar validation.
*CSS information inside moki to fulfil stylesheet_support_test.

With these changes we could take a decision on if this approach is the
adequate or perhaps put our efforts in the serialization of CSS.

One point that we are worried about is that the CSS tests are really few
but they imply  modifications in moki in a very ad hoc way. 
(Having a serialization of CSS all the work would be in the XSLT side).

So, it seems that we have a trade off between better maintenance (CSS
Serialization) and rapid development (procedural approach) :( 


Abel.



-----Mensaje original-----
De: public-mobileok-checker-request@w3.org
[mailto:public-mobileok-checker-request@w3.org] En nombre de Jo Rabin
Enviado el: viernes, 15 de junio de 2007 22:50
Para: Sean Owen
CC: public-mobileok-checker
Asunto: RE: ACTION-516 [CTF] Evaluate how hard it would be to produce
XML out of CSS stylesheets using SAC


I agree with the point about deferring till later what is not required
now. However, we do need to parse CSS in some way, we do want to capture
more than one error if there is one. And in addition to looking for
absolute measures we also need to parse by @media rule and we also need
to pull in @imports and also background and list images. All in all it's
not completely trivial.

So what I propose is that I get on with doing the minimal implementation
per the above and extract some kind of structure with the relevant
information in it. Whether that then goes on to being a full XML
serialization I think is between me and my God and/or employer. It's not
burningly urgent to have the XML serialization and there is a lot else
to do. 

It does look as though the Flute parser is the one to go for, though the
fact that it appears not to work correctly for CSS comments is a worry.
If anyone has experience that goes beyond Batik and Flute that would be
good to hear.

Jo

> -----Original Message-----
> From: Sean Owen [mailto:srowen@google.com]
> Sent: 15 June 2007 20:43
> To: Jo Rabin
> Cc: public-mobileok-checker
> Subject: Re: ACTION-516 [CTF] Evaluate how hard it would be to produce
XML
> out of CSS stylesheets using SAC
> 
> I don't have any problem with this sort of thing in principle --
> merely concerned about the amount of effort it will take to conceive
> and implement a new XML serialization of CSS. In fact, we need to do
> very little with CSS stylesheets other than load and validate them. We
> need to look for absolute units, which is almost an operation for mere
> regular expressions.
> 
> An XML serialization in the moki doc would no doubt be useful to
> future generations of extenders. Any support for putting this off
> until later though?
> 
> I won't object if you really want to do it or anything but don't think
> it's a must-have to finish an implementation.
> 
> Sean
> 
> On 6/15/07, Jo Rabin <jrabin@mtld.mobi> wrote:
> >
> > A status report on this action arising from our F2F in London this
week.
> >
> > This comes from Dom's throw-away line "couldn't you just ..." and my
> > taking the bait.
> >
> > So the story so far:
> >
> > I built a trivial framework around SAC and implemented a trivial
> > ContentHandler and ErrorHandler.
> >
> > I used the Batik CSS Parser as the starting point - on the
> > recommendation of the SAC Home Page [1] which says that it is
smaller
> > and faster than the W3C Flute implementation. It turns out that
Batik
> > appears to get into a tangle on the first error and doesn't appear
to
> > recover properly. So switching to the Flute implementation (slower,
> > bigger) it does appear to recover from errors properly - and my
guess
> > would be that is why it is slower and bigger. But for our purposes,
much
> > more appropriate. Though time will tell actually how well it works,
> > given that it appears not to pass through comments.
> >
> > (It's an interesting question, I suppose, that the Batik parser
appears
> > to contravene the spirit if not the letter of CSS parsing rules, and
> > consequently, perhaps it should appear with that caveat on the SAC
home
> > page).
> >
> > So far as JXCSS is concerned, the implementation notes say that it
> > doesn't work with Flute, if I remember correctly, which is a
limitation,
> > and it does not implement an error handler. Neither of these is a
> > terminal error , I guess, but it does raise the question of whether
to
> > implement afresh - in reality copying much of what JXCSS does in its
> > document handler, or whether it makes sense to carry out surgery on
> > JXCSS itself and contribute it back.
> >
> > I think that given Sean's military attitude to coding style :-) we
are
> > probably better doing the former, with due acknowledgement, of
course,
> > to where code has been 'borrowed'.
> >
> > There's of course the issue of error messages ...
> >
> > ... so the conclusion seems to be that the answer is 'yes' - I am
not
> > going to be able to do much more work on this over the next week or
so.
> >
> > Jo
> >
> > [1] http://www.w3.org/Style/CSS/SAC/
> >
> >
> >
> >
> >
> >
> >

Received on Wednesday, 20 June 2007 12:46:53 UTC