Closed Bug 248977 Opened 20 years ago Closed 20 years ago

Changing a table's column count is not permanent.

Categories

(SeaMonkey :: Composer, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 256846

People

(Reporter: kiminicooper1, Unassigned)

References

()

Details

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322)
Build Identifier: 1.7

Changing the number of columns in a table from "2" to "1" will change the 
table to one column, but the fix is not permanent.  Reopening the same file 
and table with Mozilla after the change will show it is still two columns.  
However, IE 6.0 correctly displays one column.

Reproducible: Always
Steps to Reproduce:
1. Create a two-column table, filling the cells with anything, and save it.
2. Select the table and using Table Properties, change the column count to "1."
3. The table will resize correctly.
4. Save the file.
5. Again select the table and open Table Properties.  Note the column count 
again shows "2."
6. Also, saving, exiting Composer, and opening said table in Mozilla shows the 
table with, you guessed it, two columns.  Going back into Composer also shows 
the table with two columns.
7. The table can be viewed at the link above and works with IE 6.0 but not 
Mozilla.
This is a chunk of the code at the provided URL:
<table border="1" cellpadding="4" cellspacing="3" width="592">
  <col width="174"> <col width="391"> <tbody>
    <tr valign="top">
      <td width="174">
      <p align="left"><a href="Design/index.html"><font face="Arial"><font
 color="#00ffff">Design</font></font></a></p>
      </td>
      <td width="391">
(...)

First off, the width calculations don't add up: so you have an over-constrained
table. If you have a td with 174 and padding and cellspacing, then for sure, the
col element can not be equal to 174, has to be greater than 174, furthermore in
the border-collapse: separate model.

"If column widths prove to be too narrow for the contents of a particular table
cell, user agents may choose to reflow the table."
http://www.w3.org/TR/html401/struct/tables.html#h-11.2.4.4 

"If a table or given column has a fixed width, cellspacing and cellpadding may
demand more space than assigned. User agents may give these attributes
precedence over the width attribute when a conflict occurs, but are not required
to."
http://www.w3.org/TR/html401/struct/tables.html#h-11.3.3

Most importantly, when you try to remove a single column, Composer will warn you
that you are deleting several cells and ask you to confirm. Now, how is Composer
or an human going to maintain and honor the width value requested of a table
width of 592 when you're also requesting that the remaining single column left
must be either 174 or 391 pixel width? You're asking a mathematically impossible
task. 
If you reduce the number of column, then which one in your code should Composer
choose to keep?

In normal editing mode and in HTML Tags editing mode, we can clearly see (thanks
to the table graphical handles) that there is a fantom column "holding", trying
to honor the 592 pixel width table.

If you want to merge (join) both columns (or adjacent cells) into a single one,
then that would be different and the Help/Help Contents/Contents tab/Creating
Web Pages/Adding Tables to your Web Page/Adding and Deleting Rows, Columns, and
Cells/ provides info on how to do this.

You can not manipulate (format, add, delete) <col> elements graphically
(WYSIWYG) in Composer. You can only manipulate <col> elements via the HTML
source editing mode. And <col> are only graphical representations of what the
table structure is. You may have here a "valid" bug, enhancement request after
all... I am not sure yet.

You first need to construct a reduced testcase, with entirely valid code and
sound width values before someone can confirm this bug.

One last thing: I don't understand what you meant in your "step" 7. Mozilla can
render the table.
I have filed bug 256846 about the aspects of this bug which were good and valid.
This bug here has good points and you deserve credit for sure. 
What I don't like about reducing column number the way your steps proposed is
that the user never actually chooses which column(s) to remove. If column number
count was 10 and then, in table properties, window the user changes it to 5,
then what exactly should Composer do? I don't see an intuitive, clear, explicit
policy here. 
On the other hand, in Normal, HTML Tags, <HTML> Source editing modes, the user
can choose, control which column(s) to delete in an explicit, controlled manner.

resolving as DUPLICATE (even though this is not exactly the case) because bug
256846 has more chances of being assigned and tackled by a developer

*** This bug has been marked as a duplicate of 256846 ***
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.