Last Comment Bug 76767 - refactor nsBlockFrame
: refactor nsBlockFrame
Status: ASSIGNED
:
Product: Core
Classification: Components
Component: Layout: Block and Inline (show other bugs)
: Trunk
: x86 Linux
: P5 normal with 2 votes (vote)
: Future
Assigned To: David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) (vacation June 4-12)
:
Mentors:
Depends on: 127117 518665 578901
Blocks: 682052
  Show dependency treegraph
 
Reported: 2001-04-19 15:30 PDT by David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) (vacation June 4-12)
Modified: 2012-07-20 20:06 PDT (History)
9 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description David Baron :dbaron: ⌚️UTC+2 (review requests must explain patch) (vacation June 4-12) 2001-04-19 15:30:00 PDT
I think at some point nsBlockFrame needs a major cleanup.  Here are some ideas I
think might work (although I haven't thought them through well enough yet to
really have a good idea how they might work):

 * It would be good to store vertical margins in separate structures, say,
nsBlockVerticalMargin (or maybe something a little shorter), since a single
vertical margin can be associated with an arbitrary number of blocks.

 * It might (I've thought about this even less) be nice to split nsBlockFrame
into two classes:  nsBlockFrame and nsBlockInnerFrame -- the outer one would
contain only other block frames, tables and nsBlockInnerFrames, and the inner
one would serve as a container for lines.  The current way the mLines array
stores both block and inline children has always seemed weird to me and I think
the code might end up being simpler if we distinguished between them.  Or
something like that...

I'm not sure if other people had been thinking about similar things, but I
wanted to jot these ideas down in a bug before I forgot them...

Note You need to log in before you can comment on or make changes to this bug.