- From: Jo Rabin <jrabin@mtld.mobi>
- Date: Mon, 9 Jul 2007 15:15:36 +0100
- 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 UTC