Archive for the ‘safari’ Category

* Surfin’ Safari

Posted on October 9th, 2008 by Dave Johnson. Filed under AJAX, CSS, JavaScript, XML, completeui, quirks, safari.

For the past little while I have been busy fixing up Complete UI to work in Safari. The big problem for us in getting Complete UI working in the WebKit powered browser was that there was no client side XSLT JavaScript API until Safari 3.

So there were a few things I had to update to get things all working properly - and this more or less applies to Chrome now as well but I need to check on a few things.


The first problem I came across was using the XMLDocument::selectNodes method. To get selectNodes working I had to implement my own NamespaceResolver which is usually handled for you by the browser.

I had to change the call to the XMLDocument:evaluate method a bit to look like this:

var oResult = this.evaluate(
  new MyNSResolver(),

Where the MyNSResolver class essentially implements the lookupNamespaceURI method through a switch statement returning the appropriate URI for the specified namespace prefix. Pretty easy but kinda annoying to figure out!

function MyNSResolver() {};
MyNSResolver.prototype.lookupNamespaceURI = function(prefix) {
  switch (prefix) {
    case "xsl":
      return "";
    case "ntb":
      return "";
      return null;

XSLT Transformations

Then there was the actual act of performing an XSLT transformation. Doing the transformations was fine but getting the output node or string from the transformations - depending on if the <xsl:output /> was text, html or xml - was rather different than both Firefox and Internet Explorer. Go figure.

For transforming to an XMLDocument here is what I found to be the output of an XML transformation for the various output methods.


<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "">
<html xmlns="">





XSLT Parameters

There is also one difference in how the Safari XSLT processor deals with parameters. Rather than casting true / false to 1 / 0 the Safari XSLT processor does not recognize true or false values and requires the inputs to be 1 / 0. I have started setting all my XSLT params like this:

oXsltProc.addParameter("paramName", val+0, "");

Events and Focus

There were some other small issues that I came across regarding implementing rich keyboard navigation and events in general.

For example, in our Grid component I had to change the HTML element that we used to “focus” the Grid so that we could capture key presses from a <DIV> to an <INPUT>. Apparently you can’t call Element:focus on a <DIV> element from JavaScript but you can on an <INPUT> (even with a tabIndex set but I try to avoid those for accessibility reasons anyhow).

However, that was not my only problem with keyboard navigation. The other problem was that the focusable element (the newly created <INPUT> in this case) was still not getting focus due to a small code snippet like this:


That second line where I cancel the event (wrapped nicely in a cross browser library call) somehow prevents the <INPUT> from getting the focus. Never figured out a workaround aside from a browser check before calling cancelEvent.


Finally, in some of our components we also generate CSS using XSTL and dynamically insert it into the page. For example, the developer defined column widths in a Grid produce dynamically generated CSS. However, WebKit does not seem to support the bulk creation of stylesheets neither using the document.createStylesheet method of Internet Explorer nor the hacky way of doing in Firefox by creating a <STYLE&gt element and setting the innerText. Instead Safari requires that you use the uber slow DOM API for adding rules to stylesheets :(


You will often see the “xml namespace prefix mapped to wrong URI” error when working with XSLT in Safari.

Be careful that you are using double quotes in your XSLT for attributes etc and only use single quotes in attribute values.

Of course you also have to be very careful about the nodes that you are transforming / selecting as you are also likely to get the “WRONG_DOCUMENT_ERR” fairly frequently.

Oh yah and depending on the application expect a lot of random “Stack overflow” errors!

Tags: , , , , , , , .

* Complete UI Q2 Released!

Posted on May 1st, 2008 by Dave Johnson. Filed under AJAX, JSF, Nitobi, completeui, safari, treegrid.

We managed to finally pull things together and get the release out despite some attempts by .NET build tools to sabotage the entire release!

With this release we now support Safari 3, have added a bunch of new themes to help you make your apps look hot, some new Dreamweaver extensions that mean there is no JavaScript to write to make master-detail grid or combo applications, and most importantly Mike did an awesome job on getting the new TreeGrid component done!

There are some exciting things in the works as well for next week - including screencasts and even some JavaServer Faces love!


* Complete UI Q2 Progress

Posted on April 28th, 2008 by Dave Johnson. Filed under AJAX, Nitobi, Uncategorized, completeui, dreamweaver, safari.

We are almost a month behind now on the Q2 release of Complete UI but Mike and I are in the final throws of polishing. We are shooting for releasing today and if that fails tomorrow at the latest. As people will know from the beta we are releasing support for Safari 3, new Dreamweaver Extensions, new themes and, most importantly, a new component called TreeGrid for displaying hierarchical data. I have a can of Red Bull in hand and one last Safari Combo bug to fix before the building will commence!


* TreeGrid and Safari Almost There

Posted on March 11th, 2008 by Dave Johnson. Filed under AJAX, Nitobi, completeui, safari, treegrid.

Just a few more days until the Q2 Beta!


* Grid 3.5 and Beyond

Posted on June 20th, 2007 by Dave Johnson. Filed under AJAX, Nitobi, Web, air, safari.

Just a quick note about the recent release of Complete UI and Grid in particular.

There are a few things to note about the recent release.

As Mike mentioned, both Grid and Combo now, like the rest of Complete UI, support standards mode - w00t. This has been a long time coming but it seems to be working pretty well so far!

Also of note with Grid is that it is much faster to load up in most cases. For example, the editors sample loads in about half the time of the the previous release. But don’t worry, there is still lots more room to improve there and we are actively working on it!

Complete UI also has two new components - Calendar, and Spotlight. AND Calendar has been integrated into the Date Picker control for Grid!

More fun stuff coming up with support for Safari 3, AIR and some new components and major updates to old ones like Tree and Grid.


* Grid With AIR and Safari 3

Posted on June 14th, 2007 by Dave Johnson. Filed under AJAX, Components, Nitobi, Web, XSLT, air, apollo, completeui, safari.

With the release of Safari 3 Beta and the recent renaming and Beta release of AIR (formerly Apollo) from Adobe, we have started to work on getting our components running in both of them.

We have run across a few problems - the biggest of which is the lack of any decent debugging tools for either one. I am sure that this will soon change. Currently the best thing around for debugging is Scout.

Grid is being a bit of a challenge given that there is no XSLT support in AIR - though there is in Safari 3. Jake and I got it almost working with a day or so of work / screaming at our computers. Here is a screenshot of what we got so far:

We are pretty happy with the progress and the fact that no one has been hurt - yet ;)
There a few known problems in AIR currently such as CSS opacity not working, table width=0px with colgroups does not work and a few other small things like that. We are certainly happy that Safari 3 and AIR both support addRule and insertRule for working with CSS while a little disappointed in no XSLT support in AIR yet good support in Safari 3.