Subject: Design for (interactively) customizable DSSSL stylesheets From: Norbert H. Mikula <nmikula@xxxxxxxxxxxxxxxxx> Date: Fri Mar 28 04:02:00 1997 EST |
We are already at the point where we are able to write easy to maintain and modular stylesheets. (Looks like, after all, what we have learned from software engineering has made its way into DSSSL practice. Yet another item where it shows how good it is that DSSSL is *very* close to a programming language). One of the problems that I am struggeling with right now, is that I want to design user agents via which you can customize your stylesheet interactively (I am having in mind for instance a (my) XML/DSSSL based WWW browser). How can I tell the user agent what things are customizable. I can take the whole stylesheet and make it editable for the user, but that would scare off most of them. If we look at a (well-done) stylespec there are only a few variables on which all others depend on. Examples for such variables could be document-font-size, para-space-before(after) ... The others are very often derived from these and/or inherited. FYI: I think good examples for such styles are the DOCBOOK style, the TEI style and of course Jon's HTML style. So my idea would be to take these variables and make them editable by the user. But..., how do I know which ones are these variables and which are really relevant for the user. The stylesheet designer knows it. Why don't we create a seperate style module where we put all these variables in. (We don't need to extend DSSSL for that. We can use what is already there). The problem, I guess, wouldn't be solved completely, however. The user agent would look at lot better if we could ad some textual information to the variable. What I have in mind looks like : (define-extended "Basic font-size for the document " doc-general-fn-size 12pt) This would define the variable to the DSSSL engine and keep the information that would be given the user agent. Or, what just came into my mind. We have one module where we have the "classical defines" and another module where we do the extedend define : Module A : (define fn-size 12pt) Module B : (define-extented "Basic font-size for the document " fn-size) That way we wouldn't have conflicts for tools that don't want to deal with this extended definitions. Please let me know what you think about it ! - -- Best regards, Norbert H. Mikula ===================================================== = SGML, DSSSL, Intra- & Internet, AI, Java ===================================================== = mailto:nmikula@xxxxxxxxxxxxxxxxx = http://www.edu.uni-klu.ac.at/~nmikula =====================================================
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Semantics of multi-mode fo, James Clark | Thread | Design for (interactively) customiz, David Megginson |
Semantics of multi-mode fo, Norbert H . Mikula | Date | Design for (interactively) customiz, David Megginson |
Month |