Let’s take a look at the core issue. Here is what a typical dialog looks like in jQueryUI 1.8.2 with some nice buttons.

Perfect example of a jQueryUI Dialog

Here’s the simple code for this.

<article id="dialogs">
	<a href="javascript: void(null);" id="dialogbutton">Open Dialog</a>
	<div title="this is my test this is my test this is my test this is my test" id="dialogtest">
	This is a div dialog test. This is a div dialog test. This is a div dialog test. This is a div dialog test. This is a div dialog test.
	</div>
</article>

<script type="text/javascript">
	$(document).ready(function() {
		/* Create a dialog */
		$("#dialogtest").dialog({
                        title: "Alert!",
			modal: true,
			buttons: {
				"Ok": function() {
					$(this).dialog("close");
				},
				"Cancel": function() {
					$(this).dialog("close");
				}
			}
		});

		/* Add Dialog Button Functionality */
		$('#dialogbutton').click(function(){
			$('#dialogtest').dialog('open');
			return false;
		});
	});

</script>

That’s really great, I mean that code is so small and yet you can get such a great looking item out of it. So how can I have a problem with that? Well let me tell you how the buttons are made, you have a name and then you have that name point to a function. The name is the text of the button, the function is the action of the button. And that’s it. Period.

Now, I find it great that I can use these simplistic featuresets and get ‘get by’ but normally my “Cancel don’t ever touch me button” is the color red(ish) while my “Oh you need to hit me to move on” button is the color green(ish). But you cannot do that (easily) with this current setup. In fact it’s very sloppy to force this setup into doing that and it ends up using a great amount of code just to do one thing, add a class.

To solve this, I did what any self respecting JavaScript ninja would do, I said goodbye to jQuery UI I opened up the source code and took a peek, found out where I could attack (fix) the code and I did it.
So before I show you the code, I will show you how I decided buttons should/could be made. My process is 100% backward compatible, yet more difficult and easier to mess up (the original goal of jQueryUI was obviously to make it as simple as possible).

Buttons with my code changes can now be made like this

buttons: {
	"Ok":  function() {
		$(this).dialog("close");
	},
	"Cancel": {
		action : function() {
			$(this).dialog("close");
		},
		type : "cancel"
	}

/* This is poor CSS by design to be simple and readable */
 div.ui-dialog-buttonpane button.cancel { background:none; border:0px none;color:red; }

and the old way of doing it will still work just fine as well.

I’ve gone ahead and added a few features, namely it is now name-points-to-object instead of the old name-points-to-function mentality. This object has two attributes: action and type. Action is the old function() that was pointed to and it will be called when this button is clicked. Type is the new feature on the block, it’s just a CSS class that is added to the function using jQuery.addClass. I’ve tried to keep is simple, and at the same time, make it robust and backward compatible. Here’s a simple change that is possible using this feature.

Now my dialogs can look like this when I want them to. This is a big usability thing (make the buttons descriptive, not just in text but in color/design and function).

So the secret sauce to all of this is actually an extension of the jQueryUI 1.8.2 Dialog code (more like rewrite of some of the code). This code can only be ran AFTER jQueryUI 1.8.2 has been created, otherwise you will get an error. I placed this code into the jQueryUI 1.8.2 custom.js file itself for easy keeping; just drop it at the bottom of the file.

/* TorchUI dialog button fix */
(function($) {
	var _createButtons = $.ui.dialog.prototype._createButtons;
	$.ui.dialog.prototype._createButtons = function(buttons) {
		var self = this,
		hasButtons = false,
		uiDialogButtonPane = $('<div></div>')
			.addClass(
				'ui-dialog-buttonpane ' +
				'ui-widget-content ' +
				'ui-helper-clearfix'
			);
		// if we already have a button pane, remove it
		self.uiDialog.find('.ui-dialog-buttonpane').remove();

		if (typeof buttons === 'object' && buttons !== null) {
			$.each(buttons, function() {
				return !(hasButtons = true);
			});
		}
		if (hasButtons) {
			$.each(buttons, function(name, fn) {
                        /* Begin the code change here */
			// Check to see if fn is being passed in as a funciton, assume it's an object if not.
			 	if(!$.isFunction(fn)) {
			 		var buttonclass=fn.type;var func=fn.action; }
			 	else {
			 		var func=fn; var buttonclass=""; }
				var button = $('<button type="button"></button>')
					.text(name)
				/* Add a class to the button, if there is a class */
					.addClass(buttonclass)
					.click(function() { func.apply(self.element[0], arguments); })
					.appendTo(uiDialogButtonPane);
				if ($.fn.button) {
					button.button();
				}
			});
			uiDialogButtonPane.appendTo(self.uiDialog);
		}
	}
})(jQuery);

If you have questions, please respond, I promise not to take them personally

So recently I discovered a very nasty bug dealing with jQuery UI dialog (withe modal:true) widgets that seems to only occur in Internet Explorer. It goes like this: If you are using a dialog with a screen reader, your main mode of navigation is with the keyboard. This is typically driven via the focus on elements. In jQuery, focus is demanded on the dialog because of the modal command. You are unable to focus on anything other than the dialog and it’s elements. Here’s the issue however, jQuery successfully can keep focus on the dialog in all browsers tested (FF, Safari, Chrome) so that the focus cannot leave the dialog. However in Internet Explorer (6, 7 and 8 ) your focus can get to the address bar, simply by tabbing to it. Once in the address bar, jQuery is no longer able to track and handle the focus, so inevitable, after tabbing through the menu, focus come back to the window. But instead of going to the dialog, it goes to the first element that can be tabbed to, which is undoubtedly BEHIND the modal dialog. jQuery, subsequently locks the tabbing at this point, most likely because you have focus on and element that is unable to be focused (in jQuery’s dialog algorithm).

So I cannot have this as that would literally cut 75% of my users from being able to use just a keyboard with the sites I’m maintaining. So I had to find a solution. First, IE seems to be the only browser with this issue and it has something to do with the fact that the focus moves out of the DOM’s control (out of jQuery’s control). But the focus would always at least get back to the first element that could be tabbed to, and then lock. So I devised a plan. What if the first element, when focused, looks for an open dialog and if it is there, focuses on that dialog? So I tried it out, like this.

$(document).ready(function() {
    $(":tabbable:first").focus(function() {
           $(".ui-dialog:visible:last :tabbable:first").focus();
    })
});

Amazingly enough, this is the exact solution to the issue. This is how it reads.

1. On page load
2. Get the first element that can be tabbed to in the body
3. When this element gains focus, check for a visible dialog
4. Take the visible dialog that is last (the last one drawn in the html) and get the first element that can be tabbed in it
5. give focus to that first element.

Now, in IE, when focus returns to the document, it goes to the dialog box, specifically, the close icon on the dialog box, thereby not breaking the fact that there a modal open on the page.

Now, there are some issues with this.  For one, the code is just assuming that the last dialog in the html that is visible is the one that is to be focused on.  Quite frankly, that’s what I need it for, as I try not to overlay dialogs, and when it do, the newest one is normally always on top.  However, there are times where you may swap between two dialogs, and the one that is on top is not the last dialog in the html, you would still have this issue in this case.  But for probably the other 95% of the cases, this is a clean and easy way to ‘fix’ the accessibility issue in IE with jQuery UI dialog modals.

** Update 7/29/2009**
I now have a page dedicated to this at http://www.alldorks.com/wordpress/notify where you can also find the source code repository.

Within a website’s user interface you have common tasks. Of late, with ajax, overlays|dialogs|lightboxes have become common place. Usually developers will use these to replace their `alerts`, `confirms` and leave it at that. But what happens when a user does something and they need to be told “Hey, I got that and it was all ok”. So you simply make an `alert` and let them know. But then you have created this thing that they must read, click and then move on. Add that up, and a user that is moving right along, may have to do 10 clicks a minute extra. Or better yet, daily tasks are now incorporating clicks that are basically pointless. A better solutions is to open up a notification, not unlike what is found in OSX, Gnome and Windows. I’m talking about those little rounded popups that show up in some corner and then disappear. Those… are notifications, and have been missing from most websites that really need them.

So now you know what I wanted. A good looking notification system that is robust, adaptive, lightweightish, easy to work with, etc, etc. Well, I couldn’t find that. I did find mainly two that are out there, jGrowl and Gritter. Both are Okay, but I run into issues with both of them whenever I’m coding. Namely, what if I want multiple notification areas? That shouldn’t be that hard, but it becomes a nightmare to edit and maintain their code. Also, what if I miss the notification (getting coffee), how can I get it back? Finally, why is it so difficult to change how these dang things look! So I put my foot down and decided, “I will go it alone on this one”. I rolled up my sleeves and put my knowledge together to form a better notification plugin. I’m calling it “notify”, and I think it will quickly become a better platform for notifications.

I have a few things that I have been focused on:

• Multiple notification spots (middle, top-left, unlimited with css)
• Simple default notifications, completely customizable with options
• Support for Class A browsers minus IE6, with hacks later to work it into IE6
• Notification history manager, along with stickyness, and missed notices handling

The list goes on from there. It’s probably best to just play with the code, for now, it’s very raw, I will probably host a page on http://alldorks.com/ for it soon, along with a version control system to get the code from. In any case, enjoy!

View the Demo Page, code is in the page

]]> http://www.geedew.com/2009/07/22/making-a-better-notification-plugin-jquery/feed/ 0 http://www.geedew.com/2009/07/11/slowly-and-surely/ http://www.geedew.com/2009/07/11/slowly-and-surely/#comments Sun, 12 Jul 2009 05:32:28 +0000 drew http://www.geedew.com/2009/07/11/slowly-and-surely/

Read the rest of this entry »

If you were to open a dialog, and then dynamically change the content in the dialog, the shadow border will not resize.  The problem is, the code does not ‘know’ the box is larger, and is not able to watch for the changes.   Their have been some solutions that I have found to solve this, like turning off shadows, etc.  But I think I have a better one, a 3-line solution so to speak
Go into your code, mine is in my jquery-ui-personalized-1.6rc6.js file… Also could be in ui.dialog.js etc.

Inside the code (mine is line 4218) after this function

$.widget("ui.dialog", {

_init: function() {

add this function

refresh: function() {
this._refreshShadow(1);
},

Then from within your code you can call something like this…

$("#dialogbox").dialog("refresh");

Check for updates, I may write a drop-in style patch so the coding isn’t necessary.

Enjoy!

The goal of the site is to host all of the ideas that I have in my head and that will in the end help motivate me to get them done and worked on… if individuals decide to comment on them   I will attempt, at my best, to keep the projects code clean and easy to follow, along with good documentation.

A few may be very helpful to some (jCritic, jSave, jSuite) so as I get them done, I will defitely get them on there with working demos etc.

In the end, enjoy!

-Tim Berners-Lee

I started this little project because I have a client whom needs to get his 24 page PDF online. The problem is that a 24 page PDF with all the bells and whistles

ends up being over 5mb in size. This causes issues for people running sub-cable internet connections, as the loading time becomes horrendous. So to solve the problem, I am going to run the PDF as a download by choice and have all the links point to the HTML(Hyper-Text Markup Language: what webpages are written in) converted page when they click on what page they want to see. This does however cause problems if something is updated on the PDF, the HTML is not dynamic or binded to the PDF so and update will p align=”left”> have to occur in both places. The only way around that is to have the HTML being the origionating source and have the ‘download as pdf’ link be a call to a server side script that packages the HTML as a PDF. That however is too much for what this client needs and the issues with the updating will have to be taken in stride.

Tools Needed:
RTF or DOC reader (I prefer OpenOffice2.2) that can convert to HTML
A Program designed to convert PDF to DOC format (I used Able2dDoc, licensed)

Unfortunately, In my case, the PDF contained a large amount of tables that were made up by images after conversion. Because of this, I had to handle things a little bit different, in which I will explain later.

First things first, lets convert to HTML

Using the software I used, Able2Doc, if you load up the PDF you can simply convert the file to a DOC format. Notice, not many converters will go straight from PDF to DOC or RTF formats. Once you are able to convert the PDF to DOC or RTF, you can then open up that file into Microsoft Office or Open Office. Both have the ability to Open up these files and then Export them as HTML.

Microsoft Offices’ way of doing things

Office is really simple. Take the document you are in and go to File->Save As->Other

Then after that you can go click and change the type to an HTML Document… put in the name and your done!

Open Offices’ way of doing things
In Open Office, it is actually easier! Just have your document open and then go to File ->Save As and you can then select the HTML from the drop down list. No extra step as there is in Word.

When things get messy…
You have to start to get creative. I know, it stinks, when things just don’t go your way. I mentioned earlier that I my specific issue just could not be settled by this process only because the images in the PDF were making up the tables and the text did not stick inside the image/tables when changed to HTML. I ended having to go with a slightly altered reality, but the end result to the user is near the same.

The idea that I had was to split the PDF into images. This was actually really easy to do. I swapped over to linux for this part (Ubuntu Gutsy). The PDF Reader program has the ability to output to JPG for your PDF’s. This came in very handy, I simply outputted the PDF I was using, 28 pages of it, as JPG’s and then used to Javascript to make a nice little setup for Checking out the picutres.

Javascript Code In the <body> tags :
<script> function PageQuery(q) {if(q.length > 1) this.q = q.substring(1, q.length);else this.q = null;
this.keyValuePairs = new Array();
if(q) {
for(var i=0; i < this.q.split(“&”).length; i++) {
this.keyValuePairs[i] = this.q.split(“&”)[i];
}
}
this.getKeyValuePairs = function() { return this.keyValuePairs; }
this.getValue = function(s) {
for(var j=0; j < this.keyValuePairs.length; j++) {
if(this.keyValuePairs[j].split(“=”)[0] == s)
return this.keyValuePairs[j].split(“=”)[1];
}
return false;
}
this.getParameters = function() {
var a = new Array(this.getLength());
for(var j=0; j < this.keyValuePairs.length; j++) {
a[j] = this.keyValuePairs[j].split(“=”)[0];
}
return a;
}
this.getLength = function() { return this.keyValuePairs.length; }
}
function queryString(key){
var page = new PageQuery(window.location.search);
return unescape(page.getValue(key));
}
function displayItem(key){
if(queryString(key)==’false’)
{
return ’1′;
}else{
return queryString(key);
}
}
</script>

What else?

Once this code is in place, you can see what it is trying to do. You are basically parsing a query address URL and looking for the specific information showing on whatever variable you pass in. This is giving your JavaScript the ability to know what a variable is from a JavaScript /PHP equivalent to the Get variables.

Now you need the code that will change values of a select box, so the complete picture will come into view.

The idea that I had was to split the PDF into images. This was actually really easy to do. I swapped over to Linux for this part (Ubuntu Gutsy). The PDF Reader program has the ability to output to JPG for your PDF’s. This came in very handy, I simply outputted the PDF I was using, 28 pages of it, as JPG’s and then used to JavaScript to make a nice little setup for Checking out the pictures.

<SCRIPT LANGUAGE=”JavaScript”>

 function loadPage(value) {

if(value == “”) {

 document.getElementById(‘mainimage’).src=”img/ProductCatalog/Page1.jpg”;

 } else {

 document.getElementById(‘mainimage’).src=”img/ProductCatalog/Page” + displayItem(‘p’) +”.jpg”;

 }

 }

 function changeImage()

{

 document.getElementById(‘mainimage’).src = document.getElementById(‘list’).options[document.getElementById('list').selectedIndex].value;

 }

function prevImage()

 {

 if(document.getElementById(‘list’).selectedIndex == 0)

 {

 document.getElementById(‘list’).selectedIndex = document.getElementById(‘list’).options.length-1;

 }

 else

 {

 document.getElementById(‘list’).selectedIndex–;

 }

 changeImage();

 }

function nextImage()

 {

 if(document.getElementById(‘list’).selectedIndex == document.getElementById(‘list’).options.length-1)

 {

 document.getElementById(‘list’).selectedIndex = 0;

 }

 else

 {

 document.getElementById(‘list’).selectedIndex++;

 }

 changeImage();

}

</script>

That was pretty much what the JavaScript needed, and then I could handle everything else from HTML which made things much easier. All that is said and done, any Q’s just ask.