CSS, XSL, and an RDF-like approach

[This discussion began on the XSL-list mailing list when Paul Prescod
criticized SVG's use of a 'style' attribute containing multiple CSS
properties.  After a few heated rounds, very little of which has had to do
with XSL, it's time to move this discussion to another venue.  At the same
time, this message contains a proposal for XSL, so for right now, I'm
cross-posting.  Hopefully the XSL list will pick up on the questions for
XSL, and www-style the more general and CSS-specific issues. The
SVG-specific material should be appropriate for www-svg.  Apologies to all
who receive two or more copies.]

Dider PH Martin wrote:
>What is contrary to the New philosophy however is to have a style property
>that has to be parsed with different constraint than the other properties.
>It would be easier to have a kind of object/property set thing. An object
>being marked up and having its property set expressed in the same manner.

The 'New philosophy', earlier described as 'XML conventions', seems to be
an argument for greater atomization through the use of XML attribute
(and/or child element) syntax for properties.  One property, one attribute
(or element, depending on the situation and time of day.)

As long as we're talking about objects and properties, it might be
worthwhile to look at the RDF approach.  RDF is pretty thorny, admittedly,
but one of the reasons it's thorny is that RDF doesn't make any strong
connection between property values and the ways they should be expressed.
While the serialization and abbreviated XML syntax are two possible
expressions of RDF information, there are lots more as well.  For example,
I think RDF could see:

<myElement css:style="color: red; font-weight:bold;
display:block">content</myElement>

as the same as:
<myElement><style css:color="red" css:font-weight="bold"
display="block"display="block"/>content</myElement>

or even:
<myElement css:color="red" css:font-weight="bold"
display="block">content</myElement>

(Note that I'm cheating a little on the last one, relying on namespaces to
help cope with the disappearance of a resource called 'style'.  Given the
controversies surrounding namespaces, this may not be so wise.)

The information contained in these three syntaxes is (I hope) equivalent,
and a processor, given advance knowledge that it would be dealing with
these possibilities, could convert between them easily.

> This said,
>the only reasonable motive that I see why we would have a style property
>expressed that way is for a retrofit reason. And for the first release of
>HTML+CSS(XML) (named voyager) it seems reasonable (there is legacy out
>there). But for SVG I don't understand because there is no legacy. In this
>last case, we should have more the object/property set stuff with a simple
>XML syntax because there is no retrofit to do - there is no legacy. So, for
>HTML+CSS, I guess we don't have any choice, because of the legacy, to have
>the style property and a embedded parsing rule different than XML which in
>this case act as a container format.

This is more or less the argument to grant privileges to syntax #3 as an
appropriate mode of expressing CSS style properties for SVG and formats
like it.  I think Didier understates the good reasons for the creation of
the single style property for HTML, and that it has a much longer life
ahead of it than a single 'retrofit' version.  SVG, however, is more
complicated. 

There is plenty of legacy already - both in CSS practice and in that SVG
elements may perhaps be included in HTML documents Using two different
syntaxes for style, one within the SVG element and one to position the SVG
element within the HTML document, is a fairly strange idea.  I tend to
regard existing CSS practice as a more important legacy, however.

>If SVG has an
>easy structure and an easy syntax (i.e XML) then the task is easy to
>implement. If, however SVG has more than one syntax embedded in the other
>the implementation is harder and as said in the article you mentioned, we
>loose in the process. 

In many non-HTML and possibly non-browser cases, CSS will not be a factor
and a facilities for processing CSS will not be available.  In other cases,
the cost of integrating generic CSS processing tools with SVG layout may
conceivably be more than the benefit.  For applications with existing CSS
processing tools, the use of a single style attribute may be useful; for
other environments, it may just be one more complication getting in the way
of an easy SVG implementation.

>I agree on the fact that we should keep in mind two
>principles: modularity and simplicity. These are the key success factors.

Keeping it simple and keeping it modular may be at cross-purposes here.
The question of modularity is whether you see SVG as a module in itself, or
a module that relies on services provided by a CSS module.  Does simplicity
here mean 'reusing a CSS module' or 'building a clean standalone
implementation'?  As always, it's not quite so clear.

So where do we go from here?  We have a number of syntax issues arising
that come from various members of a diverse community wanting to express
the same kind of information in a format most convenient to their needs.
My proposal is fairly simple, though the implications may be inconvenient,
requiring work in number of areas, including both CSS and XSL.  (SVG might
then change to reflect changes in CSS.)

Giving CSS greater flexibility regarding the form in which it accepts
in-line style information would give the folks who insist on one
property-one attribute the tools they need to simplify their processing
models.  Namespaces, for all their controversy, make this much easier,
allowing convenient identification of CSS properties in attribute names.
This would open the way for choice #3:

<myElement css:color="red" css:font-weight="bold"
display="block">content</myElement>

Specifying a format like this creates additional complexity, because
suddenly CSS processors have to look for information in different forms.
Putting into the CSS spec or an addendum that these forms are legitimate
and indeed interchangeable, describing a process whereby they can be
converted, might help reduce this complexity.

(Choice #2, the use of a sub-element, is also appealing in some cases, and
certainly has logical equivalence to the current standard.  Would there be
enough support?  I don't know.)

While I believe that XSL is capable of creating style attributes from sets
of other attribute or element values, it isn't clear to me that it can take
a style attribute value and tokenize it into a set of separate attributes.
XSL's contribution to this project could be a convenient set of tools for
converting information between these formats.  While to some extent that
might mean 'bastardizing' XSL to provide additional support for a 'legacy'
format (to use some of my favorite words from earlier discussions), it
might also help XSL deal with a much wider variety of problems.  (And if
this is already possible, so much the better!)

The results of these modest proposals seem to me threefold:
1) CSS gains a more flexible syntax and better support from XSL
2) XSL has an easier time generating documents that use CSS and possibly
other formats
3) SVG developers (and others) can use whichever syntax they find most
convenient, knowing that the tools for converting among them are available.

The genuinely radical proposal would be to junk XML processing with its
element/attribute content/value model for the simpler RDF model of
resources and properties, but I don't think most folks on these lists
really want to go there.  It would definitely grant the flexibility needed
to deal with these cases, but the cost of imposing that solution would be
pretty drastic.

Okay, bring out the artillery.  Smash this all to bits!


Simon St.Laurent
XML: A Primer / Building XML Applications (April)
Sharing Bandwidth / Cookies
http://www.simonstl.com

Received on Tuesday, 16 February 1999 09:00:42 UTC