Warning for users with unsupported browsers

[GoogleCodeExporter]

Wondering if it might be a good idea to provide a warning to users of browsers 
that won't work with SVG-edit and offer alternatives. Not sure if it should be 
a popup, or a completely separate page - I think the latter might be cleaner, 
rather than them seeing a broken interface.

Original issue reported on code.google.com by adrianbj...@gmail.com on 14 Jan 2011 at 12:28

[GoogleCodeExporter]

Sure - patches welcome! :)

Original comment by codedr...@gmail.com on 14 Jan 2011 at 3:02

[GoogleCodeExporter]

I have done a bit of reading about the most reliable method. I know that you 
have posted about detecting the adobe svg viewer plugin and Alexis has a script 
for detecting inline support, but of course neither of these will fulfill our 
needs in this case. 

I have seen something similar to this mentioned a few times:
document.implementation.hasFeature("http://www.w3.org/TR/SVG11/feature#Shape", 
"1.1")

This is basically what the modernizr script uses (code from Erik Dahlstrom) and 
is also mentioned on diveintohtml5.org:
return !!(document.createElementNS && 
document.createElementNS('http://www.w3.org/2000/svg', 'svg').createSVGRect);

Do either of you have any thoughts on this approach or whether there might be 
something better available?

Original comment by adrianbj...@gmail.com on 15 Jan 2011 at 1:09

[GoogleCodeExporter]

I think checking for both of these things is fine.  You can put it in the 
browser.js module, expose a public method (supportsSvg) and then make a call 
immediately upon invocation of svgcanvas.js or something...

Original comment by codedr...@gmail.com on 15 Jan 2011 at 2:07

[GoogleCodeExporter]

Thanks for the tips. 

Unfortunately because IE8, and presumably any other browser that doesn't 
support SVG, choke on "var svg = document.createElementNS(svgns, 'svg');", I 
had to define the function and expose the public method together before the 
createElementNS line in browser.js. It is ugly, but it works. 

I have set things up to redirect to another page, telling the user of their 
browser incompatibility:
http://ian.umces.edu/svg-edit_trunk/trunk/editor/browser-not-supported.html

or you can test the entire redirect with an incompatible browser at:
http://ian.umces.edu/svg-edit_trunk/trunk/editor/svg-editor.html

Really not sure about including caniuse.com in the iframe like that. It gets 
the information to the user the quickest, but it is a bit messy. Perhaps I 
should create a nice simple page with an SVG-edit logo, the lack of support 
message, some suggested browsers and then a link off to canisue.com. Any 
thoughts?

I am also wondering if maybe a JS alert box might be better, just in case the 
svgSupport check is incorrect and svg-edit will in fact work in their browser.

Original comment by adrianbj...@gmail.com on 15 Jan 2011 at 6:30

• Changed state: Started

[GoogleCodeExporter]

Cool - but surely you can wrap things in a try-catch?  I personally don't have 
any strong opinion about how we message it, so just use your best judgment.

Original comment by jeffschi...@google.com on 16 Jan 2011 at 12:51

[GoogleCodeExporter]

Well there are several instances of var svg = document.createElementNS(svgns, 
'svg'); in browser.js and also several other issues that prevent non SVG 
browsers from getting to the Public API section at the bottom. I could wrap all 
these bits in try-catches, or wrap almost the entire browser.js file in one 
overarching try-catch, but this doesn't seem right to me.

Because there are several other js files that get called between browser.js and 
svgcanvas.js, there are several other svg related things that cause errors in 
non svg browsers, so I decided to simply define and call the function at the 
start of browser.js file. I also added an else to the 
if(!svgedit.browser.supportsSvg()) { and put the rest of the functions in there 
so that the browser-not-supported.html page doesn't report any of the svg 
related JS errors.

Maybe I'll just commit my changes as they are since they seem to work well and 
can be improved upon if someone else wants, or if you can suggest to me how to 
use a try-catch efficiently in this case, I would be happy to take care of it. 
I am no expert, but should we be adding try-catches just to hide errors that 
occur in browsers that don't support SVG, rather than not processing the code 
in the first place?

Thanks again for your advice.

Original comment by adrianbj...@gmail.com on 16 Jan 2011 at 2:57

[GoogleCodeExporter]

Fixed in r1917, but definitely open to suggestions for improvements.

Original comment by adrianbj...@gmail.com on 16 Jan 2011 at 3:28

• Changed state: Fixed

[GoogleCodeExporter]

Cool - I think you need to do:

$ svg propset svn:mime-type text/html browser-not-supported.html

and then check it in again.

Thanks!

Original comment by codedr...@gmail.com on 16 Jan 2011 at 5:35

[GoogleCodeExporter]

Sorry about that - taken care of now, although it never displayed as html 
source for me - does that only happen in certain circumstances?

Original comment by adrianbj...@gmail.com on 16 Jan 2011 at 4:14