Fixed Header for Table Chart not working?

[Sean Larson]

Hello,

I recently noticed that my headers are behaving very strangely. When first rendered they are at the top of the chart but when I scroll the headers are also scrolling. 

But if I wait a few seconds and click the table, the headers pop back to the top of the div. If I scroll up, I then get a very ugly header in the middle of my screen. 

Did something change? Is this only with dashboards?

[Sean Larson]

It also seems that performance while scrolling has been impacted, causing the browser to stutter and slow down.

[Sean Larson]

I got the old functionality back by adding a google OnReady event to the chart, and using jquery to find the "table" tag via the google class name, to add the "position:absolute" attriubte

                google.visualization.events.addListener(myTable, 'ready', function () {
                    var x = document.getElementsByClassName("google-visualization-table-table")[0];
                    x.style.position = "absolute";
                });

There does seem to still be a performance hit as google is injecting some script to change the "top" style of every "th" tag in "thead" dynamically as the user scrolls. I am not sure this is necessary when using the absolute tag. Since the engine is using thead and tbody, there is the possibility of using these tags to achieve a fixed header, but it is not implemented this way?

[Daniel LaLiberte]

Nothing has changed in Google Charts, so the difference you are seeing might be due to some other change, such as your browser or other libraries on the page.

Can you point to a page demonstrating the problem you are seeing?  Which browser (and version) are you using? 

--
You received this message because you are subscribed to the Google Groups "Google Visualization API" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-visualizati...@googlegroups.com.
To post to this group, send email to google-visua...@googlegroups.com.
Visit this group at https://groups.google.com/group/google-visualization-api.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-visualization-api/5a3c2270-08dc-429c-868d-7f06477c64eb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Daniel LaLiberte

dlaliberte@Google.com   5CC, Cambridge MA

[Sean Larson]

I wasn't sure anything had changed or perhaps I had never noticed the issue. I will try to get a replica running and post a link / version info

[Sean Larson]

OK. I recreated what I could on codepen, but could not replicate the problem. Will keep trying.

However, I did some more digging using the developer tools in Chrome and a scroll event listener from the "gstatic" package was modifying the "top" attribute. 

https://www.gstatic.com/charts/45.2/js/jsapi_compiled_default_module.js:2882, though it does not look very suspicious and I am not sure why this piece is not suspect in my recreation.

[Sean Larson]

OK found the issue. Below is a snippet of my page. It appears giving a height to any of the divs in the snippet below will cause the API to try to implement a type of "fixed" header.

Example of bad behavior: https://codepen.io/industrepreneur/pen/ELZdvQ

Without height: https://codepen.io/industrepreneur/pen/RyKEwg

The fix I posted goes around this implementation, but it seems how the current feature is built causes some performance issues?

<div class="" id="data-content" style="width:1000px; max-height:100px; overflow-y:auto;">
  <div id="filter"></div>
  <div id="dvTable" class="" style="height: 100%; width: 100%; max-height: 100%;">


    <div id="dvMyTable" class="" style="width: 100%; height: 100%; max-height: 100%;">
    </div>
  </div>
</div>

div#data-content {
    max-height: 85vh;
    width: 100%;
    height: 85vh;
    z-index: -1;
    overflow: hidden;
    position: absolute;
}

[Daniel LaLiberte]

Removing your cssClassNames, the Table works as expected.   Specifically, when there is a fixed height that is less than the height required to show all rows without scrolling, then the fixed header row feature kicks in.  

At this point I would have to say the problem is an incompatibility between your CSS and what the Table requires.  It may be that the customizations you want can not be supported now, but of course it is not that any CSS at all should work regardless.   So I would start by asking what customization do you actually want, and then we can investigate how best to implement that.

--
You received this message because you are subscribed to the Google Groups "Google Visualization API" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-visualizati...@googlegroups.com.
To post to this group, send email to google-visua...@googlegroups.com.
Visit this group at https://groups.google.com/group/google-visualization-api.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-visualization-api/b25e42e8-9521-4ad1-bde3-c7cb29558785%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Sean Larson]

I agree and understand this is a desirable feature. After understanding how this feature is triggered, I think my issue is how it performs versus what the expectation of performance is of a fixed header. I am more concerned about other developers running into this than I am my own use.

1. If I give my container a "max-height" attribute without a height attribute, this will not trigger the fixed header feature but will trigger the overflow-y attribute if needed. In this use-case a fixed header would still be needed. Because of this, it is odd that the "height" attribute is used as a trigger as it does not describe the only time a fixed header would be appropriate.
   
2. The implementation may slow down the browser. Events like onScroll or onResize fire many, many events and I imagine this problems gets worse with the number of columns you have. Pure CSS would not impact browser performance
3. The current solution does not behave exactly like a fixed header. You can scroll down and eventually the header will appear. You can scroll up, and the header has not moved yet. I am not sure if this is just my machine or my implementation or if everyone has this issue. here is an example  

If I may suggest,

1. The fixed header should be parameterized such that the developer has to take action to implement it. I understand the purpose of automating the feature but as the API cannot determine all instances when a fixed header would be desirable the automation can make it confusing to debug why the HTML/CSS/JS is behaving in a way the developer did not intend/predict
2. Implement a pure CSS solution over script. See this gif which is using google charts here

sorry about the gif quality, couldnt get access to giphy...

[Daniel LaLiberte]

I'm not seeing any delay on Chrome, and when I tested this manually a couple years ago, there was no significant delay on the other major browsers.   Which browser and platform are you using?

The update after scrolling is done after a small timeout to allow you to drag the scrollbar without forcing an update after each small change.  The update involves a small number of style changes that is proportional to the number of frozen rows (just 1) and frozen columns (could be any number).  

--

You received this message because you are subscribed to the Google Groups "Google Visualization API" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-visualizati...@googlegroups.com.
To post to this group, send email to google-visua...@googlegroups.com.
Visit this group at https://groups.google.com/group/google-visualization-api.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-visualization-api/6bf880b0-7c6f-404c-a3c6-f1c535176f4d%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Daniel LaLiberte]

I'm not sure about the 'height' vs 'max-height' styles in the container element.  I recall wrestling quite a bit with styles until I found a combination that works while using only one table (rather than 2 or 4) to implement the frozen headers and columns, so I am not inclined to mess with it at this time.

Parameterizing the fixed header feature rather than making it automatic might be a reasonable choice (for the future).  Perhaps a pure CSS solution is possible now in modern browsers, but we will probably have difficulties with some of the older browsers which we try to continue to support as long as feasible.

Perhaps you can get what you want by wrapping your table container with another div where you specify the max-height.

[Sean Larson]

It is not such a simple feature when you start considering older browsers! I will ask my dev partner if he sees the delay as well. I am debugging in Chrome 65.0.3325.181 and loading the 'current' API

I have my fix in place listed in the first few posts, I just wanted to pursue this to see if there was a better approach out there. 

I cleared all the CSS in my codepen and the movement seems more responsive but It still lags. Do you see it https://codepen.io/industrepreneur/pen/ELZdvQ

Unfortunately, the HTML "table" tag is annoyingly limiting because thead/tbody/tfooter only accept certain styles. And using multiple tables forces you to use the forced layout. In most implementations i have reverted to parsing my own tables with divs and abandoning the table all together. I wonder if CSS grid could be used to build a good table...

[Daniel LaLiberte]

Glad you got the fix you need.  One good thing about HTML and CSS is that there is probably a way to do what you want, if you can only find it.

I do see the codepen you linked to without any lag in scrolling either by dragging the thumb or clicking the up and down arrows or outside the thumb.  There is a small animation/transition effect when scrolling, and perhaps that is contributing to the lag you see.

The table element has the main advantage of doing automatic proportional sizing of cells based on content, while forcing 2D alignment of rows and columns.  It has been difficult to implement the equivalent without table layout and styles, but perhaps CSS has matured enough to do that now.

--
You received this message because you are subscribed to the Google Groups "Google Visualization API" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-visualizati...@googlegroups.com.
To post to this group, send email to google-visua...@googlegroups.com.
Visit this group at https://groups.google.com/group/google-visualization-api.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-visualization-api/b552ae5b-2cfa-445b-a68a-124381a0c21c%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Sean Larson]

I had some colleagues try the codepen and they also report no lag, just the minor stutter. I have no clue why I am getting such terrible lag 

The last time I ran into an issue like this, it was because I am using a Microsoft Surface. The screen is so small with such a high resolution that Microsoft implemented a "scaling" feature which I have seen cause some really strange behavior. I will try connecting a monitor to see if that is the case...

Anyways...cheers!

[Sean Larson]

Well, all of this was due to the Microsoft high-DPI scaling on my Microsoft Surface. If I load that codepen into an external 1080p monitor it behaves perfectly! If I move it over to my Surface it behaves very strangely!

As always, thank you for your continued support and discussion  on this issue.