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 |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Root Node does not contain prol, James Clark | Thread | Whither linking, Paul Prescod |
Re: Formatting Objects considered h, Håkon Wium Lie | Date | Re: About XSLT, Sharon Adler |
Month |