bug 6068, 6933. nsTableRowGroupFrame::CalculateRowHeights - changed row spans to consider
top and bottom margins during height calculations. Calculations using percentages ensure that the sum of
rows sum exactly to excess.
bug 6404 BasicTableLayoutStrategy::BalanceColumnsConstrained cols in span other than 1st col was
not getting additional allocations from cell. ::DistributeRemainSpace uses max width of col
instead of max effective width. Also added checks for negative value during percentage calculations.
git-svn-id: svn://10.0.0.236/trunk@32755 18797224-902f-48f8-a5cc-f745e15eee43
this is so these getters can be bound to an XPCOM interface, nsITableCellLayout
git-svn-id: svn://10.0.0.236/trunk@20326 18797224-902f-48f8-a5cc-f745e15eee43
default cellspacing and cellpadding now comes from the table frame itself
other frames on longer look at the "tableStyle" struct for these values
git-svn-id: svn://10.0.0.236/trunk@15824 18797224-902f-48f8-a5cc-f745e15eee43
types, and mColGroups. Besides being cleaner and easier to maintain, this should speed some things up slightly
because I don't have to check display types every time I iterate through colgroup frames. I *know*
mColGroups contains only colgroups. I might do the same for rowgroups (that is, keep unknown frame types
in their own list as well.) But that's optional.
the inner table frame used to incorrectly create actual content objects for anonymous colgroups and cols. Now,
it just creates frames as appropriate, not content. To support this, I added some pseudo style contexts and
related atoms.
git-svn-id: svn://10.0.0.236/trunk@15704 18797224-902f-48f8-a5cc-f745e15eee43
1. width=0 is treated as width=auto, not width=min
2. empty cells <td></td> are assigned a width of (2*borderWidth + 2*cellspacing + 3) pixels
The "3" is a fudge factor added by Nav and IE.
git-svn-id: svn://10.0.0.236/trunk@15309 18797224-902f-48f8-a5cc-f745e15eee43
the problem was the way table layout apportioned height from a rowspanning cell.
Now, we do 2 things correctly:
1) we handle rows with rowspanning cells and no other cells.
2) we divide the height of a rowspanning cell proportionately to the rows spanned, where the proportion is defined by
the max height of a cell in that row that has no effective rowspan.
the partial fix for bug 1431 has to do with dividing width between percent-width and fixed-width columns in the same
table. You won't see any better layout for this page (ww.boston.com) as a result of the code I added. The rest of this
fix is a bit risky, so I'm waiting until after stability push.
git-svn-id: svn://10.0.0.236/trunk@15257 18797224-902f-48f8-a5cc-f745e15eee43
and/or to the width attribute on the table itself), the rule is to try to give the column the largest value
assigned to it by any cell intersecting that column.
Separate storage is maintained for a column's natural desired width (width from any source other than a cell
with a colspan) and the maximum contribution to the column's width from any cell with a colspan.
git-svn-id: svn://10.0.0.236/trunk@14732 18797224-902f-48f8-a5cc-f745e15eee43
not like specified width (which you might logically expect since all column widths are specified, but sadly that's
not the way Nav or IE interprets this case. )
nsTableFrame's use of IsPseudoFrame has been removed.
git-svn-id: svn://10.0.0.236/trunk@14095 18797224-902f-48f8-a5cc-f745e15eee43
ables were not correctly applying the min width of the content of cells
that had col spans in some cases. In this case, the nested table was specified
as being too narrow for the content. There were 4 columns each with width=25%
in the first row, and in the next row a single cell with colspan=4 and whose
content min size was wider than the specified table width.
git-svn-id: svn://10.0.0.236/trunk@13394 18797224-902f-48f8-a5cc-f745e15eee43
now autowidth columns as assigned a width starting from their minimum. The remaining
space is proportionately divided among them, never allowing a column to go over its max (for
autowidth tables only.)
git-svn-id: svn://10.0.0.236/trunk@11671 18797224-902f-48f8-a5cc-f745e15eee43
the layout strategy can now query the outer frame for the caption min width,
and use it to expand the table if necessary
did some related cleanup while I was in there.
git-svn-id: svn://10.0.0.236/trunk@11473 18797224-902f-48f8-a5cc-f745e15eee43
moved *IsSpannedInto and *HasSpanningCells into cellmap, giving us the oppurtunity
to easily cache results if we want. These methods are still accessed through nsTableFrame.
changed nsTableFrame::GetCellAt to nsTableFrame::GetCellFrameAt to make it more clear what
the method returns: a frame, not content.
git-svn-id: svn://10.0.0.236/trunk@10440 18797224-902f-48f8-a5cc-f745e15eee43
support for the case where a nested table is in a cell that has colspan>1
git-svn-id: svn://10.0.0.236/trunk@10105 18797224-902f-48f8-a5cc-f745e15eee43
these fixes are for nested tables with percent widths, for tables including both rowspan and colspan,
and for tables with only a single column.
some rounding errors were eliminated.
more debugging output, and some new assertions.
git-svn-id: svn://10.0.0.236/trunk@9655 18797224-902f-48f8-a5cc-f745e15eee43
1) sometimes we were adding 1 too many pixels in constrained tables
2) sometimes we were using the wrong value for the max width as an input to constrained tables
git-svn-id: svn://10.0.0.236/trunk@9512 18797224-902f-48f8-a5cc-f745e15eee43
the cellmap is now built incrementally, driven by nsTableRowFrame::InitialReflow
git-svn-id: svn://10.0.0.236/trunk@8888 18797224-902f-48f8-a5cc-f745e15eee43
could select the wrong starting width for the column, causing it to have the
wrong ending width.
git-svn-id: svn://10.0.0.236/trunk@8197 18797224-902f-48f8-a5cc-f745e15eee43
cells with colspans and specified widths divide their width provisionally between the columns they span. This provisional division is ammended by any cell in any of the effected columns that:
1) has a colspan=1, and
2) has a width specified
the widths of all other columns must be adjusted for cells like these. Further complicating matters is that it seems <faith> that if multiple colspanning cells intersect a column and each has a width
specified such that the column would have a different width depending on which is used, only the first such cell is used </faith>. I can neither confirm nor deny this reading the mozilla code.
I also taught the cell map how to deal with this situation:
colspan=1 | colspan=2 | colspan=1
colspan=1 | colspan=2 | colspan=1
This table "really" has 4 columns, but the middle cells are treated as if they have no colspan.
Trust me, it matters. The original colspan attributes can't simply be thrown away because Mr. DOM
could come along at any time and add/remove a cell that would make them important.
git-svn-id: svn://10.0.0.236/trunk@8185 18797224-902f-48f8-a5cc-f745e15eee43
* fixes sample6, yahoo resizing
* added BasicTableLayoutStrategy::ColIsSpecifiedAsMinimumWidth helper function,
which tells us if the given column has a width attribute that means "make me as small as possible"
* nsTableFrame methods now no longer use mCellMap directly, they ask for it from
GetCellMap which gets the cell map from the first-in-flow. Only the first-in-flow has a
cell map because the cellmap refers to the table as a single object, not to each table frame.
* Likewise, continuing table frames do not call BalanceColumnWidths or SetTableWidth
which are "global" operations. Responsibility for these lies with the first-in-flow.
git-svn-id: svn://10.0.0.236/trunk@8020 18797224-902f-48f8-a5cc-f745e15eee43
