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 XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format