Weird table-layout:fixed; "bug" on WebKit.

Question

I'm building grid component for my own needs with sortable columns, rows, etc. Existing ones either were not suiting my needs or were too heavy. I just started on resizable columns when realy unexpectedly WebKit has hit my with unexplainable anomaly. While table-layout:fixed; worked perfectly on all other browsers (even IE) Safari/Chrome gave me a headache.

Here is what I wrote so far: TSort Embriyo

As you can see it creates two tables - one for headers and one for body and some wrappers around them. Then it tries to make use of table-layout:fixed, since it better fits dynamical grid concept. For table-layout:fixed it is crucial for table to have a width, in addition to that all my cells (td/th) have overflow:hidden, white-space:nowrap and text-overflow:ellipsis to mimic grid appearance better.

Now the "bug" - both tables are constructed the same way, width of the cells and of the table is calculated and set by the same function. The "bug" is unexplainable because approach I use works as expected for top table but fails for bottom one. Basically it acts as if I had no width assigned to it. But you can see in Web Inspector that it definitely has the width... So... huh?

I tried everything, I swapped functions, I removed top table, I tried to built bottom table the way I build top table. But it keeps failing. However when I copy/paste generated table code into the page directly it starts to work. So my guess here is that it has something with dynamical nature of the table. But why it works on the top table then?

I was able to kinda get rid of this "bug" by creating table element with pre-assigned width. But it doesn't explain the weird behavior, does it?

Answer 1

I found a fix - still not sure exactly what's going on.

Move:

self._addColElements(self.bd);

to the bottom of your construct function (and of course remove it from populate).

You might have noticed that in my previous test I added a 'data' option. I found that calling populate from _init with that data worked fine - unless I used setTimeout to delay the call - like the ajax get does - and then it too distorted the table. So it's timing related - perhaps WebKit is doing something interesting to optimise rendering.

EDIT

Ok, I have a theory ;)

When the table is created and rows are added all within the same function, css is applied at the end of the function call - and at that point the table-layout:fixed item will only apply if the table has a width.

If the table is created, and the css is applied to it (i.e. because control has returned to the browser via e.g. ajax or setTimeout), when it doesn't have a width, then the fixed layout has no effect. Subsequently adding items and even setting the width does not cause the css to be re-evaluated.