Better failure mode with some legacy IE versions

[bergie]

The GSS website renders perfectly on IE11:

On IE8 we have a nice failure mode where only the CSS gets rendered, so users of this crappy legacy browser can read everything, but don't get the layout. This is acceptable:

However, IE9&10 both have the issue where they render nothing:

We should investigate whether we can either:

1. Fix GSS on those so that they will be like IE11
2. Disable GSS on those so that they will have the nicer failure mode that you get with IE8

[bergie]

Precompilation to CSS should also help with legacy browsers

[bergie]

It should be noted that IE10 is probably a recent regression. The build that we use on http://flowhub.io/ was working on IE10 and WP8 back in December when I last time saw a Windows device

[forresto]

Also Safari 5.1, according to https://github.com/the-grid/flowhub.io/issues/70

[Rodeoclash]

Out of interest, what's preventing things from running on earlier versions of IE? Is it something could possibly be addressed or is it impossible?

[forresto]

http://www.browserstack.com/ would be useful for quick testing.

http://www.modern.ie/en-us/virtualization-tools#downloads for free virtual machines.

[forresto]

@d4tocchini before precompiling, could you just sniff the browser version and only enable on whitelisted browser/versions? Quick & dirty; nicer than blank screens.

[donaldpipowitch]

Which IE versions do you will support in the future? Do you have a roadmap somewhere?

[FrigoEU]

To echo Rodeoclash: What exactly is going wrong in IE8/9?

[d4tocchini]

The GSS runtime should work with IE 10. IE 9 testing needs some love...

The key feature on our roadmap that will enable GSS to work with the legacy IE's, and any other crappy browser you may care to support, is pre-computation - where we boot up a browser in node (with something like phantom.js) precompute all the constrained values for every screen-size and spit out a huge map of vanilla css values, thus eliminating the entire runtime. This will make GSS theoretically faster than even a native CSS implementation b/c values will be resolved to constants targeting id selectors, but it will only work for deterministic layouts. Working on this with @bergie next month...

[Rodeoclash]

+1 to the pre-compilation!

[Inviz]

We do have experimental pre-computation in #interpreter branch. But it works only for static pages. There's ongoing research project that will mathemathically compute some dynamic setups into static css with media queries, calcs and dynamic units

[sebpatu]

Do you have any planning date about when you intend to have a final solution, to handle legacy ie versions, because it is a big stopper for me (and for sure, for a lot of others) to start using this great layout system.

If you already have a pre-computation working for static pages, it would be great to add it to the official release of gss. Its far better than nothing. we can at least, pre compute a new css on server at each page resize, and load it in client page for refresh of layout, it may be a bit slower, but acceptable on high speed internet connections.

[Inviz]

Basically, we do what you describe, and it's not suitable for most of the websites - there're many limitations. We don't have the bandwidth to support something with so many edge cases. Trust me, the simple way of doing it brings the worst of the both worlds - still needs js, fully static, prone to error.

You can expect some better solution in upcoming months as we're approaching public release for our main product.

There's certain possibility to make GSS work in IE8 and maybe even IE7. Of course their javascript engines are far slower than what other browsers can offer. We don't use anything special, and we feature check wherever possible. If there're people reading this who're into that kind thing, I'll provide all the help to contribute and debug issues.