Dealing with unsupported browsers, the right way.

[Rafael del Valle]

After asking the question on #sproutcore I have been asked to open the
debate here:

What is the best way to deal with unsupported browsers?

We should consider several "levels" of incompatibility:

-Browsers incapable of starting up sproutcore (say, IE5, IE6)
-Browsers that will start Sprouctore but the application will not
provide an adequate user experience (in our particular case IE7).
-Browsers that will fully run Sproutcore but the application has not
been designed for that browser or form factor (say, an Iphone trying
to run an SC desktop only application).

I think it is very important that users get a clean message of what is
going on.

While the 2 latest points can be handled with SC.browser and a bit of
code, the first one requires some additional effort, SC hacking, or
Web workarounds.

Is it possible to instruct sc-build to allow custom JavaScript on the
index.html?

From my point of view, it would be ideal to have sc-build to take an
"unsupported URL" as a directive and have the user redirected to that
URL if there is no support for its browser.

It is not trivial to know which browsers are supported for SC (from
which particular versions, etc). It would be good to have some
collective knowledge addressing the issue, etc.

Thanks,
Rafael

[Tom Dale]

Hi Rafael,

If you'd like to do custom browser sniffing, you can insert JavaScript into your index.html file using the :bootstrap_inline directive in your Buildfile. For example, let's say you had some custom JavaScript in myproject/frameworks/bootstrap/bootstrap.js. You could add a line like this to your Buildfile:

:bootstrap_inline => ['sproutcore/bootstrap:javascript', 'bootstrap:bootstrap']

(Note that we've included the original SproutCore bootstrap file in this configuration so that the SproutCore framework continues to initialize properly.)

Of course, there are many approaches to determining browser compatibility, from doing it at runtime using JavaScript to sniffing the user agent server-side. I agree that we probably need better messaging in the event an unsupported browser is detected, but so far browser support seems to be app-driven rather than framework-driven. In other words, for the large-scale applications I'm familiar with, compatibility is restricted by the custom views and logic of the application rather than the framework primitives, so I'm not sure if a "one size fits all" solution makes sense at present.

Best,
Tom

[Rafael del Valle]

Tom,

thanks!!

I agree with you in terms of app-driven browser compatibility.

Then, It would be nice it you could declare compatible or non
compatible browsers in your build file and provide an url to redirect
to. It would be app-driven and reusable at the same time.

At the end of the day, shouldn't all SC applications check their
compatibility at boot time?

I will experiment with the boostraping as suggested.

Rafael.

On Jan 25, 6:31 pm, Tom Dale <t...@sproutcore.com> wrote:
> Hi Rafael,
>

> If you'd like to do custombrowsersniffing, you can insert JavaScript into your index.html file using the :bootstrap_inline directive in your Buildfile. For example, let's say you had some custom JavaScript in myproject/frameworks/bootstrap/bootstrap.js. You could add a line like this to your Buildfile:

>
>         :bootstrap_inline => ['sproutcore/bootstrap:javascript', 'bootstrap:bootstrap']
>
> (Note that we've included the original SproutCore bootstrap file in this configuration so that the SproutCore framework continues to initialize properly.)
>

> Of course, there are many approaches to determiningbrowsercompatibility, from doing it at runtime using JavaScript to sniffing the user agent server-side. I agree that we probably need better messaging in the event an unsupportedbrowseris detected, but so farbrowsersupport seems to be app-driven rather than framework-driven. In other words, for the large-scale applications I'm familiar with, compatibility is restricted by the custom views and logic of the application rather than the framework primitives, so I'm not sure if a "one size fits all" solution makes sense at present.

>
> Best,
> Tom
>
> On Jan 25, 2011, at 1:28 AM, Rafael del Valle wrote:
>
>
>
> > After asking the question on #sproutcore I have been asked to open the
> > debate here:
>
> > What is the best way to deal with unsupported browsers?
>
> > We should consider several "levels" of incompatibility:
>
> > -Browsers incapable of starting up sproutcore (say, IE5, IE6)
> > -Browsers that will start Sprouctore but the application will not
> > provide an adequate user experience (in our particular case IE7).
> > -Browsers that will fully run Sproutcore but the application has not

> > been designed for thatbrowseror form factor (say, an Iphone trying

> > to run an SC desktop only application).
>
> > I think it is very important that users get a clean message of what is
> > going on.
>

> > While the 2 latest points can be handled with SC.browserand a bit of