Re: CSSResourceToDom questions

What about inline style attributes, and embedded stylesheets? For
consistency wouldn't we want to handle these too? I think it gets
quite complex.

Again, I am not sure why we need to construct a parse tree for CSS at
all. Either way we need to just run some regexes on the property
values, so, it is only more complex to add on this tree.

The argument I heard for it is, well, wouldn't it be nice to define a
CSS serialization in XML? and we'd rejected other parsers not because
they didn't work but because we didn't like the XML. All that's fine,
but seems like a side project.

Right now we have an uneven approach to parsing CSS and I think that
has to be addressed. I think we either define a more comprehensive
serialization of CSS for all CSS, not just external stylesheets, or
else remove the serialization. Right now I see the former being a lot
of work for no gain. Is it meeting a requirement I am not thinking of?

On 8/2/07, Miguel Garcia <miguel.garcia@fundacionctic.org> wrote:
>
> > I'm working on including resources mentioned in css, and I've come
> across > the CSSResourceToDom method in CSSUtils. Can the author of this
> method help me answer some questions?
>
> > 1) Why is this method used in EmbeddedCSSResource, but not present in
> > HTTPCSSResource?
>
> HTTPCSSResource makes a call to CSSResourceToDom in its constructor. At
> least in the revision 1.10 (which is the latest in CVS).
>
> > 2) What are the distinct advantages of this approach vs. just using
> the
> > text data of the css to get the information we need for the tests?
>
> Basically this approach allow us a more fine-grained processing than
> just using regular expressions. Aditionally we can use some existing
> tools (SAC parsers) to do part of the work. Besides I think it's easier
> using SAC than regular expressions.
>
> > Thanks!
>
> > Cheers,
> > Laura
>
>

Received on Thursday, 2 August 2007 13:16:11 UTC