It looks like you're new here. If you want to get involved, click one of these buttons!
:: CSS Transitions [script]
//function adapted from https://bitbucket.org/tmedwards/sugarcube/src/4771625160fe3ab833a936748a164476b9f7f43e/src/story.js?at=default beginning at line 144
History.prototype.display = function (title, link, render) {
var passage = tale.get(title);
...
// add it to the page
var el = passage.render();
el.style.visibility = "visible";
if (render !== "offscreen") {
var passages = $("#passages");
outgoing = passages.children();
outgoing.addClass("transition-out");
setTimeout(function () {
if (outgoing) outgoing.remove();
}, 1);
...
};
2) Use SugarCube's special PassageReady story passage to intervene before the incoming passage is rendered. This almost works. But somehow doing it this way does not quite control display properly. The only way to actual see the out transition is by including an alert, as I have done in this code:
:: PassageReady [nobr]
/% Runs just before each passage is rendered. %/
<<script>>
var passages = $("#passages");
var outgoing = passages.children();
outgoing.addClass("transition-out");
setTimeout(function () {
if (outgoing) outgoing.remove();
}, 0);
alert("!");
<</script>>
Any ideas what I might be able to do with either of these options to get this working?
Comments
#1 should be fine, as long as you're using it with the same version of the header from which you got it. Try replacing this section: With this: You'll also need something like this CSS: I suppose I could add something like this as a configurable to the next release (whenever that will be).
The problem with #1 is that it simply doesn't override SugarCube's default code. I've even tried just replacing all of the code in the function with just an alert, but there's no change in functionality--the games works fine.
(emphasis mine) I already said as much about #2 in my last reply. Reading failure?
Then you did it wrong. I'm not being dismissive, it simply cannot fail to work if done properly. Perhaps the story wasn't rebuilt afterwards? You did use the entire method, yes?
I'd call it a miscommunication. Your comment on #2 could equally well be read as referring to my own code's immediately calling jQuery's remove() method in response to a 0ms timeout. Which is in fact how I read it.
It looks OK to me and works perfectly well when I paste it into another project, so I'm guessing that there is something that is silently causing the passage not to be read in properly. I'll have to check on that tomorrow.
Ah, yes, I can see that. Fair enough then. To clarify though, I was referring to the removeChildren(passages); call in the default code removing the elements almost immediately after PassageReady completes.
Well, if you can get it to work in a another project then my off-the-cuff guess would be either a copy-paste snafu or maybe the script tag is misspelled or something like that.
PS: I have gone ahead and added configurable code for outgoing transitions, so if all else fails I can always push a small release so you can try that.
Example setup:
Yes, I rather like that myself. It really does need to be configurable somehow, IMO. If it's a fixed period and you want your transition delay to be noticeably shorter or longer, then you run into situations where you're either stuck waiting for the outgoing elements to disappear or your animation is getting interrupted because the elements were removed too soon.
I'm not sure. The last time I looked into them, there were still bugs in various desktop browsers related to transition end events (sometimes they don't fire properly, etc). I also have no clue what support on mobile browsers looks like.
EDIT: Wait, that's actually something you can test. If the outgoing elements are sticking around, check to see if the div.passage element with the ID out-passage-{passage title slug} has an event handler for the transition end event (whichever one is being used, which is determined and set at startup) bound to it.