put CSS code in a logical directory structure

RESOLVED FIXED in Future

Status

()

Core
CSS Parsing and Computation
P3
normal
RESOLVED FIXED
17 years ago
4 years ago

People

(Reporter: David Baron, Assigned: David Baron)

Tracking

Trunk
Future
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Assignee)

Description

17 years ago
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.)

Comment 1

17 years ago
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."
(Assignee)

Updated

17 years ago
Status: NEW → ASSIGNED
(Assignee)

Updated

16 years ago
Priority: -- → P3
Target Milestone: --- → Future
(Assignee)

Updated

16 years ago
Blocks: 114713

Comment 2

14 years ago
Is this still relevant?
(Assignee)

Comment 3

11 years ago
Fixed (different paln) as part of bug 272151.
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Depends on: 272151
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.