CSSFrameConstructor
This is a page for documenting the nsCSSFrameConstructor with the goal of simplifying, stabilizing and bugfixing it.== Documentation projects ==A major piece of information that we need to document is the constraints that various frames have on what child and parent frames it must or must not have. We should also document which transformations we perform between the content tree and the frame tree to enforce those constraints. This is tracked on the pages:* CSSFrameConstructor/Constraints* CSSFrameConstructor/Transformations== Ideas for design changes ===== Containing Blocks ===We need a better way of keeping track of containing frames forout-of-flow frames. Currently this logic is duplicated in both framesand the frame ctor. Additionally, the frameCtor spends time on keepingtrack of the current containers even though most of the time we don'tuse them.One way to fix this is move the logic of what is what type of containerinto the frame. This way the frame ctor can ask each frame as itsprocessing the frame children if the frame is a container. We can theneasily figure out which frames are current containers in ContentInsertedby walking the parent chain.Another solution is to make frames that need the information manuallywalk the parent chain until the desired block is found. This informationcould possibly be cached in the frame ctor.=== XBL ===XBL is currently too entangled in the frame ctor. XBL needs two things:# munge notifications so that ContentAppended/Inserted/Removed is done on the right frame, and at the right child index in that frame# Ability to create child lists that contains the mixture of anonymous and explicit children.1 could be done by the binding manager by letting all notifications gothrough the binding manager. It already is an nsIDocumentObserver so itshould have all neccesary information. Better apis into the bindingmanager is another solution.2 has to be fixed by creating a better api that the frame ctor can useto access the flattened tree. One possible solution for accessing theflattened tree is to use a treewalker. However this might be anunneccesarily big change.The ultimate goal is to move as much of the xbl logic as possible out ofthe frame constructor.=== Hash for creator functions ===Rather then the current neverending list of if-statements to figure outwhich frame to create we should have a hash table that maps tag+ns tocreator function. The hash table can also contain information aboutwhich type of frame will be constructed so that we can create, forexample, wrapping table frames beforehand.In some cases the type of frame created varies (for example for images)so we might need to call a function to get the type.These constructor functions should be able to create a whole tree offrames if neccesary. For example for list boxes or form controls.We should have a similar (or even identical) hash keyed on display typefor when the first hash doesn't produce a frame. Eventually we mightwant to move all frame types into this hash, but we need at least thecontent css property implemented for that.Bug 323233 filed.=== State management ===Until we have better transformation code in place we will probably needbetter state management code for the frame ctor. Logic should be movedinto the frames so that we can rebuild the right state in a morereliable manner.=== Frame teardown ===Frame teardown should be a lot simpler, (Do)DeletingFrameSubtree shoulddie and frames should be able to just clean themselfs up.Bug 323105 filed. === Frametree buildup ===Currently we link together the frametree from bottom up. We recursivly walk into each element for which to create frames. First we create the frame for the element itself, and then we create a framelist for all its children. Not until the childlist is fully created we insert anything into the parent. Then as we unwrap the callstack we insert the finished childlists into each element.The reason for this is that inserting a new childframe into a parent is slow (due to having to walk the linked-list of children) and forces reflow events to be created.This seems unneccesarily complicated. A better approach would probably be to insert frames as we go and let the caller worry about posting reflow events. The downside is that we'd have to keep a pointer to the last frame in the child-frame-list.