Consider using 100vw / 100vh CSS units to make things full page

[contentfree]

CSS3 gives us viewport-relative units. 100vw means 100% of the viewport width. 100vh; 100% of the height. Very handy when doing full screen slides… It also has good support: http://caniuse.com/#feat=viewport-units

[alvarotrigo]

Not supported by IE 8.
In any case, what's the problem of using percentages? Could you illustrate it somehow?

Other potential problem i see is in case in the future fullPage.js supports being initialised inside an element instead of working in all the page.

[contentfree]

100vw will always calculate out to 100% of the viewport width. If you use percentages, and you don't have 100% down from the root, you can't be assured of 100% calculating to 100% of the viewport. (And that's the whole purpose of the vw/vh units: 1vw == 1% of the viewport width)

If fullPage.js is initialized inside an element instead of working on all the page, then fullPage is a misnomer. Also, YAGNI. fullPage is designed to be full-page today… and vw/vh helps accomplish that without javascript.

(Also, IE8 represents about 3% of the global browser population – according to caniuse.com. Globally, vw/vh has ~80% support globally)

[alvarotrigo]

I get your point and I think it would also be something beneficial for a future, but right now, this plugin will still giving support for IE 8.

IE 8 seems to be more used than IE 9 and IE 10, as also pointed out here and just half than IE 11 or even more depending on the studies.

Some studies show 10% usage worldwide, which is not something to ignore.

Until support for IE 8 is dropped, I guess we could use just CSS fallback to height:100% when vh is not supported, as done in many other CSS styles.

.demo{
    height:100%;
    height:100hv;
}

I though there were going to be problems with the vertical centering inside the table-cell element if used percentages, but couldn't find any problem now when trying it again in IE 8 and Opera 12.

[andreyshipilov]

Please never implement vw/vh related behaviour.

[alvarotrigo]

@Tezro could you elaborate that?

[andreyshipilov]

Sure. IE8 is still more popular than IE9. Also vw/vh is extremely inconsistent from browser to browser.

[contentfree]

Yeah, but IE8 only represents ~4% of global usage (about the same as "UC Browser for Android 9.9"…) and IE9/10/11 together represent ~12%.

Please source "vw/vh is extremely inconsistent from browser to browser." Again, using caniuse.com as a source, there's few known issues specific to vw/vh (a notable exception being Safari on iOS 7.1 when you leave the page and come back more than 60 seconds later).

[andreyshipilov]

What we do at work is install top 5 versions of all browsers, each in separate VM. Run minimal tests for needed CSS or JS features. Compare screenshots and values pixel by pixel. You don't really need to source anything when you do web dev every day and know the issues. vw/vh and of course vmax is inconsistent depending on the browser and the OS.

And yeah 4% of IE8 means 1 out of 25 people uses it, again according to StatCounter, which you have to sign up to have your website stats used there. In real world the numbers are very different.

[alvarotrigo]

Closed as it doesn't seem to be a good solution.

[Rayken]

You're talking about a solution for what fullPage should utilize by default. I'm not ( #1515 ).

Here's the gist. Make it up to the developer and use pixels as default value – but don't disallow vh/vw. Why? Because using 100vh for example would mean less lookup for jQuery in terms of finding out window.height() on init AND on resize. This is no longer needed. 100vh is 100vh. Ultimately this means better performance and cleaner code (nothing needs to be inline styled except the container).

I'd go with better performance over IE8 support any day. Even IE9. That's me. And it should be up to the dev and project, no? As well as custom classes for container (fullpage-wrapper) and sections (fp-section) and vertically centered sections (fp-table). More options for the developer.

Why would this be bad?

EDIT: or show an example of how we could simply overwrite or extend $.fn.fullpage to use vh/vw and allow to set the variables holding class names and such.

[alvarotrigo]

I'd go with better performance over IE8 support any day. Even IE9

Sorry but I prefer to keep providing support for them. I haven't researched much about vh and vm but it seems it is not very consistent as @Tezro said:

vw/vh and of course vmax is inconsistent depending on the browser and the OS.

Using pixels instead won't create any real performance problem in your site. The difference will be negligible... They are only recalculated on window resize every 350 milliseconds, which is not a bad delay.
Using other measures can lead to problems with other options such as scrollOverflow.

If you are so worry about performance, you'd better use the pure javascript fullpage.js version. It is still under development, as I have no much time for it, but be sure it will be much faster than the jQuery version. (plus it is not using pixels as it doesn't work with scrollOverflow).

[Rayken]

I'm asking for options, not for you to change the default from pixels to vh. There's a difference!

If not, then how can I extend/replace functionality without having to fork/modify yours? Basically I'd just want to access the variables you've registered to hold the element classes as well as rewriting scrollPage function etc. Can I redefine them somehow? Like extending/overwriting.

The point being, give the tools for the developer to develop using your plugin. Don't limit the developer, give them options to decide how they'd want to use the functionality you've written?

Personally I'd want to use vh for this project. I'd also want to not have jQuery do so much inline to the DOM but use classes instead. The only thing needed to be inline would be on the container, switching sections using translate3d but with 'vh' instead of 'px', so I'd make a variable for the unit.

[alvarotrigo]

The point being, give the tools for the developer to develop using your plugin. Don't limit the developer, give them options to decide how they'd want to use the functionality you've written?

Yep, that'd be nice. I'll keep it in mind as a possible enhancement for the future.
I don't have time for it now and I still have other high priority issues or bugs to solve for the next release.

Feel free to commit a pull request if you think you can add the option into the plugin.

[Rayken]

Understood.

I would like to know how I can extend it though, as a module. Overwriting said functions "outside" the scope of the plugin. How can I do that?

Can I access e.g. var WRAPPER = 'myWrapperClass' outside the plugin and redefine it?

Also, can I replace functions, such as the scrollPage function outside the plugin? Something like $.fn.fullpage.scrollPage = function( stuff ) { more stuff; }?

[alvarotrigo]

@Quaked there's no way to do it at the moment. fullpage.js would need to be modified to support that.

[Rayken]

Any updates on supporting optional 100vh/vw transition? Or being able to extend fullPage.js?

[alvarotrigo]

Not really.