Disable CSS Transitions #63

SamHasler · 2015-09-04T14:37:42Z

I had a page that wouldn't render correctly on Chrome Stable, but would on Chrome Canary, until I realised that the css used transitons, and because I have less chrome extensions on canary that run JS on page load, it was able to complete the transition before it rasterized the page.

Would it be possible to have an option for disabling CSS transition. Perhaps something generic that could look for rules with certain props, values or selectors and ignoring them.

Alternatively, could there be a configurable delay before rasterization?

cburgmer · 2015-09-05T08:24:41Z

Currently a fixed timeout is set in the code: https://github.com/cburgmer/csscritic/blob/master/src/browser/browserRenderer.js#L36

Can you show an example for where the rendering is incorrect? So far my assumption was that the browsers all ignore transition and animations when rendering inside an SVG.

If necessary, the HTML/CSS could be transformed, similarly to how :focus/:hover is supported: https://github.com/cburgmer/rasterizeHTML.js/blob/master/src/documentHelper.js#L10.

cburgmer · 2015-09-06T03:15:12Z

I was planning to support a "snapshot" feature for transitions/animations at some point, so one can test different frames throughout an animation. In that notion you would require the 0% stage I believe.

SamHasler · 2015-09-07T13:41:18Z

Testcase:

<!DOCTYPE html>
<html>
<head>
  <meta charset="utf-8">
  <title>transitions</title>
  <style id="jsbin-css">
  body * {
    -webkit-transition: 0.2s width;
    -moz-transition: 0.2s width;
    transition: 0.2s width; }


  .box {
    margin: 20px;
    width: 50px;
    height: 50px;
    display: inline-block;
    background: lightblue;
  }

  @media screen and (max-width: 768px) {
    .box {
      width: 100%;
    }
  }
  </style>
</head>
<body>
  <div class="box"></div>
  <div class="box"></div>
  <div class="box"></div>
  <div class="box"></div>
</body>
</html>

cburgmer · 2015-09-08T14:25:50Z

I can't reproduce with this example. Here's what I did:

Registered your testcase via

                .add({
                    url: 'testcase.html',
                    width: 700
                })

Opened it in Chrome 47.0.2504.0 canary (64-bit).

I also made the transition slower:

  body * {
    -webkit-transition: 100.2s width;
    -moz-transition: 100.2s width;
    transition: 100.2s width; }

I would expect that I'd see the small boxes, but instead they are always at 100% width.

Do I need to do something differently?

SamHasler · 2015-09-08T18:37:21Z

Try a width of 200. I'm sure I saw it with that. Approve it and refresh.
On Sep 8, 2015 3:25 PM, "Christoph Burgmer" [email protected]
wrote:

I can't reproduce with this example. Here's what I did:

Registered your testcase via
            .add({
                url: 'testcase.html',
                width: 700
            })
Opened it in Chrome 47.0.2504.0 canary (64-bit).

I also made the transition slower:

body * {
-webkit-transition: 100.2s width;
-moz-transition: 100.2s width;
transition: 100.2s width; }

I would expect that I'd see the small boxes, but instead they are always
at 100% width.

Do I need to do something differently?

—
Reply to this email directly or view it on GitHub
#63 (comment).

cburgmer · 2015-09-09T12:39:56Z

I can't reproduce with a width of 200. I am testing on Mac OSX - in my experience the environment can make a big difference.

cburgmer · 2016-05-03T14:16:10Z

I can finally reproduce on Chrome and Mac OSX. Did you happen to have a look at it in the meantime?

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Disable CSS Transitions #63

Disable CSS Transitions #63

SamHasler commented Sep 4, 2015

cburgmer commented Sep 5, 2015

cburgmer commented Sep 6, 2015

SamHasler commented Sep 7, 2015

cburgmer commented Sep 8, 2015

SamHasler commented Sep 8, 2015

cburgmer commented Sep 9, 2015

cburgmer commented May 3, 2016

Disable CSS Transitions #63

Disable CSS Transitions #63

Comments

SamHasler commented Sep 4, 2015

cburgmer commented Sep 5, 2015

cburgmer commented Sep 6, 2015

SamHasler commented Sep 7, 2015

cburgmer commented Sep 8, 2015

SamHasler commented Sep 8, 2015

cburgmer commented Sep 9, 2015

cburgmer commented May 3, 2016