125048 - composer assigns properties to cells <td> rather than rows/col/table

Status: NEW

(SeaMonkey :: Composer, defect)

Description

[Not interested in Mozilla any more]

Table properties are allways assigned to <td> tags rather than <tr>, even when
'row' is selected in the cell tab of the table properties page. Steps to reproduce:

1) Start a new composer window.
2) Insert a new table (accepting the standard settings provided, 2x2 etc)
3) Click in the table and select table properties from the table menu.
4) Click on the Cell tab
5) Select 'Row' from the 'selection' drop down list.
6) Set, for example, the background colour for the cells.
7) Click the OK button.
8) Click on the source tab in the main composer window.

You will now see that the bgcolor attribute has been applied to the two <td>
tags rather than the single <tr> tag. This creates large code size and will
hamper the download times. This issue is not restricted to the bgcolor attribute
but to all settings applied via the table properties dialog. Surly if 'Row' is
selected from the 'selection' dropdown then the attributes should be applied,
where possible, to the <tr> tag.

I've seen this problem with all versions of Mozilla upto and including 0.9.8+
(2002021108) the latest build. It's definately pressent on MacOS 9.x and MacOS X
. It's presumably pressent on other platforms.

Comment 1

[Kathleen :Brade]

-->cmanske
Charley--I understood that this was how it was designed (we assign to rows or
columns or entire table if those are assigned).  Did I misunderstand or is this
a regression?

Comment 2

[Charles Manske]

Yes, this was done by design. If you don't you run into a very difficult problem
when copying and pasting (or drag n drop) of cells. What attributes of the TD
parents should be caried with the copied cell? Putting all attributes on the cell
solves that problem. Hopefully, in the future, we can do the optimization that 
puts attributes on the TR, but pays attention to them when moving cells.

Comment 3

[Not interested in Mozilla any more]

I would have thought that the editor should conform to the way the code is
written  ie:

If one or more cells are copied only the <TD>xxx</TD> code should be copied.
If one or more rows are copied the <TR><TD>..etc..</TD></TR> should be copied.

This is, after all, a HTML editor not a word processor. If users don't understand
the role of <TR> and <TD> tags the chances are that all their formatting will be
in the <TD> tags anyway. If so they won't see any odd behaviour when copying and
pasting cells.

I personally would not consider using an editor that attempted to merge the
formatting from the <TR> and <TD> tags when copying so that it could have a
WYSIWYG paste function. It denies the basic structure of HTML.

Comment 4

[Frankie]

same behavior in Windows.

Comment 5

[Mark Lassau]

I have noticed that Mozilla 1.6b always adds a <tbody> tag to any tables.
Is there any point in having this tag if properties are always assigned to <td> ?

Comment 6

[Gerke Kok]

This same thing goes for columns. There are now <col> tags possible and it would
be nice if they were used in the Editor. Any chance this will be done? I did get
the impression that not all is possible or implemented with Mozilla and the
<col> tags.

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

[Not interested in Mozilla any more]

I've moved on from Seamonkey to Firefox so someone else will have to take over this bug.

Comment 9

[Phoenix]

Issue still here
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120225 Firefox/13.0a1 SeaMonkey/2.10a1