Dynamism in CSS and DSSSL
Chris Wilson (PSD) wrote:
> "Reflow" is not a dirty word to us at all. :^) In fact, one of the two
> problems I see with DSSSL is the difficulty of extending it to support
> dynamic alteration of content (e.g., what we mean when we use the term
> "Dynamic HTML"). Practically speaking, DSSSL was originally written for
> print, and was extended for static screen (and other media)
I think that it is clear throughout the DSSSL specification that it was
explicity intended for WYSIWYG display as much as for print. The set of
flow objects and units is not sufficient for web publishing, but that
does not mean that the language is not dynamic.
> It's not really designed with hooks for dynamics - the
> DSSSL transformations are one-way.
What transformation isn't? By definition a transformation is an line
with an arrow starting from one point and going to another. You go
backwards by applying the inverse transformation.
> There's not really any way to change
> a piece of the source content (e.g., add a <P> element) and cause the
> changes to happen in the flow object tree without rebuilding the ENTIRE
> flow object tree.
That isn't true at all. In fact DSSSL has had facilities for adding and
removing elements since before CSS did. It is called the transformation
language. I think that the idea of dynamically adding and removing
content from documents at runtime is rather suspect, myself, but DSSSL
can handle it. I feel that dynamically adding and removing content is
suspect because it makes validation impossible and meaningless,
complicates UI and requires behaviour in exactly the way that SGML is
supposed to avoid. It is, however, an excellent way of hardcoding
documents so that they depend on the browsers of today.
What you want, rather, is dynamic *display* of statically marked content
markup. Excellent examples of this I have seen include Microsoft's
Encarta and Cinemania products. I do not believe that those products are
internally shifting around the structure of the elements. Why would
they? It is totally unnecessary. You simply define flow objects that
have the level of dynamism you want, that "understand" the interesting
ways to display the data.
As an example consider a footnote. Presume that clicking on a footnote
expands it "inline". The wrong way to do that is to create a new <P> or
span at runtime. The problems with this are numerous.
First, it sucks for downlevel browsers: they will never see the
footnote because it doesn't exist in the original document.
Second, you must choose a language for doing the expansion: that means
that your document will never get shown properly on platforms that don't
support that language, which to me violates the whole point of
Third, your document may or may not be valid with the paragraph
inserted. How could you have checked before it existed? This is trivial
in the case of a paragraph, but what if you're removing elements and you
remove a structurally required one?
Fourth, how does a structural search engine tag a paragraph that is not
yet a paragraph? A title that becomes a title later on?
Ugh. The whole thing is just messy. A much simpler solution is to create
a display format (flow object) that allows an element to expand and
contract when it is clicked. Not surprisingly, DSSSL has such an
element, called the "multimode" element which was designed for online
use. I expect that this element will be refined for the web as part of
the XML project.
> The other problem, which has been discussed here for the last few days,
> is the syntax; as Alan Karben just said, "...CSS is great for
> non-programmers to author in Notepad...DSSSL is built cleanly from the
> ground up..., but needs GUI tools before it is fit for widespread
> acceptance." _I_ can write DSSSL, and I don't even think it's
> unnecessarily obtuse... but it's nowhere near as simple for
> non-programmers to author stylesheets in DSSSL as in CSS.
Could you please give an example? My experience is that DSSSL becomes
complex at the point where the built in flow objects do not do what you
need: at precisely the point where CSS gives up. Let me say that again:
DSSSL does not become complex until it has *already* surpassed CSS'