Re: Tabs in CSS1

Bert Bos wrote:-----------
Not all cases can be done with tables.
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<
-------------------------

Either case should be doable with 'float: right' blocks of text (deja
vu?), #1 using an explicit width:
  .t1 { float: right;
        width: nn% }

  short <SPAN CLASS=t1>second column</SPAN>
  longer than the first column <SPAN CLASS=t1>second column</SPAN>

#2 with:
  .t2 { float: right;
        align: right }

  left short <SPAN CLASS=t2>a longer text aligned on the right</SPAN>
  a longer text on the left <SPAN CLASS=t2>a short text right</SPAN>

------------------------
...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">
-----------------------

Why should *any* entity names/numbers collapse? What then would be the
point of the SGML '&sp;' and '&tab;' entity names? The only reason for
collapsing white space is to allow readable markup. Collapsing entity
names simply imposes artificial constraints.

-----------------------
   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
-----------------------

I suspect most authors would prefer the simplicity and familiarity of
tab positions, as in:

  P { tab-default: .5in blank left fixed;
      tab-stops: 5em left 30em "_" right 32em left 52em "_" right}

  <P>&tab;Column1&tab;&tab;Column3&tab;

     Column1__________________  Column3_____________

Your proposal seems more consistent with existing HTML tag behavior,
but it requires a lot of markup. The markup for a TOC could be greater
than the content.

-----------------------
   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
-----------------------

CSS property: [ flow | fixed | column ]. Flow would be standard word
processor behavior (use the next tab stop -- to the next line if
necessary). Fixed would force overwrite. Column would move to the
correct position on the next line, with any leader being rendered
normally:

  First item   second item going too long
               ............third w/column property and leader

-----------------------
   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?
-----------------------

Best to be able to define the alignment character. But the effect of
using other characters would doable if two tab stops could occupy the
same position -- one with align right and the other with align left.
Such as:

  P { tab-stops: 40% right 40% left }

  <P>rendered as:&tab;2000;&tab;3000<BR>
  &tab;40;&tab;50

rendered as:       2000;3000
                     40;50

----------------------
   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?
----------------------

Arbitrary character. Repeating image doesn't sound useful enough to
warrant implementation and could be done with floats or tables with a
background url.

----------------------
   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...
----------------------

Could depend on the positioning behavior property. Wrap as the first
example if 'column', as the second if 'flow', as the third if 'fixed'.

----------------------
   G. If a tab stop is outside the current margins, does it have any
      effect?
----------------------

Not if using the tab stop model. With your proposal, tabs could be
defined as a special kind of float and as such be 'outside the normal
flow' and extend outside the parent element. But in that case it would
be difficult to explain how a wrap to the beginning of the next line
fits into the CSS formatting model.

----------------------
   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.
----------------------

No comment.

David Perrell

Received on Monday, 2 December 1996 15:21:31 UTC