Power-user your theme

Book page

Sometimes it's hard to distinguish between what is a theme task and what is a functional task. Neither a PHP nor HTML make that decision easy, as they've always traditionally mixed them up also.
There are several gems hidden in the handbook but they are easy to miss if you didn't even know the question to ask.

Custom rendering functions

Every fragment of a Drupal page (apart from your own page.tpl.php) has been output by a theme_*() function somewhere. If you can find the name of that function, you can bend it to your will. The hardest part is finding the right one!.
Read more about over-riding theme_*() functions. non-exhaustive list of available theme_*() functions (each contrib module adds a few more possibilities).
To find the function I often have to to a find-in-files over my drupal distribution, or inspect the likely modules directly, looking for function names.
I use The Eclipse IDE so it's usually only a cople of clicks to find the keyword I need.
Common theming targets include

Note that if there are tasks that seem too hard to do in a theme override function, you probably have to go up a level to find its caller, or maybe get happy with hook_form_alter() for serious re-renderings.

Use the magic filenames

Get familiar with the built-in power of the phptemplate theme engine, and how it can automagically select unique templates based simply on the ID of the calling object.

Manage your css as snippets

Try to break your theme CSS up into functional bits, eg search form styling, to keep it manageable. Drupal (with CSS caching) will fix thing so that this approach does not least to lots of file requests, so go granular!
I try to refactor my themes into something like:

layout.css
typography.css
admin.css
color.css

... as appropriate. Then sometimes lay on function or feature-specific tweaks such as

menu.css
ecommerce.css

if needed. This is not always needed, but if I'm doing some highly special thing to the menu navigation, maybe it is best done stand-alone.

A very custom block

Following the example of the page selection pattern, we can do the same with blocks, AND package a block-specific bit of CSS along with it.

Investigating phptemplate_block() we see that, for example, the user login block will be looked for in any available file called:

block-user-1.tpl.php
block-user.tpl.php
block-left.tpl.php
block.tpl.php

So, we can create a custom block template, called block-user-1.tpl.php and call our own css to be included only on pages where that block shows up.

block-user-1.tpl.php

<?php
// Add a block-specific css, if it exists
if(file_exists( $css = path_to_theme() .'/block-'. $block->module .'.css')){
  drupal_add_css($css);
}
// This block includes a couple of placeholders used for styling graphic corners,
// and a title placeholder for semantic image-replacement.
?>
<div id="block-<?php print $block->module; ?>-<?php print $block->delta; ?>" class="block<?php print " block-$block->module"; ?>">
  <div class="top placeholder"></div>
  <?php if ($block->subject): ?>
  <h3 class="title"><span class="title-text"><?php print $block->subject; ?></span></h3>
  <?php endif; ?>
  <div class="content"><?php print $block->content; ?></div>
  <div class="bottom placeholder"></div>
</div>

This will end up including the themes block-user.css

Due to the order the page gets built, the use of drupal_add_css() means that the css declaration will find its way into the head in time, and NOT get included if this particular block is not being shown.

You can see the possibilities for modular code here! This is quite handy if you have a small team working on the same design at the same time.
No more big interwoven CSS files.
Yeah, on the other hand this can get harder to manage in your head at one time - but with an IDE and the DOM inspector, it's not that hard at all.