Subject: Re: Topic: Tables and 1.0
From: Pierre Abbat (phma@oltronics.net)
Date: Fri May 04 2001 - 08:57:29 CDT
On Fri, 04 May 2001, Leonard Rosenthol wrote:
> Actually, in many ways the layout issues are easier than others -
>DEPENDING on your goals and/or implementation for tables. A larger issue
>that you need to decide BEFORE anything else is how much (if any) support
>you are going to provide for cross cell and/or cross table selection (ie.
>can the user select part of one cell and part of another, or select some
>text outside a table and some inside). If the answer is that every cell is
>self-contained - then tables aren't very difficult as you can treat them as
>separate containers (as you suggest). HOWEVER, if you plan to allow
>cross-cell selection, then the problem is VERY difficult to solve
>(well). I explained this to Dom over beer one night..
To me the correct way to handle table selection is:
If the selected text is part of a cell, it is just that text.
If you select a whole cell, the selection is either the text in that cell, or
the cell with the text in it. We need some way to distinguish these.
If you select more than one cell, the selection is a rectangle consisting of
complete cells. If the boundary of the selection would go through a colspanned
or rowspanned cell, it is forced to go past that cell.
If you attempt to select text outside a table and part of the table, you get
either the whole table or none of it.
If you put the cursor between horizontally adjacent table cells and paste a
table, the part of the table beginning there, and extending down as many rows
as are in the selection, is moved right and the selection is inserted. If this
would break a rowspanned cell, the paste is disallowed and the program beeps.
If the cursor is between vertically adjacent cells, part of the table moves
downward in a dual manner.
If the cursor is inside a table cell and you paste a table, it becomes a
subtable.
phma
This archive was generated by hypermail 2b25 : Sat May 26 2001 - 03:51:02 CDT