We have some tables where the column headers have a line break in them. We’ve noticed when this is the case that the row headers are shifted up by a pixel. It’s noticeable because the first row does not have a top border, and the last row the header is off slightly:
I was able to reproduce using a minimal example, with a button that edits the dom to show where the problem element is:
Hi @hank1
Thank you for contacting us. I looked into your example and fixed it in terms of how such modification should be implemented. We recommend using the afterGetColHeader hook to inject the HTML into the column headers. Then you can enable the autoRowSize plugin so the dimensions will be adjusted accordingly.
Here’s the fixed example: Handsontable off by one px (duplicated) - StackBlitz
Thanks Adrian. This works, but now we lost all the html that’s usually around those cells. See the difference between the first and second columns in the updated example:
The header generated by Handsontable has a div and a span with some padding and other styling. We could, of course, reproduce this in the colHeaderHandler, but now we’re reproducing styling/markup that Handsontable would normally generate. This seems like a dangerous approach, what if something changes with how Handsontable creates column headers?
Do you consider this pixel issue a bug that could be fixed upstream? Or are we not meant to be using multi-line headers?
Thanks for your help!
Due to the current architecture of Handsontable we recommend doing such modifications only with the afterGetColHeader hook.
However, I’m not entirely sure what do you mean that you lose all the other styling while doing it this way. Can you please share another example where this can be replicated?
I was using your fixed example - the HTML in the headers for the B/C/D/E columns have different markup than the test column, as seen with the inspector tool in my screenshot.
To make it more clear, look at this example:
Note that the first column, that uses colHeaderHandler, has no padding.
Thank you for the example. That’s right, and we treat it as a feature of this hook, as it allows for custom styling 
You can add the styling back if needed.
In the example you provided the original bug is present again.
You’re right. I checked it deeper and it seems to be a bug. I reported the problem internally and I will let you know as soon as I have more information on the possible fix.
