prinzhorn / skrollr Goto Github PK

The README should be much shorter and easier. All those technical details should be separated.

Maybe we should set up the GitHub wiki and have this stuff nicely organized.

Allow setting of constant variables to provide quicker/easier placement of elements.

Say I have 3 major sections of my page: about, how to, documentation

<div id="about" data-about-0="top:0%;" data-about-100="top:20%" data-about-400="top:100%">About</div>
<div id="about" data-how_to-0="left:0%;" data-about-100="left:20%" data-about-400="left:100%">About</div>
<div id="about" data-docs-0="top:100%;" data-about-100="top:50%" data-about-400="top:0%">About</div>

skrollr.init({ 
  constants: { 
      about: 500,
      how_to: 2000,
      docs: 3000}  
   });

would be equivalent to the current

<div id="about" data-500="top:0%;" data-600="top:20%" data-900="top:100%">About</div>
<div id="about" data-2000="left:0%;" data-2100="left:20%" data-2400="left:100%">About</div>
<div id="about" data-3000="top:100%;" data-3100="top:50%" data-3400="top:0%">About</div>

skrollr.init({ });

This would allow you to shift things forward and back easier by changing variables definitions.

When starting the example a popup opens:

Line 752: '0' is null or not an object.

Have to investigate further.

Right now skrollr doesn't fit some use cases. For example if I have a "normal" website and want to spice it up, I don't need things like automatically setting the body height to the max key frame. Instead it has to be the other way round. The original web page needs to stay untouched and skrollr just lives within the page.

Add option maxKeyFrame. Example:

skrollr.init({
    //data-end will now be equal to data-1000, no matter how much you can actually scroll
    maxKeyFrame: 1000
});

Now one could pass the document height as maxKeyFrame and have animations matching the actual scrolling of the original page.

Right now, skrollr automatically detects what you want to animate and how to parse. The flow is like this:

• Is it a transform value (scale, etc.)? -> parse transform value
• Is it a color? -> parse color
• Is it a numeric value/multiple numeric values with unit? -> parse them
• It must be a constant value like "block" or "center"

We could probably throw this away completely, because at the end, they are all based on numeric values.

Instead do this:

• Extract all numeric values from the string and remember where they were.

That's it. No matter if the string is rotate(0deg) scale(1.2) or rgb(100,20,40) or just 10px or even block, we will just parse all of them in a simple structure using a regex. For example

rotate(0deg) scale(1.2) will result in something like ["rotate(?deg) scale(?)", 0, 1.2]

or

rgb(100, 20,40) will result in something like ["rgb(?, ?,?)", 100, 20, 40]

Without looking at the code, this will probably save 20% or even more of the current code.

It get's even better: With this change, we will get support for all kinds of properties which would be hard to handle, for example gradients or shorthand values like "background", where position, image and color are mixed.

The only thing we need to keep in mind is, that there are some CSS properties that don't support floats and need <integer> CSS value. All properties in this table with either <integer> or <color> need special handling.

Given the following example (which is nonsense btw.):

<div data-0="background:red;background:linear-gradient(red, green);"></div>

The background will have a gradient in browsers which support them and no background in browsers that don't.

The desired behavior would be a red background in browsers that don't support gradients. Skrollr currently implements this by using an object to store property/value pairs. Instead, it should be property/values-array pairs.

Not sure if needed though. A static fallback can still be added as style attribute or via external stylesheet. Only animated fallbacks are currently not supported. Just keep this ticket in mind until someone cries loud enough.

Just a reminder for me.

Add something like this to skrollr.js (UglifyJS will keep it in the minified version automatically).

/*!
 * skrollr v0.2.3
 * parallax scrolling for the masses.
 *
 * Copyright 2012, Alexander Prinzhorn (@Prinzhorn) and contributors.
 *
 * skrollr can be used by everyone under the terms of the MIT license.
 *
 * Demo: http://prinzhorn.github.com/skrollr/
 * Source: https://github.com/Prinzhorn/skrollr
*/

Without the copyright notice people would violate the MIT license without even knowing about. Even though the MIT license states that it shall be included in it's entirety, we all agree that such a header at the beginning of a source code file is enough.

This is maybe a stupid question - but I was wondering if Skrollr works with the horizontal scrollbar as well as the vertical one. It doesn't seem to be able to right now.

When writing async tests with QUnit we often want to scroll to X and then check conditions after position X has been rendered. Copying the logic all over produces redundant code which is hard to maintain.

We need a base test, to which we pass the scroll position and some checks to perform. The actual call should look similar to this

/*
    After scrolling to 100 and waiting for a render to occur, check all DOM elements in "$obj" against the rules.
*/
scrollTest(100, $obj, {
    //Check if the given styles match the ones of the element (using $.fn.css)
    styles: {
        "left": "500px",
        "color": ""
    },

    //Check if the elements all match the given selector
    selector: ".foo:not(.bar)",

    //Arbitrary tests
    custom: function() {
        //Do some custom synchronous tests
    }
});

The Test should also be aware of browser differences. Testing for "opacity" on IE < 9 does not make sense.

Feature request: A way to make the scrolling layout snap to certain positions.
As seen here: http://www.ws-interactive.fr/methode/ or http://markdalgleish.com/projects/stellar.js/

In addition to the "main" example (the gh-page), add some more examples of common tasks.

• simple effects without skrollr.css and absolute/fixed positioning. just a "normal" website with some spice (parallax background maybe?).
• circular motion using custom easing (using sin/cos for left/top properties)

separated the discussion from #34

Doesn't seem to work on iOS devices. I tested on an iPad with no luck.

I forked the repo and will look into this.

We already have a render loop and different easing functions, why not allow animating the scroll position?

Example will animate from current position to 1000 offset:

skrollrInstance.animateTo(1000);

Optional arguments could include: duration, callback and name of easing function.

skrollrInstance.animateTo(1000, {
    duration: 500, //ms    
    done: function() {},
    easing: 'cubic' //same set as for other animations
});

The "data-end" attribute is already available as a convenience method to make it easier to have multiple animations end at the end (ha!).

For large skrollr instances it would be helpful to say "hey, I want this animation to start 100 px before the end".

Example:

<!-- Some other elements -->
<div data-end-100="opacity:1;" data-end="opacity:0;">Hey ma, I will fade away for the last 100px of scrolling!</div>

If the offset is larger than the maximum, it should be threated as "data-0".

Hey there, loving this plugin.

For CSS position attributes, I had to reverse the order in order to get it to work:

data-end-1600="right:-180px; opacity:0;" data-end-500="right:0px; opacity:1;

worked, for example, whereas:

data-end-1600="opacity:0; right:-180px;" data-end-500="opacity:1; right:0px;"

..fails. Any idea why?

I'm thinking about removing CSS transitions for the demo page, because it's really hurting performance. It would be as easy as using the "notransition" class on body element. skrollr itself doesn't know about transitions anyway, it just sets properties.

While adding more documentation I would of course mention that (documentation about the default skrollr.css file is missing right now). I have to make clear what skrollr does and that the skrollr.css file is just to get started and may be fully customized.

Currently skrollr sets all properties prefixed, which of course is just a temporary solution. That means we are setting things like MozLeft or webkitBackgroundColor which is just wasting cycles. We should rather have a test, if the value needs to be prefixed. Instead of having a whitelist of values and doing a regex Test, it would probably a good idea to test if the property is supported by doing something like this:

var properties = document.createElement('div').style;

//...

//The unprefixed value is not supported
if(!hasProp.call(properties, prop)) {
    //Set all prefixes
}

And maybe instead of looping over all prefixes we should detect which one to use (ua sniffing?).

Seems like the only thing which keeps skrollr from working with SVG elements is that we use className where SVG needs to be className.baseVal

The ideal way to do this is to debouce the scroll event against requestAnimiationFrame and keep that rAF going until the scroll is done.
That way you net out with 60fps and your action matches against screen refresh. It should provide the most smooth output possible.

Unfortunately I don't have any code to provide on this but this recommendation is straight from the chrome engineers who work on smooth graphics. :)

I'm thinking about dropping hsl support from skrollr core, because it's only needed for IE < 9 (and some very old Firefox etc.). I'd drop the IE "filter" stuff at the same time.

Instead of having those in core, it would available be as a plugin which transforms hsl to hex on the fly. This change could make skrollr core close to 5k small.

How plugins could work or how the api could look like: Allow plugins to hook into the setStyle method. This would allow transforming hsl as well as adding the IE filter style. Other entry points for plugins could later be specified.

Well, actually I'm not thinking about this, I will just do it.

Not only properties use prefixes, but values as well e.g. -moz-linear-gradient

Add prefixes if needed. Prefixed values are currently not working.

Not sure if this is the right place to ask. . . My apologies if this is not right.

Is it possible to have scrolling start automatically on page load?

Would this have a big impact on performance?

Thanks.

I hate websites that do a scroll animation much longer than 2 seconds and don't allow interruption.

After I pulled #55 it will easily be possible to add an option for that.

//User interaction won't impress this selfish animation
s.animateTo(2000, {interruptible: false});

//When the user scrolls, the animation gracefully stops
s.animateTo(2000, {interruptible: true});

Just found that skrollr seems to remove one whitespace too much when stripping a className. Investigating.

In order to save bytes and clean up the code base, we should remove all members, which should not be accessible form outside, from the prototype. Instead they should just be scope variables inside the main wrapper function.

Example:

//Before
Skrollr.prototype._fillProps = function(sk) {/*...*/}

//After
var _fillProps = function(sk) {/*...*/}

//Same for non-methods

//Before
self.curTop = 1337;

//After
_curTop = 1337; //Declared elsewhere.

Since only one instance of skrollr will be instantiated anyway. (Note: make skrollr a proper singleton)

When the content of a page or element changes dynamically, for example due to an AJAX request, it's needed to refresh the internal skrollr calculations.

There should be a new method named refresh([elements]) with an optional argument. The method will either parse anything again or just the given object(s).

Example:

<div data-0="left:0px;" data-end="left:500px;">bacon</div>

var s = skrollr.init({forceHeight: false});

//The body is now larger, thus data-end needs to be recalculated
document.body.innerHTML += 'foo<br>foo<br>foo<br>foo';

s.refresh();

//or
s.refresh(document.querySelectorAll('[data-end]'));

I like to know if it's possible to define animations to an element based of its own scroll position instead document scroll position. I'd like to have somethin like this:

<div data-self-1000="opacity:0" data-self-0="opacity:1"></div>

So, when the distance between the top of the element and the top of the window is 1000px, the animation starts and when the top of element is just near the top of the window, the animation stops.

this is useful when you have a lot of elements and you want take the animation control of each element individually, no matter where the element is placed.

How to set and call it in code?

The prefix detection does not work in safari.

Remove setScrollTop completely or let it use window.scrollTo

grunt could be used for:

• testing
• minification
• linting

and maybe to automatically add the Version number to the different files.

Firefox has this smooth scrolling thingy which makes the use of CSS transitions useless using skrollr in Firefox.

skrollr should get a new option smoothScrolling which interpolates the scoll offset. I guess it can be done in like 100 bytes of code.

It would be a nice to have if in browsers with smooth scrolling enabled the option could be ignored http://stackoverflow.com/questions/11897688/detect-smoth-scrolling-in-firefox-using-javascript

I'm using John Polacek's Scroll Deck plug-in with my current skrollr based page. When I add navigation and links that travel to different parts of a page, the scrolling stops not even 1000 pixels down the page. What settings need to be configured in the Javascript, CSS, or HTML code or what needs to be done to be able to have a user scroll anywhere within a page?

Just that I don't forget this:

Skrollr interpolates ALL numbers. For example if you set background-image and the url contains a number, skrollr interpolates it. Thus, we need to be able to suppress interpolation on a per-property-basis. I already know how I want to this be done, but no time.

The anchor feature will allow defining key frames related to the element's current position.

The idea is to be able to use child or parent element's as well. I'm not sure how this could look like, but that shit cray.

There could be some logic like with CSS, where certain things are able to cascade up (heh) and down.

<div>
    foo
    <div data-cascade="../div" data-bottom="background:rgb(0,0,0);" data-top="background:rgb(0,0,0);">bacon</div>
   bar
</div>

The inner DIV would change color while the outer DIV is fully inside the viewport.

I'm completely open to syntax suggestions. This could be some sort of CSS selectors. Instead of just parents/children it could be any element (not sure if useful).

When a skrollable is currently not render, that means the current scroll position is not within it's key frames, we add a CSS class called "hidden". That's incorrect and adds semantic. Call it "unrendered" instead and add "rendered" as counterpart.

The gh-pages branch should contain only the HTML/CSS files needed for the demos/examples, whereas the master branch should only contain files needed for skrollr development.

The current skrollr page does not show everything that's possible and is kind of pointless. But the most important point about updating it is that it's not working on Android, even though skrollr itself works perfectly (tryied it on ice cream sandwich default browser on Galaxy S2). That's because it uses the outdated absolute mode in combination with fixed positioning.

Maybe we should find a designer to create a kick ass page for skrollr with skrollr.

This is related to #8 and #9

By using https://github.com/zynga/scroller we could solve the iOS problem. skrollr's init method could get a new parameter scroller which expects an instance of zynga/scroller. We then use getValues().top instead of the native scroll offset if a scroller instance is available.

To keep skrollr painless for non-JavaScript programmers it may be worth to abstract this. Maybe put zynga/scroller into the skrollr repo and just call it "touch.min.js" or something (with proper attributions inside the file of course). This touch.min.js file would include all zynga stuff that is needed plus a small shim that creates an instance of scroller and exposes it globally so skrollr can use it (like window.skrollrScrollerInstance).

The changes to skrollr core would be a one liner like window.skrollrScrollerInstance && window.skrollrScrollerInstance.getValues().top inside getScrollTop

Edit: Almost forgot: setScrollTop needs to be changed accordingly. Cake.

A skrollr class should be added to the top most element (html). At the same time, any no-skrollr class should be removed. This way it's easier to create pages that work with and without skrollr at the same time (useful for mobile amongst others).

We should implement a keyword like inherit which will be replaced by the computed style of this element during parse time.

Example

div {font-size:100px;}

<div data-100="font-size:inherit;" data-200="font-size:200px;"></div>

<!--equivalent to-->

<div data-100="font-size:100px;" data-200="font-size:200px;"></div>

I'll preface this by saying it may not even be related directly to Skrollr, but I'm wondering what might be causing this. I'm using Isotope and appending in some content using Waypoints once an area has been reached.

Once this is appended, it works great, but when I scroll the page flickers randomnly––throughout all of the panels, regardless of whether the Isotope area is in view or not. It works smoothly without flickering until this stuff is appended.

I would show the project but would rather DM a link if you like.

I am only writing because I'm wondering if it may be related to the Refresh issue since I'm using AJAX to append the content.

Since scrolling and rendering are now decoupled, why still have a onscroll listener in first place? It's just a wast of cycles to listen for each scroll event when we only use the data of some of them. The _render method can easily call getScrollTop() as well.

This will not necessarily cause a push to 0.3.0, because 0.. is highly unstable anyway.

This change may as well fix #9, because iOS (and others) don't fire a scroll event while scrolling with a touch gesture. Not sure if getScrollTop() will report the correct value then.

Hi there, sorry for the issue bomb, but figured I would ask while it was on my mind.

Say I have several 'full screen panels' that each are to fill the entire screen, based on the window size; therefore the position of each of the panels can vary based on different monitor / window sizes.

How would you suggest I perform animations on objects within these panels as you enter / leave them? Maybe easier to just scrap the full screen height of each of the panels and set them to hardcoded values, yes?

You can see what I'm referring to on my personal site I hacked together this week. The first panel (my photo) is set to fill the window area (try resizing the window to see what I mean).

http://www.andrewmart.in

Just thought I'd reach out and see if you had any suggestions for a solution.

Just an idea:

Similar to how skrollr uses the inline-style syntax, we could create a templating language which looks similar to a CSS stylesheet.

#foo {
    bottom-top {
        left:100%;
    }

    top-bottom {
        left:0%;
    }

    100 {
        color:rgb(0,0,0);
    }
}

//Or maybe

#foo@bottom-top {
    left:100%;
}

#foo@top-bottom {
    left:0%;
}

#foo@100 {
    color:rgb(0,0,0);
}

<div id="foo">woooooot</div>

will be transformed on the fly to

<div id="foo" data-bottom-top="left:100%;" data-top-bottom="left:0%;" data-100="color:rgb(0,0,0);">woooooot</div>

This way we could have separate templates for different resolutions/devices. This is against the idea of having the key frames close to the element, but it's still better than mixing it with JS like $('#foo').skrollr({"100": "color:rgb(0,0,0);"}). I'ts something we are used to.

This would of course be a separate project/file, kind of like a less or sass preprocessor.

Seems like the performance on (Android) tablets is poor. Could someone with a tablet do some CPU profiling? I don't have one and I have no idea how JS can be debugged on those.

This is maybe a stupid question - but I was wondering if Skrollr works with the horizontal scrollbar as well as the vertical one. It doesn't seem to be able to right now.