"transition" property firing as soon as the page loads in webkit
See original GitHub issueHi,
I was testing out -prefix-free for the first time (btw: very cool/great work!) and quickly noticed that the transition property was being fired when the page loaded in webkit.
Steps:
- Add some simple css:
.test {
width: 400px;
height: 400px;
padding: 20px;
color: white;
background-color:black;
box-shadow: 10px 10px 10px red;
border-radius: 20px;
transition: 0.2s all;
}
.test:hover {
opacity: 0.8;
}
- Add the corresponding div:
<div class="test">
Hello
</div>
- Add prefixfree.min.js (it doesn’t matter where, but I added it to the head just after the style tag.
- Load the page in Safari or Chrome.
Result in Safari 5.1.2 (6534.52.7) & Chrome Canary 22.0.1225.0:
- The box scales to its final dimentions (going from 0px -> 400px) when the page loads.
Result in Firefox 13.0.1:
- The box just appears normally.
Here’s a test: http://jsfiddle.net/ar_fiddles/VW7g9/
Expected Result:
- The box should just appear on the page (at 400x400px) and only fire the “transition” property (converted to -webkit-transition thanks to -prefix-free) when changing the opacity on :hover.
I would only expect the box to scale into its final dimensions as the page loads if the box started with 0x0px and another class, with the 400x400 dimensions were later added to the DOM which would tell the transition property to fire. I imagine this might be what -prefix-free is doing… Then again, maybe I’m missing something really simple (I did a bunch of searching first but didn’t find anything).
Thanks.
a.
Issue Analytics
- State:
- Created 11 years ago
- Comments:5
Top GitHub Comments
There is a bug in Google Chrome for this. This can be avoided just by adding a script in the page. Even an empty script solves the problem.
https://bugs.chromium.org/p/chromium/issues/detail?id=332189
@normamendonca
Thanks for the update!
I just tried to reproduce in Chrome Canary [Version 59.0.3060.0 (Official Build) canary (64-bit)] via my original testcase and couldn’t. But I don’t know if that means anything, because I think Prefixfree is no longer doing anything to the DOM that triggers the bug (since Chrome 59 doesn’t need the prefixes it did when I originally reported in 2012!). But I could be wrong.
Sidenote: It also looks like https://jsfiddle.com stopped loading Prefixfree directly from Github (there were errors in the console about MIME types). So for a while there (years!) the testcase was likely broken! I just updated to pull from from https://www.jsdelivr.com/projects/prefixfree (Prefixfree @ 1.0.7)
I also checked out that Chrome bug report and the test case. It still happens there, as mentioned in the thread.
But I tried your fix (empty
script
tag + space) and it worked. Weird!Thanks again.