193713 - Composer should insert table rows/columns with <TH> like adjacent rows/columns

Status: RESOLVED EXPIRED

(SeaMonkey :: Composer, enhancement)

Description

[Susie Wyshak]

See attached sample.

Add another column. It adds TDs, requiring manual editing to convert those into THs.

Comment 1

[Susie Wyshak]

Attachment: test case

Comment 2

[Susie Wyshak]

-->glazman

Comment 3

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Well, not sure this is a bug. And I see no difference between CSS and not CSS.
What exactly do you want ? Your bug report is unclear, Susie.
If I open the testcase in Composer, CSS mode or not, place the caret in the
first cell (a TH) and insert a column before or after, it insert a new column
made of one TD. That's normal.

Comment 4

[Susie Wyshak]

I had hoped it would make a TH so I wouldn't have to edit manually. However if
we say that Composer doesn't support CSS tables then I won't expect it.

Comment 5

[Jim Booth]

If *ALL* the columns (or maybe the 2 adjacent columns) in the table had TH in
the first row, then it would make sense to put a TH in the top row when
inserting a column.  

Likewise if the first column contains *ALL* THs (i.e. a row header) then a newly
inserted row should have a TH in the first cell.

Susie, In your example, it's not clear from the formatting whether you want
column headers, row headers, both, or neither, so I don't see how Composer
should make any assumption in this case.  

I agree with Daniel that CSS has nothing to do with it.

Changing severity to enhancement.  

Comment 6

[Bruce Davidson]

*** Bug 239882 has been marked as a duplicate of this bug. ***

Comment 7

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 8

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420