Showing posts with label javascript. Show all posts
Showing posts with label javascript. Show all posts

Thursday, September 03, 2009

jQuery and checkboxes

Let's start with a simple checkbox like this:

<input type="checkbox" name="foo" value="bar" />

To check whether this checkbox is checked you can do either of the following two alternatives:

$('input[name=foo]').is(':checked')
$('input[name=foo]').attr('checked')

To check the checkbox we can use the attr() function

$('input[name=foo]').attr('checked', true);

And likewise to uncheck it

$('input[name=foo]').attr('checked', false);

Friday, March 13, 2009

Visual Event

This is a really neat tool by Allan Jardine, a UI developer! It makes it so easy and visual to see what even handlers are attached to the elements of a page. Great addition to my toolbox!

When working with events in Javascript, it is often easy to loose track of what events are subscribed where. This is particularly true if you are using a large number of events, which is typical in a modern interface employing progressive enhancement. Javascript libraries also add another degree of complexity to listeners from a technical point of view, while from a developers point of view they of course can make life much easier! But when things go wrong it can be difficult to trace down why this might be.

Read the whole article about Visual Event

Wednesday, November 19, 2008

Track 404 with Google Analytics

For many of us it is important as well as interesting to see where our customers go, which pages they visit. Tracking the pages is quite simple with Google Analytics. However the question is: "How do you track the pages that do not exist?"

If you configure your server or web application to handle 404 error - page not found (I strongly recommend you do) you will have a template page that is displayed every time the user navigates to an invalid URL - a page that does not exist.

So, how do we do this? How do we track our customers that somehow got lost and landed in a location that does not exists, at least not as a valid location that would provide them with the information that they expected.

It's quite easy. If you search for more information you may come across Google Analytics blog post Tracking 404 Pages, which is now outdated as the new ga script is recommended instead of old urchin. The best source for the answer is Google documentation itself. Simply follow these instructions.

<script type="text/javascript">
    var pageTracker = _gat._getTracker("UA-xxxxx-x");
    pageTracker._trackPageview("/404.html?page=" + document.location.pathname + document.location.search + "&from=" + document.referrer);
</script>

This code sends a virtual pageview of "/404.html?page=[pagename.html?queryparameter]&from=[referrer]" to your account, where [pagename.html?queryparameters] is the missing page name and referrer is the page URL from where the user reached the 404 page.

Then simply look for /404.html in your Top Content report.

Saturday, October 11, 2008

HTML id attribute valid values

Many (if not all) HTML tags can have id attribute. This attribute uniquely identifies the tag on a single HTML page. Web designers use ids when they design the page using CSS. Web developers use ids for retrieving DOM objects via JavaScript or functional testing of their sites.

Despite the wide use of id attribute, many of us get it wrong, the value of the id tag attribute to be precise.

According to the HTML 4.0 specification for basic types:

ID and NAME tokens must begin with a letter ([A-Za-z]) and may be followed by any number of letters, digits ([0-9]), hyphens ("-"), underscores ("_"), colons (":"), and periods (".").

This is a very basic rule and yet many of us get it wrong, not on purpose of course.

The most common mistake come with web applications that display data from a database. Most commonly a database record is uniquely identified in the database by a record id. This is number that is unique per database table. The common mistake is to use this (database) id as a value of the id attribute on a HTML page. The problem is that the database id is a number, but HTML ids cannot start with a digit. Remember HTML ids must start with a letter A-Z or a-z. Therefore the database id needs to be pre-pended with at least a single letter.

Even worse, I have seen web applications to use entity names as ids. These names are semi-unique, but may contain international characters, characters outside of A-Z and a-z range and even spaces.

If you are going to use a prefix before the database id and you want to separate the two, I strongly advise you to use underscore ("_"). My reasons are the following:

Don't use spaces (" ")! The reason for this is simple. Space character is not a valid for id or name attribute.

Don't use hyphens ("-")! If you intend to use an id with JavaScript in the form document.idname.value, you must use a name that is a valid JavaScript variable name. Hyphen (or minus) would break the JavaScript on your page.

Don't use colons (":") or periods (".")! These characters are valid, however if you decide to use CSS or some JavaScript library that uses CSS-like selectors (e.g. jQuery), periods will be mistaken for CSS class selectors and colons for pseudo-class selectors (e.g. :hover for links).

For the geeky ones, it is possible to start an id with a number (if you really want to) but you need to represent this number with its Unicode escaped character.


Creative Commons License This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License.