Friday, September 21, 2007

The book went to the printer today

Assuming all went well at Prentice Hall, they've passed the book off to the printer today, and I should receive a pre-distribution copy to bring with me to the Zend Conference! I got a copy of a much later draft of the book cover, which has undergone some slight changes, but should look more or less like this:

Advanced Ajax Cover

The quote on the front cover reads:

“I very much enjoyed how this book covers the full Ajax application life-cycle and not only coding techniques. Anyone who is looking to become a professional front-end developer will appreciate the architectural insight and best practices delivered by this book.” - Andi Gutmans, Co-Founder & Co-Chief Technology Officer of Zend Technologies

Labels: ,

Monday, August 20, 2007

Adavanced Ajax Cover

The cover below shows the almost-ready-for-publication cover of Advanced Ajax: Architecture and Best Practices. The yellow dialog boxes on the image just show notes from reviewers (things like the "L" in "Lauriat" bleeds into the dark bits and looks like an "I" or that my name should appear on the spine or the back cover makes it sound like I owned Buildforge, Inc.).

Advanced Ajax Cover

Exciting stuff (for me, at least) though. I have a few chapters left to get through as far as copy editing goes, but this should show up soon on Rough Cuts, I swear...

Labels: ,

Saturday, May 26, 2007

Intro to Chapter 10: Game Development

I do hope to finish this game since I have it quite close, but I need to finish the book first. I considered using sprites for the ships, star, and missiles, but decided against it to practice rotation and see what canvas could handle. Also, the original version didn't exactly use image sprites, so I stuck with entirely two-dimensional shapes in canvas. Anyway, on with a couple of paragraphs:

Ajax-driven game development brings together the challenges of scalability and performance, but often allows developers to push the boundaries of current web technologies. Just as with console or computer games, users will put up with stricter minimum requirements in order to have the better experience with the more advanced technologies available, properly used.

This chapter will focus on Universe Conflict, an implementation of Space War!, one of the first digital computer games, created in 1961 on the PDP-1 computer, as recreated using the canvas HTML5 element and Ajax (shown below). This allows the two players to battle each other from different machines, as opposed to the same one as in the original and ports since then. The game has very simple rules and a simple setup. Two ships, each controlled by a user, try to shoot each other without getting pulled into a star in the center of the screen.

Two ships poised to attach each other around a star

Sidenote: you can see the rendering in action in this simple demo of Universe Conflict, which just allows you to click a button and fly each ship around the screen using the arrow keys. Not terribly exciting, since I took the networking bits out, haven't created gravity, and only works in Opera and Firefox for now (Safari has some flickering and keyboard issues that I just haven't bothered to fix yet), but it should give a decent idea of how canvas can handle animation. I haven't tested this a whole lot, so if it sucks for you, let me know.

Labels: , ,

Monday, May 14, 2007

Slight knock on PHP in the section on coding standards

I admittedly held back quite a bit from how much I could easily rant on the topic of PHP's complete lack of consistency when it comes to its function/object library. However, I need to finish the chapter on documentation, not how much PHP's lack of consistency annoys me. As a result, the following excerpt reads much more like a hint of slight frustration than the outburst of obscenities uttered as I hit <ctrl>+<l>, <p>, <tab>, <return> to go back to the PHP manual for the twelfth time that day.

Coding conventions should also include variable, function, method, and object naming practices. When languages support upper-case and lower-case alphanumerics, underscores, and sometimes even the dollar sign character, function libraries and APIs have the potential to include a wide variety of calls available to developers. The following four PHP library functions, while all consistently lower-case, have different parameter ordering and variable naming:

strpos ( string $haystack, mixed $needle [, int $offset] )
str_split ( string $string [, int $split_length] )
explode ( string $delimiter, string $string [, int $limit] )

The strpos and str_split functions in particular should not have differences in their naming, as they reside within in the same categorization of library functions in the PHP Manual, but one has an underscore separating the "str" prefix from the full word of "split" while the other has the "str" prefix unseparated from the abbreviated "pos" instead. Looking at str_split and explode, these two functions have very similar functionality: str_split breaks a string into an array of substrings of a constant length, while explode breaks a string into an array of strings as divided by a passed delimiter. Unfortunately, while str_split takes the string as the first parameter and the split length as the second, explode takes the delimiter as the first parameter and the string as the second, requiring calls to pass an empty string as the first parameter in order to break the string into an array of characters.

No matter what the conventions decided, they should not deviate so far from standard practice that new developers have a difficult time working in the code. By using tabs, consistent naming conventions, and consistent parameter ordering, developers should have the ability to "just know" what a library function or API call looks and acts like, and developers will spend less time researching functions and more time using them.

Labels: , ,

Saturday, May 05, 2007

Support for different HTTP status codes with Ajax

While writing about adding support for different status codes into the AjaxRequest object (very easy, as I'll show momentarily), I made a little test page to try each of the initial set: HTTP Status Codes. Just click each link (check Firebug) and it optionally fetches all, part, or none of a 400-line file.

Now on to the excerpt:

Most browsers and XML feed readers take full advantage of the HTTP/1.1 specification to greatly reduce the data sent from the server, and the XMLHttpRequest object gives developers access to the same functionality. Two intertwined aspects of the HTTP/1.1 specification in particular can help Ajax-driven applications: status codes and cache-control.

Supporting these in the previously defined AjaxRequest object comes easily. It already supports setting custom headers through its headers object, just like setting GET and POST variables. In order to support the various status codes that the server can return, it just takes adding event types and adding some more flexibility to the stateChanged() method by changing it from:

// Event dispatching
AjaxRequest.prototype.events = {
  abort : [],
  data : [],
  load : [],
  open : [],
  send : [],
 };

// Callback for this.xhr.onreadystatechanged
AjaxRequest.prototype.stateChanged = function() {
 // Only trigger load if finished returning
 switch(this.xhr.readyState) {
  case 3:
   var e = new AjaxEvent(this);
   this.dispatchEvent('data', e);
   break;
  case 4:
   // Only continue if status OK
   if (this.xhr.status == 200) {
    var e = new AjaxEvent(this);
    this.dispatchEvent('load', e);
   }
 }
}

...to a new version that can handle multiple status codes:

// Event dispatching
AjaxRequest.prototype.events = {
  abort : [],
  data : [],
  internalservererror : [],
  load : [],
  notfound : [],
  notmodified : [],
  open : [],
  partialload : [],
  requestedrangenotsatisfiable : [],
  send : [],
  unauthorized : []
 };
// Simple lookup of event types by status code
AjaxRequest.prototype.statusCodeEvents = {
  200 : 'load',
  206 : 'partialload',
  304 : 'notmodified',
  401 : 'unauthorized',
  404 : 'notfound',
  416 : 'requestedrangenotsatisfiable',
  500 : 'internalservererror'
 };
// Callback for this.xhr.onreadystatechanged
AjaxRequest.prototype.stateChanged = function() {
 // Only trigger load if finished returning
 switch(this.xhr.readyState) {
  case 3:
   var e = new AjaxEvent(this);
   this.dispatchEvent('data', e);
   break;
  case 4:
   if (this.statusCodeEvents[this.xhr.status]) {
    var e = new AjaxEvent(this);
    this.dispatchEvent(this.statusCodeEvents[this.xhr.status], e);
   }
 }
}

The new implementation of stateChanged() now simply triggers the event mapped to the returned status code from the request, if the AjaxRequest object implements that event type. While the list of status codes only includes the most commonly used codes for this chapter's usage, it can include any additional codes added to the events and statusCodeEvents objects.

Labels: , , , ,

Saturday, March 31, 2007

Fun with getallheaders() and var_dump() - another excerpt from Chapter 8

In PHP, the Apache-specific functions give an extremely easy way of checking referers via the getallheaders() library function. Calling it, with PHP installed as an Apache module, returns an associative array containing all of the header names as the array keys, with their corresponding header values as the array values. Calling var_dump(getallheaders()) would display something like the following, with "Referer" as the last entry in the array:

array(9) {
  ["Host"]=>
  string(13) "192.168.2.106"
  ["User-Agent"]=>
  string(92) "Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3"
  ["Accept"]=>
  string(99) "text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5"
  ["Accept-Language"]=>
  string(23) "en-us,en;q=0.7,fr;q=0.3"
  ["Accept-Encoding"]=>
  string(12) "gzip,deflate"
  ["Accept-Charset"]=>
  string(7) "UTF-8,*"
  ["Keep-Alive"]=>
  string(3) "300"
  ["Connection"]=>
  string(10) "keep-alive"
  ["Referer"]=>
  string(31) "http://192.168.2.106/utilities/"
}

However, the following shows that a simple telnet connection can set the header to anything and the server will simply believe it, since it lacks any way of verifying it.

$ telnet 192.168.2.106 80
Trying 192.168.2.106...
Connected to 192.168.2.106.
Escape character is '^]'.
GET /utilities/getallheaders.php HTTP/1.1
Host: 192.168.2.106
Referer: The Forbidden Zone

HTTP/1.1 200 OK
Date: Thu, 22 Mar 2007 02:08:01 GMT
Server: Apache/2.2.3 (Unix) PHP/5.2.1
X-Powered-By: PHP/5.2.1
Content-Length: 117
Content-Type: text/html

array(2) {
  ["Host"]=>
  string(13) "192.168.2.106"
  ["Referer"]=>
  string(18) "The Forbidden Zone"
}

Labels: ,

Sunday, March 25, 2007

3500 words today, and counting

By standing on the shoulders of giants, Chapter 2: Accessibility has gone much easier than I even anticipated. Excerpt from the chapter, specifically the intro to the section "Screen readers can handle Ajax:"

If a user cannot see the screen (and the web application within it), they will need something to describe and read it to them. Note that it describes, as well as reads it. As touched upon in Chapter 2: Usability, semantic markup makes these descriptions much more relevant and meaningful to someone who does not (for example) have the ability to tell at a glance that four links have anything to do with each other, let alone that they provide navigation access to other parts of the web application.

A common misconception among Ajax developers and users alike: screen readers cannot handle dynamic content. They can, but similarly to supporting all of the major rendering engines of browsers, supporting the major engines in screen readers takes time and understanding. As a common example, Jaws and Windows-Eyes might recognize a focus change as a point to start reading, while Home Page Reader does not. As such, much like writing generic or all-encompassing code to support multiple browsers, writing scripts to dynamically change the DOM structure just needs to include all of the steps necessary for the most commonly used and supported screen readers.

Though use of text-only browsers such as Lynx or screen reader simulations such as the Firefox extension, Fangs do prove incredibly useful for quickly and easily checking a web application on initial page load, only by using a fully-fledged screen reader can you accurately and consistently test a dynamic web application. Jaws, developed by Freedom Scientific, has put itself into the majority of the market, especially in the United States, commanding a portion of the market comparable to IE's market share of browsers.

For developers whose primary development environment does not happen to consist of Windows and IE, the Fire Vox extension for Firefox has recently come onto the scene, and can run in Windows, Mac, and Linux. Initially written as a demo of CLC-4-TTS1, the extension has proven quite popular, and (through the CLC-4-TTS library) has beaten all of the big names in screen readers to offering support for the drafted WAI-ARIA guidelines, explored later in this chapter. It also provides MathML support (which Firefox supports "out of the box") and support for the CSS3 Speech Module.

  1. 1 Core Library Components for Text-to-Speech, written by Charles L. Chen, also the author of the Fire Vox extension

Labels: ,

Thursday, March 22, 2007

For a good example of why web applications should always regenerate session ID tokens on login

A sidenote in Chapter 8: Keeping a Web Application Secure

For a good example of why web applications should always regenerate session ID tokens on login, run tcpflow -i en0 -c port 80 | grep 'Set-Cookie:' and then navigate to a few banking or online payment sites. Most of them will set a cookie in order to store things like language, or to track your browsing for metrics. However, if the institutions do not regenerate a new session ID token on login, anybody who steals the initial, cleartext cookie, can then (assuming they take no other precautions such as tying sessions to IP addresses) use the cookie themselves without needing to authenticate as the victim.

Writing this chapter makes me hope more than ever that web developers working for financial institutions know how to keep things secure...unfortunately, common sense (and issues I've run into in the past) tells me that at least a few of them need to work on it a bit more, to put it entirely too mildly.

Labels: ,

Sunday, March 18, 2007

Intro to Chapter 8: Keeping a Web Application Secure

Many people currently have a misconception about Ajax-based web applications inherently lacking in security. While this has a basis more in misunderstanding the technology than in serious research, developers need to ensure that they do not leave doors open in the application that they might otherwise neglect, and inadvertently encourage this line of thought.

The only new technology occurring in Ajax-driven applications comes in the form of the XMLHttpRequest object, which only has the ability to make requests all browsers currently make already, with the restriction that the requests can only get made to the same domain name. In other words, while a browser makes request to any domain specified, the XMLHttpRequest object cannot perform cross-domain requests.

The largest security consideration specific to Ajax-driven web application development, a developer's mentality when writing the code itself must get kept in check. Just because users does not need to interact directly with JavaScript objects that send data to the server does not mean that they never will. Tools like Greasemonkey have made user scripts available and popular with users who don't even have any JavaScript knowledge, and can open up those abstracted objects to useful (if occasionally dangerous) functionality never intended by the developers.

In a nutshell, Ajax has not opened up any new security holes in web development, but it can raise the stakes. By exposing more of the server-side application to client-side scripting, developers broaden the surface area available to attackers. By involving more "moving parts" than in less dynamic web applications, it increases the chances that mistakes will get made. The practices elaborated on in this chapter minimize this risk.

Labels: ,

Thursday, March 08, 2007

Unit testing intro

Along with documentation, unit testing often gets left behind as a chore that should get done, but simply does not earn the attention from developers that it deserves. Maintaining and regularly running unit tests can have any number of beneficial effects on an application's development. These can include keeping the trunk stable, rather than having thoroughly untested changes create a ripple of frustration and lack of productivity hit other developers working on the same project.

More recently, unit testing has had a boost in popularity due to the Agile methods of software development, the short turnarounds of which thrive when the software has rigorous, frequent testing. No matter which methodology the development of an application follows, unit testing by individual developers can only help the quality and stability of the overall application.

For JavaScript, developers mostly use JsUnit, a JavaScript port of the Java JUnit unit testing tool. It works in all major browsers (IE6, IE7, Mozilla, Opera, and Safari), and provides a simple enough API to create tests almost immediately, while flexible enough to create entire nested suites of unit tests.

Labels: , ,

Tuesday, February 20, 2007

Rounding out chapter 3

Looking again at the UserProfile object, almost every aspect of it, from the events object to the loadValues method, can easily get pulled out into a parent object that other data models can extend. The same also goes for the ProfileController object. Using inheritence in this manner not only prevents writing redundant code, it also vastly reduces the amount of JavaScript the browsers must download in order to run the web application in the first place. Data objects then only need to contain the code specific to that data, such as custom validation or authorization checks, rather than requiring that each data object also manage its own communications with the server.

Coupling the power of inheritence with the MVC pattern, an application gains a wealth of power in the form of quickly developed modules of functionality, supporting the overall application structure. Data filtering, cleaning, and management get supported by default, along with automatic updating of the server with the appropriate data no matter how convoluted an interface the user uses to interact with it.

These methodologies, combined with event-driven application development, provide a well-rounded base for many Ajax-driven applications. By using events to trigger actions throughout the application, objects stay abstracted enough for reuse in multiple interfaces, without the need for custom code to "hook in" the objects needing to interact with it.

As with all patterns, they should get regarded as tools to use for their suited purpose rather than rules to follow. The MVC pattern can add unnecessary layers to an otherwise small and simple interface. Event-driven architectures can add meaningless abstractions and hoops to jump through when dealing with large data sets or "streaming" results. In short: design the application for the requirements at hand. Doing otherwise will add complications and make the code much more difficult to maintain and debug.

Labels: , ,

Friday, January 26, 2007

Contrast comparisons

dark text on a black background darker, partially unreadable text on a black background

A color of rgb(100, 100, 100) on black has a luminosity contrast ratio of 3.550595556268441, falling short of both Level 2 and Level 3. When enhancing contrast and having such similar colors, it actually lessens the readability.

lighter text on a black background lighter, sharper text on a black background

A color of rgb(150, 150, 150) on black has a luminosity contrast ratio of 7.2236099811596866, which meets Level 2, but falls short of Level 3. Enhancement at this level sharpens the letters more than increasing the contrast between the text and the background.

even lighter text on a black background even lighter, sharper on a black background

A color of rgb(200, 200, 200) on black has a luminosity contrast ratio of 12.719459678993227, which exceeds Level 2 and Level 3. Enhancement at this level also sharpens the letters.

Side note: I kind of wish I had found the Colour Contrast Analyser Firefox Extension before writing the "High Contrast Design" section of the chapter.

Labels: , ,

Monday, December 18, 2006

Chapter 2 excerpt

Ajax usage has exploded in a manner resembling the upswing of such web technologies as:

  1. The blink and marquee HTML tags1
  2. Animated GIFs
  3. Applets
  4. The table HTML tag
  5. Flash

Each of these - admittedly, for the most part, less technical - exploded into usage to the point where (to varying degrees) most web designers and developers have reflexive, knee-jerk reactions upon the mention of them. The original usefulness of each technology now has an overshadowing of the preconceived notion that they cannot get used in any way beneficial to the general user2.

As such, Ajax-based functionality fits best where it makes a given task easier for the user, rather than replicating functionality easily achieved by simpler, faster-developed means. Using half a dozen JavaScript files, numerous CSS files, and several Ajax calls for content, simply in order to render a company home page uses up a lot of time and memory for very little by way of benefiting the user3, and actually makes the user wait much longer than necessary while using much more of your server resources than necessary.

In contrast, adding a light-weight content loading script that displays a blog's comments when requested by the user reduces loading time by using less bandwidth, and keeps the comments in better context rather than jumping to a comment page with (in some cases) drastically different design.

  • 1 Neither of these tags actually exist within the HTML specification, but browsers have supported them for years, regardless.
  • 2 With the exception of the blink and marquee tags, which actually have specific instructions against their usage written up by the W3C.
  • 3 This does not mean that the referenced technology does not ever have benefit to the user, just that this particular use case does not benefit the user enough to warrant its usage.

Labels: ,

Tuesday, December 12, 2006

Table of Contents

At least, as of right now. Suggestions? Comments? Complaints? Just know that some of these chapter sections mean more as notes to me than actual chapter sub-headings. Ask questions, though.

  1. Introductions1
    • Background Info
    • Intentions
    • Prerequisites
  2. Usability
    • Interface vs. Showcase
    • User Expectations
    • Feedback and Indications
    • Semantic markup
    • What CSS and JavaScript have in Common
  3. Accessibility
    • Section 508 and WCAG
    • Screenreaders Can Handle AJAX
    • Unobtrusive JavaScript
    • Assuming Nothing
    • Designing with Accessibility in Mind
  4. Client-side Application Architecture2
    • Objects and Event Triggering
    • Model-View-Controller Design Pattern
    • Event-driven Application Development
  5. Debugging Client-side Code
    • Validation, Validation, Validation
    • Code Profiling
    • Browser Tools and Plugins
    • Unit Testing
  6. Performance Optimization
    • Bandwidth vs. Latency
    • Server-side Cache
    • Client-side Cache
    • Content Negotiation
    • Memory Usage
  7. Scalable, Maintainable AJAX
    • General Practices
    • A Multitude of Simple Interfaces
    • Dense, Rich Interfaces
  8. Server-side Application Architecture
    • Designing Applications for Multiple Interfaces
    • Model-View-Controller Design Pattern
    • Using the Factory Pattern with your Template Engine
  9. Keeping a Web Application Secure
    • HTTPS
    • SQL Injection
    • XSS
    • XSRF
    • Don't Trust the User
    • Don't Trust the Server
  10. Documenting
    • Yes, You Need To
    • API Documentation
    • Internal Developer Documentation
    • 3rd Party Developer Documentation
  11. Game Development
    • Single Player
    • Turn-based Multiplayer
    • "Real-time" Multiplayer
  12. Conclusions
    • Remember the Users
    • Design for the Future
    • Develop for the Future
    • Final Thoughts
  • 1Done! Just need to run it through the publisher's template (since I edit in vim and manage in subversion) and send it on its way.
  • 2First draft done! At least, as I wrote it for the sample chapter. I need to do another once-over, getting its coherency in place, so it keeps in line with the rest of the book, then run through the publisher's template, but I have most of the content and code samples there.

Labels: ,

Monday, December 11, 2006

Recommended reading (a small excerpt from the intro)

The following books (in no particular order) all have high recommendations from editors and the developer community alike, and any of them should serve as very good lead-ins to the chapters that follow.

  • Ajax in Action, by Dave Crane, ISBN 1932394613

    "Web users are getting tired of the traditional web experience. They get frustrated losing their scroll position; they get annoyed waiting for refresh; they struggle to reorient themselves on every new page. And the list goes on. With asynchronous JavaScript and XML, known as "Ajax," you can give them a better experience. Once users have experienced an Ajax interface, they hate to go back. Ajax is new way of thinking that can result in a flowing and intuitive interaction with the user.

    "Ajax in Action helps you implement that thinking--it explains how to distribute the application between the client and the server (hint: use a "nested MVC" design) while retaining the integrity of the system. You will learn how to ensure your app is flexible and maintainable, and how good, structured design can help avoid problems like browser incompatibilities. Along the way it helps you unlearn many old coding habits. Above all, it opens your mind to the many advantages gained by placing much of the processing in the browser. If you are a web developer who has prior experience with web technologies, this book is for you."

  • Professional Ajax, by Nicholas C. Zakas, ISBN 0471777781
    "Professional Ajax discusses the range of request brokers (including the hidden frame technique, iframes, and XMLHttp) and explains when one should be used over another. You will also learn different Ajax techniques and patterns for executing client-server communication on your web site and in web applications. By the end of the book, you will have gained the practical knowledge necessary to implement your own Ajax solutions. In addition to a full chapter case study showing how to combine the book's Ajax techniques into an AjaxMail application, Professional Ajax uses many other examples to build hands-on Ajax experience."
  • Ajax Patterns and Best Practices, by Christian Gross, ISBN 1590596161

    "Ajax Patterns and Best Practices explores dynamic web applications that combine Ajax and REST as a single solution. A major advantage of REST is that like Ajax, it can be used with today's existing technologies.

    "This is an ideal book whether or not you have already created an Ajax application. Because the book outlines various patterns and best practices, you can quickly check and verify that you're building an efficient Ajax application."

  • Understanding AJAX, by Joshua Eichorn, ISBN 0132216353

    "Building on what you already know, this fast-paced guide will show you exactly how to create tomorrow's richest, most usable Internet applications. Joshua Eichorn teaches through sophisticated code examples, including extensive back-end sample code based on PHP, the world's #1 server-side language.

    "You won't just learn how to code AJAX applications: Eichorn covers the entire development lifecycle, from use cases and design through debugging. He also presents detailed application case studies, including a start-to-finish update of a non-AJAX application that addresses everything from feature improvements to changing usage patterns."

The following websites also have a wealth of information available, most of which should prove useful enough to bookmark for easy access.

I'll also post an edited version of my bookmarks, since I use the references constantly for my day-to-day work, let alone when I need to look something up for the book. I just wanted to post the "I visit at least one of these sites almost every time I look up anything related to an Ajax problem" links. When I see others post a list of most-used references of theirs, I generally find at least one I didn't know about or look into enough to realize its full value.

Labels: ,

Friday, December 08, 2006

First excerpt - technologies used in the book

The example code will use the following technologies for each application layer:

  1. Webserver - Apache's HTTPD1 version 2.0. As of this writing, the Apache foundation has released the 2.2.* branch as the primary stable branch. The example configuration directives in the book should carry over without much deviation to the newer version.
  2. Database Server - MySQL Database Server 5.0. The 5.0.* branch introduces a wealth of useful functionality and stability over previous versions, including stored procedures, triggers, views, and strict mode. As of this writing, they have released the 5.1 branch as a beta.
  3. Server-side Scripting - PHP 5.2. While PHP 6 brings global Unicode support to PHP2, along with cleaned up functionality, closer integration of the new PDO database extensions, even more drastic improvements to the object model, and for some reason goto, the PHP group has only made it available from source so far. It has much development left on it, but should see greater adoption rates than PHP5 has seen so far. That said, PHP 5.2 brings an input filtering extention, a JSON library enabled by default, greater ability to track file upload progress, vastly improved time zone handling and more.
  4. Markup - XHTML 1.1. While XHTML 2.0 has reached its eighth public working draft, XHTML 1.1 maintains HTML compatibility while strictly enforcing XML, modules, and the progression to XHTML 2.0. Unfortunately, Internet Explorer does not in actuality support XHTML, rather it renders it as HTML. This does make quite a difference and holds many developers back from fully embracing the XHTML modules available to them. As such, the markup directly rendered in the browser will have the Content-type: text/html rather than application/xhtml+xml as recommended by the W3C. Technically, the specification3 strongly recommends against using text/html with anything beyond HTML 4 or XHTML 1.0 (HTML compatible). However, it does not forbid it, as it does with using anything aside from text/html with HTML 4.
  5. Style - CSS 2.1. CSS 3 introduces much of the styling and layout abilities asked for years ago and eagerly awaited by web designers, however it has not reached a stable enough point for many of the browsers to support any more than some of the basics4. Even with the much-anticipated release of Internet Explorer 7 (refered to as IE or IE7 from hereon in), IE still fails completely support even the CSS 2.0 specification. The IE development team worked very hard to improve the state of IE's CSS support and, while they did a fantastic job, they didn't quite make it all the way there. Since many resources5 exist already covering the hacks and fixes necessary to force IE6 and IE7 each to follow your design, this book will not go into detail of how to achieve complete, pixel-perfect, cross-browser designs.
  6. Client-side Scripting - JavaScript 1.5, together with the XMLHttpRequest object, which at time of writing, only exists as an informally agreed upon object and the very beginnings of a specification6. Many Ajax-type web applications and sites use Adobe Flash for text and XML communication with the server, Flash development gets too specific for coverage in this book. Many of the same principles and much of the architecture covered still apply, but the implementation differs. ActionScript, also an ECMAScript implentation, actually shares the syntax, object model, and often even development tools with JavaScript, so while the XMLHttpRequest object does not exist in ActionScript, and the working DOM differs, much of the other sample code should look very familiar and easy to follow.

Familiarity, at least to the point of understanding enough to port the code into your language of choice, will definitely help, though this book aims to provide the methodologies, architectures, and patterns which you can implement in your own rich web application, no matter what technology you use to drive it. The technologies listed above have several benefits. They can all get downloaded and/or used for free, on a wide range of platforms, tested in a wide range of browsers, and have large user bases and online communities ready and willing to assist you if you run into any problems with the technology chosen.

  • 1 http://httpd.apache.org/
  • 2 PHP does not technically pay attention to the bytes of strings. It just regards them as a numbered list of bytes. While this has the benefit of passing UTF-8 strings through PHP (even without the Multi-byte String library) unharmed, side effects can show themselves in the strangest, often most devestating, places in your application.
  • 3 http://www.w3.org/TR/xhtml-media-types/
  • 4 Rounded borders, multiple background images, column layout, text shadows, and transparency have all made it into the Webkit project. As of this writing, the Mozilla Gecko engine and Opera's rendering engine have also both implemented most of these.
  • 5 http://css-discuss.incutio.com/, http://blogs.msdn.com/ie/
  • 6 http://www.w3.org/TR/XMLHttpRequest/ as part of the Web API Working Group's activities.

Labels: ,