- From: Sean Owen <srowen@google.com>
- Date: Mon, 9 Jul 2007 10:39:17 -0400
- To: "Jo Rabin" <jrabin@mtld.mobi>
- Cc: public-mobileok-checker <public-mobileok-checker@w3.org>
I won't be around tomorrow for the call, but if we're not going all the way to a full CSS-in-XML representation (and I think that's a bit much here), which would achieve a goal of reusability, then we should go all the way towards simplicity, and simply include the text representation of the CSS in the moki document and leave it at that. I don't have a problem with Java code in XSLT. Some amount is already unavoidable. We already have to have a function to test free-form CSS in style attributes, which presumably translates easily to parsing a CSS stylesheet. Because our needs are in fact very simple, and don't require a structured representation, I suggest we keep it simple and not try to concoct a partially-structured representation. Unless I am missing something, the simple approach is entirely sufficient for our needs. Sean On 7/9/07, Jo Rabin <jrabin@mtld.mobi> wrote: > > 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:39:31 UTC