Desktop browser support for Piskel

[juliandescottes]

Raised during PR #109

Which browsers do we aim to support ?

• Latest Chrome and Firefox for sure.
• IE ??
• Safari ??
• Opera ??
• Omniweb ?? (trololo)

Let's keep the discussion around desktop browsers, since piskel is not mobile/tablet ready.
My take :

• IE 10 + : why not, if not too costly. IE still lags behind when it comes to standards and it also lacks the auto updates
• Safari : would actually be nice since it paves the way to support safari mobile. But that's the only reason I see.
• Opera : I don't care

Do we test all of them ? Or do we just try not to break the browser compatibility voluntarily (and fix bugs when reported)

[grosbouddha]

I pretty agree with everthing:

• Latest Chome/Firefox/IE
• no safari (eventually just webkit rules for CSS3 support), no opera, no konqueror, no lynx
• about testing:
  • it should work and be tested in chome all the time (every commits) (easy since that the main browser used for dev)
  • should work most of the times in FF (test sometimes, every few commits)
  • For IE10: we should at least write compatible code but no testing enforced. If we really want to make it run on ie10, probably easier to do some focused work on it every month-ish.

If we don't support a browser, we should probably have some warnings for the user, in particular for nearly-modern browsers (Safari, opera, old chrome/ff).

[captainbrosset]

Opera switched to blink, supporting it is not going to be a big hassle (at work, I tested our massively HTML5 app on Opera for the first time after almost 1 year of dev, and it worked the first time), but considering the market share, you might not even want to test ... anyway, just saying ...

Firefox should normally be just as easy as Chrome to support, given how similarly well it implements standards. However there are some tiny differences (just came accross this https://github.com/juliandescottes/piskel/blob/master/css/style.css#L58 which basically causes the drawer to be expanded on Firefox when piskel starts).

As for IE10, I wouldn't worry too much about it lagging behind, it works pretty darn well these days. The auto-update is indeed the key problem here.

In any case, even if Piskel remains a mono-page app with a relatively low set of features today, it's already too much to test manually on all browsers and ensure no bugs appear, so you're gonna have to automate testing!
Perhaps a set of WebDriver based tests would help for 2 reasons:

• they can be targetted at a PhantomJS instance, running during your build or pre-commit hooks (so all the time)
• they can be used to test Firefox and IE (which you could run on VMs).

[juliandescottes]

@captainbrosset do you know if there is a service we could use to get VMs

[captainbrosset]

In fact, since IE10, latest CH and latest FX can run together in one OS, I was more thinking along the lines of using one of the many computers you surely have lying around at home, making it run selenium tests on these browsers.
The thing with Selenium is that, since the tests can drive PhantomJS afaik, they could also be used on Travis, during the build.

[captainbrosset]

I saw you guys started to create a test using casperjs. Although I think this is great, it has the disadvantage of being tied to phantomjs only, therefore webkit.
So: http://net.tutsplus.com/tutorials/javascript-ajax/headless-functional-testing-with-selenium-and-phantomjs/

[grosbouddha]

2 cents: This setup (selenium+phatomjs) is exhaustive and powerful but it
looks DEAD heavy and I'm not sure anybody of us wants to maintain a perfect
solution that suck too much time to maintain or that will swallow our dev
cycles at dev time.

Advantage of phantomjs: the setup is dead-easy, no VMs, no java deps. We
won't have cross-browser non-regression tests, ok. However what we will get
is non-regression on architecture changes. For instance, If we refactor and
remove a semantic CSS class which is used by a piece of JS, a related test
will catch it using phantomjs. This kind of architecture misuse or
regression will break uniformly across browsers. Another way to put it: If
it breaks with phantomjs, it will break everywhere, which mean that we are
fucking up badly the application. I do care about changes that don't
respect the architecture. I think we can forgot about these small
cross-browser issues and let them bubble them back to us while developing.
We can as well rely on our front-end engineering experience and using
pull-request reviews to limit them.

For now, piskel is a non-commercial, for fun-only and 3-users application.
I'm not sure I want to put my time in this kind of heavy setup, just the
architecture non-regression using phantomjs looks fine to me.

On Sun, Jun 23, 2013 at 8:35 PM, Patrick Brosset
notifications@github.comwrote:

I saw you guys started to create a test using casperjs. Although I think
this is great, it has the disadvantage of being tied to phantomjs only,
therefore webkit.
So:
http://net.tutsplus.com/tutorials/javascript-ajax/headless-functional-testing-with-selenium-and-phantomjs/

—
Reply to this email directly or view it on GitHubhttps://github.com/juliandescottes/piskel/issues/110#issuecomment-19878713
.

[captainbrosset]

You're shortsighted @grosbouddha, ther's loads of money to be made with piskel, I'm sure ;-)
More seriously, what you said sounds completely reasonable. Fine by me.
And it's true that this kind of setup demands more than what you guys can probably put in right now, for little value.

[juliandescottes]

For now we'll need to stick with manual testing. Piskel is changing too much lately to be properly int tested. When (if) we're done with experimenting, we will write more integration tests. And then we can think about phantomjs-only or phantom+webdriver.

So we're left with :

• Supported browsers (by order of testing) :
  • Chrome latest
  • Firefox latest
  • IE10 latest