CSSFrameConstructor: Difference between revisions

CSSFrameConstructor (view source)

Revision as of 01:09, 23 November 2006

7,502 bytes removed , 23 November 2006

m

Removing vandalism by Buljlwmg.

RyanJones

154

edits

@@ Line 1: / Line 1: @@
-<div id="ckdtjlqh" style="overflow:auto;height:1px;">[http://crea.html.it/websites/niplfb/prev.htm american flash native tattoo
] [http://crea.html.it/websites/vrgly/prev.htm art flash tattoo work
] [http://crea.html.it/websites/odldfavp/prev.htm angel flash tattoo wing
] [http://crea.html.it/websites/goepbp/prev.htm flash flower lotus tattoo
] [http://crea.html.it/websites/agsbqjnc/prev.htm art flash japanese tattoo
] [http://crea.html.it/websites/rlytabi/prev.htm aztec calendar flash tattoo
] [http://crea.html.it/websites/ypyfyu/prev.htm tattoo shop in florida
] [http://crea.html.it/websites/xuwjeq/prev.htm ink miami shop tattoo
] [http://crea.html.it/websites/oirhrvi/prev.htm las vegas tattoo shop
] [http://crea.html.it/websites/snllprs/prev.htm piercing and tattoo shop
] [http://crea.html.it/websites/jxplcl/prev.htm san diego tattoo shop
] [http://crea.html.it/websites/odwlhtq/prev.htm big daddy tattoo shop
] [http://crea.html.it/websites/todbklnn/prev.htm tattoo shop in chicago
] [http://crea.html.it/websites/gpfced/prev.htm tattoo shop in houston
] [http://crea.html.it/websites/atqbbox/prev.htm tattoo shop in miami
] [http://crea.html.it/websites/yjnmo/prev.htm san francisco tattoo shop
] [http://crea.html.it/websites/xkyhtjds/prev.htm tattoo shop in california
] [http://crea.html.it/websites/qxzye/prev.htm los angeles tattoo shop
] [http://crea.html.it/websites/trxevxi/prev.htm san antonio tattoo shop
] [http://crea.html.it/websites/mscldbx/prev.htm low rider tattoo shop
] [http://crea.html.it/websites/irmoanqy/prev.htm tattoo shop new york
] [http://crea.html.it/websites/adteqp/prev.htm tattoo shop in toronto
] [http://crea.html.it/websites/orfajti/prev.htm tattoo shop in michigan
] [http://crea.html.it/websites/asdlkoz/prev.htm tattoo shop in maryland
] [http://crea.html.it/websites/lhsoz/prev.htm tattoo shop orange county
] [http://crea.html.it/websites/sjmwj/prev.htm tattoo shop in dallas
] [http://crea.html.it/websites/jlbpogs/prev.htm tattoo shop t shirt
] [http://crea.html.it/websites/jisauzsbx/prev.htm tattoo shop in hawaii
] [http://crea.html.it/websites/wsybtd/prev.htm tattoo shop new jersey
] [http://crea.html.it/websites/byxszh/prev.htm outer limit tattoo shop
] [http://crea.html.it/websites/xnnesqal/prev.htm bay area tattoo shop
] [http://crea.html.it/websites/nokzuz/prev.htm tattoo shop in minnesota
] [http://crea.html.it/websites/nkswfc/prev.htm tattoo shop in texas
] [http://crea.html.it/websites/cusmikoma/prev.htm tattoo shop in atlanta
] [http://crea.html.it/websites/uwrnp/prev.htm tattoo shop in ohio
] [http://crea.html.it/websites/jiuti/prev.htm long island tattoo shop
] [http://crea.html.it/websites/vvibshyy/prev.htm tattoo shop for sale
] [http://crea.html.it/websites/mnkbabxxz/prev.htm tattoo shop in georgia
] [http://crea.html.it/websites/yfyufiab/prev.htm tattoo shop in illinois
] [http://crea.html.it/websites/iruxzqfbo/prev.htm tattoo shop in sacramento
] [http://crea.html.it/websites/addmsiqxh/prev.htm tattoo shop in pa
] [http://crea.html.it/websites/vvxtqodeu/prev.htm san jose tattoo shop
] [http://crea.html.it/websites/ewfhctzr/prev.htm tattoo shop web site
] [http://crea.html.it/websites/piddecv/prev.htm tattoo shop in vegas
] [http://crea.html.it/websites/aslkry/prev.htm enchanted dragon tattoo shop
] [http://crea.html.it/websites/qfvjpn/prev.htm tattoo shop in winnipeg
] [http://crea.html.it/websites/zmwhlsi/prev.htm cross infinity picture tattoo
] [http://crea.html.it/websites/usocyr/prev.htm cross design tattoo tribal
] [http://crea.html.it/websites/cqlywlvh/prev.htm cross greek orthodox tattoo
] [http://crea.html.it/websites/kjkdm/prev.htm cross pic tattoo tribal
] [http://crea.html.it/websites/vtztmckx/prev.htm cross hands praying tattoo
] [http://crea.html.it/websites/yrekzcbtl/prev.htm angel cross tattoo wings
] [http://crea.html.it/websites/wralhl/prev.htm back cross lower tattoo
] [http://crea.html.it/websites/vxrpn/prev.htm christian cross design tattoo
] [http://crea.html.it/websites/spbscf/prev.htm cross greek letter tattoo
] [http://crea.html.it/websites/qykdb/prev.htm cross side stomach tattoo
] [http://crea.html.it/websites/chwahax/prev.htm cross in memory tattoo
] [http://crea.html.it/websites/ebxeif/prev.htm bones cross skull tattoo
] [http://crea.html.it/websites/oqdahoqa/prev.htm cross eva longoria tattoo
] [http://crea.html.it/websites/eskusmtdi/prev.htm cross justin tattoo timberlake
] [http://crea.html.it/websites/ilrnoclg/prev.htm bone cross skull tattoo
] [http://crea.html.it/websites/falxn/prev.htm back butterfly lower tattoo
] [http://crea.html.it/websites/kjkneao/prev.htm butterfly flower picture tattoo
] [http://crea.html.it/websites/kbamprmo/prev.htm butterfly by harley tattoo
] [http://crea.html.it/websites/bbzfim/prev.htm butterfly design tattoo tribal
] [http://crea.html.it/websites/kttwhlcb/prev.htm butterfly design fairy tattoo
] [http://crea.html.it/websites/ibhpelktc/prev.htm butterfly fairy flower tattoo
] [http://crea.html.it/websites/qxutkba/prev.htm butterfly design flower tattoo
] [http://crea.html.it/websites/eottoie/prev.htm butterfly fairy picture tattoo
] [http://crea.html.it/websites/uetqxhapj/prev.htm butterfly gallery picture tattoo
] [http://crea.html.it/websites/cyshqp/prev.htm butterfly design online tattoo
] [http://crea.html.it/websites/kokhg/prev.htm black butterfly design tattoo
] [http://crea.html.it/websites/ychtbe/prev.htm black butterfly tattoo white
] [http://crea.html.it/websites/fangirxoi/prev.htm butterfly picture tattoo unique
] [http://crea.html.it/websites/qreawpuya/prev.htm butterfly free gallery tattoo
] [http://crea.html.it/websites/cqdnlogad/prev.htm butterfly ink iron tattoo
] [http://crea.html.it/websites/nlrfdsor/prev.htm butterfly ink miami tattoo
] [http://crea.html.it/websites/doewns/prev.htm butterfly design flash tattoo
] [http://crea.html.it/websites/aylbpj/prev.htm butterfly fairy tattoo tribal
] [http://crea.html.it/websites/pbuqdae/prev.htm butterfly design picture tattoo
] [http://crea.html.it/websites/ucmlwa/prev.htm butterfly picture small tattoo
] [http://crea.html.it/websites/hqscoxo/prev.htm butterfly design floral tattoo
] [http://crea.html.it/websites/osemscbl/prev.htm picture of tribal tattoo
] [http://crea.html.it/websites/pfwgx/prev.htm tribal art tattoo picture
] [http://crea.html.it/websites/ymwsqp/prev.htm tribal sun tattoo picture
] [http://crea.html.it/websites/llslfhcn/prev.htm upper back tribal tattoo
] [http://crea.html.it/websites/wkxdbpyou/prev.htm behind neck tattoo tribal
] [http://crea.html.it/websites/ajmreiv/prev.htm tribal armband tattoo picture
] [http://crea.html.it/websites/nvjzqars/prev.htm free tribal tattoo flash
] [http://crea.html.it/websites/ralsd/prev.htm tribal dragon picture tattoo
] [http://crea.html.it/websites/igxeiof/prev.htm half sleeve tribal tattoo
] [http://crea.html.it/websites/rsewfufg/prev.htm sea turtle tribal tattoo
] [http://crea.html.it/websites/pyshxd/prev.htm american native tribal tattoo
] [http://crea.html.it/websites/zcqljofi/prev.htm tribal body art tattoo
] [http://crea.html.it/websites/afutfwhsw/prev.htm free tribal cross tattoo
] [http://crea.html.it/websites/dganvd/prev.htm free tribal tattoo art
] [http://crea.html.it/websites/iqpioqvgq/prev.htm tribal sun tattoo pic
] [http://crea.html.it/websites/jftajmbx/prev.htm tribal arm tattoo picture
] [http://crea.html.it/websites/iynzp/prev.htm tribal cross tattoo pic
] [http://crea.html.it/websites/fuvyj/prev.htm band pacific tattoo tribal
] [http://crea.html.it/websites/ryukqx/prev.htm heart tribal tattoo picture] </div>This is a page for documenting the [http://lxr.mozilla.org/mozilla/source/layout/base/nsCSSFrameConstructor.cpp 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.[https://bugzilla.mozilla.org/show_bug.cgi?id=323233 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.[https://bugzilla.mozilla.org/show_bug.cgi?id=323105 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.
+This is a page for documenting the [http://lxr.mozilla.org/mozilla/source/layout/base/nsCSSFrameConstructor.cpp 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 for
+out-of-flow frames. Currently this logic is duplicated in both frames
+and the frame ctor. Additionally, the frameCtor spends time on keeping
+track of the current containers even though most of the time we don't
+use them.
+One way to fix this is move the logic of what is what type of container
+into the frame. This way the frame ctor can ask each frame as its
+processing the frame children if the frame is a container. We can then
+easily figure out which frames are current containers in ContentInserted
+by walking the parent chain.
+Another solution is to make frames that need the information manually
+walk the parent chain until the desired block is found. This information
+could 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.
+could be done by the binding manager by letting all notifications go
+through the binding manager. It already is an nsIDocumentObserver so it
+should have all neccesary information. Better apis into the binding
+manager is another solution.
+has to be fixed by creating a better api that the frame ctor can use
+to access the flattened tree. One possible solution for accessing the
+flattened tree is to use a treewalker. However this might be an
+unneccesarily big change.
+The ultimate goal is to move as much of the xbl logic as possible out of
+the frame constructor.
+=== Hash for creator functions ===
+Rather then the current neverending list of if-statements to figure out
+which frame to create we should have a hash table that maps tag+ns to
+creator function. The hash table can also contain information about
+which type of frame will be constructed so that we can create, for
+example, 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 of
+frames if neccesary. For example for list boxes or form controls.
+We should have a similar (or even identical) hash keyed on display type
+for when the first hash doesn't produce a frame. Eventually we might
+want to move all frame types into this hash, but we need at least the
+content css property implemented for that.
+[https://bugzilla.mozilla.org/show_bug.cgi?id=323233 Bug 323233] filed.
+=== State management ===
+Until we have better transformation code in place we will probably need
+better state management code for the frame ctor. Logic should be moved
+into the frames so that we can rebuild the right state in a more
+reliable manner.
+=== Frame teardown ===
+Frame teardown should be a lot simpler, (Do)DeletingFrameSubtree should
+die and frames should be able to just clean themselfs up.
+[https://bugzilla.mozilla.org/show_bug.cgi?id=323105 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.