Theme Color IE issue (improve bundling, etc, for older browsers)

[sohrabtaee]

When I add themeColor it breaks in IE11 with this error:

SCRIPT8: The download of the specified resource has failed.
docsify.min.js (1,2752)

[timaschew]

Please show a code snippet.

[sohrabtaee]

The problem is that IE11 does not support CSS variables: https://caniuse.com/#feat=css-variables

I added the proper polyfills and it works fine now.

Since Docsify is advertised as "Compatible with IE10+", I guess a polyfill should be added to support CSS variables in IE.

[anikethsaha]

shipping polyfills may increase the package size. I think we should update the docs with the guided steps ?

cc @jhildenbiddle @trusktr thoughts?

also, @jhildenbiddle if we need to ship polyfill for css variables from core, thoughts about css-vars-ponyfill ?

[jhildenbiddle]

Best to have docsify handle loading all necessarily libraries (like poly/ponyfill) as needed via dynamic imports. This keeps the bundle size down, prevents users from having to manage multiple libraries just to get docsify working, and allows the docsify team to easily swap libraries for all users in future versions (e.g. switching from ponyfill "A" to ponyfill "B").

FWIW, docsify-themeable bundles css-vars-ponyfill, but this is only because times were different back when docisfy-themeable was created. If I were doing it today (and this is a change I will likely make in the future), I'd load css-vars-ponyfill via dynamic import instead of bundling:

const hasCSSCustomPropSupport = window?.CSS?.supports?.('(--a: 0)');

if (!hasCSSCustomPropSupport) {
  import('https://cdn.jsdelivr.net/npm/css-vars-ponyfill@2')
    .then((module) => {
      // Do stuff...
    });
}

(If you unfamiliar with the window?.css ... syntax, see @babel/plugin-proposal-optional-chaining for details)

[anikethsaha]

We need to ship polyfill for dynamic import as well right ?

[jhildenbiddle]

Nope. Bundlers like Rollup and Webpack handle these without issue or need for a plug-in.

[anikethsaha]

ahh, yea
We will be migrating to webpack so I guess we can make use of that

[jhildenbiddle]

What’s the issue with Rollup? Why Webpack vs Parcel, Snowpack, or some other bundler?

Not pushing for one over another, just wondering what the rational is for moving away from the current tool?

[anikethsaha]

webpack is kind of optimal for creating a browser bundle.
We will be using rollup for the cli

[trusktr]

I haven't tried Parcel yet, but Parcel is Webpack with default configuration to make life easy. Users do need a polyfill for ES Modules in older browsers to make an output `.esm.js` file consumable, which is something they can add (and doesn't need to be shipped with Docsify). Perhaps we should mention it in the docs when we get around to adding the ESM build. *#!/*JoePea

…

On Tue, Jun 2, 2020 at 11:11 AM Anix ***@***.***> wrote: webpack is kind of optimal for creating a browser bundle. We will be using rollup for the cli — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#707 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACIVTTDI5XIP7QRMS7P7CTRUU6EBANCNFSM4GGLYLKQ> .

[trusktr]

As an idea, here's what Tween.js' output dist/ folder looks like: https://github.com/tweenjs/tween.js/tree/1f85d6e74491037653ddad2ee4193958f09928e2/dist

Probably not many people (if any?) will use the .amd.js build. Modern bundlers, and native ES Modules in browsers, will make use of the .esm.js output. The .umd.js output is what people use for the traditional global-style <script src=""> tags.

[jhildenbiddle]

Let's move the bundler conversation over to #1168.

[jhildenbiddle]

Fixed in #1743