Skip to content

fixed-toolbars updatePagePadding sets padding on page not content #4006

frequent opened this Issue Apr 11, 2012 · 7 comments

2 participants


Right now, the padding is applied to the page not the content. See here:

// This will set the content element's top or bottom padding equal to the toolbar's height
 updatePagePadding: function () {
     var $el = this.element,
         header = $".ui-header");

     // This behavior only applies to "fixed", not "fullscreen"
     if (this.options.fullscreen) {
     // NOTE **padding set on page!**
     $el.closest(".ui-page").css("padding-" + (header ? "top" : "bottom"), $el.outerHeight());

I think the padding should go on the content, so it should be $el.closest( ".ui-page .ui-content" ) instead of $el.closest( ".ui-page" ), shouldn't it?


Hmm. Well, all of the CSS and JS surrounding this assumes the padding is set on the page itself. I think this makes sense, as the page is the parent of the toolbars, and provides their absolute positioning context (when "hidden", and inline in the document). The content div is not required either, whereas a page div is guaranteed.

Is this causing a particular bug? If not, I'm inclined to keep it as currently built. (+@toddparker)


Ok. You got me thinking, now. I think I posted this because of the comment in there

 // This will set the content element's top or bottom padding...

so I thought the padding should - as it says - go on the content. The viewport covers the available screen, the page expands depending on the content, so... not sure anymore. Need some time to think. The one thing that comes to my mind right away is your overthrow plugin. If I use it to "lock the screen" I need to have padding on the content, otherwise it's scrollbars will be sitting behind the fixed toolbars. Also need to check this again though.


Maybe I get around it the next few hrs. Trying fancy things with overthrow :-)

Will repost.



Ok. Padding feels right at home on the page. You could go ahead and close this.

If you want to try your hands on an overthrow "puzzle", I'm clueless as can be as to why the overthrow-content-sections scroll above the header, but below their button texts and stalls on the way down (iPad iOS 3.3) - see my multipanel overthrow layout. I'm going to bed, otherwise I go insane... should I post this as issue over on Overthrow? Cheers!



Fixed it.

In short:

  • I'm setting fallback position:absolute to fixed-headers inside panels in "fixed-hidden-state" vs. JQM using pos:rel
  • Headers with pos:abs cause content section to jump up to css-top:0 on blacklisted browsers
  • Setting padding-top=header.outerHeight postions content correctly, but overthrow scrolls above padded region
  • Instead setting margin-top=header.outerHeight positions content correctly and overthrow works as expected

Actually makes sense...

So, I'm closing this. Thanks for taking the time and giving input!

@frequent frequent closed this Apr 26, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.