What’s wrong with this picture?

It’s very misleading, that’s what.

The heading is asking me “Can’t see this content?”, but I can, can’t I? I’m reading it! Oh, the word “this” isn’t associated to what I’m reading (as it should be), but rather what I’m not reading. Interesting.

Misleading text has also found its way into the body content, once again, I am reading the content aren’t I? Another thing is that the content also implies that I have JavaScript disabled when I actually don’t. I believe you’re statistically more likely to have a user without flash installed, than without JavaScript enabled. So with that in mind, it would have been a better idea to ask if they have flash first then ask about JavaScript. Even better would be to do a check to see if JavaScript is enabled, if it is you don’t need to display that part of the message at all!

One last thing, those controls at the bottom; what are they doing there? I know (now) that they’re there because the content that’s supposed to be showing is a movie, but prior to having that knowledge surely they just reinforce the feeling that I am seeing what I’m supposed to. I have content, I have play controls, hey why aren’t they working? They serve no purpose apart from to confuse the user.

A slightly better picture

I’ve modified the content to be – in my eyes – a bit more respectable. It still isn’t perfect, like I said above, some JavaScript detection would be nice. Here it is non-the-less though:

“Reading this?”

I most certainly am.

“If you are reading this message, then you are unable to view our active content.”

Oh dear, so that’s what this is all about. How do I fix it?

“Please either download the latest version of the Macromedia Flash Player or enable JavaScript in your browser.”

Will do, thanks for the help Mr. Usable Information Box.

The way I see it is we’re already breaking the rule of separation by using conditional comments in the structure, so why don’t we cease this opportunity to save our friends (users of Firefox, Safari, Opera etc…) some bandwidth by providing IE specific JavaScript in the same way too?

For those wondering what I could mean by “IE specific JavaScript”, an example would be simulating the CSS focus pseudo class on form elements – something highly recommended for an accessible and usable form – which aren’t implemented in the market standard versions of Internet Explorer (6 and below).

I don’t think users of compliant browsers should be punished by downloading extraneous scripts, loading events into the queue and then spending time evaluating code that doesn’t even apply to them.

I’m proposing that we devote a section of the page head tag to Internet Explorer, that’s simply a conditional comment section that contains any style sheets and script blocks that only apply to IE.

Example 1 (what we are doing)

<!--[if lt IE 7]>

<link rel="stylesheet" type="text/css" href="/css/ie-specific.css" />

<![endif]-->

<script type="text/javascript" src="/js/ie-specific.js"></script>

<script type="text/javascript">

    addEvent(window, 'load', function() { if (document.all) { doIEStuff(); });

</script>

Example 2 (what we could be doing)

<!--[if lt IE 7]>

<link rel="stylesheet" type="text/css" href="/css/ie-specific.css" />

<script type="text/javascript" src="/js/ie-specific.js"></script>

<script type="text/javascript">

    addEvent(window, 'load', doIEStuff);

</script>

<![endif]-->

In Example 1 only Internet Explorer (prior to version 7) will download the stylesheet, but all browsers download the “ie-specific.js” JavaScript file and evaluate the addEvent code block. However if we follow Example 2, Internet Explorer will download the JavaScript and CSS just like normal, but other browsers simply see the whole section as a standard html comment and thus won’t download anything or evaluate the code block.

Wonderful, eh? I feel more comfortable with this approach than using questionable browser detection methods in JavaScript and it also reinforces (by just a tiny little bit) that compliant browsers are faster than their non-compliant brethren.

Simply close down your open instances of Safari and enter this into the Terminal:

defaults write com.apple.Safari IncludeDebugMenu 1

That’ll enable a new Debug menu next time you start Safari, simple as that. I was on the verge of loading up Firefox on the Mac
before I came across this, bad James!

Also, just in-case, running the above again with 0 will turn off the menu.

If you had a repeater that for each item contained an Hyperlink control, you’d get a duplicate entry in the ClientIDs object for every record, to avoid this problem I simply don’t output any sub-controls from within repeater style objects.

That may sound like a bit of a hack, maybe it is, but if you want to refer to multiple elements within another, you shouldn’t really be doing it by ID anyway.

You can get the updated source here or view the full article here.

<asp:TextBox ID="txtUsername" Runat="server" /> within a standard page simply has an ID of txtUsername within the HTML output. On the other hand, the following example would result in something along the lines of _parent_txtUsername as the ID:

<div id="parent" runat="server">
  <asp:TextBox ID="txtUsername" Runat="server" />
</div>

This isn’t really much of a problem when all you are working with is server-side code, but when you start tinkering with JavaScript, things become quite annoying and get an overall feeling of hackyness.

One solution, which I have used time-and-again, is to use a script block at the end of your page where you create a series of variables that contain the actual IDs. You then use these variables to reach the actual elements via JavaScript.

<script type="text/javascript">
  var txtUsernameID = '<%= txtUsername.ClientID %>';
  var txtPasswordID = '<%= txtPassword.ClientID %>';
</script>

This solution works fine, but it isn’t exactly pretty and it doesn’t weigh well on my conscience.

Javascript Mapping

I’ve created a simple class that traverses the control structure and outputs an object that contains the mappings, as above, but without any client-side intervention; not a <%= ...ClientID %> in sight.

An example of the output would be:
var ClientIDs = {
  txtUsername = 'ctrl0_txtUsername',
  txtPassword = 'ctrl0_txtPassword'
};

Which enables you to reference elements, that you know are server-controls, by calling ClientIDs.txtUsername.

Before:

<script type="text/javascript">
  var txtUsernameID = '<%= txtUsername.ClientID %>';
  var txtPasswordID = '<%= txtPassword.ClientID %>';

  function validate() {
    var username = $(txtUsernameID).value;
    var password = $(txtPasswordID).value;

    if (username == 'james') {
      alert("you shouldn't be here!");
    }
  }
</script>

After:

<script type="text/javascript">
  function validate() {
    var username = $(ClientIDs.txtUsername).value;
    var password = $(ClientIDs.txtPassword).value;

    if (username == 'james') {
      alert("you shouldn't be here!");
    }
  }
</script>

ServerControlIDs class

Methods

void Emit(page) – Builds the controls of the page into a mapped structure, registering a client-side script block for the output.

void Emit(control, literal) – Builds the controls of the control into a mapped structure, rendering the output into the literal control supplied. The literal is best suited to being placed into the <head> tag, which helps improve the semantic nature of your page.

Properties

bool Whitespace – Sets whether the output should contain whitespace, provided only for “prettifying” your code; defaults to off.

string VariableName – Sets the JavaScript variable name used; defaults to ClientID.

Usage

To use this class, simply create an instance in the PreRender event for your page — this ensures that all the controls have been set to their correct state — then call the Emit method you desire.

History

[1.1] Removed IDs from Repeater/DataGrid contained controls.
[1.0] Initial release

Download

That’s all there is to it, use the link below to get the latest version of ServerControlIDs.

Please note that this code isn’t pretty and it could probably do with some revising, but it works and that’s what’s important to me. I’m open to suggestions and feature requests.

Current Version (1.1)

That works fine, but we sure know it isn’t semantic. The way forward — greatly popularised by the Prototype, Dojo and Behaviour libraries — is to use DOM compliant event listeners. These fire arbitrary code, in a very similar way to attributes, when an event is raised. Unlike attributes these event listeners can be hidden away in their rightful place, the document header.

Perfect – clean semantic markup and real event handling.

…or is it? Unfortunately nothing is ever smooth when dealing with standards (it’s hard to promote the underdog when the underdog barely works anyway…).

Our Problem

The biggest setback for using event listeners is that nothing will fire until the whole of the body has finished loading, including any images that need to be downloaded. This can cause something similar to the FOUC, where a page appears in one state for a moment until the javascript executes; not a pretty sight and generally hard to sell as a browser fault.

If you had the following code in your header tag, the element aTable would be visible until the page has finished loading, at which point it would suddenly dissapear.

<script type="text/javascript">
    function hideATable() {
        document.getElementById('aTable').style['display'] = 'none';
    }

    Event.observe(window, 'load', hideATable, false);
</script>

What we really need is an onBodyRendered event to hook to, which fires as soon as the body has been parsed, irrelevant of whether the content has been loaded.

The Solution

The only real solution to this problem, as there isn’t an onBodyRendered event, is to force the browser to parse our javascript before it has finished loading. The method of doing this is to embed a script block just before the end of the body tag containing the functions you wish to execute. The reason this works is because the browser parses any javascript it encounters within the body tag and evaluates it while rendering.

The following code would hide the table before the page has finished rendering; exactly what we want.

<script type="text/javascript">
    hideATable();
</script>

My additions

The above method isn’t completely desirable, because it is still mixing code with markup and any code within the footer will not be cached. There isn’t much you can do about that really, but one thing that i’ve taken to doing in my websites is to make sure there is only ever one function call in that footer script block.

My method of doing such a thing is to create a special object that represents all my pages and their individual footer script blocks. You can see below an example of such an object, there’s an wrapper object that allows for further extensions (such as Unload or Validation sections) and then the Load object that contains each pages onload function. Each page then has a single line script block like Pages.Load.Home();

var Pages = {};

Pages.Load = {
    Home: function() {
        highlightSomething();
        hideSomething();
        saveCookies();
    },

    Portfolio: function() {
        hideSomething();
        makeMeLookGood();
    },

    Contact: function() {
        highlightFields();
    }
};

So the above code is stored in an external js file and loaded in the usual way, thus being cached.

Before:

<script type="text/javascript">
    highlightSomething();
    hideSomething();
    saveCookies();
</script>

After:

<script type="text/javascript">
    Pages.Load.Home();
</script>

While using it lately I came across a small bug in the code it’s based-on, Simon Willison’s getElementsBySelector(), when you use a selector that references an invalid ID paired with a tag name (e.g. body#profile, when #profile doesn’t exist), a script error occurs; yet using #profile alone works fine.

After a little bit of digging I found a solution, the source of the error is line 89:

if (tagName && element.nodeName.toLowerCase() != tagName) {

It’s finding the tagName (body), but element is undefined due to the ID being invalid. A slight change to the above if statement fixes the problem.

if (!element || (tagName && element.nodeName.toLowerCase() != tagName)) {

Maybe somebody will find that useful, I’ve posted it on Simons blog, but incase he doesn’t accept the change you can download the modified version here.

Note: If you’re using Behaviour, as opposed to just getElementsBySelector(), you’ll need to paste the contents of the above file into the bottom of your behaviour.js file, overwriting everything after the Behaviour.start(); line.

Even further outside of the web — in the real world — Sara and I got tickets for the Foo Fighters, Queens of the Stone Age and Motörhead show in Hyde Park, London. That should be an entertaining night and it’s a very good excuse to get ourselfs down to London again, a city we really enjoyed last time.

¹ Any anchors with a class of “add”, within a div with an ID of “items” that itself is within a fieldset in a form tag.

Anyway, even though both the extensions manager and Venkmans official website both say there aren’t any updates available, Joe Walker from Getahead has created and update that contains some bug fixes from Bugzilla, but most importantly Venkman now works with Firefox 1.5.0.1!

Source: Venkman for Firefox 1.5

Please, stop reading a four year old post and just download jQuery.

Download: domnavigation-1.1.js

As I said I would be in my previous post, I’ve been working on improving getNextElement. I’ve improved the overall performance of the function and also created a few others with similar purpose; including the sister function getPrevious element. I outline all the functions and their uses below; you can find the download link at the top and bottom of this post.

Any bugs anyone finds don’t fret to email me or post a comment here, i’ll work on fixing them asap.

The Functions

getNextElement & getPreviousElement

Basically this function is a more advanced, flexible version of the “element.nextSibling” and “element.previousSibling” properties. Features include the ability to specify the next element you’e looking for explicitly, so you can return the next list-item in a list (even if it happens to be a child of the current element) or the next matching node type. Also recursion is toggleable.

getFirstChild & getLastChild

A core part of getNextElement/getPreviousElement, this function recursively searches an elements child nodes for a matching element. Can be used stand alone to only return from within an elements child structure; recursively parses the childNode structures of all child elements.

getNextParent & getPreviousParent

Gets the next node in the DOM tree after the current nodes parent; this walks the DOM tree backwards until it finds a parent of the current node with a nextSibling/previousSibling present.

isType

Detects whether a specified element is of correct type; compares against a numerical value (nodeType) or a string value (tagName).

The Examples

Note: All functions that require an element as a parameter can either take a direct reference or a string ID value.

getNextElement & getPreviousElement

Both functions take exactly the same parameters and are used in the same way, so I’ll only provide examples for one.

Note: These functions also walk up the DOM tree, so if you have two lists and call getNextElement on the last list-item in the first list it will return the first item of the second list.

getNextElement(id);

Returns the next element, regardless of type, after id.

getNextElement(id, 'li');

Returns the next list item, after id; could potentially be a child of id.

getNextElement(id, 1);

Returns the next element with a nodeType of 1.

getNextElement(id, 'li', false);

Returns the next list-item that resides on the same level, or higher, as id; no child nodes are searched.

Practical example:

<div id="popup">
    <h1>This is a popup</h1>
    <p id="paragraph">Below are some options:</p>
    <ul id="list">
        <li>Your first choice</li>
        <li id="secondItem">Your second choice</li>
    </ul>
</div>

getNextElement('popup');

Would most likely return whitespace.

getNextElement('popup', 1);

Would return the H1 tag.

getNextElement('paragraph', 'li');

Would return the first list-item, “Your first choice”.

getPreviousElement('secondItem', 'ul');

Would return the UL element.

getPreviousElement('paragraph', 1);

Would return the paragraph element.

getFirstChild & getLastChild

Once again, both these functions take the same parameters and behave the same way so I’ll only provide examples for one.

getFirstChild(id);

Returns the first child of id, regardless of type.

getFirstChild(id, 'li');

Returns the first child of id that is a list-item.

getFirstChild(id, 1);

Returns the first child of id that has a nodeType of 1.

Practical example:

<div id="popup">
    <h1>This is a popup</h1>
    <p>Below are some options:</p>
    <ul>
        <li>Your first choice</li>
        <li>Your second choice</li>
    </ul>
</div>

getFirstChild('popup');

Would most likely return a Text node with some whitespace.

getFirstChild('popup', 1);

Would return the H1 element.

getFirstChild('popup', 'li');

Would return the first list-item, “Your first choice”.

getLastChild('popup');

Once again, probably whitespace.

getLastChild('popup', 1);

Would return the UL element.

getLastChild('popup', 'li');

Would return the last list-item, “Your second choice”.

getNextParent & getPreviousParent

Again, both these functions take the same parameters, so I’ll only show one.

getNextParent(id);

Returns the node next to the parent of id.

Practical example:

<ul>
    <li id="first">Item One</li>
</ul>
<ul>
    <li id="second">Item Two</li>
</ul>

getNextParent('first');

Would return the second UL element.

getPreviousParent('second');

Would return the first UL element.

isType

isType(id, 'li');

Returns true if id has a tagName of ‘li’.

isType(id, 3);

Returns true if id has a nodeType of 3.

Download: domnavigation-1.1.js