CiviCRM Community Forums (archive)

I've just upgraded a Drupal 6 site to CiviCRM 4.3.2, and spotted a problem with the display of contact names when viewing a contact record. The default CSS is:
#crm-container div.crm-summary-contactname-block {
    margin-top: -10px;
    padding-bottom: 8px;
}Removing 'margin-top: -10px;' solved it for me. So I thought about how best to implement this change to the CSS. I've not often had much need to alter CiviCRM's default CSS, and as I'd just upgraded I thought I'd check the documentation, which appeared to offer very little information (maybe I missed something).

There is an option to set a URL to a custom CSS file, and I'm sure that in the past I've just copied the whole of civicrm.css to a new location outside of the codebase (to avoid being overwritten during upgrades), implemented my tweaks in that file, and set the URL to point to this custom CSS file, which CiviCRM then uses instead of the default. Only it doesn't work (in 4.3.2 at least), because civicrm.css includes relative references to external image files, so all those get broken.

I see that CiviCRM also offers an extras.css file that we can use to implement any additional styling, but I'm unclear as to whether styles implemented in extras.css override rules in civicrm.css or not, and in any case as extras.css is located within the upgradeable codebase, it is likely that this file will get overwritten when an update is done, so that's not ideal either.

So I fall back to implementing my custom styling as part of my Drupal theme, knowing that as this is stored within my sites directory I've got a much better chance of not overwriting it.

I would be keen to learn what's considered best practice in terms of customising CiviCRM's CSS, and what approaches other people take. And if someone can clarify when and how to use CiviCRM's custom CSS URL and the precedence of extras.css that would be helpful. I'll aim to update the documentation in light of what is learned.

Thanks
Graham

Thanks Coleman

I would agree that using an h1 would seem more logical and make some more sense semantically.

I think the concept of extras.css is sound, i.e providing a central location, independent of the CMS, in which to store modifications to the core CiviCRM CSS (if indeed that's what extras.css does), is a good idea. The downside of the current extras.css set up is that it's location makes it easily overwriteable, and it's not clear whether rules placed in extras.css override the core civicrm.css

I think the latest version of CiviCRM has changes to the CSS set-up in line with the discussion in this thread. Worth looking into if you've not already done so, as it may address your issue.