Problem with fnOpen overwriting other page content

glawrie

I have observed the following using a test page that uses the fnOpen / fnClose functions.

If you add a row using fnOpen and the row is 'within' the table, the table resizes following the insertion and so the larger table still fits into the rest of the page material.

If you add a row using fnOpen and the row is the 'last' row showing, the additional material overlays the elements on the page below it.

Is there something I'm doing wrong?

Conversely - is there something I can do to fix this behaviour (other than leave a suitably large whitespace below table 'just in case'?

Thanks in advance for whatever help / assistance avail.

allan

Hi glawrie,

I suspect that from your description you just need to add a 'clear:both' to the element which follows the table in your HTML (or insert a suitable clearing element) - as you can see here, http://datatables.net/release-datatables/examples/api/row_details.html , the elements are the bottom of the page should move in relation to the table.

Other possibilities which spring to mind are that the table has a fixed height or is in a floating layer and "outside" the page flow. If you are able to post a link I'd be able to say - but I suspect the floating issue is the most likely one (it needs to be considered since the default DataTables CSS uses floats for positioning the info and paging elements).

Regards,
Allan

glawrie

Thanks for suggestions.

The page is here - http://v6dev.2gc.org/resources-weblinks-table0617

The table element is followed by a clear:both div

Simply open details for final row in table to see problem illustrated.

The odd thing is that it only happens for row inserted at bottom of table - opening a row in table higher up doesn't cause the problem (wider page rearranges itself).

Any ideas?

allan

Thanks for the link - very helpful! Add a clearing div () just after your inner table and that will do it. it looks like that table or something in it is being floated resulting in the problem.

Allan

glawrie

Neither suggestion seem to do any good.

Have updated test page with the extra clearing div, and have rooted out the nearest "z-align" values (there was only one - for the whole container the data table is in).

Any other ideas? Anything else I can add?

allan

That's the oddest thing! It looks like it only happens in browser browsers for me and as soon as I change something using the Inspector then it resolves the problem itself. I've no idea what is actually causing that I'm afraid - I suspect that it will be something to do with the floats in the CSS framework combined with an oddity of how the table is being handled. Sorry I don't have a better explanation...

I do however have a workaround :-). Because the issue resolves itself as soon as the DOM is updated after the row is displayed you can call the following on the line after your fnOpen call:

[code]
$('#weblinkscontainer').dataTable().fnDraw(false);
[/code]
And that should make it "go away"...

Regards,
Allan

glawrie

Great - that works! There is something odd going on still - with the fix in place when the table redraws it loses the margin between the table and the record status and navigation information below the table. But hopefully I can fix this by simply jacking up the gap between the table and these items in CSS so the redraw doesn't visually overlap these elements.

Anyhow - huge thanks for this. No way I'd have worked it out on my own!

allan

Perhaps adding a margin on the DataTables container element will do the job.

It was a really weird one that - never seen anything quite like it in Webkit, but a good one to be aware of, and good to know that the workaround works well for you.

Regards,
Allan

glawrie

I updated the code to use the version of the drop-downs that appears in your blog posting (http://datatables.net/blog/Drill-down_rows).

The slide-over problem is back, but this time only in webkit browsers!

The redraw fix doesn't work (but isn't necessary now for non-webkit browsers either).

I tried another jquery redraw fix (http://plugins.jquery.com/project/force_redraw) and that didn't help either.

I'm guessing this is a specific "characteristic" of webkit browsers.

Any ideas how I can work around it?

glawrie

Just so you know, I added a clearing div below the table in the innerdetails bit, made no difference.

allan

Hi glawrie,

It's a proper odd one this one - I can't quite figure out why Webkit isn't causing a reflow to occur, so I'm fair my solutions here are going to be a little bit of try it and see:

1. I'm wondering if the styles on .dataTables_wrapper are causing it. I would suggest removing the following from the CSS:

[code]
.dataTables_wrapper {
clear: both;
min-height: 302px;
position: relative;
zoom: 1;
}
[/code]

And see if that fixes it. I don't believe you actually need any of those styles for your table anyway, so there is nothing wrong with doing that and if it fixes it - hooray!

2. You could force a reflow by changing a trivial CSS property. It looks like Webkit is smart enough not to reflow if you set a value to what it currently is, but you could add/remove margin to some element where it won't be noticed - bit nasty this option...

3. You could try the animation option from the blog - that will most certainly cause a reflow.

If you could let me know if the first works, or if the third is an option :-). Sorry about the trial and error approach - the nature of web-browsers...

Regards,
Allan

allan

Or option 4... I think I've just figured out what is going on! You've got float:right on the img in the details row - I'd say that that is the problem. The browser is calculated height before the image is being loaded (when it has height and width of 0 since you've not specified otherwise), then it loads and displays at its 100% height and width - which causes an offset in the height - the the float means that there is no redraw. Working assumption at least :-)

Regards,
Allan

glawrie

OK - some developments...

1) Removing the .dataTables_wrapper item completely from CSS results in the table being drawn 'on top' of the web page, with a width of (on my browser) 1396px... regardless of browser type. This is controlled by the "position:relative" element - and it turns out it is the only element needed in the item for table rendering to work OK (at least on this particular page);

2) I've tried various forms of forced redraw based on CSS element changes prior to this suggestion, when investigating if having more powerful "clear" divs would help (one of these had two alternative forms of CSS edit and reverse included to help ensure the clear was applied). None helped I'm afraid.

3) I produced a new version of the page using the animation code from the blog (here - http://www.2gc.co.uk/resources-weblinks-tables ). This improved things in lots of ways, but the overwriting problem persists in webkit browsers only.

4) I tried replacing the 'slidedown' animations with show. This has an interesting effect. The first time you open a row the table size is adjusted properly in webkit browsers. But on the second or subsequent clicks on an expand row, the overwriting problem returns (again - webkit only).

5) I thought this might be because the 'slideup' method was messing with webkit somehow. So I changed slideup to "hide" and noticed that with the blog code, the hide was still animated. Turns out if you put anything inside the () for slideup or slidedown, jquery interprets this as you requesting it to apply the default animation to the show / hide. Weird. You had put the row delete calls in as a callback from slidedown, and this was what was triggering the default animation. So I redid your slideup code to take it out of a callback and put them as separate calls. This got rid of the animated hide, but has had no effect on the 'overwrite on second click' problem.

6) Have fixed the anomalous error reported on the page by inspectors - made no difference.

7) I guess for now the solution is to put in some conditional code to use slideup / down for non webkit browsers, and show / hide otherwise. But not sure how to do this efficiently in the code - any suggestions for this would be helpful. Won't fix the problem - but maybe will make it slightly harder to trigger...

Any thoughts on where to next?

Thanks again for your help so far.

glawrie

Just to note the solution has been found - some redundant CSS left over from an earlier version of the page was being interpreted by webkit in a different way from the other browsers - and this different interpretation resulted in the overwrites. Removing the link to the redundant CSS fixed the problem.

Kudos and thanks to Allan for working this one out :-)

jbeuckm

That "animation code" link is broken. What is the best way to use animations when fnOpen/fnClose are called?
Thanks.