[SalesForce] How to ignore Salesforce CSS on VF Page (with header)

I've been working on a Visualforce page using remoting, and am trying out building a custom UI to go along with it (not using any VF tags for the UI). While I'm aware that you can leverage standardStylesheets=false if you turn off the header to get rid of all the Salesforce CSS, I am curious how to leverage the Salesforce header but ignore the Salesforce CSS in my VF implementation. I'm hoping to maintain the header to give the illusion that my page fits into the desktop application and can be navigated to/from.

I noticed that if I use the apex:stylesheet tag, it gets loaded ahead of the Salesforce CSS includes when I look at it in the markup, so the Salesforce CSS is overriding anything I set (for instance, the h1 tag) unless I declare it inline.

I assume one way that you could handle this is making your implementation page have no header, and then have a wrapper VF page that has the header and pulls in your main VF page via an iframe, but that opens another can of worms around navigation. Is there a best practice on how to handle this?

Best Answer

You won't be able to ignore the Salesforce CSS as it will be loaded by the browser and thus used whenever there is a class that matches the name.

You don't need to use an <apex:stylesheet /> tag to include a stylesheet in your page, you can just use a regular tag. This isn't supported by the specification, but browsers will accept it.

You could also put the styles directly in the page, which again isn't supported by the specification but the browser will accept it, or use the HTML5 scope attribute on a mid-document style. You do lose the benefits of CSS this way though, as the styles are in the page and thus not cached or reusable. It looks like browser support is pretty patchy for this too.

Adding !important to your styles is a potential way to ensure that your styles have precedence over the Salesforce styles regardless of order, but there are a couple of downsides:

This tag was introduced as an accessibility feature to allow users with particular needs (e.g. large fonts due to impaired vision or different colour combinations due to colour blindness) to apply their preferred styles to a page, so your important styles could well break the page for them.
Its more difficult for someone to customise the style on your page - for example, they add a style class to the page but it has no effect because somewhere in a stylesheet the important tag has been used and that takes precedence.

The way I tend to approach this though is to use JavaScript to append my tag to the existing ones, typically through the jQuery method outlined in the answer to this question:

https://stackoverflow.com/questions/12093509/jquery-add-css-to-head

Related Solutions

[SalesForce] way to use custom CSS with the Customer Portal in a reliable and maintainable way

Yes, they provide some limited advice which you've probably seen :-)

No, there are no guarantees they won't turn on a better UI.

But the portal does look like dogs' balls, so here are some tips:

utilize the JavaScript UserContext.siteUrlPrefix in the header document to resolve the correct relative path to the CSS resource like this:

<script type="text/javascript">
document.write(
    "<link " +
        "href='" + UserContext.siteUrlPrefix + "/resource/portalCss'" +
        "rel='stylesheet' " +
        "type='text/css' " +
    "/>"
);
</script>

if significant changes are needed, there are a couple of ways to get a clean canvas. A very high specificity CSS reset can be used, or it is possible to dynamically remove the existing stylesheets with JavaScript.
```
[I can email you a portal-specific example of a high specificity reset.]
```

study the underlying markup to reverse engineer which structures belong to which components (you'll be able to grok pageBlockSections, pageBlockButtons, etc)

table#bodyTable td#sidebarCell {
    /* the left bit  */
}

table#bodyTable td#bodyCell {
    /* the right bit */
}

table#bodyTable td#sidebarCell div.sidebarModule {
    /* narrow home page components  */
}

table#bodyTable td#bodyCell div.bPageBlock {
    /* wide home page components and page blocks */
}

because the customization mechanism is the insertion of a Document (!) in the header, one may prefer using @import in the CSS rather than the standard <link />s in the Document; this offers future developers 'principle of least astonishment' so they need only modify the CSS resources, not the injected Document

like any CSS files, the URLs of the javascript will also differ depending on whether the Portal is bound to a Site or not (and again if one uses [Login As Portal User] from the CRM). Using a script loader will prevent having to change the Document, and from clobbering all paths with UserContext.siteUrlPrefix. Here's an example:

var
    scripts = document.getElementsByTagName('script'),
    source = scripts[scripts.length-1].src.split('?')[0],
    url = source.split('/').slice(0, -1).join('/')+'/',
    load = function(file) {document.write(
        "<script type='text/javascript' src='" + url + file + "'></script>"
    );}
;

load('jquery.js');
load('jquery.cookie.js');
load('tab_home.js');
load('tab_solutions.js');
load('tab_cases.js');
load('tab_ideas.js');

LaceySnr is right about it being risky if they roll out a new theme. One runs the same risk when styling any Visualforce. Just consider a fallback strategy in the face of changes to the underlying markup. If the new theme is an improvement, that strategy might be to simply turn off any customizations.

But there are two extremes. At one end, foist the out of the box implementation on customers at the expense of their experience. At the other, attempt to reinvent it all at the expense of not leveraging the platform offering.

It depends on the situation. "I need a visually acceptable customer portal solution in the next couple days" versus "the wireframe says it has to look exactly like this, be 100% future proof and my budget is unlimited". There's a Pareto principle middle ground.

Portal is pretty yukky for the guy doing the CSS, but it can be a quick win if you know the gotchas.

portal home create case

[SalesForce] Overriding Salesforce CSS with custom CSS

If you want to override one sytle sheet over another you can use !important as shown below



    body { background-color: #F3F3EC !important; }

To change the entire look and feel of the standard salesforce page you can use jquery for that and to know which style element they use you can use firebug for Mozilla Firefox or by pressing F12 in Google Chrome.

Best Answer

Related Solutions

[SalesForce] way to use custom CSS with the Customer Portal in a reliable and maintainable way

[SalesForce] Overriding Salesforce CSS with custom CSS

Related Topic