Re: CSS and XSL

[Paul Prescod <paul@xxxxxxxxxxx>]

Chris Lilley wrote:
> 
> > 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.

I don't see this as your decision to make. Sometimes it fits my data to
have a single level of translation: then I want "FO:"s. Sometimes it is
better to have one complex layer and one simple layer: then I want
XSL-T+CSS. Sometimes I need six complex layers and no simple layer: then I
want six XSL-T stylesheets such that the last one produces "FO:"s.

I strongly agree that the XSL-T+CSS mechanism will sometimes be
appropriate. I disagree that it will always be.

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

I hope you aren't putting that "mere" in my mouth! :)

As far as graphics being entirely presentational or not. I would say that
by definition data which is completely graphical is also completely
presentational. I could imagine a DTD for, let's say, orgcharts that was
semantic, but calling it an "orgchart" DTD would actually be a shorthand
for the real name: "Organization description" DTD. Org "charts" would be a
single application of the DTD. One could also generate hyperlinked org
"lists", do queries based on org-relationships, build 3-D representations
("org mazes") and so forth.

I don't see SVG allowing me to do any of these things. The only semantic
in an SVG document is: "here are instructions on how to draw a picture."
That's not generic markup. That doesn't make it bad or wrong: just
different. It is the beginnines of a PDF/EPS for the XML world. We need
that.

I think it would be a fascinating exercise to figure out how to get from
my orgchart DTD to your PDF/EPS DTD via declarative transformations. I
agree with you that it probably can't be done which emphasizes my point
that SVG is very, very far to the screen side and very, very far from the
abstraction side. We probably need something like DrawML in the middle.

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

Path data is not style, but it is clearly presentation.

Now consider a picture of a butterfly. It is a monarch. My lines are black
and my fill color is orange. Are you going to tell me that someone can
switch the orange to blue and still be looking at the picture I intended
them to see? I don't think so. Not in the same sense that you can change a
document title from orange to blue.

Yes, there may be SVG pictures where line color is "just" style, but this
is another decision that I don't think that you at the W3C can make for
website designers. If you use my per-attribute convention then SVG
creators have two separate tools, one for "necessary" presentation and
another for "style" and they can decide which to use. Of course nobody can
or should stop the end-user from doing whatever the hell she wants but at
least the SVG creator's intent can be expressed clearly.

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

Well I posited the existence of both CSS-aware *and* CSS-unaware editors.
I intended to demonstrate that in either case my proposal is better than
the status quo.

BTW, I see nothing heretical in the idea that an editor might use special
knowledge of a namespace to make your editing experience more comfortable.

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

"WYSIWYG" editing. Further evidence that SVG is a presentational DTD.

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

That doesn't strike me as a "standard drawing method." Admittedly it is
common to define "object types" in drawing programs but that isn't the
same as separating presentation and style. An object type is a description
of an amalgam of presentation properties to be reused, not to be *applied*
to other objects. An object type is more like an extension of SVG's basic
types than like a CSS style.

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

I presumed that by default a per-element specification overrides an
instruction for all elements of a type. Perhaps you are speaking of the
importance feature.

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

No, that's not what I'm talking about. Namespaces are compatible with
*DTD* validation. You cannot take advantage of all features of the
namespaces mechanism if you use a DTD, but you can still use namespaces
and DTDs together. Consider:

<!DOCTYPE HTML:HTML[
<!ELEMENT HTML:HTML ((HTML:P|SVG:PIC)+)>
<!ELEMENT SVG:PIC (...)>

<!ATTLIST HTML:HTML xmlns CDATA "http://www.w3.org/TR/HTML"; #FIXED>
<!ATTLIST SVG:PIC xmlns CDATA "http://www.w3.org/TR/SVG"; #FIXED>
]
<HTML:HTML>
...<SVG:PIC>...</SVG:PIC>
</HTML:HTML>

Let me repeat:

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

Since the W3C uses namespaces in Voyager and Voyager does have a DTD it
has apparently been decided that it is acceptable to use the namespace
mechanism partially.

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

I see no good reason to do that. You do raise in my mind the point that
future schema languages should formalize inheritable attributes but for
now they must just be handled in an ad hoc way.

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

The CSS DOM would continue to provide this information. Ideally we would
eventually standardize a mechanism for overriding attributes externally in
a way that was not specific to CSS and then the "XML DOM" would provide
the same information without making a special case for CSS.

> > It doesn't work across namespaces. It works across the CSS: namespace.
> 
> Okay, that would work once a namespace-aware schema language exists.

No, it would work today.

> I can see how you draw that conclusion and it is certainly a defensible
> position but I disagree. I see structured graphics as content. 

Content yes. Bitmap graphics are also content. When we move out of the
realm of textual documents we can no longer presume to tell people what is
style and what is content. Arguably we could never have made that
presumption but before XML we had no real option.

> The only
> things that should be styles are things that it makes sense to restyle
> when reusing the graphic.

But you can't know that when you are desiging the SVG specification. Only
the graphic's author knows what it makes sense to override. Hell, in some
graphic it might make sense to override path data if it allowed you to
make the graphic look better on your computer screen!

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

The XSL argument was a special case of the "compatibility with XML
argument." Even if you are generating SVG through an XML DOM it is much
easier under my proposal.

You are probably right that generating SVG would be too hard because SVG
is so far towards the "screen." We need a middle ground like DrawML.

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

Yes, and it is appropriate for some applications and not for all. But
modularity for its own sake is not useful.

It is quite simply easier for me to express my transformations and my
formatting in the same place. You've demonstrated that sometimes this is a
suboptimal organization. But sometimes (I would say *usually*) it is not.
Languages like DSSSL and omnimark allow the separation you describe and
sometimes people use it (for good reason) and sometimes they do not (also
for good reasons). Consider Norm Walsh's popular stylesheets for DSSSL
what benefit would he gain from generating intermediate formatting
objects? It's just another set of junk to maintain and understand.

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

Do some mind experiments. Will it be possible to display FOs in lynx?
Probably to the same extent it is possible to display HTML. Will it be
possible to do structural searches on FOs? To about the same extent it is
possible to do them with HTML. Will it be possible to render them aurally
and into braille? About the same extent it is possible to do so with HTML.

If HTML were used by experts who paid careful attention to generic markup
and used "H1s" and "H6s" consistently across the Web then HTML might have
a semantic edge but in practice nobody has had much success extracting
semantic information from the structure of HTML documents beyond the
simple stuff I described above.

I still don't understand how your model is in line with that of the XSL
working group. Do you propose that FO documents should be able to have CSS
stylesheets applied to them?

-- 
 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself
 http://itrc.uwaterloo.ca/~papresco

"In general, as syntactic description becomes deeper, what appear to 
be semantic questions fall increasingly within its scope; and it is 
not entirely obvious whether or where one can draw a natural bound 
between grammar and 'logical grammar'."  - Noam Chomsky, 1963


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