[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: CSS and XSL


Subject: Re: CSS and XSL
From: Chris Lilley <chris@xxxxxx>
Date: Fri, 19 Feb 1999 21:07:51 +0100


Paul Prescod wrote:
> 
> 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.

Right. My point was that creating a PI or link element is easy to do
with XSL - I want to move the style further from the content, not closer
towards it.

> > 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.

OK, that wasn't clear.

I do however differentiate between (graphical) content and style, even
for SVG. I don't accept all graphics as "mere" presentation.

The dividing line, for me, is this: could someone reasonably alter the
style of this and get a reasonable result. So for example, path data is
not style. Line color is.

> 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. 

Now who want special treatment for CSS? All XML editors have to know to
hide all the CSS 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.

I would hope that most SVG editing will be done graphically. I want to
use standard drawing methods for doing my SVG drawings.

> 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?

Well, same goes for the XSL pattern matching language, for example. But
I would actually rather that people designed thir content and their
style at separate times.

> > 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.

I'm not sure he pointed that out; he wanted a single css attribute
containing the exact same syntax as the style attribute in SVG which was
the basis of your original objection.

> > 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. 

Okay, I thought you were. 

> 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.

The current case is that the external style sheets and cascaded
style sheets get their chance even if the document takes it.

> > 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.

Given an appropriate namespace-aware schema, which does not yet exist,
ok.

> 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.

Yes

> > 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.

But then, all these attributes would have to inherit, down the source
tree, like xml:lang inherits at the moment. I was assuming that you were
doing away with inheritance and just listing all the values on all the
elements.

> > 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?

The CSS DOM allows the style on an element to be queried. This will be
the cascaded result of any style atttribute on the element, any (for
html) stylesheet in the style element, all linked and imported styles,
and all user stylesheets.


> > 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.
Because it seemed that you wanted to remove CSS inheritance by writing
out the cascaded style property values onto each element, as the XSL FOs
do.

> > 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.

Okay.

> > 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.

Okay, that would work once a namespace-aware schema language exists.

> > 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. 

Yes; you still want 108 attributes but these are defined in a CSS
namespace and just referenced by a namespace declaration in the document
instance. So, they are still there. Incidentally this would seem to
preclue the defaulting of values in a DTD that you alluded to earlier.

> In any case, SVG is
> a *presentation DTD*. It provides no real mechanism to separate content
> from structure currently. 

I can see how you draw that conclusion and it is certainly a defensible
position but I disagree. I see structured graphics as content. The only
things that should be styles are things that it makes sense to restyle
when reusing the graphic.

There certainly are mechanisms to separate structure from style; for
examplre you can use the standard PI to link the stylesheet to the SVG.
But people in the WG wanted per-element styles, too. 

> Sure, you can reuse formatting (through styles),
> but you can't choose not to specify formatting in the way that you could
> with HTML.

Not quite sure what you mean here.

> > > 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. 

Yes, I understand that

> 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*.

Well, that could be done quite easily. The primary reason that you gave
for doing this, however, was to make it easier for XSL to generate it.
I'm not convinced that XSL is a good way to convert something else into
SVG; and I have seen some evidence that it is not.


> > 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.

Okay.

> 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).

I see. While keeping the funky inherit-on-source CSS inheritance
mechanism, and the cascading mechanism.

> > 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.

Not really, I don't think so. The only example that I have seen so far
that really needs FOs is the queue.

> I keep thinking that your model is viable and then I wonder "why two
> stylesheets?" 

Well, if you rephrase that "one transformation sheet and one style
sheet" then it becomes clearer. Particularly when you see that the
product of the transformation step might link to multiple alternative
style sheets, and that the same style sheet might be applied to the
output of multiple different transformation processes. Its simple
modularity.

> The benefits are not clear. The formatting objects are about
> the same semantic level of HTML

Gasp. Now *that* is out of step with the XSL WG.

>  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." 

Yes, except that some 

> 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.

No, its just technical appraisal. CSS gives you a certain level of
formatting functionality (call it x); when applied to an XML instance
which has already had an XTL transformation applied (for example, to
generate a TOC, do numbering, whatever).

FO gives you a certain (higher) level of functionality - multiple flows
into multiple self-balancing columns, all the while using column
spanning and footnotes, for example. call that level of functionality y;
it comes at the expense of a different syntax and some different
concepts which the community has seemingly found more difficult to
understand than all the transformation stuff.

The XSL-and-CSS note gives you level "x" functionality with the
disadvantages of FOs, but none of their advantages. This is why neither
the CSS nor XSL WG is progressing this note. You can't do anything with
it that you can't already do using CSS.

> > 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.

OK, now I understand your proposal better. In particular, the complete
divide between presentational and structural DTDs, which was not
apparent before. I thought you wanted this for *all* DTDs, which was why
I found it so surprising and argued so much against it.

Where we differ is that you consider FO and SVG to be on the
presentational side; I consider FO to be but not SVG.

--
Chris


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



Current Thread
Keywords