misc/drupal.css

By moggy on 18 Jan 2005 at 18:52 UTC

Anybody else think this causes more trouble than it's worth?

I've been playing with a new css for box_grey for the last month. At first I couldn't understand why the style sheet for box_grey went into so much detail, so I tried to be more general in my style sheet. Ofcourse that didn't work, certain elements stubbonly refused to be styled. Now I now why.

misc/drupal.css is very detailed meaning any new styles have to be atleast as detailed to override it. It's a pain in the butt and as far as I'm concerned it's completely uneccessary. Drupal shouldn't be providing any style by default, that should be for the themes to provide, otherwise it just becomes an ugly fight between drupal and the theme as to how things are displayed

Comments

Previous discussion points

Steven commented 18 January 2005 at 19:52

Not having any default styles is fine as long as we stick to a simple UI. But if you take a look at some of the more recent UI proposals and mockups, you should realize that none of those are possible without some pretty specific CSS.

I agree that a themer should be able to override that without having to fight the CSS cascade (although it is perfectly possible), but you should also realize that the average person does not want to design a hyperadvances theme from the ground up, but just wants to use his own template with the stock Drupal UI molded in.

For those reasons, we agreed that the best way to solve the drupal.css problem is to move all non-essential styles into the themes, but keep the essential usability styles in. Then, we make drupal.css optional for those who do not wish to use it.

This is the best solution, as this allows many more themers to keep using drupal.css without having to fight it.

Still, the line between "essential" and "non-essential" styles is very fuzzy. Consider for example these rules:

#permissions td.module {
  font-weight: bold;
}
#permissions td.permission {
  padding-left: 2em;
}

These rules affect the look of the permissions table in admin. They're quite specific. But, I'm willing to bet that if you let a typical themer make a Drupal theme without drupal.css, then they'll certainly forget about this particular page, resulting in a theme that makes Drupal harder to use.

There are many other styles like this in drupal.css.

--
If you have a problem, please search before posting a question.

still not entirely convinced.

moggy commented 18 January 2005 at 21:00

while I agree that there are certain essential styles, I think some/a lot in drupal.css is non-essential, at least in 4.5. What may work for themes similar to drupal.org (black on a light colour for example) may not be appropriate for other themes, and I agree tracking down all of those little bits is a pain, even more so when you can't figure out why your styling isn't being accepted.

your example:

#permissions td.module {
font-weight: bold;
}

while I agree that that does make things easier to follow, could/should that not be done using HTML markup instead? The STRONG, BOLD, and ITALIC tags are not depreciated.

It would render as bold if you didn't style it and I could uses a site wide style for Bold tagged text that wouldn't be ignored by #permissions td.module. In addition Lynx, text readers and other 'browsers' that don't read visual style sheets would understand what you want if you used a BOLD tag.

but when

chrisada commented 18 January 2005 at 21:16

But what if I don't want that part to be bold?

Not to say I don't roughly agree with your idea, though. I think a lot of basic elements styling does not belong there. ( p, hr, form, table, th, tr, td, etc.) Same goes for styling that doesn't really affect how the interface works. (like margins and paddings or many elements)

if you don't want it bold in

moggy commented 18 January 2005 at 21:37

if you don't want it bold in your theme you do exactly what you currently have to do. Write a css style to turn off the bold for that specific element.

in that particular case it's actually a heading so thinking about it perhaps TH instead of TD would be better than BOLD, but in any case it was text that needed to be differentiated from the other text around it. DIV CLASS="ImSpecial" would probably work just as well for visual agents, but wouldn't mean a thing for other types.

Don't burn drupal.css

Steven commented 18 January 2005 at 23:02

Well the strong tag could indeed be used, but there is no tag for the indentation that does not have any other semantics loaded on it.

My point was that most people who scream "burn drupal.css" seem to forget that it does have a use and that just copying it into the themes does not address the real issue, which is that drupal.css oversteps its bounds. Removing it altogether will result in themes with bloated stylesheets sharing a bunch of rules between them.

Though it often surprises me how many people forget that there is no such thing as unsetting a CSS value. Removing a rule merely sets it back to whatever the browser and/or specs default to. A good criterium to use for deciding where rules go is see whether or not the average browser already overrides a property itself. In that case we can argue that a theme designer would be overriding the rule anyway if he/she wanted it different, be it set by drupal.css or by the browser's default styles.

--
If you have a problem, please search before posting a question.

bloat

moggy commented 19 January 2005 at 00:17

...Removing it altogether will result in themes with bloated stylesheets sharing a bunch of rules between them...

That I certainly don't agree with!
If I want to change the colour of all the links on my site I have to set a, a:link, a:hover, a:active, a:visited at least 4 times because of drupal.css, instead of just once. There are many other instances where I have to set several items to the same value individually where once would be enough without drupal.css

The problem seems to be that drupal.css sets values for very specific elements. If I want to make a global change I have trackdown all the instances of it in drupal.css and reset them as well.

don't get me wrong, I'm just trying to understand why it exists. From my point of view it's just making things more complicated for theme designers that it could be.

HTML in output

tangent commented 24 January 2005 at 21:46

Using bold or italic tags in output must not be done. These tags may not be deprecated in HTML 4 but they are in modern versions of XHTML so having them in output, regardless if they *could* be overriden, would make sites that use an XHTML doctype invalid.

Markup should be symantic and contain as few "presentation" type tags as possible. Get used to styling with CSS.

Part 1: A compromise on misc/drupal.css

adrinux commented 23 January 2005 at 20:20

From previous discussions on this and other forum threads plus #drupal it seems we can all reach a compromise. We can remove the
to drupal.css that gets inserted by drupal_get_html_head() and move it to the themes.

I had an idea to @import drupal.css at the beginning of each theme's style.css but there are several flaws with that: chameleon links to common.css before style.css (could put it in common.css but then documentation gets messy); theme-styles need a different @import url to themes (again documentation gets messier); the @import would need to be added to every theme or theme style.

So I've gone with the suggestion Steven made to me and added a
in the head of each theme. This will be the same for all themes and be inherited by theme styles, all in all a lot more efficient and easier to document.

You can get the patch here: http://drupal.org/node/13095

Apply it to a fresh checkout of CVS head by dropping it into the Drupal folder and doing:
patch -p0 -u < 20050123-HEAD-optional-drupal.css.patch

Now onto Part 2: cleaning up drupal.css, and talking about my experiences making a theme without it.

adrinux
adrinux@gmail.com

Adrian Simmons
adrinux@anaath.at

I think drupal.css is a good

iraszl commented 23 January 2005 at 00:30

I think drupal.css is a good idea and I don't get why you have a problem with it. You can just edit it or delete anything from it if you don't like it. What's the problem with doing that? You can always go back to a safe copy if you need to.
---
http://creativebits.org

upgrade hassle

adrinux commented 23 January 2005 at 13:51

The problem with that iraszl is that next upgrade drupal.css can get overwritten and you changes are lost. Of course you'll bring it back from a backup or whatever, but it all adds extra hassle.

Second and bigger problem - what about contributed themes?
Suppose I ditch drupal.css entirely and create a nice theme that I want to share with other people on drupal.org, my theme will break if everyone else leaves drupal.css in place. All other themes on their site will break if they remove it like I did...

All of which is moot, since I think the drupal.css-haters and lovers have reached a compromise, work is afoot to clean up drupal.css and make it optional for theme developers.

I'm experimenting myself and will post patches and further discussion here later.

adrinux
adrinux@gmail.com

Adrian Simmons
adrinux@anaath.at

reference material

stevew commented 24 January 2005 at 21:33

Actually, I like drupal.css because it shows how to properly call out the CSS for the various site elements. I don't mind copying out big slabs of it to override (which I had to do for Sunrise, since that was a black background/white text theme). Better to have the reference there and need to override it than to not know how to get what you want at all.

If it does go away, something like it should be distributed as a readme in the themes directory.

Steve
--
http://theme.etmeli.us/ - Drupal themes
http://etmeli.us/ - photos, commentary, occasional sarcasm

reference and a good default

clairem commented 25 January 2005 at 03:48

I rarther agree with stevew -- drupal.css is very good for reference. I'd not like to see it slimmed down too much.

What I would like, though, is for rather more attention to be paid to the situations where it uses overly-general rules because they work in some implementations.

In this category, one of my bugbears is the layout for the book navigation links links in book.module.

They use div.links, whereas .links is otherwise used in a very different context, viz the links at the bottom of the article to "printer-friendly version" etc. There is no need to use div.links in book.nav -- the book navigation elements can be set quite straightforwardly by .book .nav. Frustratingly, the default use of .links makes no difference to them: it's only when you style .links that you then have to make lots of parallel changes in .book. nav

I haven't hunted down all uses of .links, but it does strike me as being a frustratingly widely-used class, often to little benefit.

(The book navigation of function book_navigation() is generally very messy, and breaks very easily, but that's another day's work!)

File an issue

tangent commented 25 January 2005 at 04:33

File an issue for this if you think it could be improved. Simply mentioning something on the forum doesn't necessarily mean anything will change.

Base styles in drupal.css is essential

tangent commented 24 January 2005 at 21:59

Having a base set of styles in drupal.css is essential.

1. Every release of drupal may include new elements. These elements would likely have to be restyled by *every* theme if there were no base styles which would mean that in the real world many themes will look broken after an upgrade.

2. Custom themes that are similar to one of the default themes do not need to concern themselves with knowing about every element that exists and, therefore, require less styles. It is only themes that are dramatically different (dark background color necessitating light text colors) that need to override many of the base styles.

Overriding a cascading style may seem like a pain if you're new to CSS but it is actually quite flexible and powerful. Learn to use it to your advantage.

some pains...

Dextro commented 5 February 2005 at 19:40

I agree with that completely. A basic css set is essential.

But css is a part of a theme. xhtml and css are developed to completely seperate the content from the look. And that's just the way drupal should follow. So drupal.css shouldn't be in en directory 'misc', but it should be in every theme in a directory 'css' and imported in the file 'style.css' with: @import url("css/drupal.css");

1. So, as part of an upgrade, you just have to update this drupal.css in every theme. I think that's not a big problem.

2. with the tactic above, that's also something that's solved.

why override something that isn't just necessary? It just makes the code larger. Drupal is wel coded, but that's a part who just doesn't make sense in my eyes (and apparently in other eyes here too).

colors in drupal.css

thegreenman commented 18 September 2005 at 20:24

I think all color assignations,font decorations, text, and link stylings should take place in style.css exclusively.

I also think drupal.ss should handle only block sizing/spacing/layout styles and leave EVERYTHING else to the theme style.

It's just a plain cluster-fark when you have last-tier styles in a core style document.

I agree

freyquency commented 19 September 2005 at 14:34

It's profoundly useful to have the important structure design in a separate file, one that shouldn't be edited. There is the same inherent overwrite problem but it can speed up the development of site designs to have the bones in place. The other stuff in the file is just torture.

viewer accessibility options via stylesheet switch ?

JohnG-1 commented 13 October 2005 at 14:53

I saw a very nice javascript style-sheet switcher (and cookie setter) used to add 'accessiblty controls' to a website's formatting. (I can't find the link now!)

basically, it used several 'specialised' stylesheets:

layout&positioning
textsize_n
fontstyle_T
backgroundcolour_n
text colour_n

the idea was you could change the font size by clicking a fontsize + or - button, and it would switch the style sheet from say textsize_3.css to textsize_4.css

Similarly, you could change the contrast between background and text by changing their colours.

apparently some people find serif fonts easier to read, and some prefer non-serif, so this option was included. it also had an 'all capitals' toggle for making all text uppercase, for the same reason though I can't see that one at all!

etc

a user's preferences were set in a cookie.

Now I think that kind of UI feature is extremely worthwhile, and the stylesheet structure really lends itself to simple styling for css newbies. I was toying with the idea of creating a suite of themes for drupal that the user would select on their my account/settings/edit page, but that seems like over kill.

If we are considering alternative systems for drupal's stylesheet handling, I would really like to see something like this incorporated.

I can help with the css and accessibility research. Anyone else interested?

I'm under the firm opinion

freyquency commented 25 January 2005 at 07:20

I'm under the firm opinion that drupal.css is counter-intuitive. If we were talking about a style here and a style there it would be reasonable to assume that the theme developer could overwrite it. But essentially it's impossible to remember which styles are specified already.

Since I realized what was causing design pains I began including all of the drupal.css in any stylesheet I created. This helps - at least they are all in one place. But this leads to confusion as well - the stylesheet gets pretty unmanageable when being designed; editing at a later date is even more of a headache.

So i'm for a reduced drupal.css file that takes into consideration just basic formatting, really minimal. For example - tabs are really pretty but why not let themes do the formatting and present them as what they are, a list? It should be left to the theme to control the css. Whichever theme is default has the responsibility of getting more formatting in there, especially for the newbies. Hopefully themes will be easier to develop and thus more themes would have the lesser, but still important declarations as well as great styles to call their own.

As for figuring out what can be controlled via css... why not have a documentation site ala' http://drupaldocs.org - specifically class and id output. I know that when it gets to engines and some themes this would be difficult but there are a lot of things that could be cleared up. Or if that is not a great idea even just a page in the documentation that lists common tags would be awesome.

Firefox and DOM Inspector

tangent commented 25 January 2005 at 09:40

You must not have discovered DOM Inspector yet. It is an optional (or does it install by default...don't remember) component of Firefox accessible in the tools menu and it allows you to browse the structure of a webpage and identify the ids and classes which any element has. Anyone who is concerned about the lack of documentation or difficulty of styling Drupal is obviously not using this powerful tool.

it's not a part of debian's

freyquency commented 25 January 2005 at 17:50

it's not a part of debian's mozilla-firefox package, so i missed out. thanks for the heads up! this will make page design a breeze!

I'd still like to see some more documentation of classes and id's go into drupals documentation, or as a sister site for theming. I don't think it would be right to rely on a plugin for a browser to help out all alone. What's an opera user to do?

Style and ID prefixes?

clairem commented 26 January 2005 at 13:31

Chromatic, I really like your idea of documenting where all the styles and classes are used. Not only would it be a useful list for theme developers, I think that it would also reveal any illogicalities in their use.

I'm so taken with the idea that I'm willing to share the work, so I have started a new thread on it: Proposal: documenting Drupal's ID's and classes

Yours comment that "essentially it's impossible to remember which styles are specified already" also got me thinking.

When I mark up my themes, I give all my IDs and classes a unique prefix, so that when I read my CSS I can easily distinguish my IDs and classes from Drupal's, and I eliminate the possibility of inadvertently using a name which is already in use. For example, the theme which I am currently working on has div#xpgheader, div#xpgbody, div#xpgsidebar, div#xpgmaincol, div#xpgmaininner etc

Would it be a good idea for Drupal's classes and ID's to have a unique prefix, so that they are readily distinguishable? So if "dp" was used as the prefix", then div.comment would become div.dpcomment.

Or is it too big a step to breaking all existing themes? (Even if easily fixed)

I think it depends on what

freyquency commented 2 February 2005 at 16:31

I think it depends on what the purpose of the theme is for. If it were a theme that others would be modifying it could be confusing, ie - chameleon; in a theme that's already customized, like themes based on engines, it wouldn't be as much of an issue. I think it's also a good idea to do it in the theme if one were going to customize it rather than in the engine, which should remain unedited.

It's kind of a strange crossover period with the newly implemented engines/themes delineation, because it pushes themes into the realm of 'skins', which is cool. It's more in line of what I think end users think of a theme being. Wordpress themes are more meant for end user consumption, where the old drupal theming system is more of something to start out with and make your own. In documenting 'theme' classes and id's really we should be looking over engines more, as they provide the basis, then any themes with customized templates based on engines, then themes that are standalone and haven't been ported to engine templates yet (if they ever will be).

[]+][+][+[]
erik mallinson
http://coacalina.org

drupal.css RTL support

druvision commented 27 March 2005 at 20:02

I am translating the drupal interface to Hebrew. Hebrew is one of the RTL languages, where the text flows from right to left. Hence, I had to make TONS of changes to drupal.css - I have to make it left wheneve it's right, and right whenvever it's left.

For good RTL support, Drupal.css must be parametrized, or go away, otherwise I wouldn't be able to create an RTL theme. I think that a parametrized drupal.css is a better solution, and I will try to generalize it when time permits.

Amnon
-
Amnon Levav
http://www.levavie.com
http://www.hitech-dolphin.com
http://www.small-business-web-hosting-strategies.com

Just admin ?

warrenonline commented 10 October 2005 at 05:47

Is it possible to have drupal.css just apply to the admin pages ? I dont' care much about what happens back there, but I do want full control of the front end without a lot of trouble....

Warren
http://www.warrenonline.ca

stylesheet.inc ?

JohnG-1 commented 10 October 2005 at 12:58

I've just begun messing around with phptemplate theming, and I'm still getting my head round which styles are coming from where!

I was delighted, on a recent bug-hunt, to find that 'view' pages and 'edit' pages are distinguished (albeit a couple of blocks down the hierarchy) by id="node" and id="node-form" respectively.

A quick glance revealed no such useful wrapper for admin page.

Separate css files: I can see times when this would be an advantage and situations when not. Sometimes you want to control everything from a single css, to get it to cascade nicely, others you want to break things up to make them manageable.

How about a stylesheet.inc file for each theme?, then themers can easily organise their stylesheets how they want them, and control how they are loaded into the page headers.

but then I hadn't seen this : link

JohnG-1 commented 10 October 2005 at 18:41

How to generate class/id attributes for each page
http://drupal.org/node/32077

If you don't like the styles

tangent commented 13 October 2005 at 01:33

If you don't like the styles defined in misc/drupal.css then simply paste the contents (and modify to your taste) into your theme style.css and delete drupal.css. Problem solved.

I continue to support system styles because that's what "cascading" stylesheets are all about. However, I'm starting to think it might be better for modules to have their own stylesheets. Modules which are not enabled have no need to have their styles in the global stylesheet.

its easy to unload drupal.css

micha_1977 commented 10 October 2005 at 11:54

its easy to unload drupal.css (see handbook) and i really like the default style for admin pages

i think drupal should keep drupal.css and every theme designer who does not like it, well simply remove it :-)

for me the problem is not the .css but some functions one cant override within the template.php, because there are not "theme_" like, but thats another matter

-micha
work in progress with Drupal 4.6: langmi.de

If most people are like me,

freyquency commented 13 October 2005 at 02:09

If most people are like me, they don't know that drupal.css exists until after some hairpulling. After a while it gets to be something that is manageable, but that's after getting rid of it or overwriting everything.

I think drupal.css should limit itself to the very basics, mainly column structure.

you mean like agreebee ?

JohnG-1 commented 13 October 2005 at 14:30

would you use something like agreebee as a default theme for drupal?

It's like a blank canvas. IMO too unfriendly for newbies!

It certainly needs page layout (columns, blocks, etc) and should use css positioning (which can be tricky) but you could have readymade layout scripts that you cut & paste into the style.css... or better still, a layout.css ...?