This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: SAX parser for CSS (Was: Conversion from xsl to xsl:fo)
- To: XSL List <xsl-list at lists dot mulberrytech dot com>
- Subject: Re: [xsl] SAX parser for CSS (Was: Conversion from xsl to xsl:fo)
- From: Joerg Pietschmann <joerg dot pietschmann at zkb dot ch>
- Date: Thu, 25 Oct 2001 16:35:52 +0200
- Organization: ZKB
- Reply-To: xsl-list at lists dot mulberrytech dot com
Eric van der Vlist <vdv@dyomedea.com> 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