[drupal-devel] drupal.css, again (still)
A lot has been discussed about this, but as of yet nothing solved. Can we discuss this, **but with the aim to come to an agreement?** Personally I am really annoyed by the drupal.css and remove it nearly always. But it is correct to state that drupal.css must be there, for usability sake. A lot of (especially admin) pages will not work without some CSS. But that is definitely no excuse for all sorts of background-colors, font-sizes, borders etc, that are in that sheet. So, to get to a conclusion; I think we should *not* discuss whether or not drupal.css must be there, we will never come to an agreement on that. it will remain, unless someone patches a very nice solution. But we should discuss what can be in there and what not! My first idea is, drupal.css must contain * No colours, nor background colours, unless they greatly enhance useability. think of watchdog entries. But not tables, grey tables are nice, but should be styled by the theme; * No borders, paddings or margins, *unless* a page will break without them [1] * No floats, breaks, displays, centres or other things that manipulate the flow, *unless* a page will break without them. [2] * No widths, unless they are really needed to make floated erlements appear on the same line. with:100% is very annoying due to the famous border-box-model. [1] usefull: ul.primary li.active a { background-color: #fff; border: 1px solid #bbb; annoying: .tips { margin-top: 0; margin-bottom: 0; [2] usefull: br.clear { clear: both; } annoying: #aggregator .news-item .date { float: left; } or even more annoying .user-login-block { text-align: center; } Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
How about we change the drupal_get_html_head() function so that it does not inject the drupal.css file. instead, core themes and themes that want this file add that line to their <head> section manually. themes that don't want it simply omit this include. -moshe Bèr Kessels wrote:
A lot has been discussed about this, but as of yet nothing solved.
Can we discuss this, **but with the aim to come to an agreement?**
Personally I am really annoyed by the drupal.css and remove it nearly always. But it is correct to state that drupal.css must be there, for usability sake. A lot of (especially admin) pages will not work without some CSS.
But that is definitely no excuse for all sorts of background-colors, font-sizes, borders etc, that are in that sheet.
So, to get to a conclusion; I think we should *not* discuss whether or not drupal.css must be there, we will never come to an agreement on that. it will remain, unless someone patches a very nice solution.
But we should discuss what can be in there and what not! My first idea is, drupal.css must contain * No colours, nor background colours, unless they greatly enhance useability. think of watchdog entries. But not tables, grey tables are nice, but should be styled by the theme; * No borders, paddings or margins, *unless* a page will break without them [1] * No floats, breaks, displays, centres or other things that manipulate the flow, *unless* a page will break without them. [2] * No widths, unless they are really needed to make floated erlements appear on the same line. with:100% is very annoying due to the famous border-box-model.
[1] usefull: ul.primary li.active a { background-color: #fff; border: 1px solid #bbb;
annoying: .tips { margin-top: 0; margin-bottom: 0;
[2] usefull: br.clear { clear: both; } annoying: #aggregator .news-item .date { float: left; } or even more annoying .user-login-block { text-align: center; }
Regards, Bèr
Op woensdag 18 mei 2005 17:50, schreef Moshe Weitzman:
How about we change the drupal_get_html_head() function so that it does not inject the drupal.css file. instead, core themes and themes that want this file add that line to their <head> section manually. themes that don't want it simply omit this include.
This is not a real solution. drupal.css would still contain a lot of non-appropriate CSS. And also, themers should not be bothered to much with styles like the next prev links in book navigation. IMO these links should 'just work'. I just wanted to point out we have a lot of crufty code in there. all sorts of font-sizes, background-colours, inappropriate floats etceteras. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
I support this. Do not force it down the throats of people who do not want to use it. As long as it is optional, each side can have it their way. On 5/18/05, Moshe Weitzman <weitzman@tejasa.com> wrote:
How about we change the drupal_get_html_head() function so that it does not inject the drupal.css file. instead, core themes and themes that want this file add that line to their <head> section manually. themes that don't want it simply omit this include.
Op 18-mei-2005, om 18:46 heeft K B het volgende geschreven:
I support this. Do not force it down the throats of people who do not want to use it. As long as it is optional, each side can have it their way.
On 5/18/05, Moshe Weitzman <weitzman@tejasa.com> wrote:
How about we change the drupal_get_html_head() function so that it does not inject the drupal.css file. instead, core themes and themes that want this file add that line to their <head> section manually. themes that don't want it simply omit this include. Maybe we can write a new function eg, drupal_remove_stylesheet ($stylesheet), which can handle the removal of drupal.css for themers? that we you can do both, or include it or not..
It looks consistent with drupal_add_stylesheet($stylesheet, $media), which we already have.. Stefan.
Moshe Weitzman wrote:
instead, core themes and themes that want this file add that line to their <head> section manually. I made a patch that did this back in January, see comment 13 on http://drupal.org/node/13095
Another approach is just @import drupal.css at the start of your stylesheet. But *both* these approaches have a problem. Currently stylesheets are linked in the following order: drupal.css module specific module.css theme's style.css Doing as you suggest (or using my patch) means module.css will be linked in before drupal.css - something that might cause problems, and certainly means modules can't overide core styles. drupal.css isn't all that crufty and a hell of a lot of it is necessary. I've pretty much moved camps and am now firmly in Steven's 'we need drupal.css but lets clean it up' camp. -- adrinux (aka Adrian Simmons) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@gmail.com> AOL/Yahoo IM: perlucida, Microsoft: adrian@perlucida.com
Doing as you suggest (or using my patch) means module.css will be linked in before drupal.css - something that might cause problems, and certainly means modules can't overide core styles.
the theme designer can put drupal.css first or last or wherever he pleases. he can omit it if he wants. cleaning up drupal.css is a separate task, which ought to be done. that takes more time though and more consensus building.
Op donderdag 19 mei 2005 02:03, schreef Moshe Weitzman:
cleaning up drupal.css is a separate task, which ought to be done. that takes more time though and more consensus building.
yes! so can we move on and discuss what kind of things can be in drupal;css? I already made a list on the bginning of the thread, but include it here again: * No colours, nor background colours, unless they greatly enhance useability. think of watchdog entries. But not tables, grey tables are nice, but should be styled by the theme; * No borders, paddings or margins, *unless* a page will break without them [1] * No floats, breaks, displays, centres or other things that manipulate the flow, *unless* a page will break without them. [2] * No widths, unless they are *really* needed to make floated elements appear on the same line. This is all still fuzzy, so please help to get this in more detail. And then there is a new issue: module specific style. Case: a personal blog. Needs no book styles, yet these styles are sent to the clients. its not a lot of BW, but still not needed, IMO; cold we not move the styles of core contribs to misc/modulename.css ? I know we actually might be best of to have modules live in their directories, butbless someone actually writes a good script to do this in CVS and gets ppl convinced to do that thats not going to happen. thus its out of scope for this discussion IMO. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
Bèr Kessels wrote:
And then there is a new issue: module specific style. <snip> cold we not move the styles of core contribs to misc/modulename.css ? It would be better at modules/modulename.css i think, so newbie's see it there, not tucked away in misc/
But I think this is an excellent idea, it would slim down drupal.css considerably. -- adrinux (aka Adrian Simmons) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@gmail.com> AOL/Yahoo IM: perlucida, Microsoft: adrian@perlucida.com
On Thursday 19 May 2005 09:39, Adrian Simmons wrote:
It would be better at modules/modulename.css i think, so newbie's see it there, not tucked away in misc/
I concur on this point, almost -- module-specific CSS should be in the same directory as the module itself, typically modules/modulename/modulename.css. I never understood why anyone would put a contributed module's files into one of Drupal core's own directories. Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher
Syscrusher wrote:
I never understood why anyone would put a contributed module's files into one of Drupal core's own directories. We're specifically talking about *core* modules here, not contrib :)
-- adrinux (aka Adrian Simmons) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@gmail.com> AOL/Yahoo IM: perlucida, Microsoft: adrian@perlucida.com
On Thursday 19 May 2005 10:26, Adrian Simmons wrote:
Syscrusher wrote:
I never understood why anyone would put a contributed module's files into one of Drupal core's own directories. We're specifically talking about *core* modules here, not contrib :)
Sorry... The comment in the post to which I replied went off on the contrib tangent, and I let myself get sucked into the subthread. Mea culpa. Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher
Op donderdag 19 mei 2005 16:20, schreef Syscrusher:
I concur on this point, almost -- module-specific CSS should be in the same directory as the module itself, typically modules/modulename/modulename.css.
I know we actually might be best of to have modules live in their directories, but unless someone actually writes a good script to do this in CVS and gets ppl convinced to apply or run that sctipt this not going to happen. thus its out of scope for this discussion. Let us please focus, -again- on drupal.css. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
Bèr Kessels wrote:
I know we actually might be best of to have modules live in their directories, but unless someone actually writes a good script to do this in CVS and gets ppl convinced to apply or run that sctipt this not going to happen.
Something like this should work, from a CSH-ish command line: # go to a checked CVS copy of HEAD and to the modules directory % cd ~/drupal/modules % foreach i (*.module) % set j=`basename $i .module` % mkdir $j % cvs add $j % end % cvs commit . # go to the CVS repository root and the drupal repository therein % cd $CVSROOT/drupal % cd modules # copy module files into new directories % foreach i (*.module,v) % set dir=`basename $i .module,v` % cp $i $dir % end # back to the checked out copy % cd ~/drupal/modules # Remove old files % foreach i (*.module) % rm $i % cvs remove $i % cvs commit $i % end # get the new files and remove the old version tags % cvs update . % foreach i (LIST OF TAGS, e.g. DRUPAL-4-5 DRUPAL-4-4 ...) % cvs tag -d $i . % end * Checking out old revisions works correctly as long as you use '-rTAG' and not '-DDATE' to retrieve revisions. * The log of changes is maintained intact. * The revision numbers are not affected. Disadvantage: you cannot easily see the history of the file across the rename/move. -- Chris Johnson
Bèr Kessels wrote:
Let us please focus, -again- on drupal.css.
OK, here's some quickies having had a brief glance: - remove styles for hr (lines 14-17) The default style (ie none) for <hr> should suffice, the theme itself should style them if needs be. - remove widths on form items? These have always given me grief when cobbling together fixed-width themes. - colours for tr.dark, tr.light (line 34) Colours should be removed... the theme should specify these (see below [1]). - move module specific styles (most of lines 210-503) As already discussed, modules should add their own CSS styles via the <head> tag. See below [2]. ---- [1] Any CSS moved out of drupal.css, but still valuable in a theme (such as tr.light, tr.dark) should be referenced in a 'skeleton' theme CSS file. If these important classes are documented somewhere, theme designers can start with the skeleton template, or at least ensure they have implemented these 'semi-important' classes. ---- [2] On a related note - how 'nice'/efficient/standard would having several <link rel....> tags in our HTML <head> be? A site with 10+ modules enabled would end up with (up to) the same number of stylesheets linked in the header. Would another option be to build a complete stylesheet out of the following constituent parts: 1. the amended, simple drupal.css; 2. the selected theme's css; 3. any module specific styles, somehow retrievable from: - the module itself (via a hook?) - or the [style|$module_name].css file in the module's directory. This dynamic CSS file would have to be heavily cached to avoid the overhead, I suppose. Am I off target? Cheers, Paul -- paul byrne - <paul@leafish.co.uk> web monkey - <http://www.leafish.co.uk/>
Thanks for the nice feedback. Most of your suggestions are already in the patch at http://drupal.org/node/13095 Op donderdag 19 mei 2005 21:34, schreef Paul Byrne:
Colours should be removed... the theme should specify these (see below [1]).
So, who will make such a file?
1. the amended, simple drupal.css; 2. the selected theme's css; 3. any module specific styles, somehow retrievable from: - the module itself (via a hook?) - or the [style|$module_name].css file in the module's directory.
This dynamic CSS file would have to be heavily cached to avoid the overhead, I suppose. Am I off target?
I experimented with this. the main problem is caching. a non-dynamic stylesheet goes into the users cache and sits there fore a long time, reducing your BW. Dynamic CSS either needs unique names, thus on each pageload the user will download a new file (lots of overhead) Or the stylesheet will be dowloaded once, so that lots of clients do not know they actually needed to downloada new (chaged) one on certain pages. As a sidenote: imagine book.module and event module on your site. When looking at /node both need no styles (unless a block is active). the modules can know that, and thus /could/ possibly add CSS more intelligently. i;e bvook.css only on /book/view and /node/view where type == book. But that too, is out of scope for now, IMO. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
Op woensdag 18 mei 2005 23:51, schreef Adrian Simmons:
drupal.css isn't all that crufty and a hell of a lot of it is necessary.
I've pretty much moved camps and am now firmly in Steven's 'we need drupal.css but lets clean it up' camp..
I am in the same camp. Personally i always include drupal.css in my style.css (copy pasting) to have a better overview. But we abolutely need it. but the reason i brought this up again, was not (really) to discuss removal, nor some system to n include it. But to set up some rules about what should be in it and what not. Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
Op 19-mei-2005, om 11:36 heeft Bèr Kessels het volgende geschreven:
Op woensdag 18 mei 2005 23:51, schreef Adrian Simmons:
drupal.css isn't all that crufty and a hell of a lot of it is necessary.
I've pretty much moved camps and am now firmly in Steven's 'we need drupal.css but lets clean it up' camp..
I am in the same camp. Personally i always include drupal.css in my style.css (copy pasting) to have a better overview. But we abolutely need it.
but the reason i brought this up again, was not (really) to discuss removal, nor some system to n include it. But to set up some rules about what should be in it and what not.
Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
If nobody take this, I'll volunteer to have a look at the CSS which is inside drupal.css and remove everthing that is truly not needed.. Please make an issue for this on drupal.org, so we don't forget... Stefan.
Bèr Kessels wrote:
Can we discuss this, **but with the aim to come to an agreement?**
But we should discuss what can be in there and what not! My first idea is, drupal.css must contain * No colours, nor background colours, unless they greatly enhance useability. think of watchdog entries. But not tables, grey tables are nice, but should be styled by the theme; * No borders, paddings or margins, *unless* a page will break without them [1] * No floats, breaks, displays, centres or other things that manipulate the flow, *unless* a page will break without them. [2] * No widths, unless they are really needed to make floated erlements appear on the same line. with:100% is very annoying due to the famous border-box-model.
Good ideas. I completely support the idea of coming up with a minimal, clean drupal.css. -- Chris Johnson
On Wednesday 18 May 2005 12:10, Chris Johnson wrote:
I completely support the idea of coming up with a minimal, clean drupal.css.
I have no strong opinion about whether drupal.css should or should not exist, or what should be in it, with one exception.... Under the category of "clean", could we *PLEASE* get rid of this code: .node-form fieldset { display: inline; } This is the bug (http://drupal.org/node/16729) that causes Konqueror and some versions of Safari to be unable to enter text into node forms for fields that appear inside a "fieldset" tag. I reported it back in February, and it's been confirmed by a number of other people. I really hate to nag, but a bug that wipes out a couple of fairly-popular browsers, and which has a three-line patch, really needs to be fixed. If there is anything else that I can do to help make this happen, someone please tell me, and I will do so right away. I think, though, that this one is out of my hands. Kind regards, Scott -- ------------------------------------------------------------------------------- Scott Courtney Drupal user name: "syscrusher" http://drupal.org/user/9184 scott at 4th dot com Drupal projects: http://drupal.org/project/user/9184 Sandbox: http://cvs.drupal.org/viewcvs/drupal/contributions/sandbox/syscrusher
Syscrusher wrote:
I really hate to nag, but a bug that wipes out a couple of fairly-popular browsers, and which has a three-line patch, really needs to be fixed.
I've uploaded a patch that removes the offending three lines. Hope that helps solve the problem - or at least brings attention to it now that it will show up in the patch queue. andre
Bèr Kessels wrote:
or even more annoying .user-login-block { text-align: center; } Absolutely the most annoying style in the bunch...
I'm with you on cleaning up this style sheet - but it would be nice if there was a list of all the HTML element class and ID names used in core. I know someone was compiling a list of all of these... any word on that front? I'd be more than happy to spend a couple of hours pruning the css. andre
Bèr Kessels wrote:
So, to get to a conclusion; I think we should *not* discuss whether or not drupal.css must be there This is a very sensible approach :)
My first idea is, drupal.css must contain * No colours, nor background colours, unless they greatly enhance useability. Well, black, white and shades of grey are colours too, but certainly keeping the colours neutral would be a good idea, I have grey calendar styles in box_grey theme that might be adapted for the archive calendar...
*unless* a page will break without them. I tried designing a theme without drupal.css and ended up putting most of drupal.css into my theme stylesheet, to a large extent I believe things will break if you just remove most borders, padding, floats etc as you describe.
Certainly there is some cleaning up that could be done but at the end of the day Drupal is a big complicated system and it's going to need big complicated stylesheets to theme it. Everyone agrees drupal.css should be tidied up, I suspect the main reason there has been no progress on this since January is that no one found the time, I know that's been my problem, and remains so. Another point is that drupal.css does not exist in isolation, it's styling xhtml that's output by Drupal, if drupal.css is crufty it probably reflects, in part, on a mish mash of approaches to markup that have evolved as Drupal developed. -- adrinux (aka Adrian Simmons) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@gmail.com> AOL/Yahoo IM: perlucida, Microsoft: adrian@perlucida.com
Everyone agrees drupal.css should be tidied up, I suspect the main reason there has been no progress on this since January is that no one found the time, I know that's been my problem, and remains so.
I'm not sure how much there is left to discuss. For a while now, I think nearly everyone agrees that it would be worthwhile to either simplify or tidy up drupal.css as per the suggestions. It is a matter of submitting patches and discussing them one by one. Then again, I think that is what Ber is actively working on, otherwise, he wouldn't revive this discussion, would he? :) -- Dries Buytaert :: http://www.buytaert.net/
Op donderdag 19 mei 2005 06:27, schreef Dries Buytaert:
again, I think that is what Ber is actively working on, otherwise, he wouldn't revive this discussion, would he? :)
Kindof. i want to isse a 'warning': I took this up, because i needed a clean drupal.css for myself. So I made patches from that, while i cleaned it out, with in my mind teh saying " talk is silver, patches are gold'. But now that *i* have a clean drupal.css I am willing to discuss it but i cannot (just no time) maintain the patch, to make it follow any outcomes of that discussion; in other words: I need help :) issue here: http://drupal.org/node/6829 Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
Bèr Kessels wrote:
* No colours, nor background colours, unless they greatly enhance useability. think of watchdog entries. But not tables, grey tables are nice, but should be styled by the theme; * No borders, paddings or margins, *unless* a page will break without them [1] * No floats, breaks, displays, centres or other things that manipulate the flow, *unless* a page will break without them. [2] * No widths, unless they are really needed to make floated erlements appear on the same line. with:100% is very annoying due to the famous border-box-model.
I was giving this a tiny bit more thought. We should obviously be keeping in mind the fact that a page should degrade gracefully in the absence of any and all style sheets. I am going to do an experiment and try to build the style sheet from the ground up - with a plain vanilla theme (emptier than cleanslate). Only then will we/I really know what is cruft and what NEEDS to be in drupal.css If the site renders in a reasonably accessible and usable way with the bare minimum of styling in drupal.css - we can leave the rest to the theme developers. andre
I obviously have to throw my 8 cents into the mix, since I feel like I've been one of the most consistent advocates of dispensing with drupal.css altogether. In fact, in the rewrites I'm doing of Democratica (renaming to Groundswell I think), SpreadFirefox (renaming as SpreadSpread) and Lincoln's Revenge (same name...), I'm regexing drupal.css out entirely. It may mean that I have to copy over a bunch of styles from drupal.css, but at least I'll know why they're there and who put them there. That said, I think we need in general a more rational approach to styles, classes, IDs, xhtml standards across Drupal. We're at a point now where a lot of work could stand to be done on the quality of XHTML output such that even without a drupal.css file, the system would still be usable and adequately attractive, in Netscape 3 or mobile phone terms. Additionally, I'm running up against severe limitations in available themeable functions and can't do the kind of UI improvements that I feel I should be able to because not enough "themability" has been "bubbled up" to the theme layer. I have some 25 themeable functions in my theme overhaul and I've barely scratched the surface of what I *want* to be able to do. But, to get back to the topic at hand here, we need to think on this topic for just a moment longer and look at why drupal.css is such a pain in the ass and why it continues to be forced on themers. The points raised about usability, to my thinking, don't hold up. Besides the weird floated admin boxes, I don't know where drupal.css makes the standard xhtml UI more "usable", especially if you rip out the module-specific stuff. Additionally and as such, this really comes back to the integrated admin UI issue. Given that, it seems like we ought make drupal.css optional for themers and begin work on the Drupal admin UI theme. It seems like drupal.css should really handle drupal-specific UIs -- the stuff that themers probably don't care to touch, and I posit that those UIs are the ones under the /admin path. We decided to tackle this at DrupalCon and now that the drupal.css discussion has come up again, let's really address the source of the problem: Drupal's admin UI is complex, inconsistent and annoying to theme... It's time to work on that problem and leave theming the front-end to the themers and stop getting in their way. Let the eggs fly. ;) Chris
Op donderdag 19 mei 2005 06:03, schreef Chris Messina:
But, to get back to the topic at hand here, we need to think on this topic for just a moment longer and look at why drupal.css is such a pain in the ass and why it continues to be forced on themers.
Okay. let's indeed focus this discussion on the drupal.css :)
The points raised about usability, to my thinking, don't hold up. Besides the weird floated admin boxes, I don't know where drupal.css makes the standard xhtml UI more "usable", especially if you rip out the module-specific stuff. Additionally and as such, this really comes back to the integrated admin UI issue. Not everywhere. we /do/ need floats for standardbook navigation. And we /do/ need local task tabs to work. etceteras. there are loads of think hat should just work . So let us focus on what should just work, and what not.
Given that, it seems like we ought make drupal.css optional for themers and begin work on the Drupal admin UI theme. Could we raise hand on this never neding discussion and decide, here and now wether or not it should be optional?
I vote for non-optional. -1 on optional.
It seems like drupal.css should really handle drupal-specific UIs -- the stuff that themers probably don't care to touch, and I posit that those UIs are the ones under the /admin path.
Don't care to touch shoul not be the criterium. Don't need to touch should be it, IMO. difference being tha everyone will need indentation on the ULs -for example- in the navigation menu so another ule of thumb i would like to put forward: *if we think we need whitespace in drupal.css it should *alwasy* be 1em and never 1px or 0.85em, or other silly things like that. Do we all agree on *always* using 1em for whitespace? Regards, Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]
Bèr Kessels wrote:
Could we raise hand on this never neding discussion and decide, here and now wether or not it should be optional?
I vote for non-optional. -1 on optional. yes, -1 drupal.css is not optional
Steven has in the past already mentioned the upgrade issue, if we remove drupal.css we end up with a whole bunch of styles duplicated between themes that all have to be upgraded when core changes, major pain. -- adrinux (aka Adrian Simmons) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@gmail.com> AOL/Yahoo IM: perlucida, Microsoft: adrian@perlucida.com
On 5/19/05, Bèr Kessels <berdrupal@tiscali.be> wrote:
so another ule of thumb i would like to put forward:
*if we think we need whitespace in drupal.css it should *alwasy* be 1em and never 1px or 0.85em, or other silly things like that. Do we all agree on *always* using 1em for whitespace?
I don't understand this rule. When you say "whitespace", what do you mean? You mean between paragraphs? Fieldsets? Columns? I guess I don't see how, in leiu of well-planning xhtml, we really need styling of any kind that a theme can't handle on its own. When you mention standard book navigation, that argument falls apart if I theme the theme_book_navigation() function. Why would I want to include inactive styles in that case? Additionally, while I am in general in favor of the idea of putting module styles in modulename/[style|modulename].css, we get enough complaints about the dirth of stylesheets that Drupal throws at you. Breaking everything out into separate sheets is good on the backend, but not on the client side. It seems to me that we need some kind of basic module CSS compiler that grabs all the sheets from the active modules and rolls it into one, which gets sent as modules.css. If I remember correctly, the default install of CivicSpace forces something like 8 stylesheets down the pipe... and as you add modules, that number grows. I'm not saying I know the best way to handle this except that sending a separate sheet for every module is not a viable option. Those are my thoughts for now -- I'm glad to be having this discussion! Chris
Andre Molnar wrote:
a page should degrade gracefully in the absence of any and all style sheets. That's down to the xhtml code though, not drupal.css.
-- adrinux (aka Adrian Simmons) <http://adrinux.perlucida.com> e-mail <mailto:adrinux@gmail.com> AOL/Yahoo IM: perlucida, Microsoft: adrian@perlucida.com
Adrian Simmons wrote:
Andre Molnar wrote:
a page should degrade gracefully in the absence of any and all style sheets.
That's down to the xhtml code though, not drupal.css.
That was the point exactly. Thank you for making it clearer! That said - and I think I'm just re-stating Bèr's point here - some bare minimum amount of styling in drupal.css to handle things like local task menu tabs should exist. The real tasks here: 1) Make sure XHTML is clean and degrades nicely. (For times when there are NO style sheets whatsoever) 2) Add a bare minimum of styling in drupal.css (For times when there are NO style sheets in the selected theme) Sorry, I'm just adding to the noise. I'll shut up now ;-) andre
participants (11)
-
Adrian Simmons -
Andre Molnar -
Bèr Kessels -
Chris Johnson -
Chris Messina -
Dries Buytaert -
K B -
Moshe Weitzman -
Paul Byrne -
Stefan Nagtegaal -
Syscrusher