RE: css with regex

Hi everyone,

 

> a) can you stop the CSS validator from importing files to check?

 

 This is really a problem because we have error reporting

 both in the imported file and the original CSS. On the other hand I did
not 

 find how to set this with CSS validator.

 

In order to review (I am a bit lost), the current process with CSS is:

 

*In Preprocessing phase (Preprocessor class) Java classes are created

 for every kind of CSS (except inline CSS).These Java classes are
EmbeddedCSSResource

 and HTTPCSSResource. The responsibilities of these classes are
basically validating CSS.

 

*Entity of CSS Retrieval blocks are built with the data contained in
HTTPCSSResource objects.

 

*CSS tests with regex approach are made against CSS blocks in moki
(entiy tag of retrieval blocks

 or primaryDoc).

 

Now we are talking about preprocessing  CSS in order to applied only
proper media and so on. I have some doubts

with this:

 

When this modification takes place? 

-Is going to be saved in moki and accessible thorough XPATH (In this
case we would have false entity headers or would use other tags)

-Recover through XPATH CSS stuff (like is nowdays occurs) and then
process the obtained CSS.

            -Save this information and the beginning of Preprocessing in
Java Classes (HTTPCSSResource and EmbededdCSSResource plus CSS inline
info) so

             CSS validator can be  applied against correct CSS stuff. 

 

I think that this last approach is the correct if we want to solve CSS
Validator problem. What I don' know is if the modified CSS is going to
be saved in moki or not because

of the XPATH expressions. 

 

Abel.

________________________________

De: public-mobileok-checker-request@w3.org
[mailto:public-mobileok-checker-request@w3.org] En nombre de Jo Rabin
Enviado el: viernes, 17 de agosto de 2007 23:52
Para: Laura Holmes
CC: Sean Owen; public-mobileok-checker
Asunto: RE: css with regex

 

A couple of questions:

 

a) can you stop the CSS validator from importing files to check?

b) most likely the structural checkering and stripping can be done with
SAC all in one phase?

 

Jo

 

________________________________

From: Laura Holmes [mailto:holmes@google.com] 
Sent: 17 August 2007 20:49
To: Jo Rabin
Cc: Sean Owen; public-mobileok-checker
Subject: Re: css with regex

 

That seems like a pretty feasible thing to do. So, unless anyone else
has any objections, I'll go ahead and start making these changes on
Monday?

- Laura

On 8/17/07, Jo Rabin <jrabin@mtld.mobi> wrote:


Well, I suppose that there is a complication in that if the CSS is not
well-formed then stripping out the bits that don't count actually
involves parsing the css so you strip out only the right bits.

So I think the processing sequence would have to be: 

Parse as CSS 2.1
Report only structural errors
If no structural errors then strip out the @media and @import related
bits
Extract the referenced images and imports
Parse as CSS level 1 [while finding a way to suppress checking of the 
remaining imported files]

Or something like that.
Jo


> -----Original Message-----
> From: public-mobileok-checker-request@w3.org [mailto:public-mobileok-
> checker-request@w3.org] On Behalf Of Sean Owen
> Sent: 17 August 2007 18:50
> To: Jo Rabin
> Cc: Laura Holmes; public-mobileok-checker
> Subject: Re: css with regex
>
> Nah, I don't think it's all that bad. You find some particular
> patterns and cut out some bits of the document before parsing. It can 
> be done line by line, preserving line numbers, without any more
> trouble than that. There should not be any change to how anything else
> is printed. Basically we are manually processing @media before turning

> other tools loose on it, which smooths out the wrinkle we've
> introduced in the DDC, that CSS1 + @media is supported.
>
> Sean
>
> On 8/17/07, Jo Rabin < jrabin@mtld.mobi <mailto:jrabin@mtld.mobi> >
wrote:
> > If I had enough hair to raise, it would sound hair raising!
> >
> >
> >
> > I think that it might work, but also think it raises the specter of 
> pretty
> > printing the CSS just to report the line numbers, rather as we have
> > discussed the same with reference to XHTML error reporting ...