IE8 support?

[Anthony van der Hoorn]

Hey guys 

Its come up a little bit of late about whether we should support IE8 or not.

Currently, I don't actively go out of my way to prevent it from working, but I don't help it either. I know some stuff with HUD has made some of these issues come more to the surface.

My question is, how much time and energy to we want to spend bring the support for IE8 up to date?

My concerns with doing so is that it's not something that I am personally very interested in trying to maintain, that we could be opening a can of worms and that I don't want to bloat the code. Note, these aren't show stoppers if we decide its a need.

One option might be to have a separate embedded JS file that has the poloyfills required. This could be then included by a config option to turn it on or even make it a separate package. The nice thing about this as it gets around most of the above concerns and it could be maintained by those needing the required support.

Let us know what you think.

Cheers

Anthony 

[Adam Baxter]

I like the separate polyfill idea.

My interest in IE8 is only until I can use IE10 in my organisation, and I've been told it's coming Real Soon Now.

[Sebastian P.R. Gingter]

The separate polyfill idea is great. In an extra package... well, why not?

At work we need IE8 support because our WebForms application relies on 3rd party components that don't work in IE > 8. So we force newer IE's into 8 compatibility mode and this also uses the, well, not-so-capable IE8 JS engine with it's limitations. And so of course this hits our dev's when testing, even with IE9 and 10.

[nikmd23]

I think the polyfill solution is simple and elegant.

Of course, if a line of code in glimpse.js can be changed so it works in both modern browsers and oldIE than we should do that. (IE - Keep the polyfill lite where possible.)

Issue #418 is a good example of something that this polyfill could nicely handle.

From an implementation standpoint, I seems like this could be created easily as an implementation of IDynamicClientScript with a ScriptOrder of IncludeBeforeClientInterfaceScript.

Thanks,
Nik

[Christophe Gijbels]

If we look at Issues 418 then a polyfill might be the solution. On the other hand Glimpse already has a dependency on JQuery for a lot of UI stuff. So I'm wondering if we shouldn't use it more in code so that an issue like the above can be handled by JQuery as well? JQuery has been built just to address those cross-browser issues, so why not make more use of it? It would at least solve a lot of javascript incompatibilities so that we can focus on CSS issues for other versions of IE (anybody knows of a "polyfill" for CSS by the way?)

Also I would suggest using a library like underscore.js which already has some solid ground. It already acts as a polyfill for a lot of array methods, because today issues like #399 and #412 are reporting a missing indexOf method, but tomorrow it might as well be lastIndexOf or another one and solving each of then when they occur and with a custom polyfill might not always be the best way, although it is pragmatic ;-)

Any thoughts?

Cheers

Christophe

Op maandag 1 juli 2013 20:18:07 UTC+2 schreef nikmd23 het volgende:

[Anthony van der Hoorn]

In terms of adding new dependencies to Glimpse, I'm not the biggest fan on adding more than what we have at the moment. If we could cut a large amount of code from the code base or gain a large amount, but currently we don't deepened on or implement any of the functionality that Underscore provides (in fact, recently, I've been looking at whether we could remove jQuery). From what I can tell, it would mainly be 2 - 5 functions we need to support IE8. As for IE8 specifically, I don't mind pulling specific functions from Underscore that we need or other polyfills.

If someone was interested in getting this going, probably the easiest place to start is by adding the required functions https://github.com/Glimpse/Glimpse/blob/master/source/Glimpse.JavaScript/glimpse.util.js. We can then change the direct usage of the functions in question from the code base to call their equivalent in the glimpse.util. From there the polyfill module will override those functions defined in glimpse.util and replace them with ones that work for IE8. This has the advantage over just doing a standard polyfill as we aren't modifying the global namespace.

See a sample below:

Current Code

// glimpse.render.engine.master.js

(function($, engine) {

        ...

        provider = {

            build: function(data, level, forceFull, metadata, forceLimit) {

                ...

                if (isObject || isArray) {

                    if (stack.indexOf(data) > -1)

                        return '<em>--Circular Reference Detected--</em>';

                    stack.push(data);

                }

                ...

        }

        ...

})(jQueryGlimpse, glimpse.render.engine);

Modified Code

// glimpse.render.engine.master.js

(function($, engine, util) {

        ...

        provider = {

            build: function(data, level, forceFull, metadata, forceLimit) {

                ...

                if (isObject || isArray) {

                    if (util.indexOf(stack, data) > -1)

                        return '<em>--Circular Reference Detected--</em>';

                    stack.push(data);

                }

                ...

        }

        ...

})(jQueryGlimpse, glimpse.render.engine, glimpse.util);

// glimpse.util.js

glimpse.util = (function($) {

    ...

    indexOf: function(collection, data){

        return collection.indexOf(data);

    },

    ...

})(jQueryGlimpse);

// glimpse.polyfill.js

(function($, util) {

    util.indexOf = (collection, data){

        ... // polyfill code

    },

    ...

})(jQueryGlimpse, glimpse.util);

      

Hopefully this makes sense.

Cheers

Anthony   

         

 

--
You received this message because you are subscribed to the Google Groups "GetGlimpse-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to getglimpse-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Adam Baxter]

Agreed. It's one or two array functions (I have it working with one). No need for a framework - the framework in this case is Glimpse

[Christophe Gijbels]

I see what you mean by not adding more frameworks as needed, especially if you're thinking about removing JQuery.

I do wonder why you would add the additional polyfill module to overwrite the default util implementation? 

Why not have the util implementation of a method deal with the availability of a native method directly? The util module can be seen as the polyfill module then.

Cheers

Christophe

On Tue, Jul 9, 2013 at 10:35 AM, Adam Baxter <volt...@voltagex.org> wrote:

Agreed. It's one or two array functions (I have it working with one). No need for a framework - the framework in this case is Glimpse

--
You received this message because you are subscribed to a topic in the Google Groups "GetGlimpse-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/getglimpse-dev/10RN1g4MCm0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to getglimpse-de...@googlegroups.com.

[Anthony van der Hoorn]

As far as I can see the util method talks directly to the native method and then, with the aid of that abstraction, the polyfill module provides alternate implementations if needed.

--

You received this message because you are subscribed to the Google Groups "GetGlimpse-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to getglimpse-de...@googlegroups.com.

[Christophe Gijbels]

Idd, I was just wondering why not put that logic inside the util.js module directly? Since the util module is only added to handle cases where native methods do not exist and a fallback is needed. If a native method is always available (or no issues have been reported so far), then the util module wouldn't be used. So the util module seems to be the polyfill module, no?

like in 

// glimpse.util.js

glimpse.util = (function($) {

    ...

    indexOf: function(collection, data){

        if(collection.indexOf) {

          return collection.indexOf(data);

        } else {

          ... // polyfill code

        }

    },

    ...

})(jQueryGlimpse);

Cheers

Christophe

[Christophe Gijbels]

I mean with the approach metnioned, you'll have to conditionally load the polyfill module, otherwise the native method will never be called even if it exists

[Anthony van der Hoorn]

I see. The reason why I don't want the polyfill logic in the glimpse.util directly is because I don't want it to weigh down the rest of the client just to support IE8. If we put it into the glimpse.polyfill.js file, we can only include this file when we detect IE8. Does that make sense?

[Christophe Gijbels]

yups, if you want to load the polyfill conditionally then the suggested approach makes sense.

I guess when you say you don't want the polyfill to weigh down on the rest of the client, that you foresee that this polyfill might become quite big in the future?

Because this approach adds additional logic since now you need to add that conditional check for IE8 (while checking for the feature 'is indexOf available' might be more appropriate than checking for a browser version) somewhere -> did you foresee to do that server side or client side? 

Cheers

Christophe

[Adam Baxter]

On Tuesday, 9 July 2013 20:29:17 UTC+10, avanderhoorn wrote:

I see. The reason why I don't want the polyfill logic in the glimpse.util directly is because I don't want it to weigh down the rest of the client just to support IE8. If we put it into the glimpse.polyfill.js file, we can only include this file when we detect IE8. Does that make sense?

I know you didn't want to use a conditional comment, but this is where they're best used.

<!--[if IE 8]>
<script src="polyfill.js"></script>
<![endif]-->

[Anthony van der Hoorn]

We will do this, or something that we detect on the server and include if needed. If that doesn't work well we can fall back to the above.

[Christophe Gijbels]

The conditional <!-- [if IE 8]> check can become difficult, because Glimpse scripts are rendered as a whole (glimpse_client resource), which means that the Glimpse.js file contains all the Glimpse code at once, which would mean that the util.js module needs to be loaded at the beginning and that the polyfill needs to be conditionally loaded direct after it, since util code can be used by the next modules which are defined in the same file (which is generated as well)

So you can't add the conditional comment before Glimpse is loaded, since the util module would not exist or would overwrite the value set in the conditional comment script

and you can't add it afterwards since at that moment there might already have been some Glimpse code that needs one of the polyfilled util methods that has run as part of the glimpse_client script.

Maybe changing the Glimpse code so that it has 2 glimpse.js files where you render a conditional statement in between in the GlimpseRuntime GenerateScriptTags as in:

<script type='text/javascript' src='/Glimpse.axd?n=glimpse_client_part1&amp;hash=ddce2d3f'></script>

<!--[if IE 8]>
<script src='/Glimpse.axd?n=glimpse_polyfill&amp;hash=ddce2d3f'></script>
<![endif]-->

<script type='text/javascript' src='/Glimpse.axd?n=glimpse_client_part1&amp;hash=ddce2d3f'></script>



But then you end up with 2 calls for the glimpse client library. Or maybe if you could have a reliable test for IE8 on the server side, then you could have a second generated glimpse.ie8.js file as a resource and include that one, then there is no need for a conditional comment anymore, we only need to generate a second glimpse.ie8.js file with the polyfill inside of it.


Any other ideas?


Cheers


Christophe

--
You received this message because you are subscribed to a topic in the Google Groups "GetGlimpse-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/getglimpse-dev/10RN1g4MCm0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to getglimpse-de...@googlegroups.com.

[Steven Moberg]

Trailing commas are a bigger concern because they break on non ES5 browsers such as IE7 and IE8.

Some missing functionality such as 'Array.indexOf', and 'JSON.stringify' can be patched with a local include file but its would be the responsibility of developers targeting older browsers to ensure this gets included, but this fits nicely into a glimpse.config file like the 'bundle.config' for ASP.NET MVC, and then include those files before the glimplse.core.js script tag.

For pollyfills you could always implement a common utility as suggests, but allot of it is already handled by the jQuery core such as $.inArray(data, collection), they are just not utilized. Everything else could be satisfied with a CDN if you don't want to inflate the Glimpse.js file with a lite AMD.

if (!JSON) {
// load JSON2.js from CDN
}

Perhaps default a 'glimpse.config' file that has expressions and references to CDNs which would also allow for mapping to local files. Kind of like the ScriptManager enhancements in 4.5

http://blogs.msdn.com/b/pranav_rastogi/archive/2012/09/21/asp-net-4-5-scriptmanager-improvements-in-webforms.aspx

A little off topic, I'll put a feature request to define a global JavaScript variable on a page to STOP or TARGET glimpse rendering on that page/frame. I know framesets are so 1990-ish, but Glimpse act quite odd when there are multiple frames rendering.

[avanderhoorn]

Trailing commas have been addressed. If we can shift the conversation from here over to this issues - https://github.com/Glimpse/Glimpse/issues/399 - that would be great.