sequence: MoveTo(), Reflow(), SetRect(). Now that we have the WillReflow()/
DidReflow() code sandwhiches we no longer need to do the MoveTo()
git-svn-id: svn://10.0.0.236/trunk@11891 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
table frames no longer assume they are n levels below the inner table frame
table frames no longer assume their child frames are always the expected type of
frame. Now they check the display type and use that as sufficient proof that the frame
is of the right type. This implies a heavy reliance on the frame construction code to do
the right thing and always stamp out the right kind of frame for a given display type.
git-svn-id: svn://10.0.0.236/trunk@10922 18797224-902f-48f8-a5cc-f745e15eee43
from their respective InitalReflow() methods.
table-layout=fixed now completely skips pass1 reflow and doesn't require maxElementSize
information, saving a tremendous amount of time during initial reflow.
git-svn-id: svn://10.0.0.236/trunk@10841 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
nsHTMLAtoms.cpp,h added some HTML 4 strings for tables
nsHTMLParts.h added constructors for new table content classes
nsGenericHTMLElement.cpp,h added table frame creation, common table attribute parsing
nsHTMLTable*Element.cpp these are the new table content classes
nsHTMLContentSink.cpp enabled the new content and removed the old
nsHTMLStyleSheet.cpp fixed the table style optimizations to work with new content
nsTable*Frame.cpp these work with the new content
git-svn-id: svn://10.0.0.236/trunk@10047 18797224-902f-48f8-a5cc-f745e15eee43
aFilter is useful for determining if a frame should output itself during
a List(). In any event, the children of the frame are always processed.
added nsIListFilter, an interface for any object that wants to act like a filter for frame dumps
added static NS_LAYOUT nsIListFilter * GetFilter(nsString *aFilterName);
currently, only TableListFilter implements nsIListFilter.
in response to List(...TableListFilter), the frame model is dumped in a way that is useful
for table layout regression testing. Currently this is controlled by command line switches on the viewer app.
git-svn-id: svn://10.0.0.236/trunk@9156 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
support work for style optimizations
fixed a bug in table columns -- the attribute repeat defaults to 1, not 0
git-svn-id: svn://10.0.0.236/trunk@8504 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
