- 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