Big development teams can't handle a single CSS style sheet?_问答_开发者

I am currently in a 5-7 large development team creating a really large website with lots of pages and features.

I feel like we are in such a situation where a developer can change the style sheet to suit his own needs, but is unaware of the 1000 places where it probably change it for something else. I cannot blame him either, since I know it's hard to check everything.

It's a total mess.

I know that using one single style sheet file saves bandwidth and prevents duplicated code and maintenance, but I cant help wondering - is using style sheets a good idea for big sites, or should it be more object/element oriented.

Let's say you forget about the crazy large CSS and you define the CSS on each element instead. So each time you render a GreenBuyButton, it h开发者_JS百科as the "style='bla bla bla'" on it. And this is pretty much done for all elements.

This will increase the bandwidth, but it will not create duplicated code.

Could this be a good idea or how does really large teams work on a single website do with CSS to avoid it being a mess?

Why don't you create multiple CSS sheets depending on the area of the site?

blog.css
accounts.css
shopping.css

Then you could have a serverside script (say PHP) combine all CSS into 1 sheet which will get you the same result of 1 small file (could use a minimizer as well).

Check your overall site with a CSS checker to find duplicates (css defined) and manage it that way.

Otherwise communication is key between your team, who develops what, and so people don't duplicate CSS definitions. A master CSS keeper would be best suited to manage the CSS styles, besides your team should have an agreed upon style and not go rouge creating their own unique styles.

My recommendation would be to use the CSS rules on specifity to help you. For each CSS that is not global, put an activate selector on, for example

.user-list .p {
    font-size: 11pt
}

.login-screen .p {
   font-size: 12pt
}

This will make it easy to identify what rules are for which pages, and which rules are global. That way developers can stick to their own set of styles, and no mess up anyone else's.

Change how you write CSS.

Instead fo treating every area of the website like a specific piece of markup that needs styling, start defining broad classes.

Enforce some rules. Like, "All <ul> have a specific look for this project." If there are multiple ways you want to style an element, start using classes. This will keep your website looking uniform throughout. Uniformity reduces broken layout.

Create building block classes like a "framework" of sorts. This has helped me so often that I never start a project without doing this first. Take a look at the jquery-ui themeroller framework to give you the idea. Here's an example:

.icon        { display:block;width:16px;height:16px;}
.icon-green  { background:url(/green.png);}
.icon-blue   { background:url(/blue.png);}

Then on the elements:

<span class="icon icon-green"></span>
<span class="icon icon-blue"></span>

Breaking your styles up into their building blocks like this and using multiple classes on the element will keep your team members from having to change styles to suit their needs. If a particular styling quirk is not available they can define a new set of classes.

UPDATE:

Here is an example of how I used this method: Movingcost.com. Huge website, multiple different sections and pages, and only 252 lines of uncompressed css. Actually, these days I break things down further than I did on the movingcost project. I probably would have gone through those elements at the bottom of the stylesheet and figured out how to combine some of those into classes.

Multiple CSS files and combine in code

While doing development I found out that doing it the following way seems to be reasonable and well suited to development teams:

Don't put any styling into HTML. Maintainability as well as lots of head scratching why certain things don't display as expected will be really bad.
Have one (or few of them) global CSS that defines styles for global parts. Usually defines everything in template/master. Can be bound to master page or to generic controls used on majority of pages.
Have per-page/per-control CSS files when they are actually needed. Most of the pages won't need them, but developers can write them
Have these files well structured in folders
use naming and formatting guidelines so everyone will be able to write/read code
Write server side code taht will combine multiple CSS files into a single one to save bandwith.

You can as well automate some other tasks like auto adding per-page CSS files if they're named the same as pages themselves.

Doing it this way will make it easier to develop, since single CSS files will be easier to handle due to less content and you will have less code merging conflicts, because users will be working on separate functionality most of the time.

But there's not feasible way of automating CSS unit tests that would make sure that changing an existing CSS setting won't break other parts of your site.

My favorite override trick is to assign the id attribute on the <body> of each page. It's an easy way to make page specific changes without breaking out a separate stylesheet file.

You could have the following html

<body id="home">
  <h1>Home</h1>
</body>

<body id="about">
  <h1>About</h1>
</body>

And use the following css overrides

h1 {color: black}
#about h1 {color: green}

The home page gets the default css while the about gets overridden.

Using style sheets on large sites is an excellent idea. However, it only really works when you apply your team standards to the style. It makes sense to have a singular template controller that links your style sheet(s). It also makes sense to appoint someone on the team as "keeper of the style" who all changes to the style sheet should go through before making substantive changes.

Once the style standards are agreed upon and defined, then all of the controls in the site should implement the styles defined. This allows developers to get out of the business of coding to style and simply coding to the standard. Inputs are inputs, paragraphs are paragraphs, and floating divs are a headache.

The key is standardization within the team and compliance by all of the developers. I currently lead a team site that has upwards of 30 style sheets to control everything for layout, fonts, data display, popups, menu and custom controls. We do not have any of these issues because the developers very rarely need to edit the style sheet directly because the standards are clearly designed and published.

The answer is in the name. The reason it's called cascading style sheets is because multiple can be combined and there are decent rules defined on which one takes preference.

First of all, doing all your styling inline is a ridiculous idea. Not only will it waste bandwidth like nothing else, it will also result in inconsistency. Think about it for a while: why would changing a line of css 'break' another page? That indicates your css selectors are poorly chosen.

Here are my suggestions:

use one css file for the basic site look. This css file is written by people doing mainly design, and as a result the site has a consistent look. It defines the basic colors, layout and such.
use another css file per 'section'. For instance, a 'shopping' section will use components that are nowhere else on the site. Use that to define section-specific stuff
put page-specific styling directly in the page (in the header). If this section becomes too big, you're doing something wrong
put exceptional styling directly on the components. If you're doing the same thing three times, abstract it out and use a class instead.
choose your classes wisely and use the semantics for naming. 'selectedSalesItem' is good 'greenBold' is bad
if a developer changes a stylerule and it breaks the rest of the site, why did he need to change it? Either it's an exceptional thing for what he's working on (and should be inlined) or it was basically broken on the rest of the site as well, and should be fixed anyway.

If your css files become too big to handle, you can split them up and merge them server-side, if you want.

You don't want to define CSS for each element because if you ever need to make a change that affects many elements one day, say the looks of all the buttons or headers, you will be doing a lot of Search/Replace. And how to check if you forgot to update one rule to keep your site consistent?

Stephen touched on a very strong point in CSS. You can assign multiple classes to an element. You should define some basic rules that "ordinary" developers can't touch. They will provide the consistency through the site. Then developers can assign an extra class to personalize any property. I wouldn't assign more than two classes though: a global and a personalized.

Considering you already have this huge stylesheet in your hands, I'm not sure how you will pick which one of the 7 developers will have to sit down through a month and organize it. That is probably going to be hard part.

First off, you need to extract your website's default element styling and page structure into a separate stylesheet. That way people understand changing those rules affects the entire site's appearance/structure, not just the page they're working on.

Once you do that, all you really need to do is document / comment all of your code. A person is a lot less likely to write duplicate code in a well-documented stylesheet, and that is a fact.