Add numeric weight to drupal_add_css

AFAIK there is some order how css files are handled. This is from drupal_get_css function which creates css output

Returns a themed representation of all stylesheets that should be attached to the page. It loads the CSS in order, with 'core' CSS first, then 'module' CSS, then 'theme' CSS files. This ensures proper cascading of styles for easy overriding in modules and themes.

What you are saying is maybe more a feature request than a bug. But I guess there was some thinking involved when they build the system as it is with no weights.

If CSS code in contrib module A is conflicting with CSS code in contrib module B, then you don't need to reorder them. You need to file a bug against one or the other modules that are trying to be too greedy with their CSS.

Your theme really shouldn't have/need more than one CSS file per media type. It can override module CSS, although the new CSS handling system in Drupal 5 is designed so that instead you'd unset the CSS file for the module you want to override and then add whatever you want in your own theme file rather than writing rules that "undo" the module's rules.

There's actually no "core" CSS anymore, just CSS files that are associated with certain core-provided modules. Much nicer than it used to be. :-)

If you say you're in a situation where you need to order the CSS files, then you're in a situation where you need a different solution as there are already some provided that work better than simple weights.

What exactly is a CSS framework? It sounds like you're just doing a stylesheet switcher. Drupal core supports user-configurable themes, and themes can simply be alternate-CSS versions of other themes, so you can accomplish that without any additional code whatsoever. It can be made even easier with the existing Switchtheme module.

I am 98% certain that whatever it is you're trying to do can be done, but via a different method than you're trying. Without knowing what a "CSS framework" is, though, we can't say what the "right way" would be. Go with the grain of the API, not against it.

I'm afraid my German is a bit rusty (read: nonexistant), so I'm not sure if I completely understand what you're doing. :-) However, it still sounds like you're trying to solve a problem that has already been solved in a different way by Drupal.

If you want different types of nodes to have different templates, you can name templates node-mynode.tpl.php and that template will be used for that node.

If you want different paths to have different templates, Drupal 5 has that ability now, also just by the naming scheme of the templates. I forget the details off hand, but Jeff Eaton did a whale of a job putting that together and getting it tested. Do a search and you should find details on it. :-)

If you want to use a different theme on different paths, try the sections module.

No, none of those are YAML itself. But from what I can see, not being able to read German, it sounds like all of those issues are covered in some form or another, two of them just by core. Going with the grain of the system will make your life a lot easier. :-)

I understand the OP's need for ordered CSS. Use case: The Panels module writes a CSS twocol_stacked.css AFTER my custom theme's style.css. This is problematic because there is no way for me to overwrite twocol_stacked.css which I need to do in order to resolve a display issue in ie6.

That's no longer the case, actually. As of this patch, the CSS preprocessor automatically puts module CSS before theme CSS. If there's CSS that gets added by a module that you can't override, that's a bug, not a need for explicit weighting. You can also explicitly override that CSS file and tell Drupal not to add it, and then include its rules in your theme's CSS instead. You can do that in Drupal 4.7, too.

Setting to "by design".

Numeric weight was added to drupal_add_js and it cleaned up the code a lot. The same should be provided for drupal_add_css as $options['weight'].

#259368: Allow Inline CSS in drupal_add_css

subscribe

Subscribe

Opening back up. This should look/work similarly to drupal_add_js weight system.

Was having a hack at this on Monday and ran into a problem with using numeric weights instead of "module" and "theme" weight. When a CSS style is tagged as "module" if there is an associated "theme" CSS file by the same name, the "theme" one fully replaces the "module" one. If we have numeric weights, then there isn't really a way to determine which one is the module one and which is the theme one...........

A possible solution would be if there are two files of the same name, take the one with the higher weight. Not sure, thoughts?

sub

Required for #315035: Add jQuery UI elements to core. Well, not really - but to allow for a hook_css_alter() [according to Rob Loach], and thereby to allow for updating jQuery UI page requisites.

Re-classifying accordingly.

Should the weighting and reordering of CSS files take place inside their media or types groupings? Or should weight disregard these and order them in an absolute way?

The array of CSS files is structured like so:

Array
(
    [all] => Array
        (
            [module] => Array
                (
                    [modules/mymodule/all1.css] => 1
                    [modules/mymodule/all2.css] => 1
                    [modules/mymodule/all2.css] => 1
                    [modules/mymodule/all4.css] => 1
                )

            [theme] => Array
                (
                    [sites/all/themes/mytheme/styles/all1.css] => 1
                    [sites/all/themes/mytheme/styles/all2.css] => 1
                    [sites/all/themes/mytheme/styles/all3.css] => 1
                    [sites/all/themes/mytheme/styles/all4.css] => 1
                )
        )

    [print] => Array
        (
            [module] => Array
                (
                    [modules/myprintmodule/print1.css] => 1
                    [modules/myprintmodule/print2.css] => 1
                )

            [theme] => Array
                (
                    [sites/all/themes/mytheme/styles/print1.css] => 1
                    [sites/all/themes/mytheme/styles/print2.css] => 1
                )

        )

)

Edit: This essentially readdresses Rob Loach's question from #17.

It would end up looking something like this:

Array
(
    [modules/mymodule/all1.css] => Array
        (
            [weight] => 0
            [type] => file
            [media] => all
        )

    [modules/mymodule/all2.css] => Array
        (
            [weight] => 0
            [type] => file
            [media] => all
        )

    [modules/mymodule/all3.css] => Array
        (
            [weight] => 0
            [type] => file
            [media] => all
        )

    [sites/all/themes/mytheme/styles/all1.css] => Array
        (
            [weight] => 5
            [type] => file
            [media] => all
        )

    [sites/all/themes/mytheme/styles/print1.css] => Array
        (
            [weight] => 10
            [type] => file
            [media] => print
        )

    [0] => Array
        (
            [type] => inline
            [data] => body { padding-left:0px; }
        )
)

This is so that it would be really easy to use hook_css_alter(), like you see in hook_js_alter(). You could easily find specific files within the CSS array without having to traverse through the media arrays. The thing though, is that it's really hard to know which incoming CSS file is associated with the theme so that it can replace the module ones...

In this example, since mytheme/styles/all1.css is in there, modules/mymodule/all1.css should be completely removed from the array.

In this example, since mytheme/styles/all1.css is in there, modules/mymodule/all1.css should be completely removed from the array.

Do we really want to override stylesheets if their names collide? If there's a precedent for this -- if .info or drupal_add_js() works this way -- then I'm all for it. But if this is unique to this function, should we rely instead on hook_css_alter() to override stylesheets?

Also, can you estimate how long this patch would take? I'm working on a project that may need this added to Drupal 7.x in order to backport it to Pressflow 6.x. While we can handle the backporting, we can combine resources to handle the D7 patch provided we have a roadmap.

Hi Todd. In Drupal 6, theme CSS files can override module CSS files if the theme implements a CSS file of the same name. You can see that at drupal_get_css. Or, try simply adding "stylesheets[all][] = system.css" to your theme's .info file. You'll see that modules/system/system.css isn't included anymore.

Estimate how long this patch would take? If anyone submits the patch, then the patch is submitted. If someone doesn't submit the patch, then the CSS weight doesn't get in. You're saying have hook_css_alter() override the stylesheets instead of the theme? That sounds pretty reasonable. Could even just go through checking the filenames and when there is a duplicate name, just take the one with the higher weight. Since theme CSS files should generally have a higher weight then modules, that kind of makes sense.... Thoughts?

Rob: Thanks for the explanation of how a theme can override a module's CSS file simply by sharing the same name. I didn't know that -- though considering that's how everything else works (more or less), I should've inferred as much.

What I meant by "how long" was "how many hours do you think it would take a reasonably skilled developer to handle this" -- not "when is it going to get done." (I'm down with the do-ocracy!) I just wanted to get your opinion on how time-consuming this issue would be. I've since spoken to some colleagues, and I think I have a handle on this issue's size.

I think the best way forward is exactly what you outline in #21 above: replacing the nested [media][type][file] structure with a flat, weighted one. For the sake of consistency, the drupal_add_css() -> hook_alter_css() -> drupal_get_css() flow should probably behave much like that for building and aggregating JavaScript.

Unfortunately -- or perhaps fortunately? -- we've found a workaround for Drupal 6.x, so we can't justify spending client time on this patch. If my development skills were a bit sharper, I'd tackle it myself. I'm interested to see how this turns out, though.

This blocks #315035: Add jQuery UI elements to core, assigning myself.

Here is a first patch up for review.

See http://drupal.org/node/315100#comment-1748722 for another concept(!) for dealing with JavaScript and CSS dependencies.

oops... changing back status

to be clear, the link I posted is not to stop development on this patch, it's just a proof of concept and far from inclusion in core. There's a good chance it'll fail, so we at least want to have weights for CSS.

@kkaefer: AFAIK, there is another, dedicated issue for treating JS/CSS unified as "support files"/"page requisites" languishing around somewhere, which probably makes sense. However, let's do it step-by-step -- this issue should bring drupal_add_css() to the same structure and processing as drupal_add_js(), also introducing tests ensuring that it works properly for CSS. Afterwards, it will be quite easy to re-think and unify all of those JS/CSS invocations (and also the constant names).

@sun: absolutely. I said in #28 that we should by no means cease work on this patch as the other one might turn out to be a bad idea or not make it for any of the gazillion other reasons.

Thanks for starting this off Damien. I hacked at the patch a bit:

1. Moved the RTL overrides to locale_css_alter() along with a test for the CSS alter
2. Makes $type either a string or an array of the options rather then a forced array with an "inline" boolean flag. Example: 'type' => 'inline' or 'type' => 'file'. This is more similar to how drupal_add_js does it.
3. Switched from CSS_MODULE to CSS_DEFAULT to reflect JS_DEFAULT
4. Added some more documentation.

• Inline stylesheets were being added with the CSS as their array key. If there's a huge inline CSS string being added, you'd run into troubles when placing it in the array. Fixed that with using $css[] = $options.
• A constant of -0 was just silly.

@Rob Loach: thanks for catching the ball on that, that seems like a good clean up of my original patch. Two questions:

• I don't believe that having a 'file' / 'inline' key is better then just a 'inline' boolean, and I don't believe that it is a good idea to have a "string or array" $options parameter; those even if drupal_add_js() does it this way. Yuck, that's an horrible API.
• You are basically ignoring the weight for inline CSS files, and placing all those at the bottom... why? Those would override theme CSS... which doesn't sound like a good idea. I think it's better to honor the weight for those too, and live with the repetition of the
  

  tag.

The reason we use a "type" instead of an "inline boolean flag is because eventually we'll want to have an "external" type, like drupal_add_js. So, instead of having a bunch of booleans "inline" and "external" booleans, just keep using "type", and keep drupal_add_css as close to drupal_add_js as we can.

The problem I ran into with keeping the inline styles mixed in with the preprocessed one's weight was that if you added five inline CSS, you'd end up with:

<link src="example.css" />
<style type="text/css">body { padding-left: 5px; }</style>
<style type="text/css">body { padding-right: 5px; }</style>
<link src="example2.css" />
<style type="text/css">body { padding-top: 5px; }</style>
<link src="example2.css" />
<style type="text/css">body { padding-bottom: 5px; }</style>

Although the weight is kept with the inline styles fine, you end up with a bunch of different inline style tags. If we aggregate them together into one style tag, you end up with one inline style:

<link src="example.css" />
<link src="example2.css" />
<link src="example2.css" />
<style type="text/css">body { padding-left: 5px; }{ padding-right: 5px; }{ padding-top: 5px; }body { padding-bottom: 5px; }</style>

Although we do loose the explicit weights for the inline styles, I believe that aggregating them all together will help speed up the rendering of the page as well as mimic what you'd get when CSS Optimization is on when aggregating the files (since inline stylesheets shouldn't be added to the aggregated CSS file). See #259368: Allow Inline CSS in drupal_add_css for more about that. The inline stylesheets themselves do keep the weight between each other though.

@Rob Loach: then, please do the right thing and add an explict $type parameter (ie. drupal_add_css($data, $type, $options). Having a "string or array" parameter makes no sense to me.

So the inline CSS files added by, say a module, will always override the CSS file of the theme? That sounds like a deal-breaker for inline styles.

The $options as a string to define the type, or the $options as an array specifying additional arguments has been how it has worked since #251578: More flexible js/css ordering and an alter operation last year. If you want to change the function signatures, I suggest you open up a new issue.

If you're adding inline styles, then you're adding dynamic CSS that you want to override anything at all. Like the documentation says, it won't be aggregated, and therefore should be avoided unless you're doing something dynamic that can't be aggregated. The patch you uploaded also gave different output whether you had aggregation on, or off. If you had a bunch of inline stylesheets and had aggregation off, you'd end up with:

<link src="example.css" media="all" />
<style type="text/css">body { padding-left: 5px; }</style>
<style type="text/css">body { padding-right: 5px; }</style>
<link src="example2.css" media="print" />
<style type="text/css">body { padding-top: 5px; }</style>
<link src="example3.css" media="all" />
<style type="text/css">body { padding-bottom: 5px; }</style>

When you turned aggregation on, you'd get:

<link src="css_fdsfdas32re24dsf23454.css" media="all"/>
<style type="text/css">body { padding-left: 5px; }</style>
<style type="text/css">body { padding-right: 5px; }</style>
<link src="css_fdsfdas32re24dsf23454.css" media="print"/>
<style type="text/css">body { padding-top: 5px; }</style>
<style type="text/css">body { padding-bottom: 5px; }</style>

As you can see, it would aggregate example, example2 and example3 fine, but when applying the inline CSS, you'd loose the correct weighting of some of the inline stylesheet relative to the files. Example3 and a couple of the inline styles arn't in the correct locations. The conclusion we came to for this (we being mfer, sun, etc) was just putting them all after the CSS files on the page. But, changing the way the inline styles work lives in this issue: #259368: Allow Inline CSS in drupal_add_css. The point of the inline CSS is to add stuff to the page that is dynamic is meant to fully override anything on the page. This is why the inline CSS is added after any other CSS, and isn't aggregated.

There really isn't any way not to break the ordering with aggregation and inline stylesheets. Because we can't aggregate the inline stylesheets all together with the preprocessed CSS files, you're left with the inline stylesheets being in the incorrect order after aggregating the files. We discovered this with #259368: Allow Inline CSS in drupal_add_css and decided to stick them after the preprocessed files. This is exactly what drupal_add_js() does with inline scripts, it sticks them after the preprocessed files.

You would end up with even more broken ordering like you see here:

<style type="text/css">p { padding-left: 5px; }</style>
<style type="text/css">p { padding-right: 5px; }</style>
<link src="css_fdsfdas32re24dsf23454.css" media="all"/>
<style type="text/css">p { padding-top: 5px; }</style>
<style type="text/css">p { background-color: black; }</style>
<link src="css_sfaddsfdf4234frfwerq.css" media="print"/>
<style type="text/css">p { padding-bottom: 5px; }</style>

There unfortunately isn't a nice way around it without aggregating the inline styles into the other CSS files, but we can't do that. Imagine how many inline

Reminder: The best thing we can do here is to adapt the identical function signature and API like drupal_add_js() in terms of DX. Those two functions should be and work identical. When they are, we can think about optimizations and most likely consolidation.

The order of which the CSS displays actually isn't as critical as the order in which the JavaScript displays. With JavaScript, if a script shows up that depends on a library that's defined after it, you'll run into a critical error. With CSS, this isn't as important as you can override other CSS no matter where it is. You can override something in the theme layer from a module CSS simply by adding another selector to it:

Try this:

<html><head>
<style type="text/css">
p { background-color: orange; } /* System layer */
body p { background-color: yellow; } /* Module layer */
p { background-color: red; } /* Theme layer */
p { background-color: blue; } /* Inline */
</style></head><body>
<p>Hello</p>
</body></html>

Here, even though the inline and theme style is defined last, the module layer CSS will take effect since it has the most selectors. If you remove the body selector, however, then the inline CSS will take effect since its defined last. Either way, there isn't any way to keep the inline styles ordering the same when CSS aggregation is on. Inline styles are meant to be dynamic styles and override anything previously defined, since they are special to the user. Take a look at how Twitter does dynamic CSS, you can see they have the main twitter.css (the aggregated CSS file), and then afterwards, the inline dynamic styles which are meant to completely override the previously defined ones.....

Although we do loose the weight relative to the aggregated stylesheets, the weight is kept among the inline styles themselves. There is no way to keep the ordering of the inline and aggregated stylesheets correct so we just throw them all at the end since the dynamic CSS is special and should replace anything on the module or theme layer anyway. Do you think this needs better documentation?

The inline styles have to come last, or aggregation is orders of magnitude more complex. What is more, this has been the standard since Drupal 5, so discussing changing this is out of scope of this issue and is distracting us from the task at hand.

The task here is simply to add weights to CSS addition, within the constraints applied to each type of addition.

Regarding the patch, I agree with the general direction - especially keeping the same pattern as drupal_add_js for both DX and an eye on future consolidation of the backend processing (as my patch of eons ago attempted).

+    // Always add a tiny value to the weight, to conserve the insertion order.
+    $options['weight'] += count($css) / 1000;

This looks like a fairly odd approach, and not one I recognize from add_js, or other Drupal array sort patterns. Could this be made more normative?

@hass - the order of @imports is a completely different situation to the adding of inline code, and Drupal 5 clearly had incorrect behavior here.

The current behavior (and this patch) is completely consistent and does not change the order of any CSS added, it simply for very practical and logical reasons splits all CSS into 2 groups (1) file based CSS and (2) inline CSS. WIthin each group you have some control (and full control with this patch) over the order, but you cannot output inline CSS intermixed with file based CSS.

This is exactly how this was designed to operate. In every case I have seen the only point of adding inline CSS is to override something and add dynamic styles to the page - dynamically generating and adding inline CSS from your module or theme, but having it overridden by file based CSS is pretty pointless AFAICS - although as Rob points out you can still do this with careful choice of selectors.

If you feel the current behavior is wrong, then please open a new issue (describing a clear use case for needing to add inline CSS but override it with file based CSS) - but please don't continue to hijack this one :)

• Fixed the test
• Updated to HEAD
• Didn't change $options['weight'] += count($css) / 1000;, but if you think of a better way around it then please suggest it as it's soon going to be done for the JavaScript files too: #505528: JS files of the same weight are not included in the order of the calls. The thing is that although we do get weight for the files, we want to keep the order in which the files were added if weights are the same, you know?
• This is not critical for the functionality of Drupal 7, although it would be nice and would make drupal_add_css more like drupal_add_js.

weights and it comes with shiny new tests.

I'd like to have DamZ or sun sign-of on this patch given that they were involved earlier on.

I give this one a tip of the hat.

bumping to critical. We need this for the library stuff that already landed and the css and js api has diverged and we have more changes to bring them back together.

Patch got stale waiting. This is updating to the moving HEAD.

Committed to CVS HEAD. Thanks!

Marking as needs work until the docs are updated.

subscribing. Thanks

Tagging, so said docs actually get written. :)

Thanks for the reminder, Angie!
http://drupal.org/update/modules/6/7#drupal_add_css_weight