ganlanyuan / tiny-slider

Vanilla javascript slider for all purposes.
MIT License
5.24k stars 784 forks source link

False negative "PERCENTAGELAYOUT" #415

Open zipper opened 5 years ago

zipper commented 5 years ago

Issue description: In production version of our web, the PERCENTAGELAYOUT is set to false in IE 11. But in development, this value is true. This results in incorrectly set tns-no-subpixel class and broken styles of a carousel in this browser. The function percentageLayout returns different values even though these environments should be same. No other browser has this inconsistency.

The reported width od outer (class .tns-t-ct) from getComputedStyle is 7233.33px, which is clearly subpixel (and same as in Chrome). The problem is, that children has computed width 102.71px in production, but in development, they have 103.33px (again, nearly the same as in Chrome's 103.328px). I have no idea where this inconsistency comes from. As a result, the difference is well over 2 thus returning false.

Although the styles for no subpixel carousel doesn't work correctly, only the first item of carousel can be seen. That is probably caused by flexbox beeing used, so the margins are not processed as expected.

Demo link/slider setting: Settings doesn't affect this bug, since the method percentageLayout doesn't depend on any specific carousel.

Tiny-slider version: 2.8.8, but this code doesn't change in newer versions. Browser name && version: IE11 OS name && version: Windows 10

zipper commented 5 years ago

Moreover, when I'm looking into this, setting font-size as 0px and then in the child setting to px value is not clean at all 😞 Font zooming in older browsers might get broken with this technique...

tomsnep commented 5 years ago

I'm having the same issue. on Localhost tns-subpixel is set. On production environment tns-no-subpixel is set, which also results in an uncorrect layout (IE11 only). Maybe something gets broken during compiling?

gmatkowski commented 5 years ago

same here ... can You please fix this or show a workaround?

ganlanyuan commented 5 years ago

@zipper Could you make a demo for this issue? I can't reproduce it on my end.

ganlanyuan commented 5 years ago

Moreover, when I'm looking into this, setting font-size as 0px and then in the child setting to px value is not clean at all 😞 Font zooming in older browsers might get broken with this technique...

Which browsers? Do you have a better solution for this?

tpinne commented 4 years ago

I'm having the same issue. on Localhost tns-subpixel is set. On production environment tns-no-subpixel is set, which also results in an uncorrect layout (IE11 only). Maybe something gets broken during compiling?

We have the same issue. Spinning up a dev environment with typescript, webpack, blablala everything works fine in IE11 and it uses tns-subpixel class. After building it for production the slider gets rendered in IE11 with tns-no-subpixel.

Nothing fancy. Just a simple ts file doing import { tns } from 'tiny-slider/src/tiny-slider'. Settings as mentioned above have no effect for this bug.

We use the following webpack config if it helps:

const config = {
    mode: isProduction ? 'production' : 'development',
    entry: {
      app: `./${project.appDir}/scripts/main.ts`,
    },
    output: {
      path: path.resolve(__dirname, './.tmp/scripts/'),
      publicPath: 'scripts/',
      filename: '[name].bundle.js',
    },
    module: {
      rules: [
        {
          test: /\.js$/,
          exclude: /node_modules\/(?!(dom7|ssr-window|swiper)\/).*/,
          use: ['babel-loader'],
        },
        {
          test: /\.vue$/,
          loader: 'vue-loader'
        },
        {
          test: /\.ts$/,
          use: [
            {
              loader: 'babel-loader'
            },
            {
              loader: 'ts-loader',
              options: {
                transpileOnly: true,
                appendTsSuffixTo: [
                  '\\.vue$'
                ],
                happyPackMode: false
              }
            }
          ]
        }
      ],
    },
    resolve: {
      extensions: [ '.ts', '.js' ],
      plugins: [
        new TsconfigPathsPlugin()
      ],
      alias: {
        vue$: 'vue/dist/vue.runtime.esm.js'
      }
    },
    plugins: [
      new VueLoaderPlugin(),
      new webpack.ProvidePlugin({
        $: 'jquery'
      }),
      // new BundleAnalyzerPlugin(),
    ]
  };

And this is our simple slider.ts file

import { tns } from 'tiny-slider/src/tiny-slider';

export const sliderControlsText = [
  '<i class="d-block fas fa-chevron-left"></i>',
  '<i class="d-block fas fa-chevron-right"></i>',
];

const offerNewsSliderEl = document.querySelector('.offerNewsSlider');

if (offerNewsSliderEl) {
  const offerNewsSlider = tns({
    container: offerNewsSliderEl,
    controlsText: sliderControlsText,
    items: 1,
    slideBy: 1,
    loop: false,
    nav: true,
    // @ts-ignore
    navPosition: 'bottom',
    gutter: 20,
    responsive: {
      768: {
        items: 2,
        slideBy: 2,
      },
    },
  });
}
tpinne commented 4 years ago

I've tried to put together a barebones repo to make it easy to reproduce... But here it gets weird... If I simply build the sources in our clickdummy in production context and serve them locally from the dist folder everything works as expected. But when I copy the same built sources (which currently is our "workflow"...) to our CMS (local running VM) the mentioned issue appears. The HTML of the slides is the same. The md5 hashes of files, the production bundle from the clickdummy and the copied version, match each other.

So there is currently nothing I can do, to provide a reproducable example, because I don't have any clue what could be the difference that causes wrong behaviour.

joselogil commented 4 years ago

Hi, @tpinne, we were having the same issue. I fixed it doing this, when no-subpixel is set: .tns-horizontal.tns-no-subpixel > .tns-item:not(:first-child){ position: absolute; top:0; left:0; bottom:0; }

that seems to fix this issue.

danjdewhurst commented 3 years ago

I can confirm all of the above. Is minification of the JS/CSS somehow breaking whatever that subpixel class is using the decide which it uses?

Also, the above CSS hack fixed the visual issues.