At some point I'd like to reorganize the structure of the style system code, which was brutally split when layout and content were split. This depends on either one of: * layout and content being combined again (bug 106161) * the attribute mapping code being moved out of the content nodes (bug 107100) and a few other files being split and a tiny bit of COM glue (generally for DOM access for web pages) being written Either way, once this is done we could reduce the amount of COM used in the style data representation (nsIStyleContext). (We should also consider reducing the amount of COM in the sheet representation.) A possible directory structure would be something like the following (with interfaces omitted, but in the same directories as implementations): layout/css/base/ (or maybe layout/css/data/) nsStyleSet nsCSSProps nsCSSFrameConstructor nsCSSRuleProcessor (split out of nsCSSStyleSheet) nsRuleNode nsRuleWalker nsStyleContext nsStyleCoord nsStyleStruct nsStyleUtil layout/css/dom/ nsComputedDOMStyle nsDOMCSSAttributeDeclaration (split out of nsGenericHTMLElement.cpp) nsDOMCSSDeclaration nsROCSSPrimitiveValue layout/css/sheet/ nsCSSAtoms nsCSSDeclaration nsCSSKeywords nsCSSLoader nsCSSParser nsCSSRule nsCSSRules nsCSSScanner nsCSSScanner nsCSSStyleRule nsCSSStyleShee nsCSSValue nsHTMLAttributes nsHTMLAttributeMapping (split out of content nodes?) nsHTMLCSSStyleSheet nsHTMLStyleSheet layout/css/resources/ html.css forms.css quirk.css I probably missed a few files in this list. And every time I think it through I come up with a different idea anyway... (While we're doing this, we should also move nsDocumentViewer.cpp from content to layout and fix any other similar egregious mistakes.)

My comments on this structure: (1) I think frame constructor should be renamed to nsFrameConstructor and put in layout/base. IMO we should then make tearoff helpers like nsCSSFrameConstructor (for building by display type), and nsHTMLFrameConstructor, nsXULFrameConstructor, nsMathMLFrameCOnstructor, etc. that live in their appropriate subdirectories in layout. (2) I prefer layout/css/data to base, since we're talking about what is essentially the CSS "front end."

Is this still relevant?

Fixed (different paln) as part of bug 272151.