> ... The combination of an easy to use but powerful tag
> set (the next major revision of HTML?) and a flexible and powerful
> style sheet mechanism (DSSSL Light?) should give the user and
> reader the means to manage some "preference information" through
> tagging (as they do now with HTML, but they'll get better results).
> Some things they won't be able to do easily, and yet others they
> won't be able to do without being devious or employing another DTD.
>
If we can maintain a philosophy (religion?) of HTML tagging being used
entirely to mark structure (including links), with the presentation
formatting left to the recipient (via style information+presentation
software) we may be able to prevent the case of layout and formatting
information being used *instead* of identifying structure. This exactly
what occurs in conventional DTP schemes, where a command to center a line
is applied to two structurally different elements - e.g., both title
and author. The result is the output conforms to the author's artistic
tastes, but lacks necessary information for later conversion to a
structurally tagged form -- making it virtually impossible to ever use
the information with tools that make use of structure tags -- e.g.,
sophisticated retrieval systems and SGML-based printing systems. I've
written a number of conversion routines over the years, and can always
automate an (SGML+style information) into virtually any DTP or output
format. The reverse is a (generally fruitless) study in artificial
intelligence.
OK, there are cases where the format conveys some or most of the information
content -- such as an advertisement layout. These are done by skilled
graphics artists who take great pains to select a particular font, color,
and layout to achieve a particular effect. Given a stucturally tagged
document, they can ADD this information in the form of a style sheet,
and maybe demand that it not be presented in any other form. Fine by me.
Bottom line is -- presentation information must be *in addition* to the
fundamental structural tagging, never in lieu of. Removing or ignoring
formatting 'hints' should not destroy the structure information.
[Anti-flame note: I confess that I've not looked at either the HTML
DTD nor proposed 'enhancements' in enough detail to determine if
serious damage has been done, but many of the themes posted here have
me worried -- it's clear some are willing to make this concession to
get a quick fix.]
> Thanks to Murray's rangering, the principle suggests itself that
> formatting information to be considered seriously for inclusion in
> HTML should be what's needed to get common desired formatting effects
> that can't be provided by DTD+style sheet. That's a step forward
> from thinking that all style info should go in the style sheet.
I guess I'd like to see an example of effects that cannot be provided by
a well designed DTD+style sheet combo -- my feeling is that most of this
push for embedded formatting stems from omissions in the current DTDs and
inadequate tools. Much of the history of SGML has been plagued by lack of
usable editing and presentation tools, and many people wrote SGML off as a
solution for that reason alone. I have yet to see a really good, DTD
independent editor with reasonable WYSIWYG presentation while editing.
If the specification of HTML can settle down (and not get butchered in the
process), the demand for such tools will make them inevitable.
> | There is just no way that HTML can ever be everything to everyone.
> | So why not think of it as a Volks-language? It's not what you
> | would drive under many circumstances, but its easy enough to use
> | and gets you where you are going.
>
> Good design goal. So the formatting information to be considered
> seriously for inclusion in HTML should be what's needed to get
> *common* desired formatting effects (those most desired by the folk).
> Can't do everything, want what can be done to be doable simply.
> No power steering or cruise control, but we can have a good sound
> system.
>
As the proud owner of an impeccably restored 1967 VW bug, I take mild
offence at 'Volks-language' dig, but I think the real point is not to keep
HTML stripped down so it is easy to use, but develop an easy to use
editor that produces HTML documents. RTF is a messy, complex format,
but million of documents are produced in it by millions of mere mortals
whose bodies would simply reject vi as an editor. (Justifiably).
> I have to agree with Murray. Procedure aside, Netscape tried to get some
> effects they desired and that appear to be desired by the folk. At
> least some of the folks. At least at this stage of the discussion.
>
Netscape did just as you said -- made some people happy -- namely those
who were frustrated with the current status of HTML and particularly the
lack of style-sheet control over output formatting. I have tried to get
several groups here interested in using HTML and related browsers for
online document distribution. All were excited by the online and hyper-
link possibilities, and all rejected the notion when I couldn't give them
adequate control over the presentation formats -- especially hardcopy
output. My proposals were totally rejected when the various authors and
tech writers saw the sorry present collection of HTML editors. At the
risk of going into broken record mode, the problem is the lack of tools,
not lack of embedded formatting capabilities.
As a wise old Greek once said - "Give me a tool, and I'll move the Earth"!
-- Jack C. Armstrong __________ ___ ___ ___ DHL Systems Inc. ___________\ ___/ ___/ ___/ Infrastructure Research & Planning ___ ___/ _________/ ___/ 700 Airport Blvd. #300 ___/ ___/ _________/ ___/ Burlingame, CA 94010 ___ _________/ ___/ ___/ ___/___ ____ (415) 375-5317, 375-5018 fax ___ _________/ ___/ ___/ _____/ ____ Jack.Armstrong@Systems.DHL.COM Worldwide Express