Tiny-slider: False negative "PERCENTAGELAYOUT"

Created on 20 May 2019  路  9Comments  路  Source: ganlanyuan/tiny-slider

__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

Most helpful comment

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.

All 9 comments

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...

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?

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

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

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?

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,
      },
    },
  });
}

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.

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.

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.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

cyocun picture cyocun  路  4Comments

CristianEstiber picture CristianEstiber  路  3Comments

nireve picture nireve  路  4Comments

stu-fu picture stu-fu  路  3Comments

DimaGashko picture DimaGashko  路  3Comments