Posts Tagged ‘javascript’

Why plain, vanilla, anchors are a bad idea.

Monday, March 29th, 2010

A few days ago I was testing a soon to be released site. I followed a link I had never seen before and suddenly found my self confused and disoriented. In retrospect it could’ve been the fact I had just ran into a glass door on my way in (I totally didn’t see it there).

But, never the less, it lead me to tweet this:

GUIDELINE: Users should never “teleport” between areas of the page. This can be disorienting. Show the movement from one place to the other.

Ice, Ice, Baby

The reason why I suggested that is not because of the severe “bling” deficiency on the internet. Which, I might add, is getting worse by the day. Its, also, definitely not because I just got laid off and really need a job (see my resume). Its because its just plain bad UI design.

Now, don’t get me wrong. There are a lot of reasons you want link to a specific part of a document, but the way browsers implement this functionality is bad. Fortunately this is an easy fix if you use the scrollTo jQuery plugin

$(function() {
	$("a[href^='#']").click(function (e) {
		var element = this.hash;
		e.preventDefault();
		$.scrollTo(element, 1000, {
			offset: -50,
			onAfter: function() {
				$(element).css({"background": "red"});
			}
		});
	})
});

Dr. JavaScript and Mr. PHP

Wednesday, January 21st, 2009

In my last post I wrote about JavaScript variables.  It stemmed from realizing that the dollar sign ($) was a valid character in JavaScript.  I struggled to find any use for all of these new characters – other than making code unreadable.  One thing stuck out in my mind.  An old episode of Hak .5 where Billy Hoffman described a worm that would be written in a hybrid of Perl and JavaScript.  A Dr. Jekyll and Mr. Hyde scenario where the worm would embed itself in a web page and search for a “host”, and then infect that host.  That host would then serve pages with the worm embedded in it, creating exponential growth.  Unfortunately at the time he didn’t have a proof of concept.

Hybrid Means Better Gas Mileage

Unlike Billy’s technique I chose to use PHP instead of Perl.  Many of the language constructs are identical between PHP and JavaScript.  However there are few snags.

  • PHP scripts have to start and end with ‘<?’ and ‘?>’ respectively.
  • PHP variables must start with a ‘$’.
  • Most of JavaScript’s standard functions are wrapped in objects.  Math, String, etc.
  • PHP uses the ‘.’ for concatenation, while JavaScript uses ‘+’.
  • PHP uses C++ style definition for objects, while JavaScript uses a prototype definition.
  • JavaScript uses the C++ style const keyword to define constants, while PHP uses the define() function.

The Lucky Ones

Not all of these problems can be worked around, but enough of them can be worked around that functioning code can be written.

PHP scripts have to start and end with ‘<?’ and ‘?>’ respectively.
The workaround for this is to run the script using the eval() function.  The PHP’s eval() function doesn’t require the opening and closing tags as feature.
PHP variables must start with a ‘$’.
The dollar sign is a valid character in JavaScript variables, so starting them with the dollar sign poses no problem.
Most of JavaScript’s standard functions are wrapped in objects.  Math, String, etc.
PHP.js can be used to wrap the standard JavaScript functions.  Acting as a compatibility layer.
JavaScript uses the C++ style const keyword to define constants, while PHP uses the define() function.
PHP version 5.3.0 allows for the const keyword.

Taking the Plunge

As a proof of concept I wrote a small function to calculate  the great circle distance.  It computes the distance in both PHP and JavaScript.  You can find it here and hybrid PHP / JavaScript code here.

The many lives of JavaScript variables

Saturday, December 13th, 2008

So, It was about three months ago when I first met jQuery.  It’s a neat little library that helps JavaScript programmers easily do relatively complex things.  Among many of its features one stood out to me.  The $() function is an interesting beast that takes a CSS selector or XPath and returns a set of matching nodes.  However, the application of it was not what attracted me to it.

The Revelation

The name, a single dollar sign, is what struck me.  I never knew that such a character could be used in a variable name.  As I, and many others, were taught the only character allowed were:

  1. letters
  2. underscores
  3. and numbers so long they are not the first character

I was interested and decided to embark on quest to figure out what characters were allowed and which weren’t.  This took me to the ECMA-262 specification, the standard for JavaScript, or ECMA Script as its formally called. The standard states:

Identifiers are interpreted according to the grammar given in Section 5.16 of the upcoming version 3.0 of the Unicode standard, with some small modifications.

The Unicode Standard allows for nearly 14,000 characters to be used in variables, as opposed to the measly 63 that are commonly used.

The Disappointment

I instantly tried to stuff Sigmas (Σ) and Double Struck N’s (ℕ) in to my code, but to my dismay, they didn’t work.  Disappointing? Yes.  Surprising? No.  It seems to be this way with all web standard’s, either implemented wrongly or incompletely (or both, heres looking at you Microsoft).  So, to test compliance I wrote a small JavaScript that creates a variable, using one of the Unicode characters, and assigns a value to it.  If throws an exception, then that means the browser doesn’t support that character.  Simple enough, but who wins this browser compliance battle.  So far Opera, it supports 99.5% of all characters.  Heres the data I’ve collected so far:

Browser Chars Tested Non Supported Chars % Not Supported
Opera 9.27
(Ubuntu Linux)
13935 78 0.5597416576964478
Opera 9.63
(Windows XP & Ubuntu Linux)
13935 80 0.5740940078937926
Internet Explorer 8
(Windows 7 and XP)
13935 2131 15.292429135270902
Google Chrome
(Windows XP)
13935 2746 19.705776820954434
Internet Explorer 7 & 6
(Windows XP)
13935 4340 31.144599928238246
Firefox 3.0, 3.5, 3.6
(Windows XP & Ubuntu Linux)
13935 7220 51.811984212414785

Yeah, I know thats a pathetically small dataset, but you can help run the test script and then post the last three lines in the comments along with the browser, version, and OS.  WARNING: This script takes a very long time to execute, it may appear to lock your browser up, but be patient.

On an unrelated note, Chrome’s Javascript engine was suprisingly fast.