(Originally posted 2007-12-10.)

Nowadays – actually thenadays šŸ™‚ but more so nowadays – the value of a web page is related to how well structured it is. Well structured from a mashup programmer’s point of view…

As I often say you have to assume that people will want to take your web pages and mash them up in ways you never thought likely. If your web page is hard to navigate, extract material from, etc then people will use other pages and sites as the basis of their mashups. And you will lose traffic / business / kudos or whatever other metric of success you choose to use . Unless it’s obscurity you seek. šŸ™‚

Here are two simple rules I’ve become sensitised to as a Firefox extension author…

Use id Attributes On “Structural” Elements

Motivation: To reliably navigate to a particular portion of a page javascript programmers use the getElementById() method. It takes the a string parameter and returns one element whose id attribute matches.

Not having this attribute gets you into “I want the third entryfield on the page. No wait, it’s moved to be the fourth” territory. Nasty.

But should you apply this to every element on the page? Not necessarily. But you should think about the structure of the page from the mashup perspective. So a major element like the edit field on your page should probably have an id attribute. (This is a real-world example for me as my Firefox extension parses and injects stuff in a suitable entryfield – for a wide variety of pages. All the “not plain text” in this post was injected programmatically by my extension.)

Use name Attributes on Forms And Form Elements

Motivation: In javascript the document element has an array property “forms”. So you can refer to an individual form as e.g. myDoc.forms[“postForm”] or even simply myDoc.postForm rather than having to hunt through the forms array for a somehow matching form. But only if you give the form a name attribute. What’s more you can refer to the elements in the form directly (e.g. myDoc.postForm.textField) but again only if the element in question has a name attribute.

(In fact the value of using the name attribute extends (in part) to images (<img> tags) and java applets (<applet> tags) but the value is rather less. (Navigating to an image and, especially, to an applet is relatively rare.)

One minor Firefox disappointment: I use the Built-in DOM inspector a lot and it doesn’t either show the “formname” property or enumerate the forms property by form name. I wonder why it doesn’t when there are perfectly good javascript ways of doing it.

These are simple examples of how to make life easy (or difficult). I’m sure there are many more. The bottom line, though, is to make web pages easy to mash up with other sources of data.

A Note On Javascript And Other Languages

I keep mentioning Javascript, don’t I? That’s simply because it’s the language in this space I’m most familiar with. (It’s typically seen in Firefox extensions and in AJAX, particularly in frameworks such as the dojo toolkit (which I’ve just installed.)) An increasing number of web servers are going to be doing their own aggregation or mashing up. I suspect they’ll rely on other languages such as PHP.

But it doesn’t matter… The guidelines above apply in just the same way to these server-side mashup languages. (I’ve just installed PHP on Apache and intend to play around with such mashing up at some point.)

Published by Martin Packer

I'm a mainframe performance guy and have been for the past 35 years. But I play with lots of other technologies as well.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: