How to understand other people's CSS architectures?

I am reasonably good with CSS. However, when working with someone else's CSS, it's difficult for me to see the "bigger picture" in their architecture (but i have no problem when working with a CSS sheet I wrote myself). For example, I have no problems using Firebug to isolate and fix cross browser compatibility issues, or fixing a floating issue, or changing the height on a particular element. But if I'm asked to do something drastic such as, "I want the right sidebars of pages A, B, C and D to have a red border. I want the right side bars of pages E, F and G to have a blue border if and only if the user mouses over", then it takes me time a long time to map out all the CSS inheritance rules to see the "bigger picture".

For some reason, I don't encounter the same difficulty with backend code. After a quick debriefing of how a feature works, and a quick inspection of the controller and model code, I will feel comfortable with the architecture. I will think, "it's reasonable to assume that there will be an Employee class that inherits from the Person Class that's used by a Department controller". If I discover inconvenient details that aren't consistent with overall architectural style, I am confident that I can hammer things back in place.

With someone else's CSS work, it's much harder for me to see the "relationships" between different classes, and when and how the classes are used. When there are many inher开发者_JS百科itance rules, I feel overwhelmed.

I'm having trouble articulating my question and issues... All I want to know is, why is it so much harder for me to see the bigger picture in someone else's CSS architecture than compared to someone else's business logic layer?

**Does it have any thing to do with CSS being a relatively new technology, and there aren't many popular design patterns?

I'd say that generally speaking, there is no "architecture" to the way most devs write CSS (at least in my experience). Most people build CSS incrementally as rules are needed -- it's usually not planned out in advance like code architecture is. Often people group related rules with comment blocks, or maybe in separate stylesheets, but really there are not many established patterns to follow.

Your best bet is to use a good CSS editor that allows you to visually browse the hierarchy of rules defined in your sheets.

I think a lot of times people just hack the css together without a concept of the overall picture. A lot of times they just add things on as they are laying things out with little regard to any "conventions" they established that aren't directly fresh in their mind leading to all kinds of naming redundancies and discrepancies.

I don't think that its so much that CSS is new as it is that CSS is often the realm of the designers and often times they dont think architecturally when designing something - everything is somewhat adhoc.

I know when I'm a lead i establish a formal set of conventions for class naming and organization as one of the first things i do and then hammer it in to the front end underlings :-)

First of all, it's harder to read code that it is to write code.

Secondly I would say since CSS allows for loose structure, then people will set it up in a complicated manner, so I would say that it is the nature of the beast.

Possibly because CSS is not architecture but presentation. Architecture is built with HTML. It is the HTML that leads you to the element.

Developers go through tremendous pressure to make sure that designs look consistent across all browsers, and so they start hacking which only makes CSS harder to maintain and understand. There are always good practices to follow such as:

• Use Reset.
• Comment CSS.
• Use existing CSS frameworks without inventing the wheel.
• Use Object-oriented design wherever possible.

If you follow these practices, anybody would be able to follow CSS using firebug.

yes.. The biggest problem is that CSS does not have any popular design patterns. This is my way of breaking other people's css

• inspect every element through firebug
• try to find the wrappers
• since css is always sequential try finding out which element inherits what attribute from who

when i am done with this routine, i usually get a hang of their complete design approach.

Edit:
and most importantly never mind to correct the already written CSS if you spot glitches. It will save you a lot of headache. Just go ahead and find workarounds if the glitch is too bad.

I struggle with the same problem, and find that it's helpful when working my way through someone else's CSS to divide the problem up, focusing on three concerns:

• Layout for large structure things like display:, position:, and float:, or any other CSS that's about how the page is structured at a course level.
• Color is about decoration. Background images and colors and such.
• Typography is all about text.

With a bit of practice, it's not too difficult to pick up a chunk of CSS and tease these categories out one at a time. You might find that it helps to drop the CSS into a text editor and reorder the rules into layout/color/typography (or layout/typography/color) order. Once you've done this, you may find that it's easier to reason about what's going on in the design.

There can be a bit of overlap between layout and typography in how margins and padding (and sometimes borders) are used. You'll need to work that out on a case-by-case basis.

Interestingly, most "hacks" (usually workarounds for IE) seem to fall into the layout category, though you might run in to a typography hack involved in getting a consistent base font size.