- From: Bert Bos <bert@w3.org>
- Date: Wed, 27 Nov 1996 19:37:25 +0100
- To: www-style@w3.org
- Message-ID: <329C8A65.BCD@w3.org>
Stefan Olson wrote:
>
> >>I think that it is CSS1 that has caused the TAB tag to be removed when
> HTML 3.0 became 3.2. The only thing I see missing is:
>
> This is left this is right.
>
> But, can be done with tables, as all other cases of tab can.<<
Not all cases can be done with tables.
Although it is true that tabs (when used correctly) serve the same
function as tables, their visual appearance is different. Ideally, you
should be able to choose a tabular or a tabbed display from the style
sheet, no matter what your original mark-up was.
Some examples (< and > indicate the tab's anchor position):
1. when the element should start at a position that is already occupied,
it moves to the next line:
>short >second column
>longer than the first column
>second column
(didn't I see that one in a different discussion before...:-) )
2. columns can `overlap', when left/right tabs are alternated:
>left short a longer text aligned on the right<
>a longer text on the left a short text right<
3. tabs can include `leaders', which tables can't:
Chapter 1 . . . . . . . . 4
section 1.1 . . . . . . 4
section 1.2 . . . . . 45
Chapter 2 . . . . . . . 92
Chapter 3 . . . . . . . 138
4. since tabs are in-line, it is far easier to keep the correct line
spacing between successive lines. Inside tables, the `line-height'
property will give the correct result only in simple cases, if there are
no font changes or in-line images in any of the table cells.
Back in March there was some discussion of tabs and I wrote a text with
a proposal. I don't think I ever sent it to the list, because we thought
this could wait until after CSS1. I've included it below.
But before discussing the proposal, we should answer a few questions
about tabs:
A. Does the tab *character* (Unicode 9) have any meaning in HTML
(outside of preformatted text)?
- no, it is just white space
- yes, it is a SHORTREF for <SPAN STYLE="something">
B. Is it easier to set a position on an element (as I did in the
proposal below), or to set a couple of (numbered) positions on the
parent element, which are then inherited?
- the former needs less syntax in CSS
- the latter introduces an indirection, which may be easier to
maintain in the long run
- we could have both, but that might be too complicated
C. What is the better behaviour when a tab position is already
occupied?
- skip to the next line (as I did in the example above, and as
Scott Preece suggested)
- go backward and overwrite existing text (as TeX does it)
- both, subject to a CSS property
D. What kinds of tabs are there? left, right, center, decimal, any
others? Does `decimal' need an argument, or is the language's
default decimal character good enough?
E. What kinds of leaders are there? Is a small set good enough or do
we need arbitrary characters (or images?)? If a small set, what is
that set?
F. How does tabbed text wrap? Like this:
left >tabbed text that is
too long wraps but
stays behind the tab
Like this:
left >tabbed text that is
too long wraps without
considering that tab anymore
Or like this:
left >tabbed text never wraps at all, no matter how...
G. If a tab stop is outside the current margins, does it have any
effect?
H. What are the internationalization pitfalls? The proposal below has
at least one: it says that decimal tabs act as right tabs when
there is no decimal separator. It should probably say that it acts
as right or left, depending on the current writing direction.
Attachments
- text/html attachment: css-tabs.html
Received on Wednesday, 27 November 1996 13:37:29 UTC