Separating design concerns, not UI elements #4

croaky opened this Issue Jul 28, 2009 · 2 comments


None yet
2 participants

croaky commented Jul 28, 2009

Right now, Flutie has no philosophy on how CSS should be organized. The sheets are:

  • defaults.css
  • forms.css
  • lists.css
  • reset.css
  • screen.css
  • tables.css
  • type.css

defaults could be anything. forms, lists, and tables are clearly UI (HTML) elements. reset is fine. screen.css could be anything. type is probably typography.

I'd like to propose that we organize styles by different design concerns:

  • reset.css
  • color.css
  • typography.css
  • spacing.css (float, margin. padding, clear, display, align)

OR split typography.css into pieces:

  • typography/scale.css
  • typography/typeface.css
  • typography/weighting.css
  • typography/leading.css
  • typography/justification.css
  • typography/decoration.css
  • typography/measure.css

The advantages of doing it this way as I see it are:

  • avoiding inheritance problems, particularly around ems
  • thinking in terms of classic design, not as coders going, "Ah, I just need to get this one thing lined up..."
  • knowing exactly where everything goes
  • achieving true separation of style & markup
  • keeping CSS files small and readable
  • avoiding temptation to go "Ah, I'll just add this one more style down at the bottom..."
  • thinking of the app as a cohesive design, seeing related design concepts next to each other, not related ids together

cpytel commented Jul 29, 2009

I have a large concern about splitting typography up like that, you're going to end up with the style for one piece of text being split up into 8 different files and that'll be a problem for maintenance and debugging.

I have an alternative suggestion. Why not give flutie an organization for base elements like already exists or the alternative you suggest (reset/color/typography/spacing) but then have the app organize styles by "app concept". For example, everything to do with users goes in users.css, everything to do with posts goes in posts.css, and so on?


croaky commented Jul 29, 2009

That sounds good to me, Chad.

This issue was closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment