[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: Paul Prescod <paul@xxxxxxxxxxx>
Date: Mon, 19 Apr 1999 14:28:17 -0500

Jonathan Borden wrote:
> HTML at its core basically *is* a formatting language (more properly a
> *user interface language*). If it were able to handle semantics in a robust
> fashion there wouldn't be such a profound need for XML. 

There is no boundary between formatting languages and semantic languages.
As Håkon points out there is only a spectrum. More abstract -> more
rendition-specific. Typically more abstraction is expensive and difficult
but provides more flexibility in the long run.

HTML is at about the right point in the abstraction->rendition spectrum to
allow braille, TTYs and other non-GUI interfaces to render information in
a manner compatible with GUI interfaces. We cannot make a global language
much more abstract HTML (though footnotes, headers, footers, etc. would be
nice). We cannot make a multiple-media language much less abstract than

Håkon's point is that formatting objects are less abstract than HTML and
are thus less portable.

> HTML is in essense a
> language to instruct a browser what to display in a window, how to build a
> GUI, but its hardly up to the task of developing complex semantic
> structures. The semantics I think you are talking about here are scratching
> just below the surface of the GUI.

Not a GUI. HTML can work perfectly well in non-GUI environments.

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.

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?

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?

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?)

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

 Paul Prescod  - ISOGEN Consulting Engineer speaking for only himself

"The Excursion [Sport Utility Vehicle] is so large that it will come
equipped with adjustable pedals to fit smaller drivers and sensor 
devices that warn the driver when he or she is about to back into a
Toyota or some other object." -- Dallas Morning News

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

Current Thread