[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
Re: [xsl] SAX parser for CSS (Was: Conversion from xsl to xsl:fo)
Subject: Re: [xsl] SAX parser for CSS (Was: Conversion from xsl to xsl:fo) From: Joerg Pietschmann <joerg.pietschmann@xxxxxx> Date: Thu, 25 Oct 2001 16:35:52 +0200 |
Eric van der Vlist <vdv@xxxxxxxxxxxx> wrote > Joerg Pietschmann wrote: > >>>It ought to be a good time to invent XCSS :-) > > As many people on this list, I have also been thinking about this and, > IMHO, the parsing will not be the difficult part (and a SAX parser or a > XML vocabulary are equivalent) Correct. However, There are multiple mappings from the CSS data model onto a XML vocabulary. The differences are in details only, but details matter. I used <!ELEMENT css (styledef*)> <!ELEMENT styledef (selector+,style+)> <!ELEMENT style (name,value)> <!ELEMENT selector (element|attribute|class)> <!ELEMENT element (name,(child|descendant)*,attribute?)> all else are PCDATA. This is of course a subset only both of the CSS data model and of the CSS selectors. Apart from the names, there could be a heated discussion whether styledef should be defined as above or rather as (selectors,styles) with selectors being selector+ and styles being style+ (which is easier to process with XSL in some cases according to my experience). Furthermore you'll notice that i used a generic approach which would allow the concrete style tags to change without changes in the DTD. Also, the element value, as sepcified above, may actually be a list of values (for example font family names) which requires a second parse pass. Therefore there could be another discussion whether it should be value+ instead. > and what is much harder is to match the > CSS selectors and XPath... [snip, see article:] > http://lists.w3.org/Archives/Public/www-style/2001Jan/0091.html While short, the article is enlightening. My suggestion: - XMLify CSS - use XPATH for matching elements For example <css> <styledef> <selector match="td"> <selector match="table/th"> <selector match="table//td"> <selector match="tr[@class='toc']"> <selector match="*[@id='sans-serif']"> <style><name>font-family</name><value>Helvetica</value></style> <styledef> </css> While the paths above could be mapped onto CSS selectors (unless i made mistakes...), with XPath we could specify much more complex stuff. Pseudo formats (a:visited, p:first-letter) don't fit in, but could be handled by another attribute of the selector element. I don't think there is a real need to retrofit CSS syntax into XML by proposing the "Stylable DOM". Especially as long as it is a pain to operate multiple DOM implementations in the same application. In order to bring it on topic for the XSL list, i want to note that the proposed form would be most useful if XSLT has the capability to dynamically evaluate XPaths...in the result tree! I know this should better go to the xml-dev list, but i don't have time to track yet another mailing list... Regards J.Pietschmann XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] SAX parser for CSS (Was: , Eric van der Vlist | Thread | [xsl] A better solution..., Casadome, Francisco |
Re: [xsl] Javascript in XSL, Thomas B. Passin | Date | [xsl] access to combo data from xsl, Juan Perez |
Month |