Hello,

Thanks for a great module! After adding a function to my theme's preprocess, I'm able to use skrollr-stylesheets with no problem.

I've noticed that when the module is enabled, it adds a height style element to the body tag (I am using Omega 4). On the initial page load, this height is sometimes taller than the actual content, which causes extra whitespace to appear at the bottom of the page. If I resize the window, the calculation for the body height corrects itself, and the whitespace disappears. This happens across many pages, and the height of the extra whitespace varies from page to page; though, the extra height is always consistent on an individual page (I haven't really tested it, but this consistency leads me to believe the extra height is somehow derived from page-specific content like hidden elements, hidden overflow from content larger than its container, collapsed fieldsets, etc.).

I'm afraid I don't know too much about skrollr (or JS for that matter), but would appreciate any help or insights you might be able to offer.

Thanks! :)

Comments

markusa’s picture

A reason that first comes to mind:

I've noticed that the skrollr javascript library will set the height body element to a minimum of the largest data point that you use.

So if your page would naturally be 1500px in height, if you set an ending event at 2000px, skrollr will make the body element at least 2000px in height.

If you page would naturally be larger than 2000px in height or greater you wouldn't notice any extra whitespace.

Finding the right data attribute values is a trial and error experience especially with auto-generated content such as views.

You're right to use skrollr-stylesheets, you may have to use different keyframes for each view or even individual node.

You could also calculate data attribute values on the fly in the php theme templates based on computed height values.

markusa’s picture

Status: Active » Closed (works as designed)
ridgek’s picture

Okay, thanks for your insights! Unfortunately, this is happening on pages that don't even have skrollr elements, so it must be from Views, etc as you mentioned. I know it is probably no small task, but I am wondering if there should be a method so that the module can choose to only load the skrollr library on certain pages (in my case, only the front page uses it). I'd be willing to help with that in a few weeks when I have more time.

markusa’s picture

Category: Bug report » Feature request
Status: Closed (works as designed) » Active
markusa’s picture

I've just pushed a commit that will allow entering relative paths for loading the skrollr library. If their are no paths entered the 'Load Skrollr paths' admin config option is ignored...

It doesn't yet work with including paths such as "events/*"

Every path will have to be listed for the moment, I'll continue working on this as I have time. Hopefully this will allow you to push forward with you work, until I get a more robust solution in place

ridgek’s picture

Status: Active » Closed (works as designed)

Well, I feel stupid. I just figured it out; if I set ForceHeight to false, problem solved. I think being able to load it arbitrarily is a great feature for sites like the one I'm working on though (where skrollr is only loaded on a single page). Thanks again for hooking up this great module. :)

paskainos’s picture

I second @ridgek's sentiments - nice work @markusa! The Skrollr module is outstanding. I was about to shout

ForceHeight

until I got to #6. :)

I have a question slightly off the primary topic of this issue, but I'm posting it here since it's been indirectly addressed here, in hopes either of you can help. My question is; knowing skrollr doesn't support stylesheet imports, what's the best method to get skrollr stylesheets working? ridgek, I see you broached this subject here, and markusa you advocate using skrollr-stylesheets, so I'm hoping one (or both?) of you can offer some guidance.

Please let me know if you'd prefer a separate issue for this. Thanks again for your awesome work - and in advance for any insight on / assistance with skrollr-stylesheets.

markusa’s picture

You can use stylesheets, but you must enable use of the skrollr-stylesheets library. You can enable this on the Skrollr admin config page here: admin/config/user-interface/skrollr

You can include a stylesheet by giving a data attribute as stated on the skrollr-stylesheets github page:
https://github.com/Prinzhorn/skrollr-stylesheets
Definitely read that ^^

example:
<link rel="stylesheet" type="text/css" href="style.css" data-skrollr-stylesheet />
Easiest way is to add your this manually to the html.tpl.php of your theme, and put it in the head

Skrollr_stylesheets will look for link tags with that data attribute and process the keyframes defined inside it. You cannot alter the css with javascript or jQuery, because the skrollr_stylesheets processing has already occurred and put its code into the html, and a skrollr javascript process is running on that set of html information.

So that's the general getting started for skrollr-stylesheets in Drupal

If you have more specific questions, make separate issues so that people can more easily find answers later.

paskainos’s picture

Thanks again @markusa for your awesome work on the Skrollr module, and for your timely response. For future reference, here are a couple of quick thoughts regarding @ridgek's original post:

  • When using the Skrollr library(ies), it's perhaps best practice to identify / decide beforehand which 'mode' you'll need to use - absolute or relative. This is particularly important in a responsive (mobile) environment.
  • Assuming one chooses relative mode, it's important to understand how / where 'fixed and non-fixed (i.e. static) elements' must be placed; i.e. using the #skrollr-body container.
  • With that in mind, when using relative mode, it's important to understand Skrollr (relative mode in particular) is keyed to keyframes, and uses keyframes to calculate #skrollr-body content height. A clue is found in this exerpt from the 'scale' section of the Skrollr documentation, namely:

By default, skrollr uses the largest key frame and makes document height + viewport height this high, thus the max possible scroll top offset.

This is why the cutoff appears arbitrary when no keyframe identifies the end of content within #skrollr-body since Skrollr uses this method to quantify #skrollr-body content (and thus calculate size). Once I realized this, I inserted a keyframe for the 'end' (i.e. last content container relative to the parent #skrollr-body) of #skrollr-body content and voilà - fixed!

As such for mobile, in relative mode especially, you'll most likely need to define the 'end' of page content by defining / assigning a keframe for the last content container, in this case relative to the #skrollr-body parent element. Failure to do so will invariably result in content being 'cut off' at a seemingly arbitrary point, as experienced by @ridgek, and here for instance.

You can see examples of this concept at work on this site: mojo-lab.com. The home page, the staff page(s) (template), and the client page(s) (template) all use this method to indicate to Skrollr 'end' of page (i.e. #skrollr-body) content in order to properly calculate mobile content height.