What is a [web] widget

... a web widget is a portable chunk of code that can be installed and executed within any separate HTML-based web page by an end user without requiring additional compilation.
Web widget by Wikipedia

Put simply, we need to provide prospective site owners with a short piece of code (henceforth, the "embed code") that they can place on their sites and have the widget appear without any additional modifications to the site.

How would we go about creating an embeddable widget?

Cross-site scripting (XSS)

Cross-site scripting is more often mentioned as a web vulnerability which uses the same technique maliciously to manipulate the target site. In this case, Javascript will be used to create the widget on the host site and not to attack it (you should always beware of including scripts from untrusted sources).

This technique is based on embedding a script <tag> on the host site that will refer to a script residing on your service. The script should then dynamically create the widget on the host site by manipulating the DOM and adding stylesheets and script tags as needed. Dr. Nic gives a nice overview of this technique in this detailed tutorial.

As the tutorial mentions, your embeddable script should have a unique namespace to avoid colliding with local scripts on the host site. Don't be shy to use a long and verbose name for this purpose. Example:

;(function() {
	var techfounder_super_embed = window.techfounder_super_embed = {
		init: function() {
			alert('embedded!');
		}
	};
	techfounder_super_embed.init();
})();

Some quick notes:

• I used a self executing anonymous function. This allows me to declare additional variables and functions other than my main namespace ('techfounder_super_embed' in this case) without polluting the main scope or interferring with existing code on the site.
• In order for the main namespace to be available outside of the anonymous function scope, I attach it to the window object.
• I preceded the function with a semi-colon to close any potentially open Javascript statement that might have been loaded before it, which would have resulted in an error.

As opposed to the advice given in Dr. Nic's article, I usually opt to use an external library such as jQuery, in order to better account for cross-browser differences as well as leverage the power inherent in such libraries. jQuery in particular has the useful noConflict() method which allows it to work side-by-side with other libraries, and can be loaded from a google CDN so it does not add bandwidth load on your server.

As for retrieving data cross-site (from your service server to the host site), there are 3 paths you could take:

• Embedding extra script tags which include JSON data that is constructed dynamically (as shown in Dr. Nic's tutorial).
• Creating an Iframe element that accesses a remote resource (ie, on your server) to retrieve the data, and then passing the data back to the document.
• Using a JSONP call to simulate a cross-site AJAX request. I personally opt for this technique as I find it the most elegant. jQuery supports this natively in recent versions, making it almost too easy to implement.

An important note to keep in mind that styling the widget elements should be done very explicitly. As the widget is embedded directly into the host document it could be affected by any previously loaded stylesheets. A good start would be to use a CSS reset (such as this one by Eric Meyer) and apply it directly to a unique ID that identifies the base widget element.

Iframe embedding

An Iframe is the most direct approach to including content from a remote site. It's easy to pass arguments in the Iframe source URL and have a response dynamically built in return. However the Iframe approach suffers from some limitations:

• You have to specify the Iframe proportions in the embed code and it should match the content exactly, else the content can get truncated. This also means the embed code would need to change if the widget appearance changes (which comes up often for customizable widgets).
• There are some security limitations for Iframe scripting, so if you need to manipulate the host site page in any additional way,  you would need to include a script <tag> as well in the initial embed code to bypass the security restrictions.
• Iframes are invalid markup in XHTML Strict doctype. Depending on the host site doctype declaration, this could present a minor issue (if the host site owner is concerned about with valid markup).

A big advantage in using an Iframe over directly embedding the widget in the host page is that you don't have to be concerned with external styles affecting the widget.

Which should you use

Cross site scripting is useful when there is a need to dynamically manipulate the host site page. This would include placing the widget in positions different to where the embed code was placed at, offering additional user-interface interactions or communicating data back to your server (as Google analytics does, for example).

The Iframe approach is useful when you can tell ahead of time the exact size of the embedded widget, and you only want it to display content and not offer any Javascript interactions that occur outside of the Iframe.

1. OO code is less performant than procedural code

The number one argument against OO application design from procedural advocates. This argument is based more on intuition than fact. The usual examples pit short procedural code against equivalent OO code in which procedural code comes out triumphant as more terse and performant.

//Procedural, quick and to the point!
$string = 'hello world';
echo $string;
 
//OO, verbose and ineffecient...
class Speaker {
	public function say($string) {
		echo $string;
	}
}
 
$me = new Speaker();
$me -> say('hello world');

Actually, this example compares apples to oranges. Both approaches use 'echo' to output a string, only in the OO approach it is wrapped inside a class method. A more appropriate example for the procedural code would be:

function say($string) {
	echo $string;
}
 
say('hello string');

Which is very similar to the OO code written before. Strong application structure actually does not differ greatly between OO and procedural/functional approaches as my second example suggests, and it is mainly a function of the developer's skill and experience.

OO methodology however gives more language features and scope constructs to deal with code complexities and to handle code reuse, features that would require much more discipline and experience to implement using procedural programming only.

In reality, it is the efficiency of the language parser that will determine performance differences between procedural and OO code. There are no inherent noticeable performance differences between both methodologies for common usage in web applications. More typically in the web environment, IO operations such as server requests or database queries are the bottlenecks of performance / scalability.

Since it's impossible to know in advance what the bottlenecks will be (you can only make educated guesses), I try to follow the Rules Of Optimization:

1. First rule of optimization - Don't
2. Second rule of optimization - Don't ... yet
3. Third rule of optimization - Profile before optimizing

It is much more important to pick a methodology that will promote more maintainable and structured code, as OOP does, to possible minor performance gains. With a well structured design, profiling an application and refactoring slow-performing code is a relatively straightforward process.

2. The backend is the most important part of development

I often see web developers treat HTML, CSS and Javascript as second class languages. While HTML and CSS are not programming languages per-se, correct implementation of both in a cross-browser and semantic way requires much experience and skill that I often see lacking in otherwise proficient web developers.

It is not uncommon to relegate implementation of those two markup languages to web designers or "client-side developers" (which are usually regarded as lower level developers) or to use auto-generating tools for creating markup.

Both approaches are wrong - the client side is an important aspect of the web development process, especially because of the unique environment a web site or application runs in on the Internet - the browser, which has many different flavours each with its own set of problems and constraints.

Javascript (or DHTML) is another domain expertise which is undervalued and yet has become such a common requirement in today's rich Internet applications. Many web developers coming from a server-side language background have an intrinsic dislike for Javascript because of its weird OO syntax, its difficult debugging scheme and its un-uniform implementation across browsers . I would admit to once have thought the same way, however through necessity I came to like Javascript and now consider it an indispensable skill for a serious web developer.

Don't disrespect the client side languages. Sometimes the greatest challenges in web development are found there.

3. Graphical designers are good at user interface design

* This is more relevant for web applications as opposed to web sites

While there is a connection between graphical design and UI design, graphical designers do not naturally make for good UI designers. I can not emphasis this enough. User interface and user experience design is a separate expertise from graphical design. How a user will interact with a site / application is different from how he will view it. It is connected - but not the same.

Quoting wikipedia:

Where traditional graphic design seeks to make the object or application physically attractive, the goal of user interface design is to make the user's interaction as simple and efficient as possible

Graphical designers with no expertise in UI design tend to prefer aesthetics over usability, and this is only natural as it accentuates their strengths. On the flip side, (web) developers don't usually make for good UI designers either.

UI design is important for creating a usable application. Make sure the right people are creating it.

4. The existence of a superior programming language

While some programming languages are considered superior to others (higher level, more featured, better syntax etc.), no one language can be considered the superior language. Debating that one exists is more a statement of personal preferences than a declaration of actual merit.

All modern languages have roughly the same features and can perform most tasks equally well. Some languages might be more suited to specific problems than others, however no one language does everything better than the others.

Some promote specific languages because of highly acclaimed frameworks developed for them (I'm referring to Ruby on Rails, naturally). While this is a more relevant argument, currently all the major languages have at least one serious framework (Django for python, Zend Framework / CakePHP / Symphony for PHP).

Use the language you are comfortable with, but don't deride others based on your inexperience with them.

5. XML is more economic than a DB

Database are notorious for being the major bottleneck for many successful web sites / applications. It is this notoriety that prompts novice developers to seek out alternative persistence layers - and XML is the common alternative.

In general, parsing XML is slower and more resource intensive than querying a database. This is dependent on the complexity of the query, but holds true for 99% of the cases. Furthermore, databases have a much more complete language to fetch, order and manipulate result sets.

XML is a portable format for storing hierarchical data. It is useful for porting data between different databases or between databases and interfaces. However XML is not a database, so don't treat it as one.

If you have more to add to this list, I would love to hear about it.

Quoting the CSS standards guide at the w3c website:

A float is a box that is shifted to the left or right on the current line.

...

This property specifies whether a box should float to the left, right, or not at all.

The float property pulls an element out of the normal flow and places it in either the left or right ends of the current line inside its containing block element. Other elements will then wrap around the floated element, providing they have enough space to do so (if the cumulative width of the elements is too wide, they will slide to the next line).

Floating is a useful technique when an elements needs positioning in the opposite direction of the normal text-flow, or when text needs to be placed near an image.

Examples:

I am a right-floated span!1. Look to the right.

2. This is text wrapped near
a floated image.

It's important to emphasis that the floated element will position itself to the side of the current line. The most common mistake is to place a right-floated element after the text it's supposed to float near. The intuitive thinking behind this is that the right-floated element appears to the right of the text, and hence should be placed after it (logical for a left-to-right language). However, for the float to be floated to the right of the text it actually needs to be placed before it, since it will be floated for the line it is placed in.

Examples:

The complementary property to 'float' is 'clear'. The 'clear' property cancels a float to either side or both. Using the float image example from before:

This is some more text wrapped near
a floated image. If I place an element with
a

The w3c standards declare that the 'clear' property only applies to block elements, however some non-standards compliant browsers ( * cough * IE6) will also apply it to inline elements.

A standard use for the 'clear' property is to prevent a block-element from collapsing if it contains only floats. For example we want to draw a border around two float:

But the border has collapsed, as the floats are outside of the normal flow of elements. To force the div to consider the actual height of the floats, we use another element to clear the float property:

There is an alternative technique for achieving the same results which involves using the 'overflow' property in combination with giving the containing element 'layout', which is explained in detail over at quirksmode - Clearing the floats.

Floats have additional uses in more advanced layout techniques, such as CSS columns and CSS table replacements. Along with the 'position' property, they are amongst the most powerful positioning properties for CSS layouts.

For more reference material:
maxdesign on floats - extremely comprehensive
Smashing Magazine on CSS Float theory - A collection of references to more references
The w3c standards guide, Visual formatting model

• Formal support for the CANVAS drawing API. Already implemented to various degrees in some browsers (excluding the usual suspect), the CANVAS drawing API is very useful for creating web graphics and interactions programmatically. (I recently wrote about a very interesting port of the Processing language using the Canvas element)
• Native drag-and-drop API (finally!)
• Formal API for editing (contentEditable/designMode). Gone are the days of 150kb+ WYSIWYG javascript libraries.
• An offline storage API
• Browser history API (for fixing broken behavior with modern techniques, ie AJAX)
• Server notifications API (standardizing a technique known as COMET).
• New attributes such as a global 'href' allowing every element to potentially be a hyperlink.

This partial list has enough improvements to make any sane web-developer happy. HTML is definitely heading in the right direction to retain its dominant position as the markup language for the web (its biggest advantage over XHTML being a much more user friendly error handling).

Now it remains to be seen how long it takes for this proposal to be finalized and implemented.

There are several problems with most RTE packages that somewhat limit their effectiveness - They produce non-standards compliant HTML markup (using FONT tags and Tables heavily), and they are usually a relatively heavy download (~150kb packed). For a site weighing at around 50kb-60kb integrating a 150kb RTE is a painful decision.

WYMEditor attempts to provide a standards-compliant light-weight alternative, that also shows you the type of markup that is being edited (such as Header, Paragraph etc.). It removes the ability to hand select styles such as colors and borders, instead forcing the editor to use style sheets to separate markup from styling. It's an interesting approach and one that I hope will catch on.

For some more in depth comparison of RTE's read this overview from Standards Schmandards.

Still, a nice tool for web designers wishing to test their HTML and CSS layouts against several generations of IE, without having to resort to hacking multiple installations of different versions (such as multipleIE).

IETester [via LifeHacker]