I'm attempting to use the accordion for a very long list of records, where the accordion is wrapped in a resizable div that is given a fixed amount of space on the page and you would scroll to find the h3's that are too high or too low to see. The problem that I'm having is that the headers always force the size of their div, so the "overflow: scroll" is essentially ignored as the h3's spill out of the explicitly sized parent.
We are using jQuery 1.6.2, and UI 1.8.16
Seems to be working fine for me: http://jsfiddle.net/GVFsn/
try applying style="clear:both" to the parent, that should work.
The accordion is floated content, and the browser does not know where it ends.
Either that or steal the .clearfix class from FaceBook
Related
I've created a tablesorter through JSFiddle, and the best way apparently to show it on a site is through adding /show at the end. However when I add this to my site, and all the other ways I've tried there is a scrollbar within the tablesorter and the heading can be scrolled up because of the results and edit in JSFiddle.
I know that probably sounds like rubbish, so I've attached a link to my site where it apepears, as you can see it is scrollable.
Is there a way of disabling the scrollbar in the HTML, CSS or JavaScript so that when it appears on my site it is fixed.
I hope ive been clear, thanks.
Link - eylestom.wix.com/tenation#!releases/c16vn
I'm assuming you mean the scrollbar in the iframe that contains your JSFiddle? I think that iframe is taller than the "tabs" div containing it. I made an inline change to the height of the iframe to 530px (allowing for your header block) and the scrollbar isn't displayed.
So, I think you could just make the iframe smaller, or make your containing div taller, or set its overflow to 'hidden'. But, your page looks like it's going to contain a lot of data down the road. I'd suggest you look at adding the 'stickyheader' or 'scroller' widgets to your tablesorter to manage the overflow more gracefully.
<iframe src="//fiddle.jshell.net/tome98/abkNM/5961/show/light/" sandbox="allow-forms allow-popups allow-scripts allow-same-origin" style="height: 530px;"></iframe>
I have a ons-page element that I want to customize the scrolling for. There are a few things I'd like to achieve, but mostly I want to understand what's going on.
By default, the page has -webkit-overflow-scrolling: touch. This is undesirable for two reasons:
The area "behind" the page shown during overflow is just plain white
I have no hooks to take action on over scroll. I'd like to add pull to refresh mechanics.
I've tried working with iScroll, but the behavior I'm seeing is that if I declare my scrollable element to be inside of the page, it calculates the full element height as the visible height. If I declare my scrollable element to be the page, I can move the page around, but not the content within the page.
I'm guessing some of this is related to "using native scrolling where it can", but I don't really understand how that's implemented, so I'm not really sure.
Any ideas?
Onsen UI doesn't support pull-to refresh as default.
How about using this library?
https://github.com/mgcrea/angular-pull-to-refresh
This is a library for angularJS.
P.S
Now Onsen UI support pull-to-refresh. http://onsen.io/reference/ons-pull-hook.html
I am using jQuery Mobile with jQuery Mobile Router, to dynamically change content of listviews.
In the change handler I'm dynamically adding content to an inset listview, then calling listview('refresh') to re-apply all the styling to the new elements. It mostly works, however whilst it applies the ui-corner-all to the UL the ui-corner-top and ui-corner-bottom classes are not applied to the correct LIs so they don't get rounded corners applied.
I have prepared a live example that demonstrates the issue.
The first page is static, the second page is generated in the rounter handler which is trigger by the jqm beforepageshow event
Thanks for your help.
You just needed to force the refresh:
http://jsfiddle.net/j5q75/4/
JS
listview.listview('refresh',true);
I have a textbox that I am attaching jQuery UI's Autocomplete functionality to and I am using CSS to give it a max height via the example here. My problem is that doing this causes the z-index problem that bgiframe solves to come back again, but in a different way. The initial autocomplete menu is above all the controls underneath it, but when I begin to scroll the autocomplete menu falls behind them.
Any suggestions?
EDIT:
This is purely an IE6 bug.
As you can see, after scrolling down the autocomplete falls behind the other controls.
I could solve the problem by replacing offsetHeight by scrollHeight in the following line (from jquery.bgiframe.js) :
height:'+(s.height=='auto'?'expression(this.parentNode.offsetHeight+\'px\')':prop(s.height))+';'+
This change solved the bug for the autocomplete fields with vertical scrollbars. I could not spot any regression in other kinds of dialogs (but I did not run extensive tests).
You need to reverse the z-index order of the form elements (or their containers) using javascript. I.e., "Social Worker" has the lowest, "DX Code" the highest z-index.
You could change the offsetHeight to scrollHeight, like Siggen says, but I have encountered problems when there is only 1 result returned from the autocomplete. The 1 result is squished into a window that only like 2 pxs high.
I found a fix though.
When you have a data.length<2, you should use the offsetHeight, rather than the scrollHeight.
You have to modify autocomplete.js.
Locate this code:
if($.fn.bgiframe)list.bgiframe();
And make it this:
if($.fn.bgiframe){
if(data.length<2)
list.bgiframe({height:'expression(this.parentNode.offsetHeight+\'px\')'});
else
list.bgiframe();
}
Remember, this code should be used in combination with Siggen's fix.
I have used a combination of both parameter for the height like this:
'height:'+(s.height=='auto'?'expression(Math.max(this.parentNode.offsetHeight,this.parentNode.scrollHeight)+\'px\')':prop(s.height))+';'
Look at the max function. Now it is good with no scroll bar (shorter list and longer list as well)
and now the autocomplete component looks perfect in IE6.
Well here's the problem:
I have a PHP index page which uses show/hide layers javascript. I am using the on menu.click function to show and hide content relevant to each menu. On.click all divs are hidden except the content for that menu item , which fades in. The content relating to each menu item are displayed within separate DIVS. The property is applied to all the text within all the divs.
See: http://jobe-group.com/jobeco/uk/2010live/dynamic/content/index.php#
The trouble is that SIFR only appears to be applied to the displayed on.load when the page is first loaded. When this is hidden and the other s shown through the "show" function they load in classic CSS fonts without the SIFR applied.
Is this unavoidable with the SIFR setup. Or am I not calling the divs properly. I have set the SIFR to apply to the selector and indeed it works fine on the for the displayed on load. It doesn't work for the within other . In theory I would think its possible to load the SIFR on all divs on page.load even if those divs are presently visibility:hidden.
What's the verdict on this?
Hope someone can help.
Cheers,
John
After you show the previously hidden div, execute the sIFR.replace calls again to replace the content in those elements.