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

Re: HTML is a formatting/UI language was: RE: Formatting Objects considered harmful


Subject: Re: HTML is a formatting/UI language was: RE: Formatting Objects considered harmful
From: "Oren Ben-Kiki" <oren@xxxxxxxxxxxxx>
Date: Sun, 25 Apr 1999 15:44:02 +0200

Paul Prescod <paul@xxxxxxxxxxx> wrote:
>Transmitting XHTML probably does not make sense when we could instead get
>the client to do the transformation. I think we can all agree on that.


Right.

>Transforming to XHTML+STYLE-based CSS on the client side probably also
>does not make sense because the STYLE attribute is too granular to be
>generated by XSL. Do we agree?

No. It is trivial to generate a complex STYLE sttribute in XSL. It is being
able to _match_ on a STYLE attribute which is hard, and this isn't necessary
in this scenario.

>Client-side transformations to XHTML+CLASS-based CSS makes a little more
>sense but introduces an "extra" step that end users will (should!) reject
>as useless in many circumstances. Why have two transformations when one
>will do? Agree?

Not quite; one can view the 'CLASS' attribute as the last vestige of
"semantics" in the document. Converting to CLASS annotated elements, using
"well known" classes, is almost equivalent to using a "well known" XML
language - with the benefit that the document is viewable "as is".

>Formatting objects (as currently defined) have the concrete limitation
>that they are probably not compatible with non-GUI rendering environments.
>(I'm no Braille expert -- is this right or not?)

Definitely right. The point to keep in mind when considering non-visual
renderings is that such renderings are inherently one dimentional, while
visual renderings are inherently two-dimentional. The mapping from 1D to 2D
is easier (that's what we do when we parse an XML/HTML/whatever file, after
all). The problem is that the "1D" file may not be arranged in the proper
order for non-visual rendering - for example, using absolute coordinates
elements may appear at any order.

>I conclude that we need a language (FOs+semantics or HTML+style) that
>supports non-graphical renditions of common information types.


This sounds suspiciously like what HTML started out with. "H1", "P", "CODE",
... all tags with semantics + style.

How about adopting the convention that the XML/HTML/whatever tree structure
does reflect the logical hierarchy _of the presentation_ and that the order
of elements is logical _for the presentation_; authors using absolute
coordinates elements should restrict themselves to this, even if it means
adding "useless" intermediate elements. This would prevent the drift back to
the bad old days of "screen readers". It is probable that most HTML
documents obey this to a reasonable degree already.

As to how to render the elements aurally, there are really only three
choices. Either the author has given specific instructions as to how to do
so, in which case it doesn't matter what the elements are; or the elements
are from a "well known" semantic vocabulary (and HTML is the only one we
have at the moment), so the user can apply his own aural style sheet to it;
or the user is forced to apply a generic "fit all" stylesheet using the raw
tree structure of the document as a guide (think of using the depth of the
element as a cue to how important it is, and tricks of this sort).

Neither of the competing technologies - XSL, CSS, DSSL, whatever - can
change these tree options. HTML is currently "the" well known (loosely)
"semantic" element set. If another comes along, fine. FOs definitely aren't
"semantic" in this sense - they are strictly option one (explicit aural
rendering) or three (completely generic rendering).

Is this too simplistic?

    Oren Ben-Kiki


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



Current Thread
Keywords