The ImpressJS has support to ipad, ipod, iphone and android

[viniciusdsantos]

Hi my friend, thanks for your help with this amazing framework, good job :)

So, I was looking inside impress.js source and I saw that the javascript code try to discover if the devices are rendering the presentation are android, ipod or iphone and then, the impress.js do not run the presentation. But, I tested and I proved that all newest version of safari, chrome on ipod, iphone and android are capable to support CSS3 transition and animation and transforms, so, I think you can remove this following test:
( ua.search(/(iphone)|(ipod)|(android)/) == -1 );

And insert the code to test if is IE or another browser/environment.
Thanks

[bartaz]

Android, iPod, iPhone, iPad, etc 'supported' CSS 3D transforms even when I was testing it while creating impress.js, but the devices and browsers weren't able to handle impress.js animations.

I know that support is better now, but it still doesn't mean that impress.js will work fine.

I don't have time right now to test it myself, but even if it works now, it may not work on all devices or versions of browsers. It's especially true on android. It's very hard to detect if a particular device is fine to display impress.js or not. It may even be different for different presentations - those with many steps and many crazy 3D transitions are likely to fail.

So for sure I can't just remove the check.

The only thing I am considering is allowing user to run impress.js even on 'blacklisted' device if they want, but they need to know that it may fail.

[FagnerMartinsBrack]

Right now we can't just remove the checks unless we can be 100% sure that, for several versions of those devices, 3D transforms have been working and if it breaks, we will know it before someones reports it.

We need automated tests to be able to check if the presentations are glitchy or not. Until we have that, we should keep the browser sniffing as is. The plan is to support only the latest browsers, but even the latest browsers can break, therefore an automated test is a strong requirement to fix this problem.

[FagnerMartinsBrack]

See #273.

[deepu105]

But it would be good to have some way to disable the check problematically, coz say if I have a presentation intended for some devices only which I know works I should be able to disable the check as I do not care of failing browsers for that presentation

[FagnerMartinsBrack]

@deepu105 For now the responsibility of telling which browser is supported and which one is not is from impress.js. In the future, if we choose to move this responsibility to the developer, then we could create something like that.

We need to review the mobile browser support for impress.js.

[Pierstoval]

I'm digging up this repository because I've updated OrbitaleEasyImpress with latest impress.js version, and it seems that mobile support is still not activated because of this line:

var impressSupported =

  // Browser should support CSS 3D transtorms
   ( pfx( "perspective" ) !== null ) &&

  // Browser should support `classList` and `dataset` APIs
   ( body.classList ) &&
   ( body.dataset ) &&

  // But some mobile devices need to be blacklisted,
  // because their CSS 3D support or hardware is not
  // good enough to run impress.js properly, sorry...
   ( ua.search( /(iphone)|(ipod)|(android)/ ) === -1 ); // <======== This line

I've put online the new demo of EasyImpress here, and indeed the only solution to make touch work is to manually add buttons for next/previous actions.
But still, I think we could add a specific case: if "touch" is activated (whether it can be mobile or tablet or even tablet pc like HP Surface or something), we could add new events to detect left or right swiping in order to trigger next and previous events in Impress.js.

But I don't know how the "touch" API works in JS, so if you have ideas 😉

[FagnerMartinsBrack]

@Pierstoval, @and3rson have made a good progress on #496. Maybe you can use that as a guide?

[henrikingo]

@Pierstoval: I have done exactly that in my fork. Feel free to use it / contribute to it while we wait for upstream to catch up.

(Note that official impress.js also has touch support. Not swipe, but you can touch on the left or right edge to navigate. You just never see it because it refuses to load in any phone or tablet.)

[Pierstoval]

@henrikingo did you make a PR for this?

[bartaz]

Impress.js has very basic touch support (as mentioned before touch on sides of screen) that currently works on iPad only, as all others are disabled.

I've written many times about the reasons why mobile was not supported at the time impress was created, but truth is that it was years ago and things improved both in iOS and Android. Still, there may be some older devices that would simply not handle some impress presentations and using too much memory may simply crash whole Safari on iOS. So it's still safer not to enable it by default. That said, I agree that in 2016 it could (should?) be revisited and be somehow turned into option, so devs willing to take the risk of killing user browsers on mobile could turn it on.

[Pierstoval]

What were the memory issues you had? Was it about the 3d positionning, or the animations themselves?

[bartaz]

3d positioning. Each element positioned in 3d creates new rendering layer for GPU. This is every slide in impress. Safari on iOS is simply killed when memory is exceeded which may happen quite quickly on older devices (demo of impress was too much for iPhones at a time).

Of course today devices have more memory and power then couple of years ago, but you can still easily exceed it by having dozens of image heavy slides. And from impress.js user perspective you never know if your presentation will not be to heavy for some device. There is no way to detect or prevent it.

Still, this could easily be an option to enable impress on mobile 'on your own risk'. Or even programmatically set your own check for who you want to enable it instead of hard coded default one.

[Pierstoval]

Maybe could check how Reveal.js handles this? It also uses 3d positionning 😕

[bartaz]

Reveal.js only shows current plus next and previous slides. Rest is display none.

It's possible with impress if you write your CSS right, but you loose some possibilities (having all slides visible in 3d during transitions, transitioning betweetwen slides out of order etc).

[FagnerMartinsBrack]

I don't think there's much impress can do by itself.

The developer is the only one that can know if their requirements allow hiding steps, what we could do is understand the limitation and document it so that it doesn't leak to the user unexpectedly.

Allowing steps to be loaded through AJAX, for example, can fix the problem with memory overhead but if they can't load asynchronously then there's not much we can do.

The user can also choose to keep the frame of the step instead of the full content when it's not focused, but again it's a per use case decision.

[henrikingo]

@henrikingo did you make a PR for this?

It's complicated, but in short, yes, I submitted a PR for my very first changes (the qunit test framework), but it didn't end well, so I gave up on doing PRs. (I was myself part of impress.js maintainers too at that time.) My fork remains compatible with upstream impress.js (meaning, if you want to merge all 80+ additional commits together, you can), and I'm fully supportive of upstream impress.js catching up one day.

Other than that, I really don't want this thread to drift into a (potentially heated) off topic discussion, so if you have further questions about my repo, feel free to open a separate issue for that.

On the topic itself: There is also a patch which allows presentation authors to easily hide all slides except the current, previous and next, specifically to save RAM on small devices. I've added that functionality to my fork as well.

[Pierstoval]

Maybe there's a way to do like in video games : get all steps in memory, and on each slide, redraw the whole thing but keep only elements that are located in "extended" viewport size (meaning width+height+depth, each multiplied by 2 for example), this would allow the user and/or the developer to manually specify the "visible depth" as in video games when you want to specify the depth of rendering distant objects.

Do you think this is possible to do this at runtime? This would save a LOT of memory, actually, even for small projects.

There would be only some drawbacks depending on the presentation itself, for example the overview in the demo app may not show some of the elements.

Or maybe use canvas ? 😆

[henrikingo]

impress.js 1.0.0-beta1 now works (or at least tries to run) on any device.