Re: <PRE tab-width=4>

Dave Raggett (dsr@hplb.hpl.hp.com)
Fri, 27 Jan 95 05:01:27 EST

> You might consider a TABSTOPS attribute too:

> <!attlist pre
> -- ... other attributes --
> tabwidth NUMBER #IMPLIED
> tabstops NUMBERS #IMPLIED
>

Do we really want to encourage people to use tab chars in PRE text?
After all, you normally will need to filter the text prior to pasting
it into the PRE element to map &, < and > to their entity names.
Mapping tabs to spaces at this point makes a lot of sense, especially
as this is when you know what tab stops are appropriate.

> This would also be useful. (And, I hope, might
> replace the bletcherous <TAB> element in the current
> HTML 3 draft.)

Sorry Joe, I can't let you get away with this! The <tab> element is aimed
at normal not pre text, where you run into problems in defining tab stops
reliably, given that you don't know what fonts or margins the client is
using. For instance, if you use "em" units which roughly scale with the
font, the variability between different font metrics, and the fact you
may be mixing different fonts on the same line along with inlined images
makes this of limited use.

LaTeX circumvents these problems by allowing you to place a marker in
the text flow that indicates you want to define a tab stop at this
position, wherever it turns out to be, when finally printed. The next
issue is the scope of the tab stop definitions. In transferring this
approach to SGML, it seemed reasonable to duck the scoping problem
by using ID/IDREF associations. By using a unique name for each tab
stop which is then used when you want to tab to this position, you
avoid all the scoping issues in one fell blow.

-- Dave Raggett <dsr@w3.org> tel: +44 117 922 8046 fax: +44 117 922 8924
Hewlett Packard Laboratories, Filton Road, Bristol BS12 6QZ, United Kingdom