Weird timing issue with Mathjax - mathjax

I'm using MathJax with PageDown in a pretty straight forward way.
InitMathjax(converter);
var html = converter.makeHtml(text);
var $pageText = ...;
$pageText.html(html);
This works most of the time when I run the site locally, and almost never works when I run it in production. The result can also vary between each reload, so I think there is some kind of race condition based on how long it takes for various scripts to load and run.
I've tried doing Mathjax.Hub.Reprocess() and such, which don't seem to help. Doing MathJax.Hub.Queue(["Typeset", MathJax.Hub, $pageText.get(0)]); 100ms after the above code seems to have fixed the issue. But this feels like a patch, and the font looks off in production. (Looks like mathjax generated html ends up in a <span class="MathJax_Preview">, rather than <span class="MathJax">).
I want to understand the issue so I can actually fix it. Thanks!

Related

Universal correct links from navigation partial (express.js & handlebars)

this seems like a very stupid question, but I really can't figure out how to do my navigation links properly.
I'm using express.js with handlebars as view engine.
My backend.handlebars has a naviation bar and loads in every sub-page of my backend under "/admin". It looks like this:
<nav>
Dashboard
Add Post
Edit Post
Categories
Static Text
</nav>
Now the correct routes are:
[server-adress]/admin/ for the dashboard
[server-adress]/admin/add for adding posts
[server-adress]/admin/edit for the editing posts
etc.
Now the way I've setup my links sometimes works and sometimes doesn't.
Sometimes every link works correctly when I'm in a sub-route like "admin/add" and want to go to "admin/edit".
Sometimes every link works when I'm under the main "admin/" to every sub-page, but not the other way around.
And sometimes everything works as intended, mostly when I delete the dot in front of the slash and then add it back end, restarting both times.
This obviously is too much of a gamble when deployed. As I don't know the absolute adress due to changing servers, I can't use absolute paths.
How do I go about this correctly?

How do set a default accessed partial?

There's a lot of individual features that would make this easy, but instead of asking for specific features, I'll start with the actual goal.
I'm starting dust.js on nodejs, using consolidate to link it in... I plan to set the templating up from the beginning to support partial-renders and client-side renders... Seems smart!
But I have this partial-render at the top of my index.tt:
{>layout layout/}
It works great, giving me an html wrapper... but it seems it should be trivial for me to set a variable that will override this, either not rendering that partial, or rendering something like "no_layout" where it's a passthrough partial.
If I use "{layout}" instead, I'm fine as long as I make sure every runmode explicitly sets layout="layout".
If dustjs had the concept of value-defaults, I'd be fine... but I tried it, and it looks like node has to do that part (wrapping an if statement didn't seem to work, nor did an inline ||).
If dustjs let me run dustjs code conditionally, I'd be fine... but it looks like all the #if statements are about rendering.
I get that we want to keep separation of concerns, which is why I'm going to use dustjs in the first place... This to me seems like it should be a view-side concern when it will happen in the default way 99% of the time.
Here's the code I have right now (except layout.dust, which doesn't matter):
index.dust:
{>layout "{layout}"/}
{<main}
Welcome to {title}
{/main}
{/profile}
index.js:
exports.index = function(req, res){
res.render('index', { title: 'Express',layout: "layout" });
};
Like I said, it works... but it feels hacky and makes me have the controller explicitly tell the view to "render normally".
I think I will conclude that this isn't possible, and that there are so few users on dustjs that picking it because "big companies are picking it up" was a bad idea.
This is a guess, but I think the answer to this question is that nobody ever thought of this obvious situation.

Primefaces & IE9 rendering issue

We have some annoying rendering issue with Primefaces 2.2.1 & IE9. There seems to be some kind of "two step rendering" after certain ajax updates.
In the first step, the ajax-updated code is rendered without the proper css applied to it - this looks messy, like so:
In the second step, the proper css is applied and everything looks as expected, like so:
Not all ajax updates have this rendering issue, but we have a hard time sorting out what triggers this behaviour.
If you have any ideas or hints, please let me know, since this is really annoying & ugly.
Regards: jimmy

How to customize the way objects/resources load from my website created with Joomla?

Suppose I want the browser to load an image right on the first connection it makes to my website. How do I do that, considering that by default the image loads later on when it's actually called for?
Also, after the whole page finishes loading, suppose I want to load more objects (say images) that aren't required yet but are just for buffer. How do I do that? Help me people, I've been at it for quite a long time.
I'm somewhat successful with the first problem by adding a script tag while actually calling an image at the beginning of my index.php's html head part which goes like:
<script src="http://www.mysite.com/my/image/url.png"></script>
But this I realize is bad scripting.
As for "Why would you want to do that?", it's for educational purposes and also because when someone visits my site, I need to load and display certain things before other things get loaded.
For preloading you probably could start with
<body onLoad="Preload('image1.jpg', 'image.gif', 'image.png', ...)">
And preload is a JavaScript function which adds each of the array of images to DOM like
document.imageArray[i].src = args[i];

YUI Loader for YUI 3 does not load tabview

I have spent hours with this issue. I'm about ready to tear my project apart, line by line to get this figured out. But I was wondering if anyone else had this issue:
My project works great in Firefox. My customers use IE (classic - alot of people do...). My boss wants me to get this done yesterday.
I can't get IE 8 or 9 (with my document in IE 7 emulation mode) to run the following, and load the TabView. I get an error in the debugger console that telling me that it doesn't load it. I have all the required modules for tabview loaded via tags, so there is no dependence on an Internet connection - offline operation (again.. works great in Firefox).
YUI({bootstrap:false,insertBefore: 'yui3-style-overrides', filter: ''}).use('tabview','tabview-base','event-synthetic','event','event-custom','event-mouseenter','oop','yui','dom','dom-base','node','io','datasource','resize','anim','anim-easing','event-base-ie','dom-style-ie','node-focusmanager','node-event-simulate','plugin','classnamemanager','pluginhost','event-base','tabview-plugin','attribute','base','widget','widget-base-ie','arraylist','widget-parent','widget-child','event-simulate',function(Y) {
/* sand boxed code here */
});
Recently yui (3.2 or 3.3) factored out their ie fixes into separate files in the build. This caused a nightmare for me as well. You could test it with 3.1.1 if you want to isolate your variables.
What contributed more to my insanity was that I was stupid enough to use the YUI PHP Loader, which gets worse with every YUI release because YUI is getting so many dependencies even hacked up crap like the PHP Loader cannot account for all situations.
I worked around this by manually loading all the -ie- files using
<!--[if IE 7]><script type="text/javascript" src=myfile.js></script><![endif]-->
for a month or two before I was able to come up with a smarter but larger version of PHP Loader (Which, alas, I cannot share).
To see if this is your problem, use that if ie script above for every IE specific file in the build folder. Here is a list:
build/dom/dom-style-ie-debug.js
build/event/event-base-ie-debug.js
build/history/history-hash-ie-debug.js
build/scrollview/scrollview-base-ie-debug.js
build/widget/widget-base-ie-debug.js
If I were you, I'd manually load all of those except for maybe history, which you might not need - just so you can minimize your variables.
TBH, when I had this problem and troubleshot it, I loaded every yui JS file. It took a while, but the bug disappeared and I was hot on the trail of finding the -ie- files issue.

Resources