Safari Bug - max-width:100% and tiny viewport

[mcyoung]

I've noticed in Safari (Mac) that the header's are not responding the way that they should. I'm specifically using this in conjunction w/ Bootstrap 3 and a responsive table. I've also noticed that on an iOS device, using mobile Safari or Google Chrome, has the same issue. Here's what I'm seeing using a demo of bootstrap 3 from your site:

[mkoryak]

I don't have that problem with safari on osx 10.9. Also, I don't officially support safari.
I don't really support phones either, at least not intentionally. This plugin makes much more sense on desktop but not as much on mobile. I would suggest doing feature detection and disabling the plugin on mobile if you find that it does not work for some devices.

Sorry I can't offer a better solution, but supporting mobile phones is a pain I would rather not inflict on myself :)

[mcyoung]

So I revisited this and was looking at issue #117 which mentioned adding a min-width to help safari for both OSX and iOS. The min-width mentioned was 621px, which made things a little closer to being correct. I fiddled around with widths until settling at a min-width of 843px to work w/ my particular table. Not sure if you'd like to reopen this ever, but this may be a little idea on where to go w/ getting both OSX and iOS Safari working a little better. Still like this tool either way though, thanks!

[mkoryak]

I looked into this a bit more.
Looks like the problem might be because bootstrap adds a rule to the table max-width:100% and when you resize the window to be less wide than the table, safari will report $("table").width() to be container width (who the table should be 100% of). But in reality, the table is NOT that width, its actually wide enough to accommodate its contents.

You are seeing this issue on mobile safari because most tables there do not fit into the viewport.

I do not know (yet) how to fix this without modifying the table's CSS, which I strive not to do at all costs.

[mkoryak]

testcase:
http://jsfiddle.net/6nfotj8j/2/embedded/result/

check that out on safari and then on chrome. one of them is lying about width...

[mcyoung]

You're right, interesting. Chrome on OSX shows that value as being 523 where as safari show it as being 48.

[mkoryak]

I added "feature" detection for this bug and a workaround into table width code. Now it should not render so badly on iOS.

I added a testcase for it here:
http://mkoryak.github.io/floatThead/tests/safari/

you will notice that its not perfect yet, the .floatThead-container appear to be 'cut off' and it causes the background issues in the header. this can be easily worked around with css. .floatThead-container appears to have a scrollLeft() > 0 value which it shouldnt. It should stay in place and the table within in should be scrolling. There are other issues in safari that I noticed with a quick run through the rest of the tests.
Pull requests are welcome :)

Let me know if this patch gives you enough to work with on this issue.

[mkoryak]

closing this. safari is still not fully supported. ill add something to the readme about this

[saintger]

Hello,

I am a bit confused about the workaround that you mentionned for the background issue in the header.
Can you clarify what I should do ? It would really help (I have exactly the problem you described with the 'cut off' and the background on your testcase).

Many thanks

[mkoryak]

having a max-width set on the table is what messed things up for us. if you can remove it via a css rule than things will work much better (bootstrap adds a max-width to tables). does this testcase (http://jsfiddle.net/6nfotj8j/2/embedded/result/) report the table width as something around 50px for you in the version of safari where you are having problems?

[saintger]

Yes it is reporting 48px (iPhone 5S with iOS 8.1.3)

[mkoryak]

I was able to fix the issue in this http://mkoryak.github.io/floatThead/tests/safari/ where the header has no background when you scroll to the left by adding the following css rule

th {
  background-color: #fff;
}

[saintger]

Hello,

I just updated the floatThead with the latest stable release, without yet using your workaround above and it works perfectly already (with my own web page with particular use of floatThead).
Safari seems to be very strange...
However I am now 100% fully happy and thank you so much for this wonderful work.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.