Re: CSSResourceToDom questions

> Miguel, sorry I didn't recognize the XML version of the CSS called from
> the HTTPCSSResrouce constructor. Some of it was there in the moki, but i
> failed to notice it because it did not contain all of the css styles I had
> written into my test document. Primarily, @ import tags. However, this small
> error raises a more important question: should we continue to refine the
> CSS->XML parser to get it to the point where we can use it, or bypass this
> method and complete the parser at a different time? Because right now, it
> doesn't function well enough to perform the necessary CSS tests.
>
> I agree with Sean that we don't really need a serialization of the CSS at
> this point. What we need are the following:
> 1) validate correct CSS markup
> 2) a way to identify the resources referenced in CSS (stylesheets and
> images)
> 3) a way to report the lines numbers of markup errors and references
>
> As I see it, all of these things can be accomplished with regular
> expressions. The current CSS->XML handler would have to be changed
> significantly in order to support these features, and as far as resource URL
> identification, we would still need to perform some regular expression
> matching. However, with regular expressions, I feel like we can do all of
> these things (Miguel, would you elaborate what you mean by "more
> fine-grained processing"?)
>
> Also, this method isn't as flexible for inline style elements. It looks
> like we'd be making a separate stylesheet element for each inline style
> reference, which can get really messy. I would much rather have unified
> methods that identify elements in all external, embedded, and inline
> stylesheets.
>
> For the scope of our task, and that fact that this issue is holding up
> development on my side, I'm encouraging that we just get these tests done
> rather than focus on perfecting our own implementation of a CSS parser. We
> can always add in the CSS parser as a resource for developers later. Would
> everyone be ok with moving forward with regular expressions and saving the
> parser for later?
>
> Cheers,
> Laura
>
> On 8/2/07, Sean Owen <srowen@google.com> wrote:
> >
> > 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
> > >
> > >
> >
>
>