Re: Concerns about HTML+ complexity
fox@pt0204.pto.ford.com (Ken Fox)
Errors-To: listmaster@www0.cern.ch
Date: Wed, 29 Jun 1994 22:20:47 +0200
Errors-To: listmaster@www0.cern.ch
Message-id: <9406291814.AA25777@pt0204.pto.ford.com>
Errors-To: listmaster@www0.cern.ch
Reply-To: fox@pt0204.pto.ford.com
Originator: www-talk@info.cern.ch
Sender: www-talk@www0.cern.ch
Precedence: bulk
From: fox@pt0204.pto.ford.com (Ken Fox)
To: Multiple recipients of list <www-talk@www0.cern.ch>
Subject: Re: Concerns about HTML+ complexity
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
Content-Type: text
Content-Type: text
X-Mailer: ELM [version 2.4 PL23]
X-Mailer: ELM [version 2.4 PL23]
Dave,
> > <h2>HTML+ is too large and complex</h2>
>
> > <p> One of the great things about HTML is its small size. This means that
> > browsers can be created easily (well, almost :-) and that new users have
> > virtually no trouble learning how to create documents.
>
> I agree with your design goals for a simple markup format, and the need
> to keep HTML simple. I don't agree that HTML+ is complicated - in fact I
> went to great pains to keep it simple. The DTD may be complicated, but
> that is largely due to the way I modularised it.
I think that there are at least three important issues when we talk about
complexity:
(1) Level of complexity for a person to write an HTML document by hand, that
is, without using an HTML editor or some conversion tool. Call this
"user complexity."
(2) Level of complexity for a person to write a tool that parses, formats,
interprets, etc. HTML. Call this "developer complexity."
(3) Level of complexity for a person to extend the capabilities or domain of
HTML. Call this "future complexity."
I think HTML+ succeeds very well in eliminating user complexity. This is
probably what you meant when you said:
> IMHO the HTML+ table format is one of the simplest around, and as evidence
> of that, it has been adopted by other SGML working groups such as TEI.
The table *is* simple to use.
HTML+ (with the exception of equations) also fairs well for developer
complexity. Simply by making sure that a correct DTD exists helps
tremendously (not all HTML hackers will believe this, but it's true.) Your
comment below encourages me that you are trying to reduce developer
complexity:
> The switch to <P> as a container is in line with other SGML formats and makes
> it practical to set paragraph alignment. It also simplifies implementations.
I think that some other things might be explored to further reduce developer
complexity. Things like making lists and tables with the same mechanism.
Viola already uses the same code for lists as tables --- I was surprised the
first time I saw a list with borders all around the items. It simplifies
the code (Viola needs to work on the presentation though. :-) In any case,
it's hard to tell the difference between a list and a table of one or two
columns!
The part of HTML+ that really breaks down in my mind is that it does nothing
to contain future complexity. This problem is already starting to show up
with the different levels of implementation and the issues surrounding
equations. I've heard things like "the equations won't satisfy the needs of
a chemist" with the implication that this must be "fixed" in HTML+. This is
a pretty scary direction. What about all of the different variations of
form INPUT that appear in HTML+? I sure don't want SCRIBBLE fields or HTML
editor fields wired into the browser I use! I just want to bind xpaint or
emacs or *something* to a MIME type and have the browser required to start
the application and associate it with the document. Fields can be tagged
with a MIME type and the whole thing fits together.
> People do want richer control of how their documents appear, but rather than
> complicate HTML, our plan is to introduce linked style sheets.
I agree with this. HTML should control document navigation and viewing
structure. To clarify, navigation structure controls how a person can read a
document and viewing structure controls how a browser can render a document.
In my opinion, the relative position of document components (i.e. figures,
tables, paragraphs, etc.) is an important part of navigation structure. I
don't like the fact that HTML+ seems to tie layout information to content
components. For example: I can have a boxed floating figure, but not a
boxed floating paragraph.
For a general solution to this problem, I just want some basic layout
capabilities added to HTML+. Things like:
BOX a region with generic layout policy
VBOX a region with enforced vertical tiling
HBOX a region with enforced horizontal tiling
P a region with paragraph layout policy
Each of these exist to control the layout of the objects they contain.
Other people might want more. The following structures are possible:
o An IMG in a P defines a floating picture without text wrapped
around it (what we have today in HTML)
o An IMG in a BOX in a P defines a floating picture with text
wrapped around it (same as a figure in HTML+)
o An IMG and a P in an HBOX defines a paragraph with a hanging
picture (same as a table with two cells, one containing an IMG and
the other text, in HTML+)
o An IMG and a P, each positioned at (0, 0) in the same BOX defines
a picture with a text overlay.
> HTML+ allows
> authors to include an SGML ID attribute with all elements. This is used by
> style sheets to name individual elements, so you can specify rendering
> behaviour by tag name e.g. all H1 headers, and over-ride this class behaviour
> for a specific header.
I think this is great. It could go further. Variables could be stored in
the "style sheet", aka database, and called out in the document. Imagine a
simple little tag like LOOKUP which just grabs a value out of a style sheet
and includes it into the document. The point being that the style sheet is
a really powerful tool that should be available for more than just font
selection. It's easy on authors, easy on implementors and makes
experimentation easier to achieve (reduces future complexity.)
> I fully agree with the goal of reducing the cost of entry for people who
> which to experiment with new browsers etc. To this end we want to make
> browsers into a set of cooperating applets, tied together by a messaging
> scheme. The OpenDoc architecture will probably have something to offer
> us here.
I think this is great too. Will the messaging scheme be part of HTML? or
will there be another standard that covers it? How will that messaging
scheme be influenced from an HTML document? MIME types? by entity? by ID?
Will browsers be required to implement it as part of HTML?
This thread is making me feel much more confident about the intent of HTML+
and current browser design, but not at all confident about where HTML+ is
going or how it will be affected by the commercial marketplace.
> Dave Raggett
Thanks for giving us an HTML+ proposal worthy of arguing over. :-)
- Ken
--
Ken Fox, fox@pt0204.pto.ford.com, (313)59-44794
-------------------------------------------------------------------------
Ford Motor Company, Powertrain | "Is this some sort of trick question
CAD/CAM/CAE Process Integration | or what?" -- Calvin
AP Environment Section |