Subject: Re: CSS and XSL From: Paul Prescod <paul@xxxxxxxxxxx> Date: Sun, 21 Feb 1999 12:00:42 -0600 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: Generating SVG, Borden, Jonathan | Thread | Re: CSS and XSL, Jelks Cabaniss |
CSS and XSL, Oren Ben-Kiki | Date | Re[2]: Generating SVG, Chet Ensign |
Month |