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

It seems worth recording somewhere that the flute parser behaves (to me)
unexpectedly on @media rule - e.g. for "@media handheld, all {...}"ois
is probably wrong, in my view ... the e - e.g. turns just catching up).

ext Key Task force espouses my ideas on this (see r it returns only
"all". This is probably wrong, in my view ...

 

Jo

 

> -----Original Message-----

> From: public-mobileok-checker-request@w3.org [mailto:public-mobileok-

> checker-request@w3.org] On Behalf Of Jo Rabin

> Sent: 15 June 2007 21:50

> To: Sean Owen

> 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 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/

> > >

> > >

> > >

> > >

> > >

> > >

> > >