Re: CSS and XSL

Subject: Re: CSS and XSL
From: Paul Prescod <paul@xxxxxxxxxxx>
Date: Tue, 16 Feb 1999 14:43:02 -0600
Thank you for your substantive, carefully thought out post. I hear less
and less from employees of the W3C so your participation is greatly
appreciated!

Chris Lilley wrote:
> 
> That is a reasonable suggestion, though as I mentioned before brings up
> the question to what extent the generation of non-XML syntaxes is in
> scope for XSL.

Right. And making a special case for CSS would indicate that something is
wrongly designed.

> 1) It would add (for CSS2) 108 attributes (counting the properties in
> the CSS2 property index and omitting all shorthand ones). That is really
> going to mess up structured editors that let you seee for the current
> element what its attributes are and their values

Let me make clear that I am proposing this only for DTDs like SVG that are
inherently presentational.

Why? Let's presume that there are two kinds of editors, CSS-aware ones and
CSS-unaware ones. CSS-aware ones will hide either the STYLE attribute or
the 108 separate attributes. I would surely hope that most SVG-editing
would be done in CSS-aware programs because editing SVG by hand is
possible but looks like not much fun.

CSS-unaware ones will at least display something *useful* under my
proposal. Under the current system they display an opaque CDATA text entry
field. How is a novice user supposed to know that they should go get a
book on a completely different language and type in a special syntax into
the text field?

> 2) It would require setting all properties individually, including ones
> that are set to their initial values using shorthand properties or where
> related properties are all set to the same value. 

As Oren Ben-Kiki has pointed out you can maintain your current semantics
for shorthand properties.

> 3) It would require the same attributes to be duplicated on all elements
> matched by a (fully cascaded) equivalent stylesheet to all the browser
> default, author and reader stylesheets. That seems staggeringly verbose
> and a maintenance nightmare.

I don't know what you mean by that. All I can say is that I have not
suggested any change in how external styles or cascaded styles are
handled. Just as is currently the case, the document gets first crack but
if it chooses not to take it then the external style sheets and cascaded
style sheets get their chance.

> 4) It would require all these attributes to be added to the xml
> namespace, since the alternative is to either trust that everyone uses
> the same names whenthey make up a namespace, or to use a different
> namespace. The latter would (currently) preclude using valid xml
> documents; its not possible at present to validate a document that uses
> more than one namespace.

That is simply not true. There is nothing in the namespace specification
that precludes validation. Validation will break if you change prefixes
but that is the case whether you have one or ten namespaces. SVG does
allow use as a namespace so that "problem" has already been invoked.

> 5) The inheritance model would be really wierd (well, in fact, it would
> not have an inheritance model. All elements would have values set on all
> 108 stylistic attributes

That is not the case. XML does not require elements to have a default
value. An application can know whether a value has been specified or not.

> 6) Dynamic manipulation of styles via the DOM, something that is widely
> done at present, would become vastly more complicated. Querying what

I do not know why you say that. How is manipulating a CDATA style
attribute so much easier than manipulating several attributes?

> 7) User style sheets would essentially disappear

I do not know why you say that but I am confident that it is not the case.

> 8) Further development of CSS would require all DTDs to be updated to
> add the new attributes.

No more or less so than with RDF, MathML, "Voyager Tables" and all of the
other reusable document type fragments being designed within the W3C. The
W3C has committed to making modular document types. CSS property
attributes are just one such module.

> OK so you are assuming here that the attributes which used to be
> properties are just added by each person who defines the DTD. And a
> consistent style model that works across namespaces happens how?

It doesn't work across namespaces. It works across the CSS: namespace.

> Ah, by rewriting the syntax in XML. Taking us back to the dark old days
> of spaghetti documents and no separation of structure and content and no
> user choice in document presentation and no dynamic web pages.

I hope I've pointed out that none of that is the case. In any case, SVG is
a *presentation DTD*. It provides no real mechanism to separate content
from structure currently. Sure, you can reuse formatting (through styles),
but you can't choose not to specify formatting in the way that you could
with HTML.

> > I'm not so much of a purist that I think that CSS's current
> > syntax should never be used.
> 
> Good.

Let me be clear and point out that the proposal for css:rule, while
reasonable, is NOT MINE and is separate. I understand that the political
ramifications for a new syntax for *CSS* could be quite contraversial. All
I am asking for is a better syntax for *SVG*.

> Its very fashionabe right now to want to express everything in XML, and
> often that makes sense. But it seems that it obscures the underlying
> processing model in folks minds. If the input document is XML and the
> stylesheet is XML and the transformed document is XML and the styled
> transformed document is XML then, it seems, folks get confused; they
> start relying on case conventions to separate out which elements mean
> what where; they get so confused that they think HTML is a formatting
> language.

I agree 100%. By the time you get to something like RDF, the number of
layers of structure that authors must keep track of ar prohibitive.
Eventually we will have to go back to optimized syntaxes. I have no
problem with that. 

I am speaking about a single attribute, in a single DTD and in
formatting-oriented DTDs like it. In this case I am trying to *decrease*
the number of layers that the user must keep track of by aligning a
concept that they are familiar with (the attribute) with one that they may
not yet be familiar with (CSS property).

> With the addition of the transformation capabilities of XSL, which is
> designed to be able to do the sort of transformations that are required
> when styling documents, that limitation goes away; the combination of
> XSL transformation followed by CSS styling of the result gives very
> powerful formatting capabilitis in multiple output media.

Clearly your vision is out of step with that of the W3C XSL working group.

I keep thinking that your model is viable and then I wonder "why two
stylesheets?" The benefits are not clear. The formatting objects are about
the same semantic level of HTML and the formatting properties are
specified in attributes. That's more intuitive to me than a two-layer
system just for the sake of having two layers.

If you define the mapping between XML CSS: attributes and CSS styles then
the FO: output could use the CSS: attribute and the two models would be
inherently and automatically "in sync." To be honest, I'm not clear on why
the XSL working group is not using the XSL-and-CSS note as its starting
point but I presume it is just W3C politics.

> You can see that I am headed in the opposite direction from where I
> understand Paul to be heading:
> 
> stylistic attributes
> a style attribute
> a style element
> inline style links
> out of line style links
> 
> The CSS Object Model should make it transparent whether a particular
> element got its style via a style attribute, the style element or an
> external stylesheet.

I support everything above except "a style attribute." The functionality
of "stylistic attributes" and "a style attribute" overlap too much and
cause confusion. A particular DTD should go all of the way one way or all
of the way the other. Formatting-centric DTD should go all of the way to
per-attribute-style. Structural DTDs should either have NO inline style
(as I argued for HTML, but lost) or should have the single style attribute
as an equally-suboptimal-to-everyone compromise.
-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself
 http://itrc.uwaterloo.ca/~papresco

If you spend any time administering Windows NT, you're far too familiar 
with the Blue Screen of Death (BSOD) which displays the cause of the 
crash and gives some information about the state of the system when 
it crashed.  -- "Microsoft Developer Network Magazine"


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread