formVista Development Blog

window.location.href failing under MSIE 6

no_author@no_author.com — Mon, 02 Nov 2009 22:02:01 EST

So I had a function:

function fv_loadUrl( parms )
{
var elem = parms.elem;
var href = parms.href;
window.location.href = href;
return true;
}

Works like a champ in FireFox, but not in MSIE 6. I read a post that speculated the script was terminating before the page could load. Changing the return true; to return false; solved the problem.

Javascript Closures

no_author@no_author.com — Tue, 20 Oct 2009 18:11:33 EST

A technical article on Javascript Closures.

And an article describing an approach to dealing with closure memory leaks.

And an article describing a tool to track down memory leaks in MSIE.

A Firefox, Web Developer or FireBug bug

no_author@no_author.com — Mon, 19 Oct 2009 18:09:29 EST

This has represented a few hours of my life. At the present moment I don't know if the bug lies in firefox, the web developer extension or the firebug extension.

I'm using Firefox 3.0.13 under Kubuntu Linux (9.04) with the Web Developer extension v. 1.1.8 and the FireBug extension v. 1.4.3.

Consider the following small HTML page:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<title>FireFox a name ul bug</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
</head>
<body>

<a name="comments"/>

<ul id="comments_list">
<li>
<div>
<a href="void" >TEST</a>
</div>

</li>
</ul>

</body>
</html>

Using the http://validator.w3.org it validates.

Opening the page in firefox and viewing the source yields the HTML above, as one would expect. What threw me for quote some time however is that if you do a "select all" on the page and right click -> view selection source you get:

<html xmlns="http://www.w3.org/1999/xhtml"><head>   <title>FireFox a name ul bug</title> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1"> </head><body>  <a name="comments">  </a><ul id="comments_list"> <a name="comments"> </a><li> <a name="comments">  </a><div> <a name="comments">   </a><a href="void">TEST</a>

  </div>   </li> </ul>  </body></html>

As you can see there are now three erroneous <a name="comments"> interspersed between various tags. The same behavior happens under FireBug if you inspect the element.

If you change the <a name="comments"/> to <a name="comments"></a> and repeat the select all view selection source experiment it yields:

Which is correct. Since the page validates using the <a name="foo" /> notation, it seems to me it should not trash the DOM.

To see the bug in action, here's a test page.

At the present moment, my formVista blogging software does not support anonymous comments. If you would like to comment on this article please register for an account using the register link in the upper left corner.

PHP split() is listed as deprecated and will be removed

no_author@no_author.com — Sun, 18 Oct 2009 15:51:41 EST

This is one of the liabilities of using a language long term that's in a high state of flux. As you continue to build larger and larger codebases, the work required to change that codebase as the language changes increases linearly.

The formVista codebase started in 2001 and has been growing ever since. During that time the PHP language has changed significantly. In many of these cases these changes address fundamental design flaws in the language such as the whole way objects were done in PHP 4. (A change which will in the near future force me to evaluate each and every object assignment in the entire codebase. ouch.)

So today I was looking at the PHP documentation for the split(). I'm endless forgetting if the string or the delimiter comes first. To my shock and horror split() is now deprecated.

Of course you can use explode() or preg_split(), but it's another case of having to crawl through a codebase and change things. IMHO, in this case it's completely needless and arbitrary. If the underlying code that implements the split() function needs to be changed, then a wrapper function should be included so that legacy code does not break.

A Gotcha when using FireBug with Legacy HTML

no_author@no_author.com — Tue, 13 Oct 2009 17:55:41 EST

Firebug absolutely rocks. When tracking down the effects of errant CSS cascades, html quirks, DHTML side effects, etc, nothing beats Firebug.

However, today I ran into a little gotcha that consumed a few hours of my life. I wanted to align some drop downs and input fields nicely for the admin side of a new microblogging twitter/facebook/digg type component for formVista.

The backend of formVista has a bunch of legacy code. Parts of it were written close to 10 years ago. Slowly as we develop out the new moderinzed FVML tag set, we're going through and updated the very dated looking backend components.

I figured it was some style that was cascading down. Some margin, padding or alignment. Firebug showed nothing. I edited the styles inline. No joy. No matter what styles I applied the form fields displayed in the center of the form. I started to believe maybe I had run into a CSS bug in Firefox.

Then I realized the culprit. In formVista, components are hosted on pages but are completely separate. As a result, I don't spent alot of time actually looking at the HTML pages themselves. I focus on the component FVML files where all the work happens. The hosting HTML pages are just wrappers.

Legacy wrappers.

The page in question, where my newly styled component was living, used an ancient table based layout.

<table width="100%">
<tr>
<td valign="top" align="center">
...etc...

And therein lies the problem. The align="center" was cascading down and overriding my styling. My guess is that firebug doesn't have a way to handle this case, or that I'm missing something in it's use.

Re-arrange the hosting page to use a CSS layout and problem solved.

An Overview of the jQuery CSS Framework

no_author@no_author.com — Sat, 10 Oct 2009 14:39:57 EST

In case you're like me an missed this document, here's a link to the jQuery CSS Framework documentation:

http://jqueryui.com/docs/Theming/API

jQuery UI CSS scopes

no_author@no_author.com — Fri, 09 Oct 2009 20:25:30 EST

In the previous version of formVista we had a single jQuery UI installation with a theme roller created theme.

Then for each formVista theme we would override key parts of the themeroller theme. This has turned out to be a painful approach. So instead, I'm moving to a setup where we use themeroller to create a full jQuery theme for each formVista theme. It should end up being more maintainable. Time will tell.

As part of this effort and to avoid some unfortunate interactions between jQuery.UI styles and styles from other components, which in formVista are all dynamically loaded, I decided to try applying a CSS scope (i.e. prefix) to the themeroller generated theme.

This works fairly well except in the case of dialogs and other popup tags that are direct descendants of the <body> tag. In order to apply the CSS Scope to the dialog, you have to wrap the dialog in a div containing your scope. As mentioned in this blog article over the filament group, you can use:

$(.selector).dialog().parents(.ui-dialog:eq(0)).wrap(<div class="myScope"></div>);

to wrap the dialog.

The one problem with this approach is that if you happen to be creating a modal dialog, a separate div implementing the modal behavior is created /outside/ of the wrapping div which means it does not get the CSS scope style.

I'm still working on a solution to this issue.

My understanding is that jQuery will have a "helperClass" attribute at some point in the future to address this issue. Until then, I'll have to implement some hack or continue on just using a global style.

Update 2009-09-10

I've decided to fall back and punt on the CSS Scope issue for now.

Another Javascript RIch User Interface library to watch - ExtJS

no_author@no_author.com — Mon, 05 Oct 2009 15:31:15 EST

An article over at slashdot.org referred to a commercial/open source rich user interface library called ExtJS available at: http://www.extjs.com/.

As of this writing it is dual licensed under the GPL and a Commercial License, similar to the way formVista is licensed.

After a cursory glance it seems like a fairly complete toolkit, but at this point I'm committed to continuing on with jQuery for formVista.

Xinha WYSIWYG HTMLEditor in jQuery.UI tabs

no_author@no_author.com — Sat, 03 Oct 2009 15:17:27 EST

More complex AJAX/AJSON applications such as Google Maps and the Xinha WYSIWYG HTML Editor do not render correctly when placed into hidden divs, presumably because they cannot correctly get the size of the div.

According to the Xinha ticket list, the editor must be visible before it is created otherwise it will be displayed in a broken and frozen state.

Problem #1: MSIE 6 Xinha in hidden div when size is set to auto

This can be reproduced by placing the Xinha editor into an unselected tab in a jQuery.UI tab control:

The editor does not size itself correctly to the surrounding div. In addition the editor is frozen.

Problem #2: MSIE 6.0 Form Element Rendering glitch

The jQuery.UI documentation offers a solution/workaround described as the oft-left technique which involves moving divs off the visible page instead of setting it to display: none;. Unfortunately under MSIE 6 this approach seems to break when used with something that contains form elements:

This occurs after the Description tab containing Xinha has been selected and unselected. The other downside to the off-left technique is that it can confuse screen readers.

A Work-Around

Given that it was clearly a sizing problem, I discovered that if you create the Xinha editor using fixed sizing the first problem is solved.This is done by setting the width and height properties of the XinhaConfig object before creating the editor:

var xinha_config = new Xinha.Config();
xinha_config.width = "700px";
xinha_config.height = "300px";

This solves the first problem.

The second problem, namely that the editor is frozen, can be solved by noticing that the Xinha method sizeEditor() can called without any arguments. Called in this fasion it recalculates its size based on how it was originally configured. This only seems to work if the editor has fixed sizing.

So whenever the tab is shown, just call resize. This can be easily accomplished by binding a callback to the tabshow event:

$('#tabs').bind('tabsshow',
function( event, ui )
{
if ( ui.index == 1 )
{
editor.sizeEditor();
}
} );

Assuming you have a global editor object avialable. I like to avoid globals whenever possible so, in formVista, when I process the <htmleditor> FVML tag, I add the editor object to the textarea using the jQuery core data() method as in:

$('form[name=someform] textarea[name=somefield]').data( "xinha_editors", Xinha.makeEditors(xinha_editors, xinha_config, xinha_plugins));

And then in my callback I just get the editor using:

var editor = $('form[name=someform] textarea[name=somefield]').data( "xinha_editors" )['somefield'];

Note that the value stored in the xinha_editors entry is an array of editors per instructions in the Xinha newbie guide. You can certainly do it differently.

Right now, the FVML <htmleditor> tag is not yet smart enough to know that it's inside a <tabbedcontainer> tag, so I just embed the callback into the FVML using a plain <js> tag. More on doing development in FVML another time.

Conclusion

This workaround seems to work in FireFox, MSIE 6, and MSIE 8. I have not yet had a chance to try it in other browsers.

So in summary, to get the Xinha WYSIWYG HTML Editor to work with the jQuery UI tab control in an unselected tab:

configure Xinha using a fixed size
call sizeEditor() when the tab containing the htmleditor is selected.

If you find any problems with this workaround or have any questions, please leave comments here or in the forum. (Unfortunately, I don't have anonymous posting built yet, so you'll need to register for an account. See the Register link in the upper right corner.)

From a follower on twitter - net-tuts

no_author@no_author.com — Tue, 29 Sep 2009 11:25:57 EST

What appears to be a compelling resource for javascript, jQuery, HTML, PHP and CSS info: http://net.tutsplus.com/

HTML5 <canvas> tag

no_author@no_author.com — Tue, 29 Sep 2009 11:13:11 EST

Yesterday I came across a few demonstrations of what's possible using the HTML5 <canvas> tag which opens up some very interesting possibilities.

According to Wikipedia - http://en.wikipedia.org/wiki/Canvas_(HTML_element)

Some examples of what can be done with the canvas tag:

Blob Salad

http://hyper-metrix.com/#Burst

http://balldroppings.com/js/

The Xinha WYSIWYG Editor, HTMLPurifier and the non-validating br tags.

no_author@no_author.com — Wed, 23 Sep 2009 13:41:56 EST

So I just spent some time tracking down a little bug which turned out to be my own stupid fault.

formVista uses HTMLPurifier to sanitize HTML that's submitted by end users. HTMLPurifier rocks.

However, Ryan over at Nuts and Bolts Interactive discovered <br /> tags submitted using the WYSIWYG html editor are changed to <br>. This is not correct for the XHTML 1.0 Transitional doctype that we're using on the front end.

After some digging, I realized that I had set the doctype correctly on the frontend but had set it to HTML 4.01 Transitional on the backend. (We still have a lot of work to do bringing the backend out of the stone-age).

Since HTMLPurifier was being loaded on the backend it was getting the backend's doctype and doing exactly what it was supposed to do.

So the takeway is, if HTMLPurifier is not doing what you expect it to be doing, make sure to check that you are in fact passing it the correct doctype.