I agree with Ber completely, and I reported this before too. My experience that most users are unique, and hence caching of css is not applicable. As a result, .css files are real bandwidth wasters (at one point drupal.css was 12% of my bandwidth, with 8% going to my theme's style). As a sort of workaround, I compress the CSS from drupal.css as well as from my theme, using one of these: http://www.cssdrive.com/index.php/main/csscompressor/ http://cdburnerxp.se/cssparse/css_optimiser.php I keep the original around or course, in case I need to make modifications, diffs with newer releases, ...etc. On 1/5/06, Bèr Kessels <ber@webschuur.com> wrote:

Op donderdag 05 januari 2006 14:58, schreef andre:

...

CSS files are, of course, cached client side on the very first page view and *Shouldn't* be downloaded time and time again. Yes they can be large - and could use some pruning - but its not a real performance issue.

I reported this before too.

ON my server, apparantly, 75% (more even) is a one time visitor. Drupal.css is always in the top 10 of most bandwith eating files.

But too much has been said about this. I beleive nothing will happen to that drupal.css file. All threads, all patches, all projects on this died in a heated debate. We will have to get to live with it :) /end music

bèr

On 05 Jan 2006, at 21:50, Neil Drumm wrote:

Bèr Kessels wrote:

...

But too much has been said about this. I beleive nothing will happen to that drupal.css file. All threads, all patches, all projects on this died in a heated debate. We will have to get to live with it :) /end music

All of the small patches I've done usually go through easily; unless they are hijacked and turned into a giant debate about boiling the ocean (http://drupal.org/node/13095). For example, I removed the margins from buttons a few weeks ago (http://drupal.org/ node/41751).

Ber is wrong, Neil is right. Patches do get through, just don't try to do it in one go. Stop whining about it, and start contributing patches. :) -- Dries Buytaert :: http://www.buytaert.net/

Actually Ber, you bring up a very valid point. Why does Drupal ship with drupal.css and etc? Isn't that just a file for themers to use? Why should they have to write overrides to get that crud out if they don't want it? Shouldn't it be the other way around, write a file to include it if they so desire? I think all of that stuff in misc/ should be moved into the themes folder. Bluemarine should be expanded (and the other default themes) to make use of drupal.css. There should be a new 'shared' folder under themes for the JS files in core that themes can make use of if they desire. That way, I can create theme ABC and if I want to use any of those JS files, I can. If it turns out I can't stand resizable textareas, no worries, only the bluemarine makes use of it, I don't have to tell my theme to load that JS file. That makes the most sense to me and would really help Drupal out, in all areas by seperating things further and requiring less, but still having a great out of the box experience. ted

No, I never said remove the out of box experience at all. I still like it and want it, for sure. What I'm proposing is to move everything in /misc into theme specific folders. Out of the box it functions like it currently does. However, if they decided to download uber-theme-XYZ, that theme may decide to turn off certain JS features, turn on other ones it may need, and all the time not have to worry about drupal.css since it already implements what it needs to and includes drupal.css if it so desires. There is a big distinction there. Make drupal.css part of the default themes, not a required css file that *all* themes *have* to use (without overriding). ted On 1/6/06, Jeff Eaton <jeff@viapositiva.net> wrote:

Simple: because Drupal is not JUST a development framework. It is, out of box, a functional web site CMS. A lot of stuff that we take for granted (having an 'edit' tab when we have perms to change a node, for example) are handled by that CSS file. Obviously, there's a case of creep somewhere along the line as unecessary CSS code snuck in that goes way beyond those basics. All the styles for drawing archive.module's calendar, for example, would best be moved into archive.css and included as needed IMO.

Come to think of it, that's a nice idea for a patch.

But, to return to the question, eliminating all CSS from core would be a definite mistake IMO. Stripping down drupal.css to a bare minimum, though? I'm all for that.

On Friday 06 January 2006 04:40 pm, Walt Daniels wrote:

One of the things websiteoptimization.com warns you about is too many objects on a page. Splitting the CSS file into many pieces will complain about that instead of the size of one of them. There is no free lunch.

Just because it complains doesn't mean the idea is automatically bad. :-) From a module developer perspective, though, I *want* to be able to provide my own module-specific CSS. Sure a theme author can do something else if he wants, but people should be able to get a functional and reasonably-well formatted module simply by dropping the module into the right directory and checking a checkbox. That means the module has to provide its own default CSS. I mentioned something a while back about moving more CSS to modules, but it was, I grant, a bit complicated. So what about this: We're talking about moving non-core modules out of /modules. Great, I agree, bring on /sites/all. That also then means that we can put core modules into their own subdirectories under /modules (or wherever core modules end up). Then, they can each have their own module-specific CSS files THERE. It means more files, but they're logically grouped by the module they relate to. To wit: /modules /aggregator /aggregator.module /aggregator.css /user /user.module /user.css /system /system.module /system.css ... Then, modules can either register their CSS file as appropriate (many contribs do this now), or the system could be "smart" and auto-include modulename.css on an enabled module and ignore it for disabled modules. No extra work from the module required. The result is more files, but each one is smaller and on repeated loads they're browser-cached anyway. Because few people have all core modules enabled, it will actually mean LESS CSS to send per user, on average, for a net bandwidth win, I'd wager. drupal.css goes away. Anything that doesn't fit to any specific module (eg, the various form element styles) goes to system.module. From a "I want to retheme it without having to untheme it first" perspective, it's at minimum no worse than the monolithic drupal.css. If the file is smart-loaded by name, actually, then it's probably a bit better, because it would be easier to add a feature to "don't load CSS from module X, but do load from module Y". That way it doesn't have to be an all-or-nothing matter. (Another column of checkboxes on admin/modules?) Now that I think of it, the same magic-name setup could work to breakup drupal.js per-module, and then the same mechanism could enable/disable js functionality per-module, too, for those who dislike all the new ajaxness in Core. (I agree it should be more optional than it is now.) OK, I think I started thinking aloud there. :-) To recap, I'm suggesting every module be required to be a directory in /modules (or wherever), and have magic-name files for resources as well as code. So any module consists of: /mymodule /mymodule.module (required) /mymodule.css (optional) /mymodule.js (optional) Then the admin/modules page gets 2 extra columns of checkboxes: Use Module CSS and Use Module JS, both of which default to on. The system then, based on those checkboxes, adds the appropriate <script> and <style> tags. Overall less code to send to the browser, more flexibility for themers, and more logical grouping of resources. I now await someone telling me why the above is dumb. :-) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson

On Friday 06 January 2006 06:19 pm, Larry Garfield wrote:

OK, I think I started thinking aloud there. :-) To recap, I'm suggesting every module be required to be a directory in /modules (or wherever), and have magic-name files for resources as well as code. So any module consists of:

/mymodule /mymodule.module (required) /mymodule.css (optional) /mymodule.js (optional)

Then the admin/modules page gets 2 extra columns of checkboxes: Use Module CSS and Use Module JS, both of which default to on. The system then, based on those checkboxes, adds the appropriate <script> and <style> tags. Overall less code to send to the browser, more flexibility for themers, and more logical grouping of resources.

I now await someone telling me why the above is dumb. :-)

It occurred to me after I sent this that it's dumb because whether or not to use a given module's CSS or JS file is not something that should be user configurable. It should be theme-configurable only, otherwise the behavior could be unpredictable. (MyTheme expects YourModule.css to not be active but it is, or expects it to be active but it isn't.) So forget admin/modules. Instead, a given theme can itself override a module's CSS/JS file by simply providing one of its own with the same name. So if mytheme wants to override yourmodule's default-provided CSS, it can do so by simply providing its own yourmodule.css file. If it wants to just remove that styling completely and not provide its own version, just include an empty yourmodule.css file. That could happen auto-magically or via a required callback function or declaration a la the way theme_* files are overridden. Alternatively, if people don't like magic names, modules could declare their css files via a very simple hook_styles() and JS via a simple hook_scripts(), both of which return a linear array of paths to the files they provide. That would allow multiple files per module to allow a breakup into mymodule-structure.css and mymodule-appearance.css, for instance. The theme override would be done the same way. In either case, the information would be cached per-theme and only rebuild when the module list or theme list changed. We could probably cache the entire <style> and <script> strings pre-rendered and be done with it. Thoughts? Ber, would that take care of the "I don't want JS" issue you bring up? -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson

I like the idea of splitting drupal.css up into parts based on features they implement.... that you could enable or disable through the themes interface. maybe have selectable sets of css per functionality...

tabs - tabs-default.css, tabs-borderless.css, tabs-simple.css

fieldsets - fieldsets-collapsible.css, fieldsets-borderless.css, fieldsets-nolegend.css

icons - icons-modern.css, icons-kde.css, icons-gnome.css

ajax.css - ajax-enabled.css, ajax-disabled.css

colors.css fonts.css layout.css

opens up smaller and more user, friendly I think. quick disable of what you don't need, easy behavior changes... not sure if all those things are possible, but it would be nice.

This is very very good, and is similar to what the Civicspace theme does. --Jeff

Oh, oh, Stupid me. I think I need to explain a little and apologise. My original post about the patches not making it in, and so ended with /end music. I worded it terribly, now that i reread it a couple of times. for I meant this as a jokish reply to stop this thread from starting in the first place. The discussion about what Drupal.css should be, will be, about what patches do and what don't and so on was held a lot of of times. Yet *that* specific thing is not solved, and will not get solved, as far as I can see. I wrote about that in the post below. I tried to explain it in that mail below. I rewrote that mail five times, so not to make that same mistake again. Unfortunately It did fire up that thread :( The contrary from what I tried to achieve with the mail. My apologies if I sound like a whining kid who starts yelling as soon as he does not get what he wants. I did not intend my original post like that. I intended it as "Let us not start talking about that css again, nothing has been decided so far, efforts to get that css skinned, spring-cleaned etc. have died in heated debates ". So I hope that, if we want to revive this discussion, we can do so, together with some real action. Action, that, this time is backed up by (core) developers willing to help (as pointed out, that is the case). And by a consensus about drupal.css' task (which, I see as a problem still). Removing four small chunks will not really get us anywhere. Removing 400 lines neither. But, as Dries points out, removing hundred times four small chunks will get us there. Again, my apologies for the misplaced, and misworded joke :) Bèr Op vrijdag 06 januari 2006 19:13, schreef Bèr Kessels:

Op vrijdag 06 januari 2006 08:46, schreef Dries Buytaert:

...

Ber is wrong, Neil is right. Patches do get through, just don't try to do it in one go. Stop whining about it, and start contributing patches. :)

Sorry, I will not stop whining about this. People have written a lot of patches for this, most of the writers are considered themers. All of these patches are either still open, or were, in the end committed as a one-or-two line fix, instead of the proposed "lets strip all the foo, bar and more" patches.

The reason is not that Dries nor anyone else is not willing to commit the patches. Let that be clear. The reason is that everytime the time that same stupid debate comes up: Should drupal.css be there for a nice, out-of-the-box working site, or should it only provide the highly nessecary lines. We never came to any agreement there, and I think we will never come to that.

That was wat I was referring to. not to the patches per se, but to changes some patches want to make. Those changes, don't get through. Or if they did, they only fixed small thingies, they removed, for example, a no longer used line. But netto, the drupal.css file grew with 82 lines (13%) between 4.6 and now. Not exactly the thing most patches, themers and issues wanted to achieve. I still count 35 colors, 52 margins 37 paddings, 14 floats etcetc.

And yes, removing them, will render a lot of pieces of drupal less friendly, ugly or even unsuable. So removing them will make the out-of-the-box-experience bad. But a theme like CS, will fix this experience. And It will definately make a lot of themers happy.

I will be the first to spend my weekends on completely skinning that drupal.css. (in fact, i have a recent patch here, my drupal.css only 120 lines) But for now I stopped committing those (and started pointing people at the fact that this ever recurring issue is ever recurring), because it would be rejected in a discussion anyway.

Bèr

On 1/6/06, Breyten Ernsting <breyten@gmail.com> wrote:

On 1/5/06, Bèr Kessels <ber@webschuur.com> wrote:

...

ON my server, apparantly, 75% (more even) is a one time visitor. Drupal.css is always in the top 10 of most bandwith eating files.

What's the effect of instructing the webserver to compress the CSS files?

Compress as in gzip or compress as in the methods Khalid mentioned? Greg