wheresrhys

Since starting out in web development probably the most recurrent frustration (along with internet explorer 6) has been the failure of back-end developers to mark-up web pages correctly, i.e. in a semantic manner. It’s frustrating for a number of reasons

1. It’s easy
   It really is. Most of the html tags are named very sensibly and have a clear purpose. Here is a complete list, and the site that list is on also has a walk-through guide to marking up a web page properly.
2. It’s not so easy
   Despite being a doddle, it’s not something you can just assume you know how to do well, and I think too many back-end developers, because they can write html and it doesn’t produce an error message, assume what they write is good enough.
3. Sometimes the incorrect markup is put there in an effort to help
   I’m talking mostly of tables here. It’s painful to have to remove the nested table structure a back-end developer has put in to do the basic layout for you, as it’s a waste of everybody’s time.
4. It would be so easy to ask the front-end people what mark-up they would like
   IT offices aren’t generally the most talkative places in the world, but you do nevertheless hear conversations relating to optimising the caching, server loads and so on. But no-one has ever approached me asking how they should mark-up a page.

I don’t mean this post to come across a huge bitching session. I’m sure if writing some back-end code was as inseparable from front-end development as writing some html is from back-end development then back-end developers would be horrified by the poor quality of front-end developers’ contributions to the code-base. So I offer the following advice to back-end developers in the spirit of co-operation, respect, Obama and all that.

1. Most important of all, don’t worry about what the web page looks like. Removing ‘helpful’ mark-up put in to make the job of applying the design easier is often the most taxing job for a front-end developer.
2. Never use tables to layout a page. Put a div around each major content area and leave it at that, even though it will mean all the unstyled content stacks up vertically.
3. Don’t use inline styles, as these can not be overridden from a stylesheet.
4. Don’t put text directly into a div. Either the div should be a p tag (paragraph) or there should be  a p tag inside the div.
5. As a general rule, for items on a page there will be a corresponding html element.  Here is that complete list again. Take a little time to get to know what elements are available (you probably already know most of them), or even keep a print out on your desk for reference. Sometimes you have to stretch the definition a little (eg sometimes I will use the <strong> tag a bit like a heading, if the heading is supposed to appear inline within a paragraph). Only turn to using a div or a span as a last resort. If you still find yourself using something like <div class=”heading”> instead of <h2>, consider a  lobotomy.
6. Don’t put in img tags for eg bullets in a list. If the image is a design graphic as opposed to a picture with some meaning, the chances are it can be added as a background image later using CSS
7. Similarly, don’t use <br /> tags to add vertical space. Your designer would probably much rather do it with CSS margin or padding.
8. And don’t use font tags to apply a font.
9. For navigation use a <ul> tag to wrap, and <li> tag containing an <a> for each item. Don’t be fooled by the default (vertical) display of lists. Using CSS they can be laid out pretty much however, so even if the list of links is horizontal you should still use this markup
10. Forms are probably the trickiest thing to mark-up. No-one can quite agree what the best way is, but if your front-end developer is a good one chances are they will like something like this accessible forms method. Don’t be put off by the numbered list, as CSS can get rid of the numbers. Pay special attention to how it marks up the radio/checkbox elements. One thing it misses is that you should probably give a class of ‘submit’ to your submit buttons as these will most of the time need a hook to enable them to be styled differently to ordinary text inputs. (Having said all this, forms are one of the few web page elements that even zealous supporters of CSS design will sometimes revert to using a html table for, so I’d check with your front-end person first how they’d like the form marked up).

Now let’s all just get along!

I read somewhere the other week that jQuery is deprecating its jQuery.browser method, which means that in the future (though not yet, as the method still works but will not continue to be developed/supported, and will eventually be dropped) you will not be able to directly ask jQuery which browser it is being run in.

The rationale behind doing this is on the face of it sound: The reason you want to check what the browser is is that you want to check if a feature of javascript is available in that browser… so why not just ask if that feature is available, then the question of which browser it is becomes irrelevant. This will enable your script to continue to function (most probably) even in the unlikely event that eg Microsoft bring out a patch for ie6 that makes it fully support javascript.

But there is a flaw in this reasoning. It assumes that the only reason you would want to serve some different script to a browser is because of flaws in the browser’s javascript implementation, but in fact there are other reasons for doing this too, principally the browser’s failure to render CSS correctly.

While the new jQuery.support method does include tests for boxModel (ie6 and 7′s incorrect rendering of the CSS box model being the principle reason behind serving different CSS to different browsers) and one or two other CSS bugs, this simply isn’t up to the task. The box model is broken in ie6 and ie7, but broken in different ways, so normally to fix a layout bug I will want to serve different CSS to both.

Using various combinations of jQuery.support, eg

!jQuery.support.boxModel && jQuery.support.objectAll

you can still detect ie6 and ie7… but is this really an improvement on jQuery.browser?

jQuery.browser.msie && jQuery.browser.version.substr(0,1)=="6"

With jQuery.browser it is wholly transparent what you’re trying to detect, and if the code within the conditional’s braces contains a hefty amount of CSS rules your average developer should be able to work out the reason for the browser detection is to fix CSS bugs.

One other reason for explicitly detecting a browser (which I need at the moment as I’m developing a jQuery plugin) is that different browsers render form elements differently (the most obvious black sheep is safari’s making most elements look blue and glossy, but there are subtle differences in other browsers too). If I, say, want to fake a <select> element  by using a <ul>, and want it to look convincing in all browsers I need to supply each browser with differentiated CSS. jQuery.browser would be the obvious way to do this. No matter how many CSS bugs get fixed in browsers, how to render form elements by default isn’t specified by CSS/html, so there will always be this reason to want to detect browsers.

jQuery.browser is a very useful feature and it’ll be a shame when it goes.

The canal jungle
Will swamp and scour away
Man’s shallow footprint

I have always meant to read the American constitution. Now, thanks to www.usconstitution.net, I have fulfilled my ambition, and was underwhelmed.

I was always under the impression it was a classic of political literature, guided by Rousseau and inspired by Voltaire, but I’m afraid to say that it’s more of a classic of bureaucratic literature. Nearly all of it – including most of the amendments – concern themselves mainly with the internal machinations of the federal government. Not that this is a bad thing; I remember at the time of the rejection of the European constitution various political pundits opining ‘why couldn’t it be more like that classic of elegant state building, the American constitution’  (though I think it’s a bit idiotic to suggest that a constitution for how a number of complex, fully formed states in a modern world could be as simple as one drafted in a different age and for new states keen to break with the past).

So not that it’s a bad thing, but it really offers very little guidance if you want to learn about freedom, democracy and all the things America is supposed to embody. Indeed, all of the more ideological amendments – freedom of speech, right to bear arms etc.. – didn’t even apply at state level at first, and have only gradually made their punctuated way in to law that applies to everyone in any state (right to bear arms still hasn’t, and probably never will). The constitution was never really intended as something which spells out the relation of individuals to the state, but more about the relation of federal government to the individual states. The right to vote isn’t even included!

So that was an afternoon well-spent.

I should have mentioned this earlier.

For the benefit of people interested in me but not web development, or vice versa, I now offer several different RSS feeds, compartmentalising this blog’s posts into it’s overarching areas of interest. So you may wish to unsubscribe from this feed’s all things to all men content, and instead tune in to the area that really gets your pulse racing. Links to these virile sources of substandard prose and poesy can be found in the right hand column of the blog.

I’m reading Tricks of the Mind by Derren Brownat the moment, hence the overly flowery – some might say positively luscious – verbosity of this item.

A tattooed skinhead
Proclaims your identity
And deters muggers

Not content with making the download of their latest browser a maze in a labyrinth in a rabbit warren, Once you’ve downloaded it and want to report something wrong with it they once again fail (though in a more minor way).

For added security many sites ask you for the answer to a pertinent question only you will know the answer to. CPP mess this up in a big way, and so do Microsoft. The choices of question are as follows:

• Mother’s birthplace
  Why not go for maiden name. In most cases that is 100% known by the child, but birthplace…? I’m fairly sure I know what mine is, but then there are all sorts of permutations – would you enter the name of the town, or the hospital name, or the town and country if they were born overseas. How are you supposed to remember which permutation you used?
• Best childhood friend
  Let’s see, it was definitely Scott… although we did fall out for a bit, so maybe James. But then again I only knew him from when I was 11, so maybe Gareth…
• Name of first pet
  The only question in the list that cuts the mustard.
• Favourite teacher
  Similar to best childhood friend. In general having an opinion question as a security question is borderline idiotic (though I do see how it prevents people from working out your answer based on factual research), as opinions change. Asking your opinion on something way back in the past has the advantage of being more likely to be immune to day to day fluctuations, but could nevertheless be prone to drifting as your rose-tinted glasses warp slowly with time.
• Favourite historical person
  On the face of it seems to be immune to day to day fluctuations, but could be changed by as simple an act as reading a magazine article.
• Grandfather’s occupation
  Do they not realise that everybody has two grandfathers?

I suppose you could argue that for each person only one option has to be a plausible candidate, but my point is that unless you assume the person has very unshakable opinions about the past, only two of the above are reliable. Honestly!

Marking up web pages semantically is normally more or less a doddle. Most tags are named (or have abbreviated names) that are straightforward. If you’re writing a  paragraph, wrap it in a <p> tag. If you’re writing an ordered list put it in an <ol>… and so on and so forth. And it’s actually less effort than typing eg <div class=”list”>.

But there are nevertheless lots of examples where the tags offered by (x)html seem hopelessly limited in their semantic meaning. Recently I worked on this site. On the home page is a list of holiday offers, and I ummed and aahed over how to mark it up for a while. Previously I would always follow the same practice – lists of complex items would be marked up as a list, and whatever more complicated markup needed would be placed inside the <li> items. But I’ve read somewhere that putting too much information within a list item can actually be a hindrance to accessibility,  so this time things would be different.

Design of list of holiday packages

The design superficially lent itself to a simple nested list:

<ul>
  <li><h3>Blue Reef Resort</h3>
     <ul>
        <li>All inclusive</li>
        <li>8, 15 dagen</li>
        <li>Marsa Alam</li>
        ...
     </ul>
  </li>
</ul>

But it’s hardly satisfactory. The items in the sub-list are in fact properties of the particular holiday offer. In fact, the whole thing is more like a table, which becomes clear if we just move some bits around.

Modified design to show true semantic structure

So to achieve the required design all we need is to hide the table header and move some of the cells around. The first task is easily completed with a display:none, but the second is alas not very feasible. While support for floating and positioning table, tr and td elements is supported in ie8 and other good browsers, in ie6 and ie7 there are big problems as they more or less ignore that the <tr> element is there. You can’t float a tr, you can’t give it position:relative (in order to absolutely position td’s within it) but, bizarrely, you can absolutely position a tr, though this is of limited use. Racking my brains for a use the only one I’ve come up with is in order to give you the ability to absolutely position the tr’s td’s absolutely in relation to the tr, but then you would need a different style for each tr to avoid them layering on top of each other. Which admiteddly could be generated dynamically as an inline style, so perhaps not all that hopeless a situation.

ie6 and ie7 also don’t support floating on table cells either, in case you were thinking that was an option.

As it turns out, I may have discovered a new bug in Internet Explorer 8. While writing this I set up a test page to make sure what I thought was the case was correct (turns out I was, in my main thesis, incorrect, as I thought HTML/CSS had no provision for positioning table elements). Here are 3 screenshots:

Correctly positioned table elements (firefox)

Incorrect table element positioning (ie8)

Incorrect table positioning (ie6/7)

Once again, ie has problems dealing with relative positioning on tr’s. On the face of it it’s not as bad in ie8 as in ie6/7, but what’s happening is that instead of letting the tr’s confuse the positioning completely, it just ignores them, and goes ahead and positions relative to the next positioned ancestor, which is een worse if you look at where the cells get put relative to where they shoudl be – ie6 and ie7 nearly get it right (but this might be a fluke that a larger table would unmask), but ie8 is completely wrong.

The long and short of this article is that there are lots of instances where a table should be the natural choice of markup (given a little thought about what the content’s structure is), but once again thanks to Internet explorer, it’s going to have to be a nice idea that will have to be shelved for the time being.

So, unless you fancy individually positioning each tr with its own style rule, nested lists it is for now.

I mentioned the other day I hadn’t experimented with alternate tunings for playing Irish guitar, Well, all that has now changed, and I am sold on DADGAD tuning. Yes, you can pretty much only play things in the key of D, but then again, who cares when it sounds so lucious. And as you barely need to use any fingers to play a chord you can free your hands up to do some nice intricate twanging jangly stuff.

Below is the result of me playing around for a bit, trying to emulate to some degree the wonderful picking of Steve Baughman. That’s the other great thing about the tuning – it really is easy to play something passable.

Audio clip: Adobe Flash Player (version 9 or above) is required to play this audio clip. Download the latest version here. You also need to have JavaScript enabled in your browser.

The swirling sea fakes
The imprint of a giant
Limpet on a rock