Re: HTML 3.0 Process
Dave Raggett <dsr@hplb.hpl.hp.com>
Date: Mon, 12 Sep 94 13:38:42 EDT
Message-id: <9409121257.AA14263@dragget.hpl.hp.com>
Reply-To: dsr@hplb.hpl.hp.com
Originator: html-wg@oclc.org
Sender: html-wg@oclc.org
Precedence: bulk
From: Dave Raggett <dsr@hplb.hpl.hp.com>
To: Multiple recipients of list <html-wg@oclc.org>
Subject: Re: HTML 3.0 Process
X-Listprocessor-Version: 6.0c -- ListProcessor by Anastasios Kotsikonas
X-Comment: HTML Working Group (Private)
Murray,
> First, I think that it would be a mistake NOT to include the
> elements of inline mathematical formatting into the general
> %text definition. That is, I must be able to use <SUP> and
> <SUB> and some of the other elements within a paragraph, list
> or heading.
The HTML+ DTD *allows* <math> elements within %text, but allows
you to use SUB and SUP (not ROOT) in ordinary text with out the
need for an enclosing math element. I was assuming the same
would be useful for HTML 3.0.
> If you want to use TeX, then why not provide support for TeX
> within the browser and provide portable code to the rest of
> the community to support it too?
TeX is too large to be required as a standard part of every browser.
The HTML-math proposal aims to provide math support at *MODEST* cost to
browsers, and when combined with tables, avoids the need for generating
these as inlined images when converting from Word or Framemaker etc.
The BOX element loosely corresponds to TeX's use of curly braces {}.
LEFT and TOP correspond to \left ... \right and are needed when you
want to ensure that delimiters or integral signs etc. scale to match
the size of the enclosed expression. I originally used attributes for
the left and right delimiters, but this doesn't work well when you have
tripple integral with limits on each. The content declaration is then
dictated by the need to avoid ambiguous content models.
Although ABOVE and BELOW can be mapped into BOX, it was felt that having
these as explicit elements would help authors, and reflects the underbrace
and overbrace commands in TeX (also the underline and overline). In fact,
we may want to introduce additional elements for \vec{a}, \ddot{a} etc.
> In the definition of <BOX> attributes above, I have used a NUMBER
> for the SIZE attribute so that relative size could be indicated.
I chose an enumerated set here because typographical concerns dictate
a small set of sizes rather than arbitrarily variable ones. Basically,
it looks poor when the bracket sizes vary arbitrarily.
> <MATH> is defined to include <LABEL> at the end of its content.
> Why not have <LABEL> at the beginning and then place it at the
> end if that is how you decide to format it?
I did it this way to reflect common practice in labelling equations.
As you say, it doesn't really matter though.
> I see that <B> is redefined to contain %formulae;, but I note
> that <I> is not similarly redefined. Why not?
Within the MATH element the parsing/rendering works very differently
from normal text. It is sometimes the case, that authors want to
embolden certain terms in expressions. By default terms are rendered
in italic, except for function names such as sin, log, etc. which
are written as entity names. As a result it seemed pointless supporting
the I element as well.
The HTML-math proposal is the result of long study of the LaTeX and TeX
manuals and repeated discussions with Phil Hallam-Baker.
--
Best wishes,
Dave Raggett
-----------------------------------------------------------------------------
Hewlett Packard Laboratories email: dsr@hplb.hpl.hp.com
Filton Road tel: +44 272 228046
Stoke Gifford fax: +44 272 228003
Bristol BS12 6QZ
United Kingdom