YASB – Yet Another Symfony Blog

September 26, 2007

Yet another grievous error on IE’s part (updated: float problem)

Filed under: IE, Javascript — Krof Drakula @ 8:49 am

AJAX can be really useful sometimes. We all agree on that. We’ve pretty much solved the cross-browser divide when it comes to the XHR object by using libraries, but one thing still remains – what about the GUI?

I know this might seem like just another post about using AJAX and fancy GUI updates, but let me point out that it isn’t. It’s about a major error I’ve found in IE7 (and possibly 6) that kinda blows your whole client-side dynamic updates. I’m talking about rendering errors regarding lists in IE. The dynamically rendered ones.

A test case involves an unordered list (possibly ordered, too), which is empty by default (on page load) and gets populated after the AJAX request fires. What my script did was it took a JSON response and appended li elements to the list. You’d think something as simple as this would pose no problem to the new and improved Trident, but it does. The list expands as though the list items are there, but they’re transparent. If you want to see the contents, you have to drag a selection over the text (and even then renders only the letters that were actually selected), but they dissapear upon re-rendering.

The first solution I could come up with is to apply a CSS transformation to the text after adding li elements. Which is a major pain in the ass. I just did a quick .fadeOut(1).fadeIn(1) to force change in opacity:

// lang javascript

That way, no blinking would be noticed by the user since the animation would be faster than a screen redraw, thus eliminating the problem.

Haven’t done a baseline test on this one, but it shows just how grimey stuff gets when you’re not developing straight onto IE7 in the first place, then porting to others.

Long live Trident. You bastard.

UPDATE: I’ve managed to identify the culprit causing this disastrous behaviour – it has to do with floated elements and clearing elements. Also known as the Peekaboo bug. While this solution might not be appropriate for you, it worked for me in the given situation.

Basically, this problem manifests itself when you try to use floats, then a clearing element after them to ensure they are fully contained within a parent container div. The problem is solved by assigning the following style to the clearing element:

// lang html

The only problem here I can see is that it breaks pixel accuracy – while you can assign padding and margin of 0, you cannot style it with height:0 or font-size:0. And also, adds to the semantics of the page, which I personally dislike. Sure, you can class the style in the above example, but you still need to put a non-breaking space in there.

This was supposed to be fixed in IE7, as the link says. Guess not. (Tested on IE 7.0.5730.11, update version 0, Windows XP SP2 fully patched.)

July 14, 2007

RobotReplay, a usability testing tool

Filed under: Ajax, Browsers, General, Tips and tricks — Krof Drakula @ 4:54 pm

If you’ve ever asked yourself just why your web site or web app doesn’t perform as well as you’ve thought it would, since you’ve given a lot thought into the design of the page and user interface, then you might ask yourself – are you the proper person to be judging the design?

In comes usability testing. It’s giving the end user a chance to work with your product (in our case, a web page or application) and having a system measure the user interaction – how long it takes them to locate a certain function, where they have the most difficulty identifying a certain feature, finding information, etc. There’s already great software that does exactly this (Morae, for example), but the problem here is that you still need a lab to conduct such experiments.


June 13, 2007

Followup: Creating rich GUIs with Javascript in Symfony

Filed under: Browsers, Javascript, PHP — Krof Drakula @ 11:08 am

Well, I’ve written up a short summary of ideas relating to handling Javascript files in relation to requests, not it’s time to evaluate them.

First thing I’ve noticed with the different ways of injecting Javascript into the response is the order by which the files are loaded, the problem being dependency. If you’re using a library such as jQuery (or any other for that matter), the order by which the JS files are loaded is crucial. I usually force jQuery to use the noConflict mode by calling jQuery.noConflict() in a separate file (to keep the original library file intact in case of upgrades and updates) and loading it after jQuery. That’s done in the general view.yml file on the app-level configuration.

But when I try to add an action-specific JS to the mix, things start getting hairy – when you call $this-&gt;getResponse()-&gt;addJavascript(), it adds Javascripts to the beginning of the list of JS files, before the view.yml gets a chance to add its own. In this case, you’re limited to adding JS files via a module-level view.yml file by specifying the view to which you want to append the JS.

This is different when handling components – imagine having, say, a countdown timer written in Javascript. If you’d like to include it in several places but don’t want to handle the dependencies, then there’s a foolproof way of handling those – simply include the dependencies using $this-&gt;getResponse()-&gt;addJavascript(). This time, the components get rendered AFTER the main view, so including JS files this time adds them to the end of the list, after the main view’s files have been added.

The good thing about the latter is that you never have to worry about changing any view.yml files after including the component anywhere in your main views. That lends itself to building self-contained, no-fuss plugins using components, which, in the context of this article, could be HTML widgets, like calendars, calculators, AJAX comment boxes, shoutboxes, etc.

Anyways, hope this insight helps. Now for some midday coffee.

May 20, 2007

Using jQuery to manipulate a foreign DOM

Filed under: Browsers, HTML, Javascript, Tips and tricks — Krof Drakula @ 9:39 am

This is somewhat of an old topic, but digging through a myriad of ways of including jQuery into a website that doesn’t use it (eg. Wordpress having Prototype and such), I stumbled upon a bookmarklet written by John Resig that loads jQuery into the current DOM and enables you to run an onload function that executes when the library’s ready to use.

Here’s the page where the process is documented with an example of manipulating Digg using jQuery. The approach used with this bookmarklet is useful because it enables you to turn on the noConflict mode without manually waiting for the library to load. You do this by replacing the comment fragment in the bookmarklet with jQuery.noConflict() inside the onload handler and hey presto! you have jQuery enabled and available via jQuery.*.

March 30, 2007

Implementing rich GUIs in Symfony

Filed under: HTML, Javascript, Tips and tricks — Krof Drakula @ 9:57 pm

When it comes to rich graphical interfaces, we’re currently being swarmed by all these big and small players readily available on the net – there’s Script.aculo.us, YahooUI, Yui-Ext, Moofx, to name a few of the most prominent. All’s fine and dandy until you try coding some of the stuff inside views of actions.


February 10, 2007

Getting jiggy with the Yahoo! UI library

Filed under: General, HTML, Javascript — Krof Drakula @ 1:59 am

I know I’ve been away a while, but I’ve been knee deep in preparing for our upcoming show and finishing up on some projects at work and at home.

More relevantly (is that even an adjective?), I’ve been implementing the Yahoo! UI JS/CSS libraries, augmented with Jack Slocum’s excellent Yui-Ext. It provides incredible flexibility and code logic organization, better than any I’ve seen so far. I especially like Yahoo’s event handlers, which resemble somewhat the .Net approach, where you can actually define your own events and having object calls abstracted via listeners, further improving object isolation. Not only does this guarantee better object interoperability and easier debugging (imagine going through chains after chains every single time), it takes care of all the wiring for you.

So, to get things back on track, I’ll submit some code snippets from the next upcoming project, Horseshoe, for which I’m developing the browser frontend. It’s actually not a Symfony project, but it’s a tool that everyone could use – a test suite browser, supporting multiple testing engines. The testing server and browser will be decoupled, meaning the interface will be consumable by either the HTML/JS client or a wholly different one, since the server will support multiple protocols.

As always, stay tuned.

Powered by WordPress