Developing web sites has become increasingly complex and fragmented with the release of one programming framework after another, and library after library, provided by a variety of different organizations, from Adobe to Zend.  This site accompanies my book on standards-compliant web site design and development, of the same title as at the top of this page, that's published by Amazon.

Web 2.0 means different things to different people.  Here, it refers to the designs and technologies used to implement modern, user-friendly Rich Internet Application ( RIA ) sites.

However this doesn't include any of the third-party 'eye-candy' libraries and frameworks that currently exist, such as JQuery. These contribute little or nothing to usability while bloating page sizes and slowing down site loading.

This site provides working examples of designing and developing web sites without using these libraries and frameworks, and without relying on features in specific HTML versions beyond HTML 4.01.  The focus is on building usable web sites, with design and coding blended in a practical, state-of-the-art guide to creating cross-browser Web 2.0 RIA sites in the simplest way that achieves the desired end result.

The web site architecture used here to implement Rich Internet Applications is pragmatic.  A single code base is used for cross browser-compatible Web 2.0 RIA 'Master Pages' that pass W3C validation.

These master web pages consist of HTML and CSS structural skeletons, and content that is pre-loaded, and loaded with Asynchronous JavaScript And XML ( AJAX ), that's swapped into and out of view as users navigate sites.  The content swapping is accomplished by manipulating the Document Object Model ( DOM ) with JavaScript.

Front-end web pages use AJAX to make background calls to pages running on web servers.  And AJAX is configured to return data in any format, not just XML.

Server-side code should only run functions that absolutely must execute on back-ends, such as database SQL queries.  And the use of back-end pages to write front-end pages' structure to browsers should be avoided, and they should just write the server-side data they access to front-end pages that load this content into the appropriate section of the page / site.

Whatever type of server-side pages are employed, client-side browsers use the DOM to swap old content out of view, format and write new content to front-ends, and swap new content into view.  Examples show returned data from partial and whole HTML pages, database SQL query results from PHP pages, remote domain mashups, information delivered in data arrays such as .CSV and JASON, and more.

Many different browser vendors and versions exist, so cross-browser solutions are provided that run in Internet Explorer ( IE ) 6, 7, 8, 9, 10, and 11, Firefox, Chrome, Opera, and Safari, under various Operating Systems, without third party libraries or frameworks.

HTML is fault-tolerant, with its ability to ignore new entities that will be defined in future releases of HTML, and that current and older versions cannot render.  And the concepts of fault-tolerance and avoidance, internally in web page code, are covered.

Defensive coding practices that handle unexpected situations are covered.  Examples of avoiding JavaScript programming issues, such as math rounding errors and problems due to improper use of JavaScript keywords like 'this', are provided, as are using a JavaScript subset to avoid problems with other keywords, such as 'with'.  And ways to avoid security issues like SQL injection and cross-site scripting are looked at.

Working examples from the companion book are shown on this site, with detailed explanations in the book.  These are written in HTML, JavaScript, AJAX, and CSS on the front-end, and PHP for file and database accesses, and cross-domain mashups, on the back-end.  None of these software packages require source code compilation, either initially or when code changes.

Dividing functionality between front-end UI code, server-side code and databases, and graphics production and design, will be discussed.  And the use of version control, both locally on development systems, and on servers used for hosting, will also be covered

The latest versions of HTML and CSS attempt to combine aspects of the numerous frameworks, libraries, and product versions, in new standards by including some of their features in the core language specification of HTML 5 and CSS 3, while maintaining backward compatibility with both HTML 4.01 and XHTML 1, and earlier versions of CSS.  But the new capabilities of HTML 5 and CSS do not work in legacy browsers that only support older versions, such as HTML 4.01 and CSS 2.

JavaScript

The defacto language standard for adding interactivity to web pages is JavaScript, and it's a lot more cross-browser compatible than HTML and CSS.

The various different browsers in use worldwide are as follows: Source : thenextweb.com
As you can see from the graphic, IE 6 still has more users than either Opera or Safari. So, unless you intend to focus on just one or two browsers and ignore everything else, you will have to deal with all 9 browsers, IE 6, 7, 8, 9, and 10, Firefox, Chrome, Opera, and Safari.

Of these, by default Firefox, Chrome, Opera, and Safari have ( more or less ) automatic updates, so only the current versions of these should need to be supported, along with the 5 versions of IE that you are likely to encounter ( at least, until the next version is released ).

PHP is the most widely used server-side language, although there are a number of others, such as C# and Perl.

So we will focus in this book on using PHP to run parts of applications that need to execute on the server, such as executing SQL queries on databases.

Topics will include the meaning here of usability and user-centered design.  Also covered will be how users' needs rather than programming issues should drive site design. For example, content is more important than whether Object Oriented Programming ( OOP ) or the Procedural style is used, or whether the site is programmed in PHP or Java, and so on.

However, ways to optimize page load times as perceived by users, will be discussed.  For example, loading viewable page areas before the whole page loads, with examples of what to do and what not to do.

User-friendly site navigation methods will be covered.  This will include providing 'Breadcrumb' indications of where users are located in menu structures, and keeping menus to a reasonable number of choices at any particular level, as well as limiting the depths of submenu levels, so that users can easily remember the choices they made to reach any particular topic

The importance of using a consistent navigation model that shows all options that users' have in menus will be stressed, as opposed to using one method on one page and another method on a different site page.   For example, switching from a horizontal menu at the top of one page to buttons scattered around on another page, should be avoided.

The twin concepts of 'Progressive Enhancement' and 'Graceful Degradation' will be covered, including how to avoid reducing web page functionality when the browser being used is an older version, by using JavaScript, which is inherently more cross-browser compatible than HTML, to provide the same functionality as in more advanced browsers.

Menus

The importance of separating functionality into client-side code running in browsers and back-end code running on remote web servers is discussed in the RIA book.  Everything that can be run at the client should be executed in browsers, and only tasks that absolutely must run on the back-end should be run at servers.  These concepts are key to using AJAX to produce RIAs.

The concept of swapping preloaded and AJAX-loaded content into and out of view in the client with JavaScript and the DOM, will be covered.  Using AJAX to call server-side web pages and partial pages will be briefly discussed, and expanded on in chapter 4.  And use of the smallest possible array format to return data will also be covered.

Examples of the Client-Server Master Page model are provided in the RIA book, including code for both the front-end and the back-end.

Menus consist of two types that operate a little differently from each other, the application's main menu and its submenus.  The two type of menus have appearances that can be set using HTML and CSS, or graphic images.  This site demonstrates both types, with graphic image main menu tabs, and HTML and CSS submenus, and RIA book describes menus in detail.

CSS is used to activate menu events - clicking the mouse to select a menu item, moving the mouse, over a menu item, and moving it off menu items - and the changes to menu items' appearance that result, such as different versions of an image for mouse-over and mouse-out, or different text colors for an HTML and CSS menu item.  And all the menus are built with HTML <a> anchor elements so that they can run JavaScript functions when clicked without the need for coding onclick(), and use CSS for onmouseover and onmouseout events which are otherwise all subject to event bubbling when coded in menu elements.

In all cases the menu and submenu items run JavaScript code to activate and show the selected items' contents and hide the contents of items no longer selected.   When a menu items with submenus is clicked it's shown along with a default selected submenu, if one has been previously selected.   If no submenu has been selected previously, the first submenu items' content is shown.

The menus are coded in 2 parts, one is the HTML code that forms the "shell" of the menu, and the other is the JavaScript code that's activated when menus are clicked.   Each menus' HTML shell is also divided into several parts. The main menu looks like this:

The approach to swapping content into and out of view is to switch entire sections of the site using the menu structure and events to control the showing and hiding of different sections.   And where sections haven't been loaded, they are imported with either an <iFrame> or AJAX.

Site sections can be hidden and shown using either the 'style="visibility:visible;"' and 'style="visibility:hidden;"', or the the 'style="display:block;"' and 'style="display:none;"' CSS instructions, both of which can, of course, also be executed with JavaScript.  But using the 'display' instruction removes the element from the DOM, so it can't be manipulated while the value is set to 'none'.

Swapping content into and out of view is a core concept of Web 2.0 and Rich Internet Applications, and is covered in detail throughout the RIA book.  And the technique is demonstrated with this site as well as in the widgets.zip, 'menus' section, and as shown below.

When using JavaScript, most of the code is cross-browser compatible, so with a little care to eliminate JavaScript code that only works in certain browsers, cross-browser issues mostly occur with page layouts.  This chapter of the book covers use of HTML code that avoids cross-browser problems by coding W3C standards-compliant site skeletons with nested HTML <div> elements.

The 'Occam's Razor' approach to cross-browser compatibility will be discussed - use the simplest approach that achieves the desired results.  This principal will be used to create a single code base for all targeted browsers, rather than detecting which piece of code to use in what browser, and switching the code around for different browsers.

Another approach is using different JavaScript and CSS code for different browsers, and this will also be covered using both inline code and external include files.  And the use of browser-detection and feature-detection to employ different code for different browsers will be covered.

These topics will be expanded on in the next chapter, including the IE-only method of using conditional CSS to determine the IE version and then using different values, and use of the <link> tag to load resources such as CSS and JavaScript files, e.g.

    <!--[if !IE]>-->
        <link href="non-ie.css" rel="stylesheet">
    <!--<![endif]-->

Note that this code validates properly, while hiding the code from browsers.

Layout, coloring, and contrast issues will be discussed.  And the use of popup alerts, lightboxes, and Model dialog boxes will be covered.

Readability, understandability, and usability for programmers will also be discussed, since clarity is important for efficient coding, especially if multiple programmers are working on each project or part of a project.

Ways to achieve browser compatibility with legacy browsers as well as all current browsers will be briefly covered.  Using 'Progressive Enhancement', or 'Graceful Degradation', and ways to avoid using these techniques so that the same capabilities are provided in both old legacy browsers and current browsers, will be covered.

For example, the 'AutoFocus' page element attribute in HTML 5 places the browser cursor in the page field where entry is to start ( e.g. a 'First Name' field ).  Currently this is done with JavaScript and the DOM, and if use of the DOM method is continued even though it isn't needed in HTML 5, browser version detection in order to branch to different code if the browser doesn't support HTML 5, is avoided.

The ways in which sites can be built to accommodate different screen widths will also be discussed, including fixed and variable-width page elements and text lines, and 'floating' page elements, with examples.

Fully operational, cross-browser, W3C-compatible examples of all of the above items in this chapter will be shown.

Event Bubbling occurs when JavaScript functions such as onclick() are used, and handling of the event passes up the document tree to parent elements from the element where the event occurred.  See the example below, Bubble.html:

Event bubbling can be avoided where it's not desired by cancelling bubbling as in the above example, but it's better to avoid it altogether if it isn't needed, to prevent unexpected interactions from occurring.

Ways to avoid event bubbling issues are covered in the RIA book in the 'Menus' section of Chapter 3.

Defensive coding is the practice of avoiding site errors by writing code that either avoids problematic situations altogether, or that checks for problem areas and handles exceptions.  If possible, code that avoids problems should be used ( such as recommended in the book for layout issues ), but if this isn't possible checks for problem areas should be coded, such as layout differences caused by variations in browsers rendering pages, where in that particular case browser detection can be used to fix such problems.

The underlying theme running through the RIA book is to avoid problem areas of web site construction where possible, just as Douglas Crockford recommends only using JavaScript's "Good Parts" in his book.  For example, several IBM articles point out the memory leak problems encountered with JavaScript closures, and suggest ways to get around them, including simply avoiding closures altogether.

See https://www.ibm.com/developerworks/library/wa-sieve/ and http://www.ibm.com/developerworks/web/library/wa-memleak/.

Ways to build Web 2.0 RIA sites with JavaScript will be shown, and the kind of language that JavaScript is, Procedural, Object Oriented, or Hybrid, and when it should and should not be used will be covered, and using JavaScript with all three styles will also be discussed.

Douglas Crockford's approach of using a sub-set of JavaScript will be covered and expanded on to provide cross-browser compatibility, with usage examples.  Using JavaScript to code functions that are native to HTML 5, but don't exist in legacy HTML versions and browsers, such as rounded page element corners, will be discussed.

Using JavaScript to detect the browser and version, and the use of feature detection, will be covered and compared.  Feature detection's shortcomings, such as not working for cross-browser layout variations will be covered.  Use of <iFrame> page elements to update sites will be compared with using the DOM to hide and show site sections.

Defensive programming will be covered, e.g. ways to avoid problems with JavaScript's 'this' and 'with' language keywords.  And examples of alternatives to unsafe code will be provided.  Cross-browser issues with deferring execution of scripts will also be presented.

Security issues such as SQL injections and X-Site scripting will be discussed, with examples of avoiding these problems.

The advantages of using arrays in JavaScript will be discussed extensively, including building HTML page elements such as drop down boxes and tables, with arrays and the DOM on-the-fly.  And implementing sorting of those tables will be covered.

Coding cross-browser events to inspect and compare existing page element values will also be investigated and demonstrated.

JavaScript's AJAX subset will be covered with examples of setting up AJAX to work in all browsers and call server-side pages that return any kind of results, rather than just XML data.  No third party libraries or templates will be needed or used.

Fault-tolerant programming that handles unanticipated conditions and checks for user input errors, will be covered.  Graceful degradation, or progressive enhancement - the disabling of capabilities in older browsers - and how that differs from fault tolerance, will be discussed.

The preferred method, of using cross-browser JavaScript to render progressive enhancement unnecessary, will also be examined.

Coding graphical page elements with JavaScript will be covered, e.g. rounded HTML element corners, drawing graphs, and image fading.

Use of 'Minifying' techniques to reduce both JavaScript and CSS file sizes and speed-up load times will be discussed, and savings will be compared to savings resulting from optimizing graphic file sizes.

AJAX loading of submenu content sections of the RIA site is accomplished by leaving the submenu content container <div> blank, as in:

	   <div id="subMenu80" style="height:2550px;position:absolute;top:-10px;left:20px;width:900px;">
	   </div>
	   

and putting all of the section content in a separate file named 'subMenuXX.txt', e.g. subMenu80.txt and subMenu84.txt which both contain the calendar and rounded corners example page.
 
 
These files are then called up in the 'loadFile(fileName)' function in the RIA site, which has been set up to load the named file content into a page submenu element of the same name, e.g. the file 'subMenu84.txt' loads into the page element '<div id="subMenu84">', in the following function in the RIA site:

	function loadFile(fileName)
	{
	  var request = createXMLHttpRequest();	// Initialize AJAX variable
	  var tempName = fileName + ".txt";
	  request.open("GET", tempName, true);
	  request.onreadystatechange = function() 
	  {
	    if (request.readyState == 4) 		// File has finished loading
	    {
		var responseText = request.responseText;// Collect file content
		el = document.getElementById(fileName);
		if (el)					// Defensive code check for page element
		{
			el.innerHTML = responseText;	// Put file content in blank element <div>
			el.style.visibility = "visible";
		}
	    }
  	  }
	  request.send(null);
	  return false;
	}
	   

Two calendar packages are discussed in the RIA book, a simpler and more lightweight one from DevX, and a more configurable but larger code size one from Gerd Tentler that has a slightly more restrictive license.  A live DevX calendar example is shown below, and is invoked by clicking the calendar icon next to the 'Move Date' fields. This example can be viewed stand-alone and downloaded at www.web2ria.com/calendar, and is also available in the widgets.zip file.

The current date in the calendar is highlighted, and the date clicked on is dropped into the 'Move Date' fields.

The Gerd Tentler calendar is covered in Chapter 7 of the RIA book, and can be found at http://www.gerd-tentler.de/tools/calendar/index.php?page=download, about half way down the page at the link calendar_js.zip.

This calendar, as shown below, is used in a bank time sheet application, with the first days of weeks highlighted in yellow for unsubmitted weeks and in lightgray for submitted weeks, as shown below.

 

Getting new random position

Test User Name = aliceClient     Test Password = pl01L4/?O]c     Scroll down the screen to see the "Usage" section

Usage

On first coming to this page, click the "Click to start Log-in / randomly shift Log-in position" button to display the Log-in widget, and use the keyboard normally to key-in the default "User Name" ( web2RIA.com ).  Then click the small keyboard icon ( ) next to the "Password" field to display the on-screen keyboard that's required to enter a password.

Mouse-over each character of the default password ( ISBN:781491 ) on the on-screen keyboard, and when done click the "Log-in" button to proceed.

Note that when it's displayed, the on-screen keyboard's position changes dynamically as you scroll around the screen, to maximize readability.  To see this, click the keyboard icon next to the Password field, and try scolling up and down the screen.  And if the Log-in widget is near the far right side of the screen, the on-screen keyboard automatically shifts to the left so that it's displayed in the visible part of the screen.

Calendars

Auto-complete

Drag and drop web page elements

Site maps with expanding

JavaScript Rounded

Table sorting and scrolling

Graphics

Mapping

Bubble Tool TipsAlessandro Fulciniti

Database Manager - EMS SQL Manager

FTP file transfer - Core FTP

Internet Explorer Testing - IETester