YASB – Yet Another Symfony Blog

November 27, 2007

Apple, Safari, Windows and a whole lot of confusion

Filed under: HTML, WebKit — Krof Drakula @ 11:12 am

Before I start off, this isn’t a Mac vs. PC bash article. Nor is it a comparison between the two. I disclaim any statements about the superiority of each platform, since this will not be an article discussing these topics. That said, let’s move on to the topic of relevant interest.

As any self-respecting web developer, I try to cover as much ground as possible when it comes to the population of browsers that inhabit our Internet. It’s a pain in the ass, but we have to do it. Much of it is alleviated by the numerous JS and CSS libraries that I use to leverage the complexity of being cross-browser compatible (jQuery, Blueprint CSS, YUI CSS, just to mention a few). Still, it’s a daunting task.

Recently, Apple announced that it would be bringing the Safari browser to Windows and I thought “Gee whiz, it’d be great not to have to buy a Mac just to see IF my site works on a Mac.” I downloaded a copy, had it installed in less than a minute and was pretty impressed by the painlessness of the process. Nice job, Jobs (pun intended). My only gripe was the page loading time – everytime I’d start it up, it would take anywhere from 10-20 seconds to load up the first page, subsequent loads were quicker. I surfed a few pages thinking that it was good that it had its own typography rendering engine (nice to see how fonts look on Mac natively – very important for making accessible designs). Also, it seemed kind of… different. The pages I was looking at seemed more vibrant in colour. Then it hit me – of course, Macs have a gamma of 1.8 whereas Windows has 2.2. It must be using that preset to render colours within the browser. Neato, I thought, since most sites looked better.

What I was thrown off the chair for was testing a design I threw up with the help of a friend of mine. Nothing special, just a few background images and some JPEGs. Nothing special. Everything looked perfect on Linux and Windows (the two targets I test for primarily), worked on Opera, Firefox, IE6 + 7, Konqueror and a few other minor browser that I just felt like testing in. Finally I thought, “okay, moment of truth!” Fired up Safari on Windows and lo and behold, HTML colour space was different than the image colour space, be it PNG, JPEG or GIF (I even tried removing colour profiles from the images, to no avail). In plain terms, #00aa00 (HTML) != #00aa00 (image). All the backgrounds were now fractured at the seems and the page seemed like it was thrown together at gun point.

Now, I ask, what is the point of having your own colour space calibration if you don’t apply it consistently? While I don’t have a minimal test case for when this happens, I presume I just wasn’t paying attention at the other sites to notice a similar effect. Or I may be missing the point.

But the point is, I wasn’t expecting an image colour space misalignment problem, more of CSS and JS-related problems. I guess until Apple sorts this colour space problem in the Windows version of Safari, it’s widely unusable for anything but functional and layout testing purposes. It seems browsing the web on Windows is best left to non-Apple browsers. That, or depending on your colour blindness to counter the colour problem present.

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
jQuery("ul.error").fadeOut(1).fadeIn(1);

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
<div>&nbsp;</div>

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.

(more…)

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.*.

April 2, 2007

A list of handy browser-specific CSS selectors

Filed under: Browsers, HTML, Tips and tricks — Krof Drakula @ 7:12 am

Well, not exactly breaking front page news, but I thought I’d share this handy library of CSS selectors for targeting specific browsers:

CSS Hacks

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.

(more…)

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.

January 24, 2007

Fixing the column problem in IE6

Filed under: General, HTML, IE, Tips and tricks — Krof Drakula @ 1:31 pm

I’ve just stumbled upon a bug in IE6 that doesn’t manifest itself in IE7, and it has to do with floated elements.

I’ve used 4 floated columns to display 4 independent DIVs and floated them all left within a container DIV element. During development, I’ve been changing widths of the columns to get them aligned just right with the background images. All modern browsers (including Opera, Firefox and IE7) displayed all the columns fine. Except for IE6.

(more…)

Powered by WordPress