This seems to be a repeated problem, at least with Vaadin 7, so I am hoping someone has solved it. It seems in Chromium based browsers, the heading cans be off with respect to the data. It seems to work fine rather consistently with IE. Since Edge is now Chromium based, it seems to have stopped working. See below for an example:
![bad column header alignment]
(https://i.stack.imgur.com/M1crF.png)
So has anyone actually solved this? There is an older post out there on this topic, but it really does not have a clear solution, and it is really old, so thought I would rephrase the problem and see if it gives anyone any ideas.
Sorry to keep asking, but I am shocked no one has had this problem. Can someone at least confirm they don’t have this issue in Chromium based browsers for Vaadin 7 applications? Maybe point me to an example application that works perfectly in this regard. Any help would be appreciated. We have been dealing with it for years, but it finally hit a breaking point, and we really need to solve it. Thanks.
Is there a better way or place to ask this question? I see many examples of it online, but I don’t see a single solution that makes any sense or works in my case. Even a better explanation as to why it is happening would help. Thanks.
The only really usable suggestion that comes to mind is that you should try to switch to Grid instead of Table. Otherwise you’ll need to start debugging Table’s client-side internals and that’s not going to be easy.
Thanks. I just noticed something interesting. I have one table the behaves perfectly, but then, on the same view, I have a second table where it is off. What is super interesting is that the “header” and “data” columns have the same width in HTML, but look different from perspective of the browser ( Brave browser, so Chromium based ). Any ideas what would cause that?
https://stackoverflow.com/a/14857179/3329922 seems to suggest that TD width is ignored in some cases. Why it is ignored in one table and not the other is interesting, but researching now.
Since the Table component ends up being two <table>s (don’t know why, maybe GWT issue, or legacy issue), does anyone have a way to sync the two tables? There are lots of good ideas out there using jQuery, etc, but so far, all of them assume you mean all the tables on a page, which is definitely not what I want.
If I could sync them, or even treat them as one <table>, that would solve my problem, I think.
Grid just has one <table>, which is why it works consistently. Sadly, it would require many code changes to change the my Tables to Grids. I probably have 10-20 tables.
Ok, found the problem, but don’t know how to fix it. For some situations, where things look perfect, the width of the header table is the exact same as the data table class="v-table-table". But where the mismatch occurs, the table widths do NOT match. If I cheat and make them match in the browser, everything lines up perfectly. So why do the widths of the “header” and “data” tables not match and how can I make them match?
Yet more information. Below are two examples in the Brave browser. One is running with test data, that matches real data precisely, on my development machine using jetty. The other is on a CentOS machine running tomcat. For some reason the width of the header table is calculated different between the two. This is, for all intents and purposes, the same application, the same CSS, the same data, same browser. So why are the calculated widths different? More importantly, how can I ensure that the “header” table is the same width as the “data” table?
This issue is a well known thing in Vaadin 7, and there are some tickets about it in the issue tracker, for example these ones https://github.com/vaadin/framework/issues/3144 , https://github.com/vaadin/framework/issues/7571. There was multiple attempts to fix the problem, but no satisfactory way was found within Table architecture. This and couple of other issues were behind the decision to create a completely new component to replace Table, which would have different DOM architecture, hence came the Grid. So our way to fix the problem is still the same, it is the Grid. Unfortunately that is not a drop in replacement component, partly because something totally different was needed to overcome the limitations of Table DOM and some other architectural issues.
