Possible solution for fluid layout issue

[sharcashmo]

If table wrapper doesn't have a fixed height (as in examples) but it uses absolute positioning to use as much space as allowed by surrounding elements current implementation didn't work because the div container

$container = $container.wrap("<div style='position: relative; clear:both;'></div>").parent();

will have a computed height of zero, and so will happen with the table wraper put inside.

Changing the container to use absolute positioning and setting top, bottom, right and left to zero (ie, use all available space) will solve the problem and allow us to use tables which height is not fixed.

Anyway, I've set that configurable, behing default behaviour as it was.

[mkoryak]

Thanks for the pull request. Can you also provide a link to a jfiddle with example html that exhibits the problem that this pull request solves so that I can test / add it do the docs site before merging this in?

[sharcashmo]

Yes, I'll write the code as soon as possible.

Maybe it could be solved with the existing options, who knows?

On Tue, Feb 11, 2014 at 4:39 PM, Misha Koryak notifications@gh.neting.ccwrote:

Thanks for the pull request. Can you also provide a link to a jfiddle with
example html that exhibits the problem that this pull request solves so
that I can test / add it do the docs site before merging this in?

Reply to this email directly or view it on GitHubhttps://github.com//pull/45#issuecomment-34766076
.

Salú, tranquilidad y todo eso

[mkoryak]

Maybe, or maybe we can auto detect that this is happening and not need an option. Id need to see it to wrap my head around it

[sharcashmo]

Hi,

here you have a working example.

http://jsfiddle.net/sharcashmo/4B8QM/

It uses floatThead patched so you can test what happens. The layout has
some areas: header, menu, footer and main area.

floatThead works well as it is with the table at footer area; as it is
fixed height, table height is also fixed and it works.

However it doesn't work with the above table. You can play with #window
height in CSS to test what I mean. Table uses available space using
absolute position.

If the new wraper is added around, with relative position, absolute
positioned elements are broken. That is because absolute positioned
elements are brought outside normal page layout, the relative positioned
div element has actually no elements inside (the absolute positioned ones
are not taken into account) and the new div element has a height equal to
zero.

The inner absolute positioned elements, however, take the closest parent
with either absolute or relative position. Ie, the absolute positioned
element uses the new height 0 wraper, and tries to use all space with top,
bottom, left and down set to 0... that leads to a 0 height absolute
positioned wrapper to the table.

Maybe there's a simpler solution, that worked for me.

Regards,

David (aka sharcashmo)

On Tue, Feb 11, 2014 at 5:15 PM, Misha Koryak notifications@gh.neting.ccwrote:

Maybe, or maybe we can auto detect that this is happening and not need an
option. Id need to see it to wrap my head around it

Reply to this email directly or view it on GitHubhttps://github.com//pull/45#issuecomment-34770173
.

Salú, tranquilidad y todo eso

[sharcashmo]

However, I think you're right. It could be autodetected.

I think it will happen whenever the wraper element (the one use as
scrollContainer) has position absolute; its relative positioned wrapper
will have a height of zero.

Maybe it could be solved by checking how the wrapped element is positioned.
If it's absolute, then the new wrapper should be positioned absolute too,
with top, bottom, left and right set to the same values the wrapped element
has, and then set top, bottom, left and right of the wrapped element to 0.

On Wed, Feb 12, 2014 at 1:51 PM, David Lozano
david.lozano.ruiz@gmail.comwrote:

Hi,

here you have a working example.

http://jsfiddle.net/sharcashmo/4B8QM/

It uses floatThead patched so you can test what happens. The layout has
some areas: header, menu, footer and main area.

floatThead works well as it is with the table at footer area; as it is
fixed height, table height is also fixed and it works.

However it doesn't work with the above table. You can play with #window
height in CSS to test what I mean. Table uses available space using
absolute position.

If the new wraper is added around, with relative position, absolute
positioned elements are broken. That is because absolute positioned
elements are brought outside normal page layout, the relative positioned
div element has actually no elements inside (the absolute positioned ones
are not taken into account) and the new div element has a height equal to
zero.

The inner absolute positioned elements, however, take the closest parent
with either absolute or relative position. Ie, the absolute positioned
element uses the new height 0 wraper, and tries to use all space with top,
bottom, left and down set to 0... that leads to a 0 height absolute
positioned wrapper to the table.

Maybe there's a simpler solution, that worked for me.

Regards,

David (aka sharcashmo)

On Tue, Feb 11, 2014 at 5:15 PM, Misha Koryak notifications@gh.neting.ccwrote:

Maybe, or maybe we can auto detect that this is happening and not need an
option. Id need to see it to wrap my head around it

Reply to this email directly or view it on GitHubhttps://github.com//pull/45#issuecomment-34770173
.

Salú, tranquilidad y todo eso

Salú, tranquilidad y todo eso

[mkoryak]

wow thanks for a detailed fiddle. Ill have to think about this and play with different possible solutions later today. Ideally id want to autodetect this, but only if the autodetection doesnt yield false positives on other layouts that we haven't considered.

another idea i had was to add a class to the wrapper (ill probably do this either way) and let you css style it yourself to accommodate for this.

I have to be careful not to solve every possible problem with the plugin and thus bloat its code and ease of use. That being said, ill have a hard look at this, and see if there is a solution that makes sense for everyone

[mkoryak]

Hey, I am going to come back to this issue when I have time again, but for now you can use a new option added in 1.2.3 - floatWrapperClass: 'floatThead-wrapper'
so the wrapper has a class which you can style like this:

.floatThead-wrapper {
    position: absolute !important;
    top: 0;
    right: 0;
    bottom: 0;
    left: 0;
}

Hopefully that workaround will work for you in the mean time.

[sharcashmo]

It is ok for me. Thanks!

I'll try to think also in a solution that works transparently to the user.
El 17/02/2014 22:47, "Misha Koryak" notifications@github.com escribió:

Hey, I am going to come back to this issue when I have time again, but for
now you can use a new option added in 1.2.3 - floatWrapperClass:
'floatThead-wrapper'
so the wrapper has a class which you can style like this:

.floatThead-wrapper {
position: absolute !important;
top: 0;
right: 0;
bottom: 0;
left: 0;}

Hopefully that workaround will work for you in the mean time.

Reply to this email directly or view it on GitHubhttps://github.com//pull/45#issuecomment-35325878
.

[ghost]

I still can't get it to work. Here's my fiddle: http://jsfiddle.net/wr1dac7a/4/
Hope someone can help me with this. Both tables needs the blue table header to be fixed when scrolling through the recordset.

[mkoryak]

@JanOonk here you go:
http://jsfiddle.net/wr1dac7a/7/
this hack is not needed with when you set useAbsolutePositioning: false and also your fiddle incorrectly used .wrapper as the scroll container when in fact .view was the element that has the overflow