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

RE: ACTION 515 -New CSS approach

From: Jo Rabin <jrabin@mtld.mobi>
Date: Mon, 9 Jul 2007 15:15:36 +0100
Message-ID: <C8FFD98530207F40BD8D2CAD608B50B448363F@mtldsvr01.DotMobi.local>
To: "public-mobileok-checker" <public-mobileok-checker@w3.org>

I don't particularly see a problem with having the CSS results in the moki document - though I do agree with the point about not wanting this to be an established part of moki - so we could have a teeny namespace within which to put such things?

I don't think that standardising as part of moki a limited CSS-in-XML format as such a good idea. 

All in all, I don't think there is a good answer to this problem ... I would on balance prefer to do a full CSS in XML, but then you'd all probably expect me to say that :-)

Jo



> -----Original Message-----
> From: public-mobileok-checker-request@w3.org [mailto:public-mobileok-
> checker-request@w3.org] On Behalf Of Miguel Garcia
> Sent: 09 July 2007 14:11
> To: public-mobileok-checker
> Subject: RE: ACTION 515 -New CSS approach
> 
> 
> When dealing with CSS tests we have two options, doing the test in
> Preprocessor class (as validation is done) or trying to make the test by
> an XSLT.
> 
> Our first approach was adding a element to moki with the result of
> performing the test (StyleSheetSupport) during preprocesing. This approach
> has its flaws mainly adding an specific mobileok test result to moki (as
> we hope moki could be used for other tools not only mobileOk checker).
> 
> The other option passes through getting an CSS representation in XML, not
> necessary an "exact" representation but an "equivalent" one that is
> suitable for doing the tests. We have committed this early implementation
> to discuss.
> 
> A Java function called from XSLT is an option (perhaps the best) for
> inline styles but not for style blocks (style tag and linked stylesheets).
> 
> Also using a lot of Java functions from XSLT will make us more dependant
> to the XSLT library.
> 
> Miguel
> 
> >>-----Mensaje original-----
> >>De: public-mobileok-checker-request@w3.org [mailto:public-mobileok-
> >>checker-request@w3.org] En nombre de Sean Owen
> >>Enviado el: sábado, 07 de julio de 2007 23:27
> >>Para: Abel Rionda
> >>CC: public-mobileok-checker@w3.org
> >>Asunto: Re: ACTION 515 -New CSS approach
> >>
> >>
> >>At a high level, I don't understand why we need to do much of anything
> >>with CSS. We record the retrieval of the CSS document and its
> >>contents, and some information about syntax errors. That's all we
> >>need.
> >>
> >>The only tests we conduct on CSS then look for absolute units of
> >>measure, which is almost just regular expression matching, does not
> >>need to be conducted in preprocessing, and is easily implemented in
> >>Java.
> >>
> >>What is the need then for CSS-in-XML or anything this complicated? I
> >>remain concerned about how much complexity is increasing here.
> >>
> >>Sean
> >>
> >>On 7/6/07, Abel Rionda <abel.rionda@fundacionctic.org> wrote:
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> This is a summary of what we  have already committed regarding CSS
> >>stuff:
> >>>
> >>>
> >>>
> >>> *So far, what was previously committed in CVS was explained in
> >>>
> >>>  a mail some days ago but the main points were:
> >>>
> >>>
> >>>
> >>>             -Java classes for represent CSS resources.
> >>>
> >>>             -Representation in moki of CSS validation info.
> >>>
> >>>             -Representation in moki of CSS test specific info.
> >>>
> >>>
> >>>
> >>> *As Sean said, the last point was not very correct (having an
> >>intermediate
> >>>
> >>> doc with mobileOK test specific info) so we tried to proceed with
> using
> >>java
> >>>
> >>> functions from XSLT (similar approach to Caching test).
> >>>
> >>> But we desisted from this approach because Java functions would not
> >>return
> >>> primitives
> >>>
> >>> types but blocks of XML result code, which it is not a very good
> >>solution.
> >>>
> >>> In addition tests classes would need visibility of PreprocessorResults
> >>to
> >>> extract CSS info
> >>>
> >>> (what is not contained in moki)
> >>>
> >>>
> >>>
> >>> *So this week, we (basically Miguel) go on with another different
> >>approach
> >>> to fulfil
> >>>
> >>> this problem. This is a pseudo serialization of CSS in XML in the
> >>following
> >>> format:
> >>>
> >>>
> >>>
> >>>             <styles>
> >>>
> >>>             <style>
> >>>
> >>>                <selector>a:link</selector>
> >>>
> >>>                <property name="color">rgb(0, 0, 204)</property>
> >>>
> >>>             </style>
> >>>
> >>>             <style>
> >>>
> >>>                <selector>a:visited</selector>
> >>>
> >>>                <property name="color">rgb(0, 0, 204)</property>
> >>>
> >>>             </style>
> >>>
> >>>
> >>>
> >>>       </styles>
> >>>
> >>>
> >>>
> >>> And we have modified MeasuresTest and StylesheetsSupportTest to deal
> >>with
> >>>
> >>> this approach and also in order to use the new result template.
> >>>
> >>>
> >>>
> >>> Any feedback on this will be welcome. J
> >>>
> >>>
> >>>
> >>> CTIC team
> 
Received on Monday, 9 July 2007 14:15:58 GMT

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