Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Replace macro - transition CSS bug hunting

edited November 2014 in Help! with 1.x
I've always had to work around a bug when using L's <<replace>> macro.

The bug is incorrect transition behavior. No matter how the transition is styled, default or otherwise, the transition is nearly always instant; rarely, it will work properly, and I don't know why. After testing, I've learned that this bug is in <<replace>> 1.3.0, the combined replace macro set 1.1.5, and every iteration of <<revision>>.

Recently, while I was playing one of Porpentine's hypertexts, I noticed she used <<replace>> without the above issue. Curious - I'd been having the issue for well over a year now, and she'd announced this hypertext in the past few weeks. I imported the .html into twine, and discovered she used <<replace>> 1.0.0.

I tried using version 1.0.0 myself - the default transitions work properly 100% of the time.

In the very next version, <<replace>> 1.1.0, and in all subsequent versions, the bug is there. So the bug was introduced in 1.1.0 and has remained since.

I've attached two sample .html files, compiled twine stories as examples. Each uses the default CSS transition. The 1.0.0 version shows it functioning properly. The 1.1.0 version shows it functioning improperly.


  • edited June 2015
    Old thread but this issue has been plaguing me as well. Thanks so much for pointing out the 1.0.0 version! I cut and pasted the code out and reformatted it to being readable. After some digging I found this:

    In 1.0.0, L calls the fade() function to handle the transitions, which is a function built into the theme with what looks to be a callback as well. Since this uses visibility and opacity controlled by JS, it works within Firefox.

    In his combined macros, he sets the display:none/display:inline, and then relies on the CSS transitions to do the rest. This makes it so that the user can write their own transitions (in theory), however Firefox's CSS transition behavior is unpredictable when the display property is changed by JS. In this case it behaves as if the transition were complete already.

    I'm still working on the problem for my own projects so I don't have usable code to post, but hopefully that's a starting point for someone else.
  • Sorry, everyone. I updated the script with a somewhat clunky fix, which I shall explain thus:

    The transitions are implemented by first applying the .revision-span-in class, then removing it as quickly as possible, thus causing the element to transition from .revision-span-in to the regular text style. In other browsers, this class is removed after 1ms and works fine - however, FF doesn't work inconsistently when it's this fast.

    The clunky fix is to extend the delay from 1ms to 20ms, which seems to give FF enough time to recognise the need for a transition. I don't like this very much because it means that the times you supply to the <<timedcontinue>>, <<timedinsert>> etc. macros are now incorrect by 20ms, and it's now impossible to make them run any sooner. But, if this is what it takes to get it working, I guess I have to do it.
  • SugarCube's set has been synchronized with the new version.
  • edited June 2015
    I never encountered this problem in SugarCube. Timedcontinue, replace etc was working perfectly fine for me in FireFox.

    Maybe I just didn't notice it.

    Anyway, my game will only be for node webkit, so luckily cross browser compatibility isn't an issue.
Sign In or Register to comment.