Breaking up – a short workaround on Salesforce tables to remain scrollable

What can you do when Salesforce tables are supposed to remain scrollable while being included to an SFDC Object’s page layout?

Some of you might already have experienced the work with Visualforce pages within the Salesforce (SFDC) universe. As great as those built-in technologies are, customizing them to match your customer’s needs can turn into a fun (and sometimes not so fun) challenge.

Please imagine that you have built up a Visualforce page which has a swift and easy purpose: gather information, display it in a table. The customer wants that page to be displayed not as a standalone page, but within the page layout.

Here is a simple table, displayed in the page layout of the Account object, filled with dummy data:


Breaking Up - 1

What looks easy to access and neat to view at first glance bears a problem if there are too many entries within the table.


Imagine more entries:

Breaking Up - 2

If the table we have just created goes beyond the height that is set for the page section in the page layout, the table has to be scrolled down to view further entries.

SFDC does offer you the possibility of enabling scrollbars via page layout, which sounds great – but it includes the following problem:

If you do use the built-in scrollbars from SFDC, you will see that the table head is not at a fix position, but slides down together with the body of the table.

It basically disappears in the depth of your browser window, making it hard for the customer to orientate himself when using the table. That behaviour is perfectly normal for such an occasion but for us, it causes a problem:

The more columns exist, the harder it will be for the customer to get a clear view of the required data without having to scroll back up to the table head one or even two times.

The following screenshot shows another table with more columns added to visualize the problem:

Breaking Up - 3

In the above screenshot, I have already scrolled down the table.

You cannot see what kind of information is displayed in a column, what informationen is pending and so on. You might have a guess (“Bob” might be a First Name, d’oh!) but I assure you that even in not-empty columns, you won’t always be able to identify via the table’s cell’s context what information is contained within.

The obvious way to deal with that problem is to pin the table’s header row in a fix, immovable position of the screen to greatly increase usability and efficiency. That way, your customers can scroll down as much as they ever want to – the table head will always be there to help keep track of each column’s information. But what you want to accomplish is the table head staying in the visible area, so you can easily scroll through the table entries.


The first step to our solution is disabling the built-in SFDC scrollbars.

That is simply because those scrollbars will always scroll the whole Visualforce page that contains our table instead of just the table that we have created. If we want the table head only to be fixed, we need to address the data table properly with our CSS/JavaScript.

That said, it becomes very clear that the SFDC scrollbars do not suit our needs.

Disable them via the page layout:

Breaking Up - 4

As we have just deleted any possibility to scroll the Visualforce page as a whole, we have to provide scrollbars to our data table manually. Time to get into code:

We do that by simply wrapping a <div> tag around the visualforce table tags and add a piece of CSS to it: “overflow:scroll”, among a fixed height. That height value must equal or be lower than the height value that you chose in the “Visualforce Page Properties”, as you can see in the screenshot above.

That step will cause the table to provide a custom scrollbar (mind the difference: when you scroll, you will not scroll the whole embedded Visualforce page, as you would do if you would be using the SFDC scrollbars, but the table only).

Now we do have the scrollbars set and provided a frame to our next working steps.

Sadly, what appears to be the easiest way simply does not work: giving a ‘position:fixed’ to the <th> tags. You will run into the following problem if you do this:

Breaking Up - 5

Adding the very same CSS to the  <thead> produces a similar result. This is because a position:fixed rule destroys the relation of the <th> cells to the remaining <td> cells within the table. Because of that, their dynamically (and automatically) calculated width gets lost.

This is the point where we stop using Visualforce tags and CSS only and start adding jQuery.

Before we start coding, we need to know exactly what we are doing. We do not want to break the tables any further! These are the steps to follow:


  1. For each <th> cell we will gather the width of the corresponding <td> cell and store it into a variable.
  2. Then, we will add those freshly acquainted width values to the corresponding <th> cells, using jQuery to apply the value as an inline CSS attribute.
  3. Finally, pin the head’s cell on the screen so it won’t move anymore using the position:fix rule.

Here is the snippet which pretty much translates our steps into jQuery:




Using this snippet will (after proper adaption to your CSS classes of course) ensure a great user experience for anyone working with tables that are bound in on Salesforce Object’s page layouts.

We hope it helped!

The following two tabs change content below.

Lukas Heinen

Lukas is a Junior Developer at Aptly. Since he's a qualified IT specialist, his blogposts broach the issue of everday as well as special challenges and experiences, which evolve from the usage of webbased cloud-technologies like Salesforce.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.