W3C home > Mailing lists > Public > public-mobileok-checker@w3.org > June 2007

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

From: Sean Owen <srowen@google.com>
Date: Fri, 15 Jun 2007 15:43:01 -0400
Message-ID: <e920a71c0706151243y39586b47s68443f50826194f4@mail.gmail.com>
To: "Jo Rabin" <jrabin@mtld.mobi>
Cc: public-mobileok-checker <public-mobileok-checker@w3.org>

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 Friday, 15 June 2007 19:43:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:13:03 GMT