- From: Miguel Garcia <miguel.garcia@fundacionctic.org>
- Date: Mon, 9 Jul 2007 15:11:16 +0200
- To: "public-mobileok-checker" <public-mobileok-checker@w3.org>
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 13:10:48 UTC