2005 2006 2007 2008 2009 2010 2011 2015 2016 2017 2018 aspnet azure csharp debugging docker elasticsearch exceptions firefox javascriptajax linux llblgen mongodb powershell projects python security services silverlight training videos wcf wpf xag xhtmlcss

3D RSS XAML Demonstration

Here's a short application I wrote for a demo recently. This is a rather simple RSS application, but I created it in 3D in XAML using the February CTP of WinFX. Also, the code is self-sufficient. That is, you can use the below XAML declaration in XAMLPad.

The first thing to notice about this application is that the data is real. That is, the actually RSS information you are seeing on the screen is from a live RSS feed; this demonstrates XAML's XML data-binding capabilities. The next thing to notice is that the entire thing is on an angle. That's because this is all rendered in 3D. So, this also demonstrates using XAML in 3D. You should also notice the background. This is actually just a JPG on my website. There is no C#/VB.NET anywhere... it's all XAML. This demonstrates the power to skin objects. Finally, you should notice that the rendering has different font styles and sizes. This demonstrates how you can style controls... yes, controls. There's nothing fancy here. There isn't really a "3D TextBlock" or anything. A TextBlock is a TextBlock. I just so happen to be using it in 3D.

So, there are many things this demo demonstrates. I actually recorded a short video lesson on 3D XAML programming and I will be releasing it very soon. In the future I may have an entire series on 3D XAML programming.

      <XmlDataProvider x:Key="xmlData" Source="http://fxfeeds.mozilla.com/rss20.xml">
      <Style x:Key="rssTitle" TargetType="{x:Type TextBlock}">
        <Setter Property="FontSize" Value="24"/>
        <Setter Property="TextBlock.Foreground">
            <LinearGradientBrush StartPoint="0,0" EndPoint="0,1">
                <GradientStop Color="Blue" Offset="0"/>
                <GradientStop Color="Green" Offset="1"/>
      <Style x:Key="rssText" TargetType="{x:Type TextBlock}">
        <Setter Property="FontSize" Value="12"/>
        <Setter Property="Foreground" Value="Gray"/>
          <AmbientLight Color="White"></AmbientLight>
                Positions="-1, -1, 0  1, -1, 0  -1, 1, 0  1, 1, 0"
                TriangleIndices="2 0 1 3 2 1"
                TextureCoordinates="1 1 1 0 0 1 0 0"
                Normals="0,0,1 0,0,1 0,0,1 0,0,1">
                    <VisualBrush.Visual >
                        <ListBox ItemsSource="{Binding Source={StaticResource xmlData}, XPath=rss/channel/item}">
                            <ImageBrush ImageSource="http://davidbetz.net/kansas/xamlimage.jpg"></ImageBrush>
                                <TextBlock Text="{Binding XPath=title}" Style="{StaticResource rssTitle}"></TextBlock>
                                <TextBlock Text="{Binding XPath=description}" Style="{StaticResource rssText}"></TextBlock>

C# Fundamentals Exam Released!

Awesome! The Brainbench C# Fundamentals exam just went public! Why do I care? Well, because I was the technical editor for the exam! I'm rather excited because this was my first publicly shown work as a technical editor of anything.

I think exam takers will find the exam to be fair. It's not too terribly advanced, but it's not a beginners exam either. It should really test if you know what you're talking about. One thing that I will remind everyone of is that C# is a standardized language, not "some Microsoft language". So, this exam tests your knowledge of the official C# (ECMA-334) language, not your slang usages of it. Also, sadly, this exam is on the older C# 1.0, not 2.0, which is my favorite language.

Currently the exam is available for free at brainbench.com. The full link is below. Enjoy!

Breaking the Silence

Well, good news and bad news. I was offered the gig to write the new Brainbench C# 2.0 exam. I've been wanting that for a while, so obviously I took it. Of course three days later I get an offer from an editor for me to write a chapter or two for a soon to be released Ajax book. Ha! The bad news is that they had the exact same time frame (1 to 2 months). That, plus my intensive physical training and skydiving pursuits I found absolutely no time on my (Google) calendar to write a chapter! This is a major lesson in timing for me.

I'm really excited about the C# 2.0 exam though. If you know anything about how I write samples and questions you'll know that I'm BEYOND uptight about strictness to best practices and the official framework design guidelines (thank you Krzysztof Cwalina and Brad Abrams). So, my questions will obviously follow those VERY legalistically.

...and NO I won't have threading questions or web questions on the exam. This is NOT a framework exam! I hate it when test writers put that stuff on those exams. Strictly web people will miss every threading question and strictly Windows people will miss every web question. So, it will be fair... but, no, not easy!

By the way, I know I haven't posted any research in a VERY long time on either of my blogs (this one and my Ajax blog), but I've been rather swamped with non-technical activities for the past few months. I still have many more videos just sitting here that I need to post, but I just need to find the right time.

Exam Update

Well, I'm a month into the ACTUAL writing of the C# 2.0 exam and I'm finding it just as fun as I thought it would be. This exam is more advanced than most people are probably going to want it to be, but I just can't imagine WHY someone would want to take a sissy exam. That doesn't help anyone. On the other end of things, anyone who knows Richter's CLR via C# book by heart should do great on this exam.

The only previews I can give at this time are that this exam is really more of a C#/CLR 2.0 exam as I have a sections for reflection and AppDomain management. I also have sections for more controversial things like COM Interop and unsafe code (not too bad-- I'm not about to ask pointer arithmetic questions!). The other thing I can say is that this complements the 70-* certification exams in that this covers the more technical dimension of the CLR, C#, and the framework. It's more like computer science exams than the certification exams. That is, they are more algorithmic than scenario-based.

As I progress, I'm also setting aside questions for a possible CLR 2.0 exam (for my own exam; probably not Brainbench). I figure this exam could cover things like fusion, assembly loading mechanics, CLR internal memory management, identification of core DLLs ( i.e. mscorwks.dll) and other fun topics. I would really like to see "IT" people think MUCH more like CS people; internals and mechanics are VERY good things to know.

JavaScript Graphics Development Updated

For all those interested in learning some introductory concepts some lesser known features of JavaScript, I just updated my e-chapter on JavaScript Graphics Development. This an introduction to using JavaScript and Ajax concepts to do manual graphics development. It also touches briefly on concepts involving interactive graphics and widget creation.

Anyhow, here's the link:

New Design/New Name

For all you getting this via Atom/RSS (btw, thanks for subscribing), come on by and check out the new blog design. This time I went for a darker design giving a bit of a Vista-ish feel. Also, you will see I finally formally changed the name to NetFX Harmonics to agree with the INSANE decision to rename WinFX to .NET 3.0.

Finally, if you haven't done so already please start using the new feed at http://feeds.feedburner.com/FXHarmonics/ to replace to old one. I will soon be discontinuing the old feed.


Here's a quick update on a few things...

First off the primary feed for this site is now at the below link:

Please change all your references to point to the new link. I'll be removing the old one in a few months.

Secondly, since someone had an aneurysm and decided it would be a great idea to confuse the entire planet, WinFX is now called .NET 3.0. Ergo, I'm changing the name of this blog to NetFX Harmonics for the time being.

Thirdly, I'll probably be posting much more content in the near future. Recently I was at an MSDN event and I was amazed at how little everyone (including the presenter) knew about new technologies. There were people who actually asked what SOA event was. I assumed everyone in the Microsoft technical community would be at least somewhat up to date with WinFX (Uhhhh duhhh .NET 3.0) information. Clearly I was wrong. I guess I should start publishing again!

Working with application-based XHTML

Ajax Development

Working with application-based XHTML

By David Betz - 07/16/2005


For years presentational HTML was how we created our websites and front-ends for our web-applications, but times change and so do technology paradigms. Today presentational HTML is considered a legacy technology and should not be used in any manner at all. What replaced it is a set of technologies which interweave with each other to create a harmonous symphony of elegance.

Thought HTML was so popular, it suffered from many problems. The first is the fact that it integrated page content with page style. Today this concept is strongly considered taboo due not only to the fact that this type of integration is virtually impossible to management, but also due to the fact that this increases page sizes dramatically. Another problem with HTML is the fact that it was basically unparseable to a human. Sure there are standards stating what HTML should be like, but the rules were never enforced. A human looking at sloppy presentational HTML could really tell exactly what the page is supposed to look like. Many times a browser felt the exact same way. What a developer thought he or she was writing was not exactly that which rendered on the screen. The most common example of the unparsability is the lack of enforcement for requiring the closing of tags.

Many developers and many tools which would create webpages for you used to use the <p> tag as a line break, when in fact <br> was an HTML line break and <p> was the beginning of a paragraph. This brings up two more obvious problems related to that: first, a beginning of a paragraph calls for an ending, but in many old HTML pages the <p> tag was missing. secondly, if <br> is the line break, where does the line break end since text between a less-than and greater-than sign is a tag beginning calling for an ending.

XHTML fixed all of those problems by clearly stating that XHTML is to be written as XML. This naturally created a way for humans and browsers to both be able to easily parse client-side 'presentation' code. First, since XML requires an ending, developers were forces to add </p> somewhere after a <p> to close the paragraph, which gave strong enough hint to the fact that <p> is not a line break. Secondly, since <p> was obviously not a line break, <br/> stood out as an obvious line break and since it does not have an ending it was self closing dude to the / at the end (this is all of course using the old model of design, where using <br> was still considered proper.)

Now with a clear way to parse client-side 'presentation' code, developers had a way to test to see if their code was proper. That is, compliant to standards. A validator became and still is one of the web developer's and designer's most powerful tools. Programmers have their compilers to catch syntax errors, and now web developers and designers had validators. But a problem still remains: This code was parseable, but still not parsed. That is, a developer could write code as good as possible and be in such a hurry to release code that he or she forgets to do the critical step of validating (which is much like forgetting to compile your application.) So, the risk still existed that a developer could release improper code. How is this problem solved? This is where application-based XHTML comes into play.


XHTML is actually split into two major branches: text and application based. Text based XHTML is XHTML 1.0 and is nothing more than HTML written to look like XML. Technically it is XML, but browsers don't really care. A web browser will look at XHTML with the same eyes it looks at HTML. It could not care less that now you have a sense of properness about your code by putting a little slash at the end of your img object. In this world XHTML is just HTML, with the cleaned ability to read your own code due to your writing code properly. This world contains frame set XHTML as well as what you could think of as two levels of XHTML: transitional and strict.

The transitional version is basically the first level of XHTML. It's HTML written in XML, but it's not really that strict about things. Old paradigms are allowed. That is, tags like font, applet, menu, strike, and u are all still allowed as well as various legacy attributes like 'align' on tags like div and the header tags (i.e. h1, h2, h3, etc...). XHTML strict does not allow for these tag and elements and forbids many, many others and brings a web developer one step further from legacy development and closer to proper coding, but not to the highest level of proper coding we currently have. In HTML the web concepts are focused on the presentation of the page, but XHTML 1.0 changes the focus of the web to various other places and even changes the point of the page itself. That is, the page is no longer a presentational format, but it's rather a structure containing objects. This is especially true with XHTML 1.0 strict, in which it's considered extremely taboo to have any presentational elements in your structure (that's what CSS is for.)

Other than these varieties of XHTML there is the highest level of XHTML we currently have: XHTML 1.1. XHTML 1.1 is actually a very misunderstood format. It's not simply HTML written in XML, it's actually a new format all together. While XHTML 1.0 transitional brought the first level of code clarity to the page and while XHTML 1.0 Strict a stronger sense of a major paradigm shift, XHTML 1.1 brings that paradigm shift to full tilt.

This is traditionally used as application-based XHTML and the standard strongly recommends this. In fact, it's considered poor programming to not use it as applcication-based XHTML. In what I call 'application-mode' Pages are no longer just XHTML pages written to look like XML that can allow for errors, they are actually parsed on the client end just like XML to ensure a quality product.

Just like how you cannot ship out C#, Java, or C++ code before you compile your code, you should not be able to ship out your web code before you validate. One of the great things about a compiler is that not only does it make your product smaller by creating a binary version of it, it also checks for errors. A C# compiler for example will not let your product be released if you try to use an uninitialized variable. It saves you from the extreme problem of having a memory leaking product in production. Validators are the same way, but with XHTML 1.1 you are forced to take web development as seriously as you would any C#, Java, C++, or like development.

One of the reasons for this is that your XHTML page is as I say not a presentational page, but rather a page structure for other things to work off of. Think of it as the foundation for any further work. If you are a desktop-developer you can think of an XHTML page as being like your forms resource file (i.e. resx, XAML file, etc...) You can't expect an improperly written Windows-form to work properly if you don't have the correct format, so you can't expect your XHTML page to work properly if it's not properly written. Thus the beauty of XHTML really shows: it really is XML.

One of the things that makes XHTML 1.1 real XML is the mime type it uses. Text-based XHTML is actually sent with the old fashioned text/html mime type. Thus it's still html. XHTML 1.1 however is sent with the application/xhtml+xml mime type, which kicks the browser into a type of ultra strict mode. If your XHTML page is not proper you will get an error just as you would if you sent improper XML since XHTML is XML.

Something that many programmers may think of with regard to the entire concept of having a parsed page is that while compilers check their code at the server-side, this is checking at the client-side. How does this help the developer? Doesn't that cause more problems because an error skipping our development may still show up at the client? Isn't this the OPPOSITE of what a compiler does? Starting with the last of these and moving backwards, this is exactly what a compiler does, just in a different way. A compiler, among many other things, will make sure you code is right, that is it will check syntax among other thing. That is, it is validated. Unvalidated code is as bad as having code that never went through the test of being compiled. Second, the compiler is at the client-end and the developer will have it as well. This puts more pressure on the developer to do coding properly, a concept which is virtually obsolete. That also answers the question as to how it helps the developer.

Application based XHTML is a very powerful format because it is XML using an XHTML namespace. In these days of meta-data addiction and excessive Q&A testing, you would think that everyone would immediately drop their legacy HTML and text-based XHTML to start creating applications which are required to be proper, not for creating a warm and fuzzy, but for actual survival of the application.


n the old days web developers would do page editing, dynamics, and hacks by writing more HTML out to the screen. The most common way of doing this was the document.write method. This allows a developer to create incredible dynamic pages which were capable of virtually anything. You can do similar things in text-based XHTML as well. For example, while document.write as the standard thing to do in the days of presentational HTML the following would be appropriate in text-based XHTML.

object.innerHTML = '<div id="objectId"><span class="Italic">Cats and Dogs</span></div>';

This simply adds text inside of a span inside of a div to some object. It's rather simple to see how this work, but understanding why this is illegal in application XHTML may require explanation.

The one thing that is an absolute constant in application XHTML is strictness. The philosophy is simple: If a compile won't allow that type of slop, neither will application XHTML. So, what's the problem? What's so improper about that innerHTML code? To illustrate, look at the following code.

object.innerHTML = '<div id="objectId"><span class="Italic">Cats and Dogs</div></span>';

Notice anything wrong? The div and span endings are backwards and this is absolutely and critically illegal in XML, thus also in XHTML since it is XML. The risk of allowing improper code in is far too serious to entertain even in the slightest. Thus, it's absolutely illegal to do this.


So, while this may work in lesser browsers, it would cause a browser which respects application-based XHTML to throw an exception. But, what do you do if you had to dynamically place data into another object? The first way to do this is to use the DOM to create manually create the objects.

var divObj = document.createElement('div');
divObj.id = 'objectId';

var spanObj = document.createElement('span');
spanObj.class = 'Italic';

spanObj.appendChild(document.createTextNode('Cats and Dogs'));


While this is the proper way of doing things, this method breaks down when you need to insert data that you don't control, like a blog entry. When a blog entry comes in, you have no idea what objects the writer used in his or her entry. It could have image objects, table objects, or even legacy font objects. With this level of uncertainty, creating the objects to insert manually is not an option. Fortunately, theres a solution.

Firefox has an object called DOMParser which will parse incoming data into appropriate objects. It actually creates an entire object tree from incoming data. You can then use a simple loop to insert all the nodes it parsed. The code for this may look like the following.

var incomingData = '<div id="objectId"><span class="Italic">Cats and Dogs</span></div>';
var parser = new DOMParser();

var doc = parser.parseFromString('<div xmlns="http://www.w3.org/1999/xhtml">' + incomingData + '<\/div>', 'application/xhtml+xml')
var root = doc.documentElement;
for (var i=0; i < root.childNodes.length; ++i) {
    parentObj.appendChild(document.importNode(root.childNodes[i], true));

As you can see the incoming data is being places between in a div object with the appropriate XML name space and the parse does all the parsing work for you. All you have to do is iterate though the children nodes of the documentElement of the parsed data appending each of the children found to the parent.

One other thing to consider is optional support for legacy browsers, such as IE6 for Windows. IE6 doesn't even have support for application based XHTML, so there isn't even any point in doing this. But you may want to create a unified solution to handle both systems. For example, you might use the following to handle both.

function applyNewData(parentObj, incomingData) {
    if(new DOMParser( )) {
        var parser = new DOMParser();
        var doc = parser.parseFromString('<div xmlns="http://www.w3.org/1999/xhtml">' + incomingData + '<\/div>', 'application/xhtml+xml')
        var root = doc.documentElement;
        for (var i=0; i < root.childNodes.length; ++i) {
            parentObj.appendChild(document.importNode(root.childNodes[i], true));
    else {
        parentObj.innerHTML = incomingData;

This method combines the use of DOMParse with simple use of the object.innerHTML setter. Depending on if the browser has support for DOMParser, the browser will use either the XML DOMParser or use the innerHTML setter.

The html Object

I keep saying this but application XHTML is XML. Text-based XHTML is supposed to be XML, but it's never enforced, so no one can say if it really is or not, but there is no mistake about the fact that application-XHTML is XML. Because of this, each level of the XHTML (XML) tree means something. So, while Presentational HTML as well as the versions of text-based XHTML don't really care about the usage of the html 'tag', in XHTML it's a real. In HTML and text-based XHTML it was there just for looks more than anything. In application-based XHTML, however, the importance is very critical. For example, if you were to set a background color on a page like in the following code.

body {
background-color: #f1f1f1;

In this case, you expect the background color to be that color and this is the case with text-based XHTML, but not with application-based. With application-based XHTML, there will possibly be a gap at the top of the page due to the fact that the body object is a child of the html object. To work around this you have to apply the background color to the html object, thought it's a better practice to apply it to both the html and body objects.

body {
background-color: #f1f1f1;

This method will fix the background color problem of having the gap at the top of the page. The story is basically the same for anything you traditionally apply only to the body object, or body tag as it used to be called. That is, anything you would traditionally apply to just the body tag, you would probably now apply to both the html and body elements.

Setting application-based XHTML

You can activate application-based XHTML in various ways. First, you can set your file extension to .xhtml or you could set the content-type of the http header to application/xhtml+xml. Doing either of these things will kick Firefox into what I call ultra strict mode and treat your XHTML as it was meant to be treated, as real XML. To add full validation capabilities you will also need to set the DOCTYPE of your page to XHTML 1.1. If you use another type of XHTML, your page will still be treated as real application-XHTML, but validators will validate based on your declaration of the DOCTYPE.

To some developers, Application-based XHTML may seem like an extra worry, but it's exactly that type of attitude that drives quality-assurance teams crazy, creates immediately obsolete applications, and that destroys any remnants left of respect for programming. Application-based XHTML allows a developer to create solid applications without having to rely on the obsolete nature of presentation HTML, which also allows a developer to retain a solid foundation for more advanced development without having to worry about any mistake in his or her user-interface structure.

What is Ajax?


I'm never been one to start by uselessly stating what an acronym stands for, but since it may be helpful in this case, I'll break my own rule this once: AJAX ("Ajax") stands for Asynchronous JavaScript with XML. It's the future of web development and for many, including myself, it's been what web application development has been about for years.

You can think of Ajax web development as being the quantum mechanics of the web development world. The paradigms are different, the players are different, and even the rules are different. Traditionally a web application goes through a "roundtrip" to process and update data to the user. That is, the web browser sends the server a request and then an entirely new page loads to complete a "roundtrip." This is a synchronous processing method where the client and server take turns I a synchronous manner. Ajax, by definition, thanks to the 'A', is asynchronous, so you no longer have to wait for an entirely new page. The user sends a request, goes about his or her other business and then receives an update on what he or she requested. No more waiting for just one thing to be completed at a time. To avoid the needless "roundtrips", the user just sends a request on the fly to the server for some specific data and receive only the data he or she requested without the waste of getting an entirely new page.

While I have been developing Ajax applications since before this millennium, it has only recently become popular with the general web population. The most obvious example of an Ajax application is Google's Gmail. People often ask me why Gmail is so different than other online message/e-mail services. In my answer there are of course allusions to the life-saving concepts of labels instead of folders and conversations instead of e-mails, but also there is my answer regarding its use of asynchronous technology.

In Hotmail and Yahoo! Mail, when you want to, for example, mark a message or series of messages as read you have to press a button and wait for the server to complete a "roundtrip." That is, you have to wait for the server to send you an entirely new updated page. In Gmail, with its use of Ajax technology, there is no roundtrip. So, while the other e-mail services refresh the entire screen when a user presses the button, thus sending a tremendous amount of redundant information to the user, Gmail works with only the appropriate components. In this case, it would send a message to the server telling it that you want to mark a series of messages as read and the server will send your browser back a confirmation all without a roundtrip and alter the screen accordingly. This process saves bandwidth and therefore, time.

That is just one example of a popular Ajax application. Another great example is Google Maps. I've never personally talked to a person who wasn't absolutely amazed at this website (ok, it's an application, but most people call it a website.) You can navigate all around the United States on just one little screen. The application almost never does a "roundtrip", thus gives the user a lightening fast user experience.

But, Ajax isn't just about asynchronous processing to allow for lightening fast applications and websites. The next part is the JavaScript portion. JavaScript is often called the most misunderstood programming language in existence. I would definitely have to agree. When most web developers think of JavaScript they think of data validation or some sort of form processing to allow simple messages like 'Sorry, but your phone number doesn't seem to be in the correct format.' Or a simple message like in Yahoo! Mail 'Are you sure you want to empty the trash box." Some with regard to JavaScript may even think of some sort of dynamic presentation like changing the text on the screen. But JavaScript is more than a simple scripting system, it's an extremely power programming language which brings to the table a tremendous amount of possibilities. This isn't just true for JavaScript as defined in the past 13 years of it's life, but more so future versions like ECMAScript version 4 that is soon to be public with the release of Firefox 1.1 due in the third quarter of 2005.

Going back to the example of online mail service, when you hit a reply button in Hotmail or Yahoo! Mail, a request is sent and, as before, a tremendous amount of redundant information is sent back to the user to create an entirely new screen just for the message response. In Gmail, however, you simply click in the reply box. Done. It immediately creates a new e-mail around the mouse cursor. It does this by using JavaScript to dynamically alter the page is drastic ways. What may take 4 seconds in Yahoo! Mail and Hotmail, now takes less than a second with Gmail. So, if you are a dial-up user, you need to be using Gmail. Well, actually, if you are a human, you need to be using Gmail. This is all thanks to Ajax technology.

Using JavaScript, an expert web developer could theoretically create entire web solutions without ever touching a single line of server-side code. With Firefox a developer could even utilize Firefox's built in SOAP and WSDL capabilities to do all necessary web service processing. Then a developer could use JavaScript to update all necessary pieces of the application with the new data retrieved by the web service. Of course in practice you would have a middle layer of C#, PHP, JSP or whatever to do your server-side accessing to play the middle-man role between the client-side application and the database and file servers. Put another way, Ajax allows you to keep your middle layer as small and efficient as possible.

JavaScript allows you to access and manipulate virtually any object on of off screen. It's your key to deploying web-based desktop-like applications. Soon, in ECMAScript version 4, you will be able to work with things like XML with incredible easy. It's already no problem to work with XML and you can currently use JavaScript to open a local or remote XML file to allow data access served by your middle layer, but soon there will a new syntax and language structure which will allow for more intuitive and more powerful XML processing than ever seen in any other technology. You can thank Firefox 1.1 for making this new technology, ECMAScript version 4, something that we can all use publicly on the web. It's actually no coincidence that JavaScript works so well with XML. The last letter of the AJAX acronym is the X which represents XML.

When some people think of XML, they think of a data format and when some people think of HTML they think of a presentation format. Well, while it may sound like I'm building up to a correction, these theories are actually absolutely correct. XML is for data and HTML is for presentation. But with Ajax and in the world of modern web-standards, there is a technology which combines the two. Thus enters XHTML.

XHTML combines XML and HTML to create something that is not data, and definitely not presentation, but creates rather a page structure. XML by itself cannot render data and therefore cannot solely be used to put controls (i.e. text boxes, buttons, etc…) on the screen and HTML is actually unparsable by today's standards, so it can't be used in strict production environments. XHTML combines the visual aspect of HTML with the parsability of XML to create the new canvas used in modern websites and web applications. With the various types of XHTML, a developer can choose that which best suits his or her own needs at the moment. It's actually a little known fact that there are two primary types of XHTML: one that is text based, which is really just HTML written in XML, and one that is application based, which is true XHTML.

In modern Ajax development when you are creating applications you should seek to use the applications version of most technologies. Why? The text version is not parsed like the application version. Deployment of applications requires a way of mechanical testing. Usually this is done with a compiler, which will check your code for errors, but what about uncompilable things like HTML? While with HTML and text based XHTML, you have to do this manually, by using the application based version XHTML you can parse and validate your code just like any compiler would. That is, no Java or C++ application would ever run with poor syntax because the compiler will prevent it from ever being deployed. So is the same with application based XHTML. If your XHTML code is improper, that is, has poor syntax or other problems, then it will not run. You will be able to catch your errors much earlier and you are forced to take XHTML errors as seriously as you would Java or C++ compiler errors. This allows you to ensure that your web applications are proper, thus bringing you another step closer to having web application development really feel more like windows development…and the quality assurance team will love you for it.

While that exhausts the acronym, there are more parts to Ajax. The one that seems to be the most important to many people, including myself, is one that didn't receive a letter in the acronym and that's web-standards. Some people think that web-standards bring you the ability to write standardized code that will work anywhere. Well, anyone who has been a web developer for more than a month knows that this isn't currently the case. While this is of course the ultimate goal, and until then all web browsers clearly miss the mark, the truth about web-standards today is that they are standards because of the high level of standards they bring to your development.

By writing code that is web-standards compliant; you are ensuring your application to be compatible with the future and are saying that you want your application to be usable for another two, five, or even ten-years. Without the use of web standards, who knows how long the proprietary code you used will last? That's a tremendous risk that no company can ever take. Web standards provide a way to ensure that your applications will work ideally for the long haul. Not only that, they are also the best way to ensure they are the most powerful for the long haul. Proprietary features are the equivalent of get-rich-quick schemes in that while they provide you with the initially buzz that originally sold you on the product with the buzz soon dying off leaving you with a distaste for the temporary world you involved yourself in.

To wrap up, you can think of Ajax development as being verified, standards-based, event-driven, potentially object-oriented, JavaScript coded, asynchronous web development which brings the potential of desktop applications to the web. Before Ajax, online mail services were slow and bulky, but now with Ajax and its application in Gmail, we finally have an online e-mail service that is efficient and powerful to meet the today's needs. What about your application development? your websites? Wouldn't you like the public to say the same about your applications and websites? If so, then asynchronous development, JavaScript, XML, and web-standards all wrapped in this new world called Ajax are your new tools for success!

JavaScript Graphics Development

Samples (primarily for Firefox, but IE support was added)


A few years ago I found an article which stated that there are three things that JavaScript cannot do. The article listed these three as local file actions, networking, and graphics. How true is this? First off, it's very true that JavaScript can't access local files. I think we can all agree that this is a feature. I mean, do you really want to go to a website and have that website access your local files? Copying them to their own machines? Writing out new files? Copying viruses locally? If you want to be able to do stuff like that then you can use Internet Explorer. It hosts a technology known as ActiveX which allows just these things. Everybody I know has learned this the hard way. JavaScript on the other hand is safe and clean with regard to viruses. But, can JavaScript do networking? It really just depends on what you are trying to do. If you're trying to access a resource across over a local network, you're out of luck, however if you would like to access resources on a web server, JavaScript can easily do this via XmlHttp. Furthermore, in modern web browsers, JavaScript has the ability to work directly with SOAP messaging and web services (though many times as a wrapper of XmlHttp). So, yes it can, but only in incredibly safe ways (which is a plus).

Lastly, what about graphics development? While many people have always thought it to be impossible, it's actually been possible for many years. This is the topic I would like to discuss here.


The basis for all graphics development is basically the pixel. It's the simplest and most foundational unit of graphics development. With the ability to create pixels, the sky (or, rather, web browser performance) is the limit for graphics development. But, JavaScript can't write pixels, right? Sure it can. The trick behind JavaScript pixels is the use of standards XHTML objects. In our case we are going to use a very small colored div object to create a pixel. That's really all there is to it. To create more advanced graphics, you simply create more div objects. The beauty behind using a div object is that JavaScript can seamlessly interact with them and they are easy to place using simple 2D coordinates. In addition, div objects are easily customizable via CSS.

Using a div is great, but what size and shape should the div be exactly? You would think that it?s a 1px by 1px div object with a colored background and no border, but that?s won?t work since the buggy IE6 for Windows can't handle 1px by 1px div objects; it actually renders them as being vertical bars. To get around this problem our pixels will be created from transparent div objects with just about any height and a width of 1px and a colored border on the top only. This div object renders as a simple pixel and allows both Mozilla Firefox and IE to render pixels flawlessly.

I've stated at the outset that the prerequisites for this is understanding of the DOM, understanding of basic CSS, and understanding of modern web development or design paradigms. This is because all graphics development here relies heavily on the DOM, uses basics CSS as well as modern web development and design paradigms. If you are living in the old paradigms of presentation HTML, then I highly suggest you study up on XHTML/CSS development and design as well as shedding your old philosophies before continuing. Understanding of the DOM is also critically important for any modern web developer, since it?s via the DOM that you create new objects. This is what I'm going to demonstrate first.

To create a pixel you simply have to create the previously described div and put it somewhere.

function PlotPixel(x, y, c) {

    var pixel = document.createElement('div');

    pixel.className = 'Ink';

    pixel.style.borderTopColor = c;

    pixel.style.left = x + 'px';

    pixel.style.top = y + 'px';



As you can see in the code snippet, and a new element (object) is created, the Ink className is assigned to it, the border top is set, the width and height are both set to 1px, the pixel location is set, and then the pixel is assigned to a parent object (we?ll discuss this a bit later).

The Ink class is as follows and it's rather simple.

.Ink {

    position: absolute;

    background-color: #fff;

    border-top: 1px solid transparent;

    width: 1px;

    height: 1px;


The above JavaScript and CSS snippets are simplified version of what you could actually use. In reality you would customize both to suit your needs, or you could keep these simple versions, creating other graphics mechanisms to rely on them. One example I'm thinking of is a rectangle. With regard to the mechanism I just described, a rectangle in this context is just a pixel with a width or height greater than 1px. So, you could rewrite the PlotPixel method to actually be a DrawRect method and create pixel with DrawRect(x, y, 1, 1, c), though it's better practice to write that method separately though.

Now, the most obvious question is where did this pixel get places? As we see from the above pixel code, it was appended to the parentObj object, but what is that? This is the root in the DOM tree that is going to house this child pixel. In practice it would either me another DOM created object, like a canvas object (discussed later) or a hard coded object in the structure of the page. It?s actually a good practice to keep a hard coded object in the structure of your page so that dynamically created objects have a common root. I refer to this special object as a dynamic attacher.

All you have to do to create a dynamic attacher object is create a simple div which will sit immediately after the body opening. If you put it anywhere else in the body object then you will probably end up having object positioning problems. This is because whatever is above the object adds to the object's positioning. So if you put your page's <h1> prior to the dynamic attacher, then your objects are going to shifted by the size of the <h1>.

So, put the following code immediately after the start on the body object.

<div id="dynamicAttacher"></div>

To utilize this object, you simply have to get a JavaScript reference to this object.

var dynamicAttacherObj = document.getElementById('dynamicAttacher');

In the context of the above pixel function, the JavaScript object which references the XHTML object was called parentObj. Since the DOM is a tree, you can nest objects under other objects. The dynamic attacher doesn?t have to be the parent of the pixel, but it should be the root of your graphics tree. In fact, it should really only have one child and all further objects should be added to that child (which of course then, makes it a parent.)

That's about all there is to it with regard to creating pixels. With that one function you have a new world of possibilities. Years ago, many people used a similar type of method to create simple effects like snow fall. However, all the effects that I've ever seen followed the old HTML paradigm of thinking. The method I'm using here is standards compliant and follows the Ajax (Asynchronous JavaScript with XML) model of thinking. But, you don't have to stop with pixels though. What about lines?


According to geometry, a line is a straight 1-dimensional object with no thickness and extends infinitely in both directions. Well, we won't be creating anything with no thickness and we sure aren't going to even imagine creating something of infinite length, but what we can do is create line segments with thickness.

Creating a horizontal or vertical line is rather simple and if you know anything about graphics development at all then you know that you simply have to iterate through a loop n-times where n is the length of your line. This is true, but in web development it's much easier. While in classic graphics development a box is created by many pixels, in web development a pixel is created by a box.  In other words, we can simply create an elongated pixels.

You might think that a method to create this elongated pixel is nothing more than the DrawRect method I mentioned earlier, but that won't work since legacy IE6 can't handle div objects of unit height. So, we actually need to create DrawHorizontalLine and DrawVerticalLine methods. They might look something like this.

function DrawHorizontalLine(x, y, l, c) {

    var longPixel = document.createElement('div');

    longPixel.className = 'Ink';

    longPixel.style.borderTopColor = c;

    longPixel.style.width = l + 'px';

    longPixel.style.left = x + 'px';

    longPixel.style.top = y + 'px';



function DrawVerticalLine(x, y, l, c) {

    var longPixel = document.createElement('div');

    longPixel.className = 'Ink';

    longPixel.style.border = '0';

    longPixel.style.backgroundColor = c;

    longPixel.style.height = l + 'px';

    longPixel.style.left = x + 'px';

    longPixel.style.top = y + 'px';



Do you see the difference between the two methods? The horizontal line basically created an elongated pixel, while the vertical line is created by a completely different method entirely.  If you recall, the PlotPixel method used a transparent background with a colored top border to create a pixel. If we were to try to create a vertical line using that method, then we would get into trouble really fast since only the top of the line would be colored. So we actually had to create a div object with no border, a colored background and a height of the length.

What about lines that are diagonal? First off, the following is not going to help anyone.

function DrawLine(x1, y1, x2, y2, c) {

    var longPixel = document.createElement('div');

    longPixel.className = 'Ink';


    for(var x = x1; x < x2; x++) {

        for(var y = y1; y < y2; y++) {

            plotPixel(x, y, c);




The reason this isn't that useful is that first off it's creates a box. Secondly, even if it you were to create something that created something like a line using a simple 'for' loop, you could only create a perfect 45 degree angle because of the fact that the screen is not continuous, but is rather made up of discrete units. To create a computer graphics line properly, you would use Bresenham's Line Algorithm as created by Jack Bresenham in 1962 at IBM. The algorithm uses some simple algebra to approximate the most accurate line possible. Here is the appropriate DrawLine method.

function DrawLine(x1, y1, x2, y2, c) {

    var steep = Math.abs(y2 - y1) > Math.abs(x2 - x1);

    if (steep) {

        t = y1;

        y1 = x1;

        x1 = t;

        t = y2;

        y2 = x2;

        x2 = t;


    var deltaX = Math.abs(x2 - x1);

    var deltaY = Math.abs(y2 - y1);

    var error = 0;

    var deltaErr = deltaY;

    var xStep;

    var yStep;

    var x = x1;

    var y = y1;

    if (x1 < x2) {

        xStep = 1;


    else {

        xStep = -1;



    if(y1 < y2) {

        yStep = 1;


    else {

        yStep = -1;


    if(steep) {

        PlotPixel(y, x, c);


    else {

        PlotPixel(x, y, c);


    while(x != x2) {

        x = x + xStep;

        error = error + deltaErr;

        if(2 * error >= deltaX) {

            y = y + yStep;

            error = error - deltaX;


        if(steep) {

            PlotPixel(y, x, c);


        else {

            PlotPixel(x, y, c);




For more information on Bresenham's Line Algorithm, check Wikipedia or any online computer graphics tutorial.

Not only do you now have the ability to create a line, you also have the powerful ability to create a vital graphics component.  The most basic component of a polygon is a line.  Now that you know how to create lines, using them to construct shapes should be easy.

Creating a polygon is as simple as drawing the start of one line at the end of another.  You can create closed or open, complex or simple, or even wild and erratic objects using this method as the basis.  But, what about circles? Given that a circle in Euclidean Geometry is an infinitely sided polygon you should definately use the line method, but how about we try something different?


Creating a circle is one of the easiest things anyone can do in computer graphics. At least it was 15 years ago when I would create them in game development. These days our screen resolutions have gotten a bit better than the 320x200 I used to work with. Let's begin by examine how we used to create circles using that old school method.

This method relies on the fact that you can create a circle by rotating a line around a center point and plotting the end of the line, much the same way you would draw a circle with a compass. In computer graphics however, we will rely on trigonometry, not on a physical a device.

The basic math behind this method is simple. Given a center point of P(x,y) and a radius r and angle a, you can find the point on the circle C(x,y) simply by finding the components x and y where x is r + Cos(a) and y is r + Sin(a). That's great, but this isn't the middle ages or third grade so we are going to be using radians instead of angles. Now, given a in angles we now have C(x, y) in radians where x is r + Cos(a*pi/180) and y is r + Sin(a*pi/180). In practice, you simply have to plot the pixel C(x, y) at every angle from 0 to 359.

Graphics.prototype.DrawCircle = function(xc, yc, r, c) {

    for(var a = 0; a < 360; a++) {

        PlotPixel(r * Math.cos(a * Math.PI / 180) + xc, r * Math.sin(a * Math.PI / 180) + yc, c);



On a 320x200 resolution screen this shows a perfectly enclosed circle, however not on our modern screens.  The reason this worked 15 years ago, but not today is because this method draws only one point for every degree in a circle.  For a lower screen resolution every one of these points would touch each other, however on our modern screen this leaves enormous gaps between the circles.

So what do we do? The answer simply lies in geometry. I'm not going to explain the math behind this, but I will say that it uses the 2D circle formation and symmetry. You should be able to find a good explanation of modern methods of creating a circle online, but here is the code for it.

function DrawCircle(xc, yc, r, c) {

    var x = xc - r;

    var y = yc - r;

    yc = yc - r /2;

    xc = xc - r;


    circle.style.left = x + 'px';

    circle.style.top = y + 'px';

    circle.style.width = r * 2 + 'px';

    circle.style.height = r * 2 + 'px';

    var r2 = r * r;

    x = 1;

    y = parseInt((Math.sqrt(r2 - 1) + 0.5));

    PlotPixel(xc, yc + r, c);

    PlotPixel(xc, yc - r, c);

    PlotPixel(xc + r, yc, c);

    PlotPixel(xc - r, yc, c);

    while (x < y) {

        PlotPixel(xc + x, yc + y, c);

        PlotPixel(xc + x, yc - y, c);

        PlotPixel(xc - x, yc + y, c);

        PlotPixel(xc - x, yc - y, c);

        PlotPixel(xc + y, yc + x, c);

        PlotPixel(xc + y, yc - x, c);

        PlotPixel(xc - y, yc + x, c);

        PlotPixel(xc - y, yc - x, c);

        x += 1;

        y = parseInt((Math.sqrt(r2 - x*x) + 0.5));


    if (x == y) {

        PlotPixel(xc + x, yc + y, c);

        PlotPixel(xc + x, yc - y, c);

        PlotPixel(xc - x, yc + y, c);

        PlotPixel(xc - x, yc - y, c);



Looking at it you will actually be able to see the symmetry it's doing. It will plot a pixel at C(xc + x, yc + y) then at 7 other mirrored points on the circle. You may also notice the r2 = r * r (r squared) in there and recall from a Calculus or advanced geometry course how a circle is actually defined.

Speed Considerations

You can do more complex things with JavaScript graphics development, but you have to remember that each pixel is actually a div object. So an implementation of a flood fill algorithm used to fill areas with a certain color may not be something you will want to manually do any time soon. For things like that, you may want to switch to SVG graphics as seen in Firefox 1.5.

As far as performance of web browsers, Gecko, Firefox's rendering engine, is currently the fastest of the web rendering engines on the market and it will be able to take on many of the graphics development projects you throw at it. Trident, IE6's rendering engine should also be able to handle it, but you should take special care when even thinking about offering any Opera support. Opera's rendering engine, Presto, is the slowest of these web rendering engines and it's not just slow, it's really slow. You won't really be able to do any manual graphics creation using Opera's engine, so you may actually want to give them a stop sign and a redirect to getfirefox.com to help them along.


Now that you have seen some of the basics objects you can create using JavaScript Graphics Development, what about interaction of the objects? This is actually very easy in standards-compliant browsers (i.e. Firefox/Mozilla), but can get rather weird in IE and Opera (especially Opera.), so I'm really only going to demonstrate the proper way of doing this without using any special IE or Opera tools.

Before I explain actual interaction, you will need to understand the concept of a canvas object. Without a canvas, you simply have a ton of objects all over the place with no connection between them. A canvas will allow you to group your pixels together in a larger parent object. You could theoretically group your pixels by giving them a common id prefix or create a virtual attribute identifying them with each other, but the DOM is a tree and to group things together they need only be on the same branch.  A canvas is that branch.

To create a simple canvas you could use something like the following code.

function CreateCanvas(w, h, id) {

    var canvas = document.createElement('div');

    canvas.className = 'Absolute';

    canvas.id = id;

    canvas.style.width = w + 'px';

    canvas.style.height = h + 'px';

    canvas.PlotPixel = function(x, y, c, id) {

        var pixel = document.createElement('div');

        pixel.className = 'Ink';

        pixel.id = id;

        pixel.style.borderTopColor = c;

    pixel.style.left = x + 'px';

        pixel.style.top = y + 'px';

        if(x <= parseInt(canvas.style.width) &&

                y <= parseInt(canvas.style.height)) {




    canvas.SetLocation = function(x, y) {

        canvas.style.left = x + 'px';

        canvas.style.top = y + 'px';


    canvas.CreateBorder = function(width, style, color) {

        this.style.border = width + ' ' + style + ' ' + color;


    canvas.CreateContainer = function(w, h, id) {

        var container = document.createElement('div');

        container.className = 'Absolute';

        container.id = id + 'Container';

    container.style.width = parseInt(w) + 'px';

        container.style.height = parseInt(h) + 'px';

        return container;


    canvas.CleanCanvas = function( ) {

        if(this.firstChild) {




        this.appendChild(this.CreateCanvasContainer(this.style.width, this.style.height, this.id));


    canvas.appendChild(this.CreateContainer(w, h, id));

    return canvas;


Did I say simple? Well, ok, maybe it looks a bit complicated, but it really is simple. This method will create a canvas object and then return the canvas object. That's the gist of the matter, but as you can see there's more going on. The first thing you will notice is the internal PlotPixel function on the canvas. If you have never worked with JavaScript OOP, this is going to seem really odd. In JavaScript you can actually assign methods just like you would any variable. Other languages do this too, but they may have a special name for this process. C#, for example, calls these types of methods, anonymous methods. Regardless of what you call it, you're creating a function.

In fact I'm not just creating one function, but a few. The first is our new PlotPixel method, the second SetLocation actually moves the canvas to a place on the screen and the third, CreateBorder, is really just an added bonus for creating a canvas border. Then there is a function, CreateContainer, used to create the container object which will actually hold the pixels and finally a cleaning method, CleanCanvas, used to clear off the canvas.

There is one thing that I should definitely explain. In the PlotPixel function, there was the following code:

if(x <= parseInt(canvas.style.width) &&

        y <= parseInt(canvas.style.height)) {



The conditional is actually implements clipping. Clipping is where something is only seen within a certain area. For instance, in a video game where an enemy walks half way behind a wall, only half of the enemy is seen. The other half is clipped. Here, this makes it so that only pixels within the canvas area are drawn, therefore saving memory and helping performance out a bit.

The second thing to notice in that code snippet is the this.firstChild line. This line actually assigns the newly created pixel to the container object of the canvas, this container object contains the actual content of the canvas. If you look at the canvas function again, you will see that the last thing it does before returning the object is create a container object and assigns it as  a child of the canvas. Since this is a newly created canvas object, this is the first child. Thus, by adding the pixel to the first child of this canvas, the pixel is actually being added to the container of the canvas, which is exactly what this line is doing.

To use a canvas you simply have to create one and then append objects to it's canvas. Here is how to create the canvas:

var canvasObj = CreateCanvas(w, h, id);

I know, that's rather obvious. You simply give it the width, height and what ID you want to call it. That's it. To draw a pixel on  the canvas, you simply call the canvas.PlotPixel method. The pixels are then automatically applied to the canvas. But what about actually seeing the pixels? Adding them to the canvas is great, but we never assigned the canvas to anything.  If you recall, you have to actually assign the object as a child of the dynamic attacher object discussed earlier, or to something that is attached as a child of the dynamic attacher object.  So let's create an Attach method to help us out.

function AttachObject(parentObj, childObj) {



You just give it a parent and child object and it applies it for you. So in practice you could do the following.

var canvasObj = CreateCanvas(100, 100, id);

canvasObj.SetLocation(0, 0);

canvasObj.CreateBorder('1px', 'solid', '#000');

canvasObj.plotPixel(10, 10, '#000');

canvasObj.plotPixel(10, 11, '#000');

canvasObj.plotPixel(10, 12, '#000');

canvasObj.plotPixel(10, 13, '#000');

canvasObj.plotPixel(10, 14, '#000');

canvasObj.CleanCanvas( );

canvasObj.plotPixel(10, 10, '#000');

canvasObj.plotPixel(11, 10, '#000');

canvasObj.plotPixel(12, 10, '#000');

canvasObj.plotPixel(13, 10, '#000');

canvasObj.plotPixel(14, 10, '#000');

AttachObject(dynamicAttacherObj, canvasObj);

This is actually a horizontal line since we are plotting pixels vertically, clearing the canvas off, and then plotting pixels to the right. The rest should be fairly self explanatory.

You could expand on this example by adding the line and circle methods to the canvas, or you could go even further and create all your geometric shapes under the canvas class to allow everything to be canvased and therefore encapsulated as a larger entity.  Speaking of larger entities...


What if you did create some entity using a canvas.  What about manually moving the entity? This is actually rather easy. Due to the tree structure we have been working work, JavaScript allows us to move simple objects as well as complex objects. That is, given that the object has a way to be found (i.e. by an id) we can move the object directly or we can move the branch the object lies on, there by moving all the branches child objects including this object. By adding this functionality, we have effectively turned a basic object into an entity known as a Widget.

So where do we start with interaction and the creation of a simple widget? There's really only two things to do: make sure the object has an id and do capture some events like mousedown, mouseup, and mousemove . I'm actually only going to show the very basic way of doing this. In reality, you would probably actually add more error checking and as well as other basic windowing features but this will do for now.

function ultraSimpleMovement(obj) {

    obj.moving = false;

    obj.addEventListener('mousedown', function(evt) {

        obj.layerX = evt.layerX;

        obj.layerY = evt.layerY;

        obj.moving = true;

    }, true);

    obj.addEventListener('mouseup', function(evt) {

        obj.moving = false;

    }, true);

    obj.addEventListener(obj, 'mousemove', function(evt) {

        var x = evt.clientX;

        var y = evt.clientY;

        if(obj.moving) {

            obj.style.left = (evt.clientX - obj.layerX) + 'px';

            obj.style.top = (evt.clientY - obj.layerY) + 'px';


    }, true);


As you can see by the use of addEventListener, this code is only for standards compliant browsers and systems. Thus, if you really need to have IE6 support, then you will have to add a few tests in there as well as use a few non-standard Microsoft DOM methods and events.

There are a few parts to this code, but most should be self explanatory. The basic mechanics work something like this...

  1. Create a virtual attribute called moving which is set to false.

  2. Capture mousedown and on mousedown set that virtual attribute to true.

  3. Capture mouseup and on mouseup set that virtual attribute to false.

  4. Capture mousemove and if the moving virtual attribute is true, move the object.

Those are the obvious parts though. The less obvious parts involve the use of both evt.clientX (and evt.clientY) as well as evt.layerX (and evt.layerY). evt.clientX and evt.clientY actually tell you where the mouse is with relation to the client are, while evt.layerX and evt.layerY tell you where the mouse is with relation to the current object. Why am I using both here? If you didn't use the second ones, when you moved an object your mouse would immediately jump to the upper left of the box since you are moving the upper left, top part of the box to that location. You need to subtract where the mouse is currently from where it is on the screen to keep the mouse 'grabbed' where you originally 'grabbed' it.

In a production system, however, you would use something a bit more robust to account for the mouse moving too quickly out of the box area as well as other considerations.  You would also probably want to add more logic to control where the widget could be placed and how the widget may be moved.  Perhaps you only want people to move the widget by a handle on the top, or maybe you want the entire thing movable by any part.  Whatever you would like to do, the ideas shown above are a good foundation.


So what could you do with all this? First off, the widgets are self explanatory. You could create a system with a floating calendar . If you were to link techniques similar to these to other Ajax principles like asynchronous processing (i.e. XmlHttp), you could allow users to design their own portals without ever doing a single post back. This is very similar to what Google dos for their portal and what Microsoft does with live.com.

Non-widget applications, however, may be more up your alley. One sample application I built is a JavaScript sin-wave example. This example shows how you can plot various parallel sin-waves using JavaScript graphics. You could extend this application by creating a trigonomic graphing calculator. You could use the same techniques to do simple animations, visual-aide demonstration, or even web assistants on your websites, all without images.

Another example I've built is a JavaScript graphs and chart library.  The example isn't so much an example as it is what I'm using on my personal website to render data.  It was created completely using JavaScript and the DOM.  In fact, the only hard-coded item in the page structure is my dynamic attacher object.  The library also has widget capabilities.

The Future

The most obvious graphics technology is Macromedia Flash.  However, using Flash has many disadvantages including the requirement to purchase Macromedia Flash, the high learning curve of Flash, as well as a proprietary graphics format.  With Flash you create the graphics and then interact with them.  The Flash animations are in a Flash format and have no code representation, so, editing Flash requires Macromedia Flash.

One technology that is increasing in popularity is SVG or Scalar Vector Graphics. Using SVG, web developers can display vector-based, instead of plain raster-based images in a web environment.  Using SVG programmers have full access to the code of the graphics.  That is, unlike Flash, SVG graphics are in code which allows for easy and powerful editing.  Firefox 1.5 is the first major web browser to provide native SVG support.  Interaction with SVG is done via JavaScript, which can either be an advantage or a disadvantage depending on if you are a JavaScript expert or not.

Another great web graphics technology is WPF/E.  WPF, Windows Presenation Foundation is Microsoft's unified graphics system component of the .NET Framework 3.0.  It's used to create anything from business applications to more complex 3D games with a single unified graphics programming interface.  WPF/E, Windows Presenation Foundation/Everywhere, is Microsoft's technology that takes the WPF out of the Windows world and out to the world.  WPF/E shares the same easy to use unified .NET programming interface as WPF, minus 3D capabilities.  WPF/E works not only in Windows and IE, but also in Mozilla Firefox, Apple Safari, and well, everywhere else basically.  Using WPF a developer could create a powerful desktop application using the very intuitive, elegant, and powerful C# programming language and then publish the application on a website allowing Firefox and Safari users to get in on the action.  In addition, WPF/E components in a web browsers are controllable by JavaScript.  For these reasons, WPF/E has been called "the Flash killer".


As you can see, despite the myths about JavaScript you can do graphics development. All that's requires is knowledge of the DOM and knowledge of JavaScript.  These skills combined with Ajax paradigms, you too can create powerful web component as seen on Google portal and live.com.  Furthermore, you can use these kills plus Ajax paradigms in applications integrating SVG or WPF/E components to create even more powerful web applications.