selections and tables (was Re: Topic: Tables and 1.0)

Subject: selections and tables (was Re: Topic: Tables and 1.0)
From: Paul Rohr (
Date: Fri May 04 2001 - 10:58:24 CDT


Thanks for the drill-down on the desired UI here. I knew that the answer to
Leonard's question was:

  "Of course, we want cross-cell selection"

... but I haven't spent the time to actually try to spec what those
behaviors were. All I knew was that they're complicated, and that someone
would need to do a careful enumeration of all the cases so they could be
taken into account at design time. You're way ahead of me on this one. :-)

At implementation time, I'm sure we'll be sending people back to this thread
(among others) to make sure that "basic" stuff like this all Just Works.

While we're on the subject, I should also point out that keybindings also
tend to mutate once you're inside table cells. Not only are there a host of
new complexities related to selection and navigation -- where do Right,
Ctrl-Right, Shift-Right, and Ctrl-Shift-Right each go? -- but other bindings
such as Tab and various Enter chordings also mutate.

However, the keybindings are probably far less of an obstacle than making
the selections Just Work. Right, Leonard?


At 09:57 AM 5/4/01 -0400, Pierre Abbat wrote:
>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
>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
>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

This archive was generated by hypermail 2b25 : Sat May 26 2001 - 03:51:02 CDT