drupal_add_css() array should be modifiable

Option 1, Globals: If globals are the answer, you're asking the wrong question. :-) We should be using fewer globals, not more.

Option 2, hook_css_alter: I am not opposed in principle, but I'm not sure I see the need. Modules should not be playing with each other's CSS. The theme already can in the preprocessing function nee _phptemplate_variables(). Themes can also now override a parent theme's CSS via the info file.

I guess I don't see the use case here that isn't already covered.

Yes, nice and simple. But again, what the heck is a module doing screwing around with another module's CSS? That's the theme's job, for which there is already a mechanism (albeit not perfect).

fyi, this queue right here tried dealing with the issue already. Was postponed for 7.x

http://drupal.org/node/163785

jjef, I totally agree it should be simplified and made easier for themers to do what they please with core or any style sheets for that matter. I listened to the podcast and found it *very* interesting seeing it from a new perspective. Thank you for doing that. If I could make a request here, I'd say bring in more people that are new to Drupal to interview so everyone else too close to Drupal can gain more insight. Work with Drupal long enough and you start to forget how complicated it can get if you don't know the system well.

Yes, it's possible to remove core styles sheets right now but it's not straight forward and we need to fix that. I hope I can contribute to that in 7.x. I think the easiest approach is to have directives (is that the right word?) inside .info files that tell Drupal what to do like using the file system to discover overrides or simply simply switching them off completely.

Here's a handbook page on using the file system for 5.x. It can be easily adapted for 6. Your last use case for doing it through the theme engine is possible with the same technique. In fact, I plan on creating an engine myself to do the same.

http://drupal.org/node/155400

As far as modules overriding style sheets, I am totally against that. As Crell mentioned, modules have no business messing with other styles.

@jjeff: thats wrong. I have build a theme that "unset" a css file and later add it back... thats working in D5. Look here:

function _phptemplate_variables($hook, $vars = array()) {
  switch ($hook) {
    case 'page':

      // Add YAML Theme styles
      $vars['css'] = _yaml_add_css($vars);
      $vars['styles'] = _yaml_add_styles($vars);
      
      break;
  }
}

function _yaml_add_css($vars = array()) {

  // snip-snap to be short...

  // Remove the style.css added as first array item and move it to the end
  // of the styles array. This allows to use themes style.css and keep
  // the required CSS cascading order intact for CSS overriding.
  $css = drupal_add_css();
  unset($css['all']['theme'][$vars['directory'] .'/style.css']);
  $css['all']['theme'][$vars['directory'] .'/style.css'] = TRUE;

  // Return themed styles
  return $css;
}

function _yaml_add_styles($vars = array()) {

  $directory_temp = $vars['directory'];

  // The styles array is complete, get the styled version and append the
  // IE Hacks. Additional this allows to dynamically add packed iehacks.
  $output = drupal_get_css($vars['css']);
  $output .= "<!--[if lte IE 7]>\n";
  $output .= '<style type="text/css" media="all">@import "'. base_path() . $directory_temp .'/yaml/core/iehacks'. (variable_get('preprocess_css', FALSE) ? '.pack' : '') .'.css";</style>' . "\n";
  $output .= "<![endif]-->\n";

  // Return themed styles
  return $output;
}

This still applies (not surprising, it being one character). But going to bump for D7 since it clearly needs more discussion.

Patch #2 still applied.

Doesn't seem to be much support for this, so marking to won't fix.