Browser support

[tremby]

I'm aware that the docs say I can look at the support property, but it would be really useful to have a chart of supported browsers as part of the documentation.

[bikeath1337]

I tried to update the readme to emphasize what browsers are compatible with Evaporate. I know there were some issues with bugs on IE but as they seem to have been addressed, I think that the documentation around support of the File API should suffice. There is also a link to a list of that browsers that do support that API and should be compatible. What do you think?

BTW, I also added a note that computeContentMd5 should really be set (it defaults to off) for any new application. It's related to browser compatibility because if you don't use checksums, you don't need the File API...but everyone should be using checksums, as you've probably already seen in your tests of huge files...the corruption in transit is surprisingly common.

[tremby]

I don't agree.

Saying "browsers which support features XYZ", even with links to lists of said browsers, isn't easy to understand. A new user coming here and considering evaporate for usage will see it as a chore to then go and look all this up. Add to that that different browsers have different levels of support for certain features, or buggy implementations, and it's very hard to get a solid idea of whether evaporate would be supported or not.

A new user coming here wants to know straight off the bat which browsers and versions it should be working in.

[jakubzitny]

Maybe something like this would be cool http://godban.github.io/browsers-support-badges?

[bikeath1337]

Totally agree. Who wants to take on the task of keeping the list current and making sure we have a pull request to merge it at appropriate intervals?

I've been around awhile and know that the task of maintaining browser compatibility lists is much work work than many people think.

In terms of clarity of presentation, I like the badge concept!

[jakubzitny]

Maybe after there is a reasonable test coverage here, we can try adapting all tests for some sort of automated browser testing suite and run that on Travis (or somewhere else before every release).

[tremby]

I wasn't suggesting it would be easy or pleasant to add. But one person who knows the software well can do a much better job of it than a potential user who don't know the software at all. If the information isn't in the readme here, each potential user individually has to take on the same task if they want to be sure the package is suitable for their use case.

[bikeath1337]

Agree with you completely.