greenwood website home page loading has syntax error with internet explorer 11 (also causing no logo fade?)

[thescientist13]

Type of Change

• New Feature Request
• Documentation / Website
• Improvement / Suggestion
• Bug
• Other (please clarify below)

Summary

Loading the Greenwood website in IE11 and the home page loads, but the fading text doesn't show and the button color is green not blue (like in #196 ).

Otherwise the site is working pretty good! (also, this looks the same in production before the Polyfills changes)

Details

Maybe something to do with CSS @keyframe / animation? Not sure if that's a different issue from the syntax error?

[thescientist13]

Wondering if es5 adapter would be needed for this to get the syntax error fixed?

From there, not sure if we would also need some sort of PostCSS plugin for the fade too, to support CSS @keyframe / animation?

Found a SO post that seems to have a working solution for the CSS, once the syntax error is fixed.
https://stackoverflow.com/questions/34809544/css3-animation-is-not-working-in-ie11-but-works-in-other-browsers

[thescientist13]

Trying a few things to fix the loading error, no luck so far

• https://stackoverflow.com/a/52264800/417806
• why lit-html is not transpiled to es5 in npm? lit/lit#516 (comment)

Created a branch to try some of these things out with this and other various attempts

Seems like from the second screenshot, that some ES6 features aren't getting transpiled. Maybe open it up to all node_modules just to confirm?

[thescientist13]

oh, right. this should probably use process.cwd(), not __dirname. 🤦‍♂

[thescientist13]

So digging deeper into this, it looks like .babelrc isn't even getting loaded, likely because babel-loader is looking for the file in the root. 🤦‍♂

Once I added it as an option

module: {
  rules: [{
    test: /\.js$/,
    loader: 'babel-loader',
    options: {
      configFile: path.join(__dirname, 'babel.config.js'),
      include: [/node_modules/]
    }
  }, {

things started working breaking, so at least something is happening now, but will need to go down the rabbit hole a bit on this though, but definitely should git it fixed.

Will also probably want to look into checking .browserslistrc is also configured correctly as well.

[thescientist13]

OK, got babel configuration working, but still seeing an issue in IE11 with class not getting recognized

Made an issue for tracking babel configuration specifically, removing P0 from this ticket #256

Probably because browserslist isn't working :/ . (will likely need to make a new issue)

[thescientist13]

Will need to enable process of node_modules, but this might mean it makes sense to do #224 instead...

[aholtzman]

Considering the audience for this site is primarily developers and others within the technology realm it seems incredibly unlikely that anyone visiting the site with IE 11 would be doing so intentionally. I vote to not worry about supporting IE and to close Thai and any related issues.

[thescientist13]

Hmm, I certainly see your point regarding maintaining the website, but I wonder if the real world use cases out there support it though from a Greenwood CLI perspective? I feel like especially in corporate / enterprise and some (local) government, IE11 is still a meaningful consideration in regards to their user's browser demographics and so I feel like it's still worth tracking #224 at least. (I guess i was mostly keeping this open to keep us honest about the limitations of Greenwood? That said, maybe we can track along with the USWDS and their of support of IE11 as a leading indicator, which I think they plan on dropping soon?)

Basically, I would like to piggy back of our polyfills plugin and add support for (opt-in) differential loading so that (maybe in combination with our Babel plugin) a user could still build with modern standards and WCs, but still have the option to operate in an ES5 environment. WebComponents polyfills provide an ES5 adapter which I think we would want to leverage in this case.

---

TL;DR I agree for the website we can drop IE11 (close this issue), but I think providing a differential loading mechanism is still useful, so still keep #224 open, though at a lower priority unless someone asks for it perhaps? When we do add it, that's when we can use the website as an opportunity for dog fooding.

Thoughts?

[aholtzman]

That is a solid plan.