Re: CSSResourceToDom questions

I am happy to see this serialization built if it meets needs, but as
far as I can tell our need is simply to look for a number followed by
certain unit indicators in a text file that happens to be CSS. I could
be wrong, but I don't think this serialization even breaks apart the
"50" and "px" in a property value "50px", so we are doing the same
parsing anyway.

I think defining a comprehensive serialization of CSS in XML is a nice
project, and could even be part of this code, but later, in my
opinion.

If it were already complete, I wouldn't argue with leaving things as
they are. But the current implementation would still need more work.
At least:
1. Would have to define some way to incorporate inline and embedded styles
2. Would have to somehow record line numbers from the original CSS

I think Laura's view is that the CSS styles are already present in the
moki document -- external stylesheets' bodies are available, as are
all inline and embedded styles in the document itself. So it's a
matter of applying the same code that detects bad units on all these
strings. That's it.

Sean


On 8/3/07, Miguel Garcia <miguel.garcia@fundacionctic.org> wrote:
> Hi
>
> >>What about inline style attributes, and embedded stylesheets? For
> >>consistency wouldn't we want to handle these too? I think it gets
> >>quite complex.
> >>
>
> Embedded stylesheets and linked stylesheets can be (and currently are)
> processed the same way, theirs only difference is one is already
> included inside XHTML code and the other must be downloaded.
>
> Inline style attributes use a subset of CSS syntax (inside a style
> attribute you can't use at-rules) so they could be treat diferent.
>
> >>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 idea is just do css related tests by string comparisons with no need
> of regular expresions. (currently CSS representation in moki maybe needs
> to split some properties values in two fields: numeric value and unit
> measure)
>
> >>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?
> >>
>
> I'm not sure if we need a more comprehensive serialization, we just need
> a representation suitable (but try not limited) to ours requirements.
>
>
> Please explain a bit how would be the process, what css information
> would be in moki, when to apply regular expresions,... because I think
> I'm blind and I don't catch how moki, xslt test and regular expresions
> will be related.
>
> Regards,
> Miguel
>
> >>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 Friday, 3 August 2007 13:46:27 UTC