As a preamble, I don't quite know what XTF frame construction is aiming to achieve. So I'm not sure how many of the following issues are by-design.... We probably want to file bugs for the ones that are actually bugs and track them here. In what follows, I'm assuming that given that nsXTFXMLBlockDisplayFrame is an nsBlockFrame and that nsXTFXMLInlineDisplayFrame is an nsInlineFrame one would expect them to behave as blocks or inlines. So the issues I see in ConstructXTFFrame are: 1) XTF frames with display values of table, table-row, table-cell, table-row-group, table-column-group, list-item, etc, etc are all being treated as inlines. 2) Columns are not supported on XTF block frames. 3) Overflow is not supported on XTF frames. 4) Positioned XTF frames do not become containing blocks for absolutely positioned descendants. 5) Block XTF frames do not become containing blocks for floated descendants. 6) Inline XTF frames do not handle block descendants (causing bug 266685, probably). 7) AppendFrames is used on the insertionFrame, which generates an extra reflow command... I suspect this could just use setInitialChildList, but I could be wrong. 8) Absolutely positioned XTF blocks don't become margin roots (see NS_NewAbsoluteItemWrapperFrame, eg). 9) Floated XTF blocks don't shrink-wrap (see NS_NewFloatingItemWrapperFrame). For a lot of these issues, the right fix is to simply use ConstructBlock/ConstructInline, which may need to be modified accordingly. With some factoring of code out of ConstructFrameByDisplayType(), this may fix issues 2, 3, 4, 5, 6, 8, 9. For the rest, I'm not sure what the best way to proceed is.

(In reply to comment #0) > As a preamble, I don't quite know what XTF frame construction is aiming to > achieve. So I'm not sure how many of the following issues are by-design.... You can assume that most stuff that doesn't look quite right is not by design, but a result of my general ignorance of frame construction issues. I've only really used XTF in a XUL & SVG setting. > 1) XTF frames with display values of table, table-row, table-cell, > table-row-group, table-column-group, list-item, etc, etc are all being > treated as inlines. I guess when demand for these display types arises we should rethink our layout-side xtf implementation strategy. Deriving new frame classes for all possible display types seems a bit excessive. We only subclass frame classes to add nsIAnonymousContentCreator and for 'DidLayout()' calls. If we add a flag to nsIFrame for marking frames as being 'xtf' frames, we could change the code in nsCSSFrameCTOR::CreateAnonymousFrames() to QI xtf content elements for nsIAnonymousContentCreator (rather then their frames). > 7) AppendFrames is used on the insertionFrame, which generates an extra reflow > command... I suspect this could just use setInitialChildList, but I could be > wrong. Hmm, wouldn't that mean that 'setInitialChildList' might get called twice on the insertionFrame?

> Hmm, wouldn't that mean that 'setInitialChildList' might get called twice on > the insertionFrame? Hmm... if the insertionFrame can have anonymous kids, then yes. So never mind that.

One other possible issue, or at least annoyance in what I'm working on now... is there a reason to code the xtfElem->GetElementType() == nsIXTFElement::ELEMENT_TYPE_GENERIC_ELEMENT check into frame construction instead of putting it in style resolution or something along those lines and just having it force display:none? At the moment this is at least making us resolve visibility structs for those elements unnecessarily, quite apart from complicating other code that has to work around the fact that these frames suddenly decide to not be there (see XXX comments I'll add in bug 269566).

XTF visuals have been removed (Bug 355100), so this is WFM.