RE: ACTION 515 -New CSS approach

Hi,

What we seek is not a "reversible" representation but an "equivalent" representation of CSS.

I'll try to explain myself.

We don't need an XML that is an exact representation of the CSS source. We just need a representation in XML suitable to apply XPATH expressions and our XSLT template to get the test outcome. This task is easier to achieve than the former. 

For example, a difference between Jo example and our example is that we don't save what kind of selectors are used. 

Jo's selector representation: <selector value="a" pseudo="visited"/>
Miguel's selector representation: <selector>a:visited</selector>

There is no need of further processing of css selectors so we don't need to add this kind of information to moki, moreover if complex selectors like "div#menu a#menu_link:hover" would be quite complicated to represent. 

Even more, do we need any selector information at all?, would it be enough just saving CSS properties in moki document?

Another issue is processing short hand css properties, at least properies we are interested in. What we are thinking about is split them to their canonical css properties. An example will clarify this.

CSS: h1 { font: bold, 12px , "Verdana, Arial"; }

XML representation (it isn't implemented yet): 
<property name="font-weight">bold</property>
<property name="font-size">12px</property>
<property name="font-family">Verdana, Arial</property>

We think that with these simplifications CSS representation in XML will work. 

We expect to discuss and settle this issue in next teleconference.

Miguel

________________________________________
De: public-mobileok-checker-request@w3.org [mailto:public-mobileok-checker-request@w3.org] En nombre de Jo Rabin
Enviado el: viernes, 06 de julio de 2007 14:56
Para: public-mobileok-checker@w3.org
Asunto: RE: ACTION 515 -New CSS approach

Ah, I thought we had abandoned the CSS-in-XML approach. As I had been working, in a rather background kind of way, on a serialization which I thought might be useful some time down the road. If we are to have a serialization I think it needs to be robust as a stand-alone piece of work and it needs to work for style sheets, style elements and style attributes.

If we are going to switch tack back to CSS-in-XML I’d be happy to up the priority of what I have been doing. It does not look a whole lot different to what is suggested below, but as always, the devil is in the detail.

Jo

      <ruleset>
            <selector value="table"/>
            <declaration property="margin" important="true">
                  <value value="2" unit="px"/>
                  <value value="2" unit="px"/>
                  <value value="2" unit="px"/>
                  <value value="2" unit="px"/>
            </declaration>          
            <declaration property="background-color">
                  <value value="#ffccff"/>
            </declaration>          
      </ruleset>
      <ruleset>
            <selector value="a" pseudo="visited"/>
            <declaration property="color">
                  <value value="rgb(120,120,120)"/>
            </declaration>
      </ruleset>

________________________________________
From: public-mobileok-checker-request@w3.org [mailto:public-mobileok-checker-request@w3.org] On Behalf Of Abel Rionda
Sent: 06 July 2007 13:17
To: public-mobileok-checker@w3.org
Subject: ACTION 515 -New CSS approach


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. ☺

CTIC team

Received on Monday, 9 July 2007 12:00:44 UTC